> > See original stack back trace below and Andreas' patch and analysis
> > here:
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0410.3/1844.html
I probably should add that with "original" stack back trace a trace of
a 2.6.10 kernel was meant, if that wasn't clear, but the DM code is
still the same in 2.6.14.
> > <4>Call Trace:
...
> > <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
...
This part of the call trace is actually good for >1500 bytes of stack
usage and is what kills us and should be fixed.
I'm surprised that there are no other bug reports regarding DM and
stack overflow with 4k stacks.
> 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.
Yes, you're right. Just forget the do_mount() patch. It's the wrong approach.
Heiko
-
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]
