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:
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?
At Tue, 27 Jan 2015 14:08:04 +0100,
Dimstar / Dominique Leuenberger wrote:
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
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).
Author: Linus Torvalds <torvalds(a)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
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
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
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:
Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org>
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org