libsigsegv build fail with kernel 3.18.3

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

libsigsegv build fail with kernel 3.18.3

Dominique Leuenberger / DimStar
Dear Kernel hackers,

We're having an interesting case that needs urgent diagnosis in Factory
(as it's a ring-1 package, it blocks anything else from entering, as the
staging areas all show the same issue).

The issue: libsigsegv fails the test suite since the kernel has been
updated to 3.18.3 (before we had 3.18.1).

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).

Are you aware of or can think of any change in the kernel that would
cause this to happen?

Or is the error the stackoverflow sample tries to catch, simply no
longer meant to be caught by a sigsegv?

One of the tests failing is the code to be found at
http://git.savannah.gnu.org/cgit/libsigsegv.git/tree/tests/stackoverflow1.c

Thanks a lot for your help!

Dominique

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Michal Marek
On 2015-01-27 13:24, Dimstar / Dominique Leuenberger wrote:

> Dear Kernel hackers,
>
> We're having an interesting case that needs urgent diagnosis in Factory
> (as it's a ring-1 package, it blocks anything else from entering, as the
> staging areas all show the same issue).
>
> The issue: libsigsegv fails the test suite since the kernel has been
> updated to 3.18.3 (before we had 3.18.1).
>
> 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).
>
> Are you aware of or can think of any change in the kernel that would
> cause this to happen?

This is probably commit fee7e49d (mm: propagate error from stack
expansion even for guard page).


> Or is the error the stackoverflow sample tries to catch, simply no
> longer meant to be caught by a sigsegv?

I'm affraid it's either undefined behavior or the implementation is free
to kill the process with whatever signal it wants :-/.

