On Sun, 16 Jan 2005, Henrique de Moraes Holschuh wrote: > Tracked down to 033-rlimit_memlock_check.dpatch. I did not check whether > 034-stack_resize_exploit.dpatch also causes problems, since it does not > apply without 033.
Curiously enough, something IS setting a 32kbyte limit on locked memory even on the emergency shell (i.e. these limits are active during the early boot sequence). That caused the segfault, as the above patches were enforcing that limit. I am pretty sure I have not asked for such a draconian limit anywhere (and all greps I could think of seem to agree with me) -- and such a limit is cleary something we would be better off without at the early boot sequence. I will see if I can track down the culprit to make sure it is something stupid *I* did, as opposed to something higly stupid sysv-init or the kernel itself is doing, and file bugs accordingly depending on what I find. Anyway, apparently such limit enforcement is considered a bug (regardless of the fact that there should be no limit to be enforced in the first place), and Herbert Xu sent me a patch that fixes the issue. Thanks, Herbert! Maybe that patch should make it to the SVN tree? PS: Herbert, my provider seems to have screwed up again, and my static IP is being blacklisted by your server, so my replies to you were probably discarded. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
