Valdis.Kletnieks@xxxxxx writes: > [...] > Some paths in the kernel get very deep stacks (for instance, nfs reading > an xfs file that's on an lvm partition on a dm-crypt target is famous for > blowing the stack without any further help). On my laptop, the low-water > mark is already pretty low: > > % dmesg | grep 'stack depth' > [ 2.094319] cryptomgr_test (42) used greatest stack depth: 6456 bytes left > [...] > [ 145.528777] dhclient (1306) used greatest stack depth: 4072 bytes left > [ 226.188576] ip (2232) used greatest stack depth: 3344 bytes left > [ 300.303981] ip (2468) used greatest stack depth: 3152 bytes left > > So in the first 5 minutes, I already was down to 3K of stack. All it takes > is that code interacting with another code that allocates 1K popping when I > was at that 3K low water mark, and my kernel is in deep juju. Note that the kernel stack is not a monotonically exhausted resource. Each task has its own. It's freed up gradually as internal functions return, and fully as control returns to the user thread. The reported numbers decrease monotonically only to show "worst-case-until-now". It's not "only this much space remains, reboot soon" kind of thing. - FChE _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