Michal
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Jan Engelhardt-4

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 <[hidden email]>
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:

        """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).
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Dominique Leuenberger / DimStar
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 <[hidden email]>
> 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 <[hidden email]>

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Andreas Schwab-2
Dimstar / Dominique Leuenberger <[hidden email]> writes:

> 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.

If libsigsegv can no longer detect stack overflow it becomes pointless.

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Jan Engelhardt-4
On Tuesday 2015-01-27 14:20, Andreas Schwab wrote:

>Dimstar / Dominique Leuenberger <[hidden email]> writes:
>
>> 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.
>
>If libsigsegv can no longer detect stack overflow it becomes pointless.

Well no, it can still react to writes to unmapped regions.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Dominique Leuenberger / DimStar
In reply to this post by Andreas Schwab-2
On Tue, 2015-01-27 at 14:20 +0100, Andreas Schwab wrote:
> Dimstar / Dominique Leuenberger <[hidden email]> writes:
>
> > 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.
>
> If libsigsegv can no longer detect stack overflow it becomes pointless.

I  looked a bit deeper in its code... seems there are similar such
things already done for Mac-OS and other platforms (hurd, Macos, ...)

I patched signals.h to have it handle SIGBUS the same way as it does for
those platforms now... first tests build already again.

--
Dimstar / Dominique Leuenberger <[hidden email]>

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Andreas Schwab-2
In reply to this post by Jan Engelhardt-4
Jan Engelhardt <[hidden email]> writes:

> On Tuesday 2015-01-27 14:20, Andreas Schwab wrote:
>
>>Dimstar / Dominique Leuenberger <[hidden email]> writes:
>>
>>> 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.
>>
>>If libsigsegv can no longer detect stack overflow it becomes pointless.
>
> Well no, it can still react to writes to unmapped regions.

Stack overflows are its main use case.

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Yamaban
In reply to this post by Dominique Leuenberger / DimStar
On Tue, 27 Jan 2015 14:08, Dimstar / Dominique Leuenberger <dimstar@...> 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 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 <[hidden email]>
>> 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?

Due to the patch mentioned above the stack breaking the segment is
caught BEFORE it happens, thus SIGBUS, so no more SIGSEGV that way.

Either libsigsegv is modified to handle SIGBUS for Kernel >=3.18.3
the same as SIGSEGV, or raise the question upstream why those
projects depend on libsigsegv at all.

For me the pure 'need' to use libsigsegv in a project beyond testing
is cause for rised hackles and premotions of BAD coding.

Either way, here is upstream in question.
  - libsigsegv to handle SIGBUS for kernel >= 3.18.3
  - the dependend projects to eliminate need for
    libsigsegv at all.

For us here? - SIGBUS hack is the fasted way to go forward ATM.

  - Yamaban.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Andreas Schwab-2
Yamaban <[hidden email]> writes:

> For me the pure 'need' to use libsigsegv in a project beyond testing
> is cause for rised hackles and premotions of BAD coding.

The point of libsigsegv is to handle stack overflows gracefully, instead
of just crashing.

> Either way, here is upstream in question.
>  - libsigsegv to handle SIGBUS for kernel >= 3.18.3
>  - the dependend projects to eliminate need for
>    libsigsegv at all.
   - the kernel to eliminate a regression (tell Linus and he will agree
     violently)

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Takashi Iwai
In reply to this post by Dominique Leuenberger / DimStar
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 <[hidden email]>
> > 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 <[hidden email]>
>
> --
> To unsubscribe, e-mail: [hidden email]
> To contact the owner, e-mail: [hidden email]
>
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Linus Torvalds
On Tue, Jan 27, 2015 at 11:32 AM, Takashi Iwai <[hidden email]> wrote:
>
> the commit [320b2b8de126: mm: keep a guard page below a grow-down
> stack segment] seems resulting in a regression with libsigsegv.
>
> 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.

Yeah, no, that's obviously a kernel regression and needs to be fixed,
even if no sane program should care about SIGSEGV vs SIGBUS. But "sane
program" is irrelevant for the regression rule - somebody noticed.

The only reason it returns SIGBUS is that we don't have an equivalent
VM_FAULT_SIGSEGV error return.  Which is something of an oversight,
but adding it is a pain too, simply because the callers are mainly the
architecture page fault handlers, so the VM_FAULT_SIGSEGV handling has
to be added to all of them.

Very annoying. The patch would look something like the attached -
TOTALLY UNTESTED.

Does this fix things for you?

                               Linus

patch.diff (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Takashi Iwai
At Tue, 27 Jan 2015 12:36:38 -0800,
Linus Torvalds wrote:

>
> On Tue, Jan 27, 2015 at 11:32 AM, Takashi Iwai <[hidden email]> wrote:
> >
> > the commit [320b2b8de126: mm: keep a guard page below a grow-down
> > stack segment] seems resulting in a regression with libsigsegv.
> >
> > 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.
>
> Yeah, no, that's obviously a kernel regression and needs to be fixed,
> even if no sane program should care about SIGSEGV vs SIGBUS. But "sane
> program" is irrelevant for the regression rule - somebody noticed.

Oh yeah, I meant kernel regression, too, sorry for confusion.
(Maybe I chose the wrong word unconsciously as a kernel hacker ;)

> The only reason it returns SIGBUS is that we don't have an equivalent
> VM_FAULT_SIGSEGV error return.  Which is something of an oversight,
> but adding it is a pain too, simply because the callers are mainly the
> architecture page fault handlers, so the VM_FAULT_SIGSEGV handling has
> to be added to all of them.
>
> Very annoying. The patch would look something like the attached -
> TOTALLY UNTESTED.
>
> Does this fix things for you?

Unfortunately it doesn't seem to work.  I compiled and test quickly,
but two of five test still gives SIGBUS (stackoverflow1 and
stackoverflow2).

FYI, I'm testing libsigsegv-2.10, that can be downloaded:
  http://www.gnu.org/software/libsigsegv/#Download

and just make, make check.  It should be easily testable on your
machine, too.


thanks,

Takashi

>
>                                Linus
>  arch/alpha/mm/fault.c         | 2 ++
>  arch/arc/mm/fault.c           | 2 ++
>  arch/avr32/mm/fault.c         | 2 ++
>  arch/cris/mm/fault.c          | 2 ++
>  arch/frv/mm/fault.c           | 2 ++
>  arch/ia64/mm/fault.c          | 2 ++
>  arch/m32r/mm/fault.c          | 2 ++
>  arch/m68k/mm/fault.c          | 2 ++
>  arch/metag/mm/fault.c         | 2 ++
>  arch/microblaze/mm/fault.c    | 2 ++
>  arch/mips/mm/fault.c          | 2 ++
>  arch/mn10300/mm/fault.c       | 2 ++
>  arch/nios2/mm/fault.c         | 2 ++
>  arch/openrisc/mm/fault.c      | 2 ++
>  arch/parisc/mm/fault.c        | 2 ++
>  arch/powerpc/mm/copro_fault.c | 3 +++
>  arch/powerpc/mm/fault.c       | 2 ++
>  arch/s390/mm/fault.c          | 6 ++++++
>  arch/score/mm/fault.c         | 2 ++
>  arch/sh/mm/fault.c            | 2 ++
>  arch/sparc/mm/fault_32.c      | 2 ++
>  arch/sparc/mm/fault_64.c      | 2 ++
>  arch/tile/mm/fault.c          | 2 ++
>  arch/um/kernel/trap.c         | 2 ++
>  arch/x86/mm/fault.c           | 2 ++
>  arch/xtensa/mm/fault.c        | 2 ++
>  include/linux/mm.h            | 6 ++++--
>  27 files changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
> index 98838a05ba6d..9d0ac091a52a 100644
> --- a/arch/alpha/mm/fault.c
> +++ b/arch/alpha/mm/fault.c
> @@ -156,6 +156,8 @@ retry:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
> index 6f7e3a68803a..0f8df3b5b1b3 100644
> --- a/arch/arc/mm/fault.c
> +++ b/arch/arc/mm/fault.c
> @@ -161,6 +161,8 @@ good_area:
>  
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>  
> diff --git a/arch/avr32/mm/fault.c b/arch/avr32/mm/fault.c
> index 0eca93327195..d223a8b57c1e 100644
> --- a/arch/avr32/mm/fault.c
> +++ b/arch/avr32/mm/fault.c
> @@ -142,6 +142,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/cris/mm/fault.c b/arch/cris/mm/fault.c
> index 1790f22e71a2..2686a7aa8ec8 100644
> --- a/arch/cris/mm/fault.c
> +++ b/arch/cris/mm/fault.c
> @@ -176,6 +176,8 @@ retry:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/frv/mm/fault.c b/arch/frv/mm/fault.c
> index 9a66372fc7c7..ec4917ddf678 100644
> --- a/arch/frv/mm/fault.c
> +++ b/arch/frv/mm/fault.c
> @@ -168,6 +168,8 @@ asmlinkage void do_page_fault(int datammu, unsigned long esr0, unsigned long ear
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/ia64/mm/fault.c b/arch/ia64/mm/fault.c
> index 7225dad87094..ba5ba7accd0d 100644
> --- a/arch/ia64/mm/fault.c
> +++ b/arch/ia64/mm/fault.c
> @@ -172,6 +172,8 @@ retry:
>   */
>   if (fault & VM_FAULT_OOM) {
>   goto out_of_memory;
> + } else if (fault & VM_FAULT_SIGSEGV) {
> + goto bad_area;
>   } else if (fault & VM_FAULT_SIGBUS) {
>   signal = SIGBUS;
>   goto bad_area;
> diff --git a/arch/m32r/mm/fault.c b/arch/m32r/mm/fault.c
> index e9c6a8014bd6..e3d4d4890104 100644
> --- a/arch/m32r/mm/fault.c
> +++ b/arch/m32r/mm/fault.c
> @@ -200,6 +200,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/m68k/mm/fault.c b/arch/m68k/mm/fault.c
> index 2bd7487440c4..b2f04aee46ec 100644
> --- a/arch/m68k/mm/fault.c
> +++ b/arch/m68k/mm/fault.c
> @@ -145,6 +145,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto map_err;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto bus_err;
>   BUG();
> diff --git a/arch/metag/mm/fault.c b/arch/metag/mm/fault.c
> index 332680e5ebf2..2de5dc695a87 100644
> --- a/arch/metag/mm/fault.c
> +++ b/arch/metag/mm/fault.c
> @@ -141,6 +141,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/microblaze/mm/fault.c b/arch/microblaze/mm/fault.c
> index fa4cf52aa7a6..d46a5ebb7570 100644
> --- a/arch/microblaze/mm/fault.c
> +++ b/arch/microblaze/mm/fault.c
> @@ -224,6 +224,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
> index becc42bb1849..70ab5d664332 100644
> --- a/arch/mips/mm/fault.c
> +++ b/arch/mips/mm/fault.c
> @@ -158,6 +158,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/mn10300/mm/fault.c b/arch/mn10300/mm/fault.c
> index 3516cbdf1ee9..0c2cc5d39c8e 100644
> --- a/arch/mn10300/mm/fault.c
> +++ b/arch/mn10300/mm/fault.c
> @@ -262,6 +262,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/nios2/mm/fault.c b/arch/nios2/mm/fault.c
> index 15a0bb5fc06d..34429d5a0ccd 100644
> --- a/arch/nios2/mm/fault.c
> +++ b/arch/nios2/mm/fault.c
> @@ -135,6 +135,8 @@ survive:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/openrisc/mm/fault.c b/arch/openrisc/mm/fault.c
> index 0703acf7d327..0a0c5fa1a64f 100644
> --- a/arch/openrisc/mm/fault.c
> +++ b/arch/openrisc/mm/fault.c
> @@ -171,6 +171,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (faulr & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
> index 3ca9c1131cfe..e5120e653240 100644
> --- a/arch/parisc/mm/fault.c
> +++ b/arch/parisc/mm/fault.c
> @@ -256,6 +256,8 @@ good_area:
>   */
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto bad_area;
>   BUG();
> diff --git a/arch/powerpc/mm/copro_fault.c b/arch/powerpc/mm/copro_fault.c
> index 5a236f082c78..094b7d445023 100644
> --- a/arch/powerpc/mm/copro_fault.c
> +++ b/arch/powerpc/mm/copro_fault.c
> @@ -79,6 +79,9 @@ int copro_handle_mm_fault(struct mm_struct *mm, unsigned long ea,
>   } else if (*flt & VM_FAULT_SIGBUS) {
>   ret = -EFAULT;
>   goto out_unlock;
> + } else if (*flt & VM_FAULT_SIGBUS) {
> + ret = -EFAULT;
> + goto out_unlock;
>   }
>   BUG();
>   }
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index eb79907f34fa..6154b0a2b063 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -437,6 +437,8 @@ good_area:
>   */
>   fault = handle_mm_fault(mm, vma, address, flags);
>   if (unlikely(fault & (VM_FAULT_RETRY|VM_FAULT_ERROR))) {
> + if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   rc = mm_fault_error(regs, address, fault);
>   if (rc >= MM_FAULT_RETURN)
>   goto bail;
> diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
> index 811937bb90be..9065d5aa3932 100644
> --- a/arch/s390/mm/fault.c
> +++ b/arch/s390/mm/fault.c
> @@ -374,6 +374,12 @@ static noinline void do_fault_error(struct pt_regs *regs, int fault)
>   do_no_context(regs);
>   else
>   pagefault_out_of_memory();
> + } else if (fault & VM_FAULT_SIGSEGV) {
> + /* Kernel mode? Handle exceptions or die */
> + if (!user_mode(regs))
> + do_no_context(regs);
> + else
> + do_sigsegv(regs, SEGV_MAPERR);
>   } else if (fault & VM_FAULT_SIGBUS) {
>   /* Kernel mode? Handle exceptions or die */
>   if (!user_mode(regs))
> diff --git a/arch/score/mm/fault.c b/arch/score/mm/fault.c
> index 52238983527d..6860beb2a280 100644
> --- a/arch/score/mm/fault.c
> +++ b/arch/score/mm/fault.c
> @@ -114,6 +114,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/sh/mm/fault.c b/arch/sh/mm/fault.c
> index 541dc6101508..a58fec9b55e0 100644
> --- a/arch/sh/mm/fault.c
> +++ b/arch/sh/mm/fault.c
> @@ -353,6 +353,8 @@ mm_fault_error(struct pt_regs *regs, unsigned long error_code,
>   } else {
>   if (fault & VM_FAULT_SIGBUS)
>   do_sigbus(regs, error_code, address);
> + else if (fault & VM_FAULT_SIGSEGV)
> + bad_area(regs, error_code, address);
>   else
>   BUG();
>   }
> diff --git a/arch/sparc/mm/fault_32.c b/arch/sparc/mm/fault_32.c
> index 908e8c17c902..70d817154fe8 100644
> --- a/arch/sparc/mm/fault_32.c
> +++ b/arch/sparc/mm/fault_32.c
> @@ -249,6 +249,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/sparc/mm/fault_64.c b/arch/sparc/mm/fault_64.c
> index 18fcd7167095..479823249429 100644
> --- a/arch/sparc/mm/fault_64.c
> +++ b/arch/sparc/mm/fault_64.c
> @@ -446,6 +446,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/tile/mm/fault.c b/arch/tile/mm/fault.c
> index 565e25a98334..0f61a73534e6 100644
> --- a/arch/tile/mm/fault.c
> +++ b/arch/tile/mm/fault.c
> @@ -442,6 +442,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c
> index 5678c3571e7c..209617302df8 100644
> --- a/arch/um/kernel/trap.c
> +++ b/arch/um/kernel/trap.c
> @@ -80,6 +80,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM) {
>   goto out_of_memory;
> + } else if (fault & VM_FAULT_SIGSEGV) {
> + goto out;
>   } else if (fault & VM_FAULT_SIGBUS) {
>   err = -EACCES;
>   goto out;
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 38dcec403b46..e3ff27a5b634 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -898,6 +898,8 @@ mm_fault_error(struct pt_regs *regs, unsigned long error_code,
>   if (fault & (VM_FAULT_SIGBUS|VM_FAULT_HWPOISON|
>       VM_FAULT_HWPOISON_LARGE))
>   do_sigbus(regs, error_code, address, fault);
> + else if (fault & VM_FAULT_SIGSEGV)
> + bad_area_nosemaphore(regs, error_code, address);
>   else
>   BUG();
>   }
> diff --git a/arch/xtensa/mm/fault.c b/arch/xtensa/mm/fault.c
> index b57c4f91f487..9e3571a6535c 100644
> --- a/arch/xtensa/mm/fault.c
> +++ b/arch/xtensa/mm/fault.c
> @@ -117,6 +117,8 @@ good_area:
>   if (unlikely(fault & VM_FAULT_ERROR)) {
>   if (fault & VM_FAULT_OOM)
>   goto out_of_memory;
> + else if (fault & VM_FAULT_SIGSEGV)
> + goto bad_area;
>   else if (fault & VM_FAULT_SIGBUS)
>   goto do_sigbus;
>   BUG();
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 80fc92a49649..dd5ea3016fc4 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1070,6 +1070,7 @@ static inline int page_mapped(struct page *page)
>  #define VM_FAULT_WRITE 0x0008 /* Special case for get_user_pages */
>  #define VM_FAULT_HWPOISON 0x0010 /* Hit poisoned small page */
>  #define VM_FAULT_HWPOISON_LARGE 0x0020  /* Hit poisoned large page. Index encoded in upper bits */
> +#define VM_FAULT_SIGSEGV 0x0040
>  
>  #define VM_FAULT_NOPAGE 0x0100 /* ->fault installed the pte, not return page */
>  #define VM_FAULT_LOCKED 0x0200 /* ->fault locked the returned page */
> @@ -1078,8 +1079,9 @@ static inline int page_mapped(struct page *page)
>  
>  #define VM_FAULT_HWPOISON_LARGE_MASK 0xf000 /* encodes hpage index for large hwpoison */
>  
> -#define VM_FAULT_ERROR (VM_FAULT_OOM | VM_FAULT_SIGBUS | VM_FAULT_HWPOISON | \
> - VM_FAULT_FALLBACK | VM_FAULT_HWPOISON_LARGE)
> +#define VM_FAULT_ERROR (VM_FAULT_OOM | VM_FAULT_SIGBUS | VM_FAULT_SIGSEGV | \
> + VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE | \
> + VM_FAULT_FALLBACK)
>  
>  /* Encode hstate index for a hwpoisoned large page */
>  #define VM_FAULT_SET_HINDEX(x) ((x) << 12)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Linus Torvalds
In reply to this post by Linus Torvalds
[ Adding 'linux-arch' to the recipients, since this touches pretty
much all architectures ]

Background for arch people: it seems that a few applications really
care about the difference between SIGSEGV and SIGBUS, but the generic
VM layer currently has no way to say "this access should generate a
SIGSEGV". We have that VM_FAULT_SIGBUS, but no equivalent
VM_FAULT_SIGSEGV.

So when the stack limit fix went in, I used VM_FAULT_SIGBUS, and a
couple of apps noticed that the stack rlimit violation changed from
SIGSEGV to SIGBUS as a result.

It's actually sad that this whole error handling is duplicated all
over every architecture, but oh well. This is a completely mindless
patch to add VM_FAULT_SIGSEGV.

Some architectures aren't affected, for the simple reason that they
already ended up returning SIGSEGV for non-SIGBUS errors. Most other
architectures had a BUG_ON() for the unrecognized case, and just need
a trivial "if (fault & VM_FAULT_SIGSEGV) goto bad_area;"

And then some architectures had a different pattern, and I tried to
fix it up as straightforwardly as possible, but I could easily have
screwed up.

Can people take a look?

On Tue, Jan 27, 2015 at 12:36 PM, Linus Torvalds
<[hidden email]> wrote:
>
> Very annoying. The patch would look something like the attached -
> TOTALLY UNTESTED.

Actually, I missed a couple of places in mm/gup.c and mm/ksm.c (and
one in lustre, although that one just uses filemap_fault, so it never
triggers the stack case, but for completeness).

So this would be the more complete patch. Still totally untested. I
may have screwed up something obvious.

                         Linus

patch.diff (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Linus Torvalds
In reply to this post by Takashi Iwai
On Tue, Jan 27, 2015 at 12:56 PM, Takashi Iwai <[hidden email]> wrote:
>
> Unfortunately it doesn't seem to work.  I compiled and test quickly,
> but two of five test still gives SIGBUS (stackoverflow1 and
> stackoverflow2).

Oh, I forgot to make it clear that the patch was _purely_ the
"infrastructure" patch to add support for VM_FAULT_SIGSEGV.

To actually make the stack guard page access failure give SIGSEGV,
you'd need to also then change that

        if (check_stack_guard_page(vma, address) < 0)
                return VM_FAULT_SIGBUS;

in mm/memory.c to actually use the new "VM_FAULT_SIGSEGV" thing.
Otherwise it will obviously continue to send SIGSBUS.

                           Linus
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Jan Engelhardt-4
In reply to this post by Linus Torvalds

On Tuesday 2015-01-27 21:36, Linus Torvalds wrote:

>The only reason it returns SIGBUS is that we don't have an equivalent
>VM_FAULT_SIGSEGV error return.  Which is something of an oversight,
>but adding it is a pain too, simply because the callers are mainly the
>architecture page fault handlers, so the VM_FAULT_SIGSEGV handling has
>to be added to all of them.
>
>Very annoying. The patch would look something like the attached -
>TOTALLY UNTESTED.
>
>Does this fix things for you?

The 2nd patch (from 12:57:20 -0800) plus the one-liner for mm/memory.c
at the callsite for check_stack_guard_page makes the test still
not succeed.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Linus Torvalds
On Tue, Jan 27, 2015 at 1:12 PM, Jan Engelhardt <[hidden email]> wrote:
>
> The 2nd patch (from 12:57:20 -0800) plus the one-liner for mm/memory.c
> at the callsite for check_stack_guard_page makes the test still
> not succeed.

Really? What platform? I get

  ==================
  All 5 tests passed
  ==================

with the patch I sent out, combined with this:

   diff --git a/mm/memory.c b/mm/memory.c
   index 54f3a9b00956..2c3536cc6c63 100644
   --- a/mm/memory.c
   +++ b/mm/memory.c
   @@ -2632,7 +2632,7 @@ static int do_anonymous_page(struct mm_struct
*mm, struct vm_area_struct *vma,

           /* Check if we need to add a guard page to the stack */
           if (check_stack_guard_page(vma, address) < 0)
   -               return VM_FAULT_SIGBUS;
   +               return VM_FAULT_SIGSEGV;

           /* Use the zero-page for reads */
           if (!(flags & FAULT_FLAG_WRITE) && !mm_forbids_zeropage(mm)) {

but since architecture matters, and I run on x86-64, some other
platform might still have issues.

(And yes, I checked that it failed without the patch, so I think I'm
testing the same thing you guys are)

                         Linus
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Takashi Iwai
In reply to this post by Linus Torvalds
At Tue, 27 Jan 2015 13:00:36 -0800,
Linus Torvalds wrote:

>
> On Tue, Jan 27, 2015 at 12:56 PM, Takashi Iwai <[hidden email]> wrote:
> >
> > Unfortunately it doesn't seem to work.  I compiled and test quickly,
> > but two of five test still gives SIGBUS (stackoverflow1 and
> > stackoverflow2).
>
> Oh, I forgot to make it clear that the patch was _purely_ the
> "infrastructure" patch to add support for VM_FAULT_SIGSEGV.
>
> To actually make the stack guard page access failure give SIGSEGV,
> you'd need to also then change that
>
>         if (check_stack_guard_page(vma, address) < 0)
>                 return VM_FAULT_SIGBUS;
>
> in mm/memory.c to actually use the new "VM_FAULT_SIGSEGV" thing.
> Otherwise it will obviously continue to send SIGSBUS.

OK, got it.  Now the result is positive. libsigsegv "make check"
passed all tests.  (tested with your second patch + this change)

Do you have a test case that should still generate SIGBUS, too?


Thanks!

Takashi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Linus Torvalds
On Tue, Jan 27, 2015 at 1:41 PM, Takashi Iwai <[hidden email]> wrote:
>
> Do you have a test case that should still generate SIGBUS, too?

Nope, but it should be easy to generate: doing a shared mmap() that is
larger than the file you're mmap'ing, and then trying to access a page
past the end of the file. That's the traditional way to get SIGBUS.

                     Linus
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

Takashi Iwai
At Tue, 27 Jan 2015 13:55:08 -0800,
Linus Torvalds wrote:
>
> On Tue, Jan 27, 2015 at 1:41 PM, Takashi Iwai <[hidden email]> wrote:
> >
> > Do you have a test case that should still generate SIGBUS, too?
>
> Nope, but it should be easy to generate: doing a shared mmap() that is
> larger than the file you're mmap'ing, and then trying to access a page
> past the end of the file. That's the traditional way to get SIGBUS.

Yeah, thanks.  I just misunderstood the patch as if there were still
cases with stack limit violation triggering SIGBUS.  Forget my
question above.  I need to go to bed...

In anyway, feel free to add my tested-by tag
  Tested-by: Takashi Iwai <[hidden email]>

I'll merge the patch into SUSE kernels for wider testing once when the
patch is finalized.


Thanks!

Takashi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12