|
Home > Archive > Unix Programming > March 2007 > POSIX spec about SIGKILL or etc
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
POSIX spec about SIGKILL or etc
|
|
| Bin Chen 2007-03-16, 7:28 am |
| Is there any POSIX spec for SIGKILL signal handler in kernel space? As
the application can't catch this signal, so there are a lot of things
that OS can do.
One outstanding question, if the application opens a device driver
node, then when the SIGKILL is caught, is the OS's responsibility to
call 'close' function of the opened device driver? Is it mandatory?
| |
| Emmanuel Fleury 2007-03-16, 7:28 am |
| Bin Chen wrote:
> Is there any POSIX spec for SIGKILL signal handler in kernel space? As
> the application can't catch this signal, so there are a lot of things
> that OS can do.
The only POSIX specification of SIGKILL (signal 9) is that it is not
stoppable (at least by user-space processes).
> One outstanding question, if the application opens a device driver
> node, then when the SIGKILL is caught, is the OS's responsibility to
> call 'close' function of the opened device driver? Is it mandatory?
Ah ! Very interesting question indeed !
In fact, when a user process is waiting for a request to a kernel
thread, it is not interuptable. Meaning that if a user process is
requesting an I/O on a hard-drive and the driver happens to crash before
delivering an answer, the process will hang forever whatever the number
of SIGKILL you can send to it.
Regards
--
Emmanuel Fleury | Room: 261
Associate Professor, | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax: +33 (0)5 40 00 66 69
351, Cours de la Libération | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury
| |
| Jens Thoms Toerring 2007-03-16, 1:19 pm |
| In comp.unix.programmer Bin Chen <binary.chen@gmail.com> wrote:
> One outstanding question, if the application opens a device driver
> node, then when the SIGKILL is caught, is the OS's responsibility to
> call 'close' function of the opened device driver? Is it mandatory?
Yes, of course. If a process is killed, via a signal or other-
wise, _all_ still open files are closed, and that includes device
files. The kernel will have to call the close-method - not the
system call close(), that is for user-lamnd programs, but some
function from the device driver for closing it (if it exists)
that the kernel has been told about during initialization of the
device driver. That will probably be the same device driver
function that also gets invoked (but indirectly) via the close()
system call.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
| |
| Bin Chen 2007-03-16, 1:19 pm |
| On Mar 16, 7:39 pm, Emmanuel Fleury <emmanuel.fle...@labri.fr> wrote:
> Bin Chen wrote:
>
> The only POSIX specification of SIGKILL (signal 9) is that it is not
> stoppable (at least by user-space processes).
>
>
> Ah ! Very interesting question indeed !
>
> In fact, when a user process is waiting for a request to a kernel
> thread, it is not interuptable. Meaning that if a user process is
> requesting an I/O on a hard-drive and the driver happens to crash before
> delivering an answer, the process will hang forever whatever the number
> of SIGKILL you can send to it.
I am not saying we am in UNINTERRUPTIBLE state, just open it and do
other things except doing HW IO.
| |
| Bin Chen 2007-03-16, 1:19 pm |
| On Mar 16, 8:32 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> In comp.unix.programmer Bin Chen <binary.c...@gmail.com> wrote:
>
>
> Yes, of course. If a process is killed, via a signal or other-
> wise, _all_ still open files are closed, and that includes device
> files. The kernel will have to call the close-method - not the
> system call close(), that is for user-lamnd programs, but some
> function from the device driver for closing it (if it exists)
> that the kernel has been told about during initialization of the
> device driver. That will probably be the same device driver
> function that also gets invoked (but indirectly) via the close()
> system call.
This challenge the device driver programmer. Suppose a sound driver
whose close method will close the codec or etc. But it is possible
that user program has started a DMA request and data is running in the
bus! OS simply call close() may cause hardware failure.
Not to mess up the question. Is Linux doing this? Is Solaries doing
this?
| |
| Henry Townsend 2007-03-16, 1:19 pm |
| Bin Chen wrote:
> Is there any POSIX spec for SIGKILL signal handler in kernel space?
POSIX does not concern itself with kernel space in any way. It does not
even presume the existence of a kernel AFAIK. It specifies how user
space should behave; what happens on the other side of the trap is an
implementation detail and not subject to standardization.
| |
| Jens Thoms Toerring 2007-03-16, 1:19 pm |
| In comp.unix.programmer Bin Chen <binary.chen@gmail.com> wrote:
> On Mar 16, 8:32 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> This challenge the device driver programmer. Suppose a sound driver
> whose close method will close the codec or etc. But it is possible
> that user program has started a DMA request and data is running in the
> bus! OS simply call close() may cause hardware failure.
The user process itself didn't start the DMA transfer, it asked the
device driver to start it. And then the driver has to stop the DMA
transfer in its close-method. And, actually, there isn't any diffe-
rence to the situation where the user requested an action that re-
sults in a DMA transfer getting started and then closing the device
file without sending a request to stop tha action and the situation
where the process that has the device file open suddenly gets killed.
A driver must be written in a way to deal correctly with this (and
all other possible) situations - that's what makes writing device
drivers interesting, if you make a mistake you often not just get a
crashing program but a crashed machine - and running things under a
debugger usually isn't an option;-)
> Not to mess up the question. Is Linux doing this? Is Solaries doing
> this?
I don't know about Solaris but under Linux a close-method (if one
exists) is registered with the kernel when the driver is loaded and
that is the function that gets called when the user closes the de-
vice file via the close() system call as well as when the device
file needs closing for any other reason.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
| |
| Bin Chen 2007-03-16, 1:19 pm |
| On Mar 16, 9:32 pm, Henry Townsend <henry.towns...@not.here> wrote:
> Bin Chen wrote:
>
> POSIX does not concern itself with kernel space in any way. It does not
> even presume the existence of a kernel AFAIK. It specifies how user
> space should behave; what happens on the other side of the trap is an
> implementation detail and not subject to standardization.
Just ignore the 'kernel space', this is a term used by me for the
service provider(such as OS). As I know, POSIX is a standard for the
set of services that OS should provide if it claims conform to POSIX.
So from this point of view, the SIGKILL action taken by OS apparently
should be included in the standard.
| |
| James Carlson 2007-03-16, 1:19 pm |
| "Bin Chen" <binary.chen@gmail.com> writes:
> On Mar 16, 8:32 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> This challenge the device driver programmer. Suppose a sound driver
> whose close method will close the codec or etc. But it is possible
> that user program has started a DMA request and data is running in the
> bus! OS simply call close() may cause hardware failure.
It's the driver writer's responsibility to handle the close() entry
point properly, and do everything that's needed.
If he doesn't do that, then it's a bug in the device driver, just like
any other bug. You should report it to the maintainer. (There are
_many_ ways that a shoddy kernel device driver can blow away the
system. The possibility that you suggest is merely one obscure case.
I'm not sure why it would be significant compared to the other
possible mistakes that can be made.)
> Not to mess up the question. Is Linux doing this? Is Solaries doing
> this?
Solaris, absolutely. The kernel function you want is proc_exit(),
which calls closeall(). See:
http://cvs.opensolaris.org/source/x...xit.c#proc_exit
Also on Solaris, see the close(9E) man page for documentation of what
drivers are supposed to do, and the "Writing Device Drivers" book (on
docs.sun.com) for additional information.
Linux, no idea. But if it's a useful OS at all, then I assume so.
--
James Carlson, Solaris Networking <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
| |
| Jens Thoms Toerring 2007-03-16, 1:19 pm |
| In comp.unix.programmer Bin Chen <binary.chen@gmail.com> wrote:
> On Mar 16, 9:32 pm, Henry Townsend <henry.towns...@not.here> wrote:
[vbcol=seagreen]
> Just ignore the 'kernel space', this is a term used by me for the
> service provider(such as OS). As I know, POSIX is a standard for the
> set of services that OS should provide if it claims conform to POSIX.
> So from this point of view, the SIGKILL action taken by OS apparently
> should be included in the standard.
And what would that be? It's not POSIXs job to tell kernel writers
how to implement functionalities, it only tells kernel writers which
functionalities are required. And I don't see anything that wouldn't
be specified clearly enough in case of a SIGKILL signal - the process
must get killed whatever the process wants (leaving not more than a
zombie, i.e. just a slot in the process table with the exit status
of the process) and then the system must clean up process resources
- like closing all open file handles. What else do you expect?
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
| |
| Bin Chen 2007-03-16, 7:20 pm |
| On Mar 16, 11:09 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> In comp.unix.programmer Bin Chen <binary.c...@gmail.com> wrote:
>
>
>
> And what would that be? It's not POSIXs job to tell kernel writers
> how to implement functionalities, it only tells kernel writers which
> functionalities are required. And I don't see anything that wouldn't
> be specified clearly enough in case of a SIGKILL signal - the process
> must get killed whatever the process wants (leaving not more than a
> zombie, i.e. just a slot in the process table with the exit status
> of the process) and then the system must clean up process resources
> - like closing all open file handles. What else do you expect?
Clean up process resources is vague, right? I am not meaning POSIX
need to instruct how to write a OS that conform to it. But it need to
define exactly which resource should be cleaned, otherwise, how to
ensure programs developped to be portable?
- like closing all open file handles.
A 'like' in a standard may kill the programmers.
| |
| Martin Vuille 2007-03-17, 1:26 am |
| "Bin Chen" <binary.chen@gmail.com> wrote in
news:1174088884.893963.160830@d57g2000hsg.googlegroups.com:
>
> Clean up process resources is vague, right? I am not meaning
> POSIX need to instruct how to write a OS that conform to it. But
> it need to define exactly which resource should be cleaned,
> otherwise, how to ensure programs developped to be portable?
>
SUSv4/POSIX has this to say about what happens to a process
that is abnormally terminated due to a signal:
"The process is terminated with all the consequences of _exit( )
except that the status is made available to wait( ) and waitpid( )
indicates abnormal termination by the specified signal."
MV
--
I do not want replies; please follow-up to the group.
| |
| Bin Chen 2007-03-17, 1:26 am |
| On Mar 17, 9:22 am, Martin Vuille <jpm...@yahoo.com> wrote:
> "Bin Chen" <binary.c...@gmail.com> wrote innews:1174088884.893963.160830@d57g2000hsg.googlegroups.com:
>
>
>
>
> SUSv4/POSIX has this to say about what happens to a process
> that is abnormally terminated due to a signal:
>
> "The process is terminated with all the consequences of _exit( )
> except that the status is made available to wait( ) and waitpid( )
> indicates abnormal termination by the specified signal."
>
Thanks Martin, this is what I want. Could you please point me to a
link of above statement?
| |
| Jens Thoms Toerring 2007-03-17, 7:29 am |
| In comp.unix.programmer Bin Chen <binary.chen@gmail.com> wrote:
> On Mar 17, 9:22 am, Martin Vuille <jpm...@yahoo.com> wrote:
> Thanks Martin, this is what I want. Could you please point me to a
> link of above statement?
In SUSv3 (is there really a SUSv4 or was that a typo?) it's at
http://www.opengroup.org/onlinepubs...s/signal.h.html
It's directly below the table of the signals.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
| |
| Martin Vuille 2007-03-17, 7:29 am |
| jt@toerring.de (Jens Thoms Toerring) wrote in
news:561sc2F25gq1rU1@mid.uni-berlin.de:
>
> In SUSv3 (is there really a SUSv4 or was that a typo?) it's at
>
Typo.
MV
--
I do not want replies; please follow-up to the group.
| |
|
| In article <1174049122.087240.47480@n76g2000hsh.googlegroups.com>,
Bin Chen <binary.chen@gmail.com> wrote:
>But it is possible that user program has started a DMA request
>and data is running in the bus! OS simply call close() may cause
>hardware failure.
Huh? How would the OS calling close() be any different than the
process making the same call? The close method of a driver is
*required* to shut down things like DMA before it returns. How
could it be otherwise?
--
http://www.spinics.net/lists/
|
|
|
|
|