From: Alex Riesen <Alexander.Riesen@synopsys.com>
To: Mihai RUSU <dizzy@roedu.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: mmap, SIGBUS, and handling it
Date: Sat, 11 May 2002 15:27:38 +0200 [thread overview]
Message-ID: <20020511132738.GA22916@riesen-pc.gr05.synopsys.com> (raw)
In-Reply-To: <20020510.083050.55863714.davem@redhat.com> <Pine.LNX.4.33.0205101900090.9661-100000@ahriman.bucharest.roedu.net>
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
next prev parent reply other threads:[~2002-05-11 13:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-10 15:37 Mihai RUSU
2002-05-10 15:30 ` David S. Miller
2002-05-10 15:53 ` Maciej W. Rozycki
2002-05-10 15:47 ` David S. Miller
2002-05-10 17:03 ` Maciej W. Rozycki
2002-05-10 16:56 ` David S. Miller
2002-05-10 19:54 ` Maciej W. Rozycki
2002-05-10 15:56 ` Dave Gilbert (Home)
2002-05-10 15:48 ` David S. Miller
2002-05-10 16:04 ` Mihai RUSU
2002-05-11 13:27 ` Alex Riesen [this message]
2002-05-10 16:27 ` Alan Cox
2002-05-10 16:40 ` Mihai RUSU
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020511132738.GA22916@riesen-pc.gr05.synopsys.com \
--to=alexander.riesen@synopsys.com \
--cc=dizzy@roedu.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®