Re: mmap, SIGBUS, and handling it

Re: mmap, SIGBUS, and handling it

[David S. Miller]

   From: Mihai RUSU <dizzy@roedu.net>
   Date: Fri, 10 May 2002 18:37:21 +0300 (EEST)
   
   PS: why signal(SIGBUS,SIG_IGN) doesnt work, but a user handler its called
   if set with signal(SIGBUS,handle_sigbus) ?

How would you like the kernel to "ignore" a page fault that cannot be
serviced?

mmap, SIGBUS, and handling it

[Mihai RUSU]

Hi

One change in kernel 2.4.x is to send a SIGBUS signal to the process
trying to read a mmap section that is invalid.

Ex, if we have a file server, and that program gets a request for a file,
it does a mmap. After that starts serving the file to the client (by
write()-ing to the socket fd). If in the meantime some other process
truncates the file which was mmap-ed , our program will receive a SIGBUS
in write().

If I understand right this is more POSIX compliant.

Is there a clean/good way of handling this ?

PS: why signal(SIGBUS,SIG_IGN) doesnt work, but a user handler its called
if set with signal(SIGBUS,handle_sigbus) ?

Thanks

----------------------------
Mihai RUSU

Disclaimer: Any views or opinions presented within this e-mail are solely
those of the author and do not necessarily represent those of any company,
unless otherwise specifically stated.

Re: mmap, SIGBUS, and handling it

[David S. Miller]

   From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
   Date: Fri, 10 May 2002 17:53:21 +0200 (MET DST)

   On Fri, 10 May 2002, David S. Miller wrote:
   
   > How would you like the kernel to "ignore" a page fault that cannot be
   > serviced?
   
    I would expect it to return from the handler with no action, possibly
   re-executing the faulting instruction (if the reason was synchronous) and
   causing an infinite loop.  For consistency, whether it makes sense, or not
   (ditto for SIGSEGV, etc.). 

If we reexecute the instruction it will take the signal endlessly,
forever.  That makes no sense.

Next, if we skip the instruation, what should be in the destination
register of the load?  There is no reasonable answer.  If you put
zero there the program will likely segfault on a NULL pointer
dereference.

So my original point I was trying to make, which still stands, is that
what is being requested is totally rediculious behavior, trying to
ignore a page fault that can't be serviced.

Re: mmap, SIGBUS, and handling it

[David S. Miller]

   From: "Dave Gilbert (Home)" <gilbertd@treblig.org>
   Date: Fri, 10 May 2002 16:56:03 +0100

   David S. Miller wrote:
   > How would you like the kernel to "ignore" a page fault that cannot be
   > serviced?
   
   Well imagining you really wanted to do it you could skip a store 
   instruction or put a dummy value in the register that something is being 
   loaded into.

What is a suitable dummy value?  Zero?  That would likely lead to a
segfault if the value being loaded is supposed to be some pointer.

There is no reasonable behavior other than to kill the process if it
has not specified it's own handler.

Re: mmap, SIGBUS, and handling it

[Maciej W. Rozycki]

On Fri, 10 May 2002, David S. Miller wrote:

>    PS: why signal(SIGBUS,SIG_IGN) doesnt work, but a user handler its called
>    if set with signal(SIGBUS,handle_sigbus) ?
> 
> How would you like the kernel to "ignore" a page fault that cannot be
> serviced?

 I would expect it to return from the handler with no action, possibly
re-executing the faulting instruction (if the reason was synchronous) and
causing an infinite loop.  For consistency, whether it makes sense, or not
(ditto for SIGSEGV, etc.). 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: mmap, SIGBUS, and handling it

[Dave Gilbert (Home)]

David S. Miller wrote:
>    From: Mihai RUSU <dizzy@roedu.net>
>    Date: Fri, 10 May 2002 18:37:21 +0300 (EEST)
>    
>    PS: why signal(SIGBUS,SIG_IGN) doesnt work, but a user handler its called
>    if set with signal(SIGBUS,handle_sigbus) ?
> 
> How would you like the kernel to "ignore" a page fault that cannot be
> serviced?

