Linus, the commit [320b2b8de126: mm: keep a guard page below a grow-down stack segment] seems resulting in a regression with libsigsegv. Looking at the change, it's pretty obvious why it breaks; libsigsegv expects SIGSEGV explicitly for the scenario the patch touches. (FWIW, a failing test code to be found at: http://git.savannah.gnu.org/cgit/libsigsegv.git/tree/tests/stackoverflow1.c ) This is a case giving us a dilemma. Of course, we can "fix" libsigsegv to handle SIGBUS gracefully. OTOH, this can be seen as a user-space regression we'd like to avoid usually. What do you think? thanks, Takashi At Tue, 27 Jan 2015 14:08:04 +0100, Dimstar / Dominique Leuenberger wrote:
Jan,
On Tue, 2015-01-27 at 13:58 +0100, Jan Engelhardt wrote:
On Tuesday 2015-01-27 13:40, Michal Marek wrote:
On 2015-01-27 13:24, Dimstar / Dominique Leuenberger wrote:
The test suite is intentionally 'badly written' and is supposed to cause sigsegv for various cases. The current tests failing are around stack overflows. Up to kernel 3.18.1, those reported SIGSEGV back, but it seems nowadays we get a SIGBUS (which is not in scope of a library called libSIGSEGV to be caught).
This is probably commit fee7e49d (mm: propagate error from stack expansion even for guard page).
Relatedly interesting:
commit 320b2b8de12698082609ebbc1a17165727f4c893 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Thu Aug 12 17:54:33 2010 -0700
mm: keep a guard page below a grow-down stack segment
This is a rather minimally invasive patch to solve the problem of the user stack growing into a memory mapped area below it. Whenever we fill the first page of the stack segment, expand the segment down by one page.
Now, admittedly some odd application might _want_ the stack to grow down into the preceding memory mapping, and so we may at some point need to make this a process tunable (some people might also want to have more than a single page of guarding), but let's try the minimal approach first.
Tested with trivial application that maps a single page just below the stack, and then starts recursing. Without this, we will get a SIGSEGV _after_ the stack has smashed the mapping. With this patch, we'll get a nice SIGBUS just as the stack touches the page just above the mapping.
Whether it ought to be SIGBUS or SIGSEGV, is perhaps a matter of debate. WP has to say about it:
That one sounds actually very much like the kernel changes this behavior intentionally and 100% conscious.
"""a process is trying to access memory that the CPU cannot physically address: an invalid address for the address bus, hence the name. [...] segmentation faults, which occur primarily due to memory access violations: problems in the logical address or permissions."""
The guard page, I would say, is an access violation protection, rather than something unadressable (like unaligned words on certain CPUs).
Indeed, semantics. Somebody should ask Linus about it :)
IF this is to remain SIGBUS, then I don't think it's (anymore) in scope of libsigsegv to catch it and offer a handler for it, in which case removing the test would be the logical step; but I don't know what all else we might break with that.
osc whatdependson gives me this short list: libsigsegv : cedilla clisp emacs-auctex maxima texlive wxMaxima xindy yodl
Thoughts anybody?
-- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org