Heiko Carstens <[email protected]> wrote:
>
> From: Andreas Herrmann <[email protected]>
>
> This is a resubmit of Andreas' patch that reduces stackframe usage in
> do_mount. Problem is that without this patch we get a kernel stack
> overflow if we run with 4k stacks (s390 31 bit mode).
> See original stack back trace below and Andreas' patch and analysis
> here:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0410.3/1844.html
>
> <4>Call Trace:
> <4>([<000000000014ade6>] buffered_rmqueue+0x36a/0x3b4)
> <4> [<000000000014aed6>] __alloc_pages+0xa6/0x350
> <4> [<000000000014b258>] __get_free_pages+0x38/0x74
> <4> [<000000000014f9fe>] kmem_getpages+0x32/0x140
> <4> [<0000000000150396>] cache_alloc_refill+0x3ae/0x58c
> <4> [<000000000014feb0>] __kmalloc+0xc0/0xe8
> <4> [<00000000002acc64>] zfcp_mempool_alloc+0x24/0x34
> <4> [<00000000001494ea>] mempool_alloc+0x56/0x1e8
> <4> [<00000000002bfb46>] zfcp_fsf_req_create+0x56/0x5d8
> <4> [<00000000002c0cf0>] zfcp_fsf_send_fcp_command_task+0x44/0x5c4
> <4> [<00000000002afbda>] zfcp_scsi_command_async+0x7a/0x1f8
> <4> [<00000000002afe68>] zfcp_scsi_queuecommand+0x44/0x54
> <4> [<000000000024f458>] scsi_dispatch_cmd+0x234/0x3c0
> <4> [<0000000000255fb2>] scsi_request_fn+0x2c6/0x67c
> <4> [<000000000023f3ea>] __generic_unplug_device+0x52/0x60
> <4> [<000000000023d392>] __elv_add_request+0x8a/0x98
> <4> [<0000000000240c5e>] __make_request+0x306/0x62c
> <4> [<0000000000241074>] generic_make_request+0xf0/0x21c
> <4> [<0000000010831380>] __map_bio+0x70/0x160 [dm_mod]
> <4> [<000000001083173e>] __split_bio+0x1e6/0x538 [dm_mod]
> <4> [<0000000010831ba8>] dm_request+0x118/0x25c [dm_mod]
> <4> [<0000000000241074>] generic_make_request+0xf0/0x21c
> <4> [<0000000010831380>] __map_bio+0x70/0x160 [dm_mod]
> <4> [<000000001083173e>] __split_bio+0x1e6/0x538 [dm_mod]
> <4> [<0000000010831ba8>] dm_request+0x118/0x25c [dm_mod]
> <4> [<0000000000241074>] generic_make_request+0xf0/0x21c
> <4> [<0000000010831380>] __map_bio+0x70/0x160 [dm_mod]
> <4> [<000000001083173e>] __split_bio+0x1e6/0x538 [dm_mod]
> <4> [<0000000010831ba8>] dm_request+0x118/0x25c [dm_mod]
> <4> [<0000000000241074>] generic_make_request+0xf0/0x21c
> <4> [<000000000024121a>] submit_bio+0x7a/0x154
> <4> [<00000000001736e6>] submit_bh+0x106/0x184
> <4> [<000000000017514e>] __block_write_full_page+0x23a/0x58c
> <4> [<000000000017558e>] block_write_full_page+0xee/0x108
> <4> [<000000000017a908>] blkdev_writepage+0x24/0x38
> <4> [<00000000001a0f76>] mpage_writepages+0x1da/0x9d0
> <4> [<000000000017a4fa>] generic_writepages+0x22/0x30
> <4> [<000000000014cc1e>] do_writepages+0x36/0x54
> <4> [<0000000000144fe2>] __filemap_fdatawrite+0x5a/0x6c
> <4> [<0000000000145016>] filemap_fdatawrite+0x22/0x30
> <4> [<0000000000171244>] sync_blockdev+0x30/0x5c
> <4> [<00000000001df074>] journal_recover+0x88/0xbc
> <4> [<00000000001e2876>] journal_load+0x52/0xcc
> <4> [<00000000001d37b4>] ext3_fill_super+0x1a48/0x1d38
> <4> [<0000000000179faa>] get_sb_bdev+0x13a/0x208
> <4> [<00000000001d3bd6>] ext3_get_sb+0x22/0x34
> <4> [<000000000017a32e>] do_kern_mount+0x86/0x1f4
> <4> [<000000000019aaf4>] do_mount+0x1c8/0x8e4
> <4> [<000000000019b7ba>] sys_mount+0xce/0x1dc
> <4> [<000000000010f9a6>] sysc_do_restart+0xe/0x12
I'd call that a device mapper bug. If you were to increase the stacking
from 4-deep to 5-deep, it will crash the kernel, patched or not.
I'm (very) surprised that DM doesn't perform its stacking iteratively.
Eliminating the 36-byte `struct clone_info' in __split_bio() would be most
effective here.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
