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?

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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?

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

"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... />
#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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]