Well imagining you really wanted to do it you could skip a store 
instruction or put a dummy value in the register that something is being 
loaded into.

Dave

Re: mmap, SIGBUS, and handling it

[Mihai RUSU]

On Fri, 10 May 2002, David S. Miller wrote:

>    From: Mihai RUSU <dizzy@roedu.net>
>    Date: Fri, 10 May 2002 18:37:21 +0300 (EEST)
>
>    PS: why signal(SIGBUS,SIG_IGN) doesnt work, but a user handler its called
>    if set with signal(SIGBUS,handle_sigbus) ?
>
> How would you like the kernel to "ignore" a page fault that cannot be
> serviced?
>

You are right, its not that I want to ignore it. The problem was that I
want to handle it some way but I dont know how. If I will make a user
handler for it how can I know if its a SIGBUS from a HW error or a SIGBUS
from that write()-case. Because I have to continue serving files even
after received a SIGBUS in that write (otherwise my file server will exit
with SIGBUS and thats no good :) ).

Take for example any single process ftp/http server, they are hit by this
problem. Which solution would you recommend ? :)

----------------------------
Mihai RUSU

Disclaimer: Any views or opinions presented within this e-mail are solely
those of the author and do not necessarily represent those of any company,
unless otherwise specifically stated.

Re: mmap, SIGBUS, and handling it

[Alan Cox]

> truncates the file which was mmap-ed , our program will receive a SIGBUS
> in write().
> 
> If I understand right this is more POSIX compliant.
> 
> Is there a clean/good way of handling this ?

sigsetjmp/siglongjmp

Re: mmap, SIGBUS, and handling it

[Mihai RUSU]

Hello again,

Thanks for all the answers and help.

On Fri, 10 May 2002, Alan Cox wrote:

> > truncates the file which was mmap-ed , our program will receive a SIGBUS
> > in write().
> >
> > If I understand right this is more POSIX compliant.
> >
> > Is there a clean/good way of handling this ?
>
> sigsetjmp/siglongjmp
>
>

----------------------------
Mihai RUSU

Disclaimer: Any views or opinions presented within this e-mail are solely
those of the author and do not necessarily represent those of any company,
unless otherwise specifically stated.

Re: mmap, SIGBUS, and handling it

[David S. Miller]

   From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
   Date: Fri, 10 May 2002 19:03:19 +0200 (MET DST)

   On Fri, 10 May 2002, David S. Miller wrote:
   
   > If we reexecute the instruction it will take the signal endlessly,
   > forever.  That makes no sense.
   
    It depends on an application.  It certainly shouldn't be the default, but
   a user may choose such an option for some reason.  E.g. for debugging a
   system with an ICE or a similar tool.
   
He's talking about how SIG_IGN should behave.

If you want non-default behavior, specify a signal handler instead
of SIG_IGN.
   
   > So my original point I was trying to make, which still stands, is that
   > what is being requested is totally rediculious behavior, trying to
   > ignore a page fault that can't be serviced.
   
    Why should we enforce policy on a user?  If one wants to ignore such
   signals for whatever reason, let him do that. 
   
We don't specify any policy other than the behavior of SIG_IGN which
is to kill off the process for SIGBUS.

If you specify a handler you can have SIGBUS do whatever you want it
to.  There are no enforced limitations, only a specified behavior
for SIG_IGN when used for SIGBUS.

The original poster has solved his problem, yet you continue to argue
one and on and on.

Re: mmap, SIGBUS, and handling it

[Maciej W. Rozycki]

On Fri, 10 May 2002, David S. Miller wrote:

>     I would expect it to return from the handler with no action, possibly
>    re-executing the faulting instruction (if the reason was synchronous) and
>    causing an infinite loop.  For consistency, whether it makes sense, or not
>    (ditto for SIGSEGV, etc.). 
> 
> If we reexecute the instruction it will take the signal endlessly,
> forever.  That makes no sense.

 It depends on an application.  It certainly shouldn't be the default, but
a user may choose such an option for some reason.  E.g. for debugging a
system with an ICE or a similar tool.

> Next, if we skip the instruation, what should be in the destination
> register of the load?  There is no reasonable answer.  If you put
> zero there the program will likely segfault on a NULL pointer
> dereference.

 This option is out of question, obviously.

> So my original point I was trying to make, which still stands, is that
> what is being requested is totally rediculious behavior, trying to
> ignore a page fault that can't be serviced.

 Why should we enforce policy on a user?  If one wants to ignore such
signals for whatever reason, let him do that. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: mmap, SIGBUS, and handling it

[Maciej W. Rozycki]

On Fri, 10 May 2002, David S. Miller wrote:

> He's talking about how SIG_IGN should behave.

 So do I.

> If you want non-default behavior, specify a signal handler instead
> of SIG_IGN.

 Well, SIG_IGN is non-default (user-specified) behavior -- SIG_DFL is. 

>     Why should we enforce policy on a user?  If one wants to ignore such
>    signals for whatever reason, let him do that. 
>    
> We don't specify any policy other than the behavior of SIG_IGN which
> is to kill off the process for SIGBUS.

 Making a special exception to well-defined semantics because it seems
less useful for a certain case is policy.  SIG_IGN means to ignore a
signal (except from SIGKILL, SIGSTOP, SIGCONT signals that cannot be
ignored, but that's a result of how they work and it is explicitly
specified in standards) -- everything else is unexpected semantics. 

> If you specify a handler you can have SIGBUS do whatever you want it
> to.  There are no enforced limitations, only a specified behavior
> for SIG_IGN when used for SIGBUS.
> 
> The original poster has solved his problem, yet you continue to argue
> one and on and on.

 s/argue/discuss/

 Anyway, since the code seems to work like I describe/expect, there is
really no problem for me.  Haven't you meant SIG_DFL, actually? 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: mmap, SIGBUS, and handling it

[Alex Riesen]

On Fri, May 10, 2002 at 07:04:36PM +0300, Mihai RUSU wrote:
> On Fri, 10 May 2002, David S. Miller wrote:
> 
> >    From: Mihai RUSU <dizzy@roedu.net>
> >    Date: Fri, 10 May 2002 18:37:21 +0300 (EEST)
> >
> >    PS: why signal(SIGBUS,SIG_IGN) doesnt work, but a user handler its called
> >    if set with signal(SIGBUS,handle_sigbus) ?
> >
> > How would you like the kernel to "ignore" a page fault that cannot be
> > serviced?
> >
> 
> You are right, its not that I want to ignore it. The problem was that I
> want to handle it some way but I dont know how. If I will make a user
> handler for it how can I know if its a SIGBUS from a HW error or a SIGBUS
> from that write()-case. Because I have to continue serving files even
> after received a SIGBUS in that write (otherwise my file server will exit
> with SIGBUS and thats no good :) ).
> 
> Take for example any single process ftp/http server, they are hit by this
> problem. Which solution would you recommend ? :)
> 

Just take a closer look on sigaction(2). The field sa_sigaction and
flags SA_SIGINFO in sa_flags can help to identify the source of the
SIGBUS.

SIGACTION(2)        Linux Programmer's Manual        SIGACTION(2)
...
       the  sender  of  the  POSIX.1b  signal.   SIGILL,  SIGFPE,
       SIGSEGV and SIGBUS fill in si_addr with the address of the
       fault.  SIGPOLL fills in si_band and si_fd.
...
       si_code indicates why this  signal  was  sent.   It  is  a
       value,  not  a bitmask.  The values which are possible for
       any signal are listed in this table:
...
       |                  SIGBUS                    |
       +-----------+--------------------------------+
       |BUS_ADRALN | invalid address alignment      |
       +-----------+--------------------------------+
       |BUS_ADRERR | non-existent physical address  |
       +-----------+--------------------------------+
       |BUS_OBJERR | object specific hardware error |


-alex