What will happen if I kill a process which is waiting for the retuan ioctl() syscall?

[valdis.kletnieks at vt.edu]

On Wed, 14 Mar 2018 11:27:41 +0800, Larry Chen said:

> > 3. If ioctl() still running even after we terminate this process, where doe
s the return value ioctl() will return to?
> That sounds insane.

That's because it *is* insane.

The ioctl() *can't* "still be running" after the kill -9, because signals are
by default not delivered to processes in the kernel until the kernel returns to
userspace.  In other words, terminating the process won't start happening until
the ioctl() call finishes and starts to return.

That's why you can't kill -9 a process that's stuck in 'D' state according to
'ps' - the kill remains pending.

(And of course, if the driver does an explicit "is there a signal pending" check
and returns to userspace without cleaning up it's mess, that's by definition
a bug in the driver...)

Now, there *is* a possibility that the ioctl() has initiated a hardware action
that will take a while to complete (for example, issuing a rewind&offload to a
tape drive can take 90 to 120 seconds to complete).  If the driver is silly
enough to return to userspace before the hardware action finishes, it's the
driver's job to do more status checking on the next call for the device (for
instance, "is the tape ready to act, or is it unwinding/loading/dropped on the
floor by the robot"?)  This gets complicated because often, *some* I/O commands
can be accepted and executed by the device while others are still pending - but
other different commands have to wait until the long-running command completes.

(And yes, I've had tapes dropped by an SL8500 robot.  Particularly annoying
because the robot arm on the lowest rail runs close enough to the floor that
an LTO tape cartridge won't fit under it.)

https://www.youtube.com/watch?v=IDgXa0ioVTs

> > 4. How to keep the device's state consistent when we kill a process when it
> > is invoking a system call?
> Sorry, I did not get your point.

That's *totally* device dependent.  The things a driver needs to do to ensure
consistency for a 40Gbit ethernet adapter are *totally* different from that USB
memory stick.

But in general, a driver will employ locking the current request and not return early, so at
any given time, the next request to be made will not proceed until the device is
in a known consistent state (whether that state is suitable for the next request is
a totally different question of course - consider a tape drive where the state is
'tape unloaded' and the next reqest is a read from the tape....)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180314/18b8b4a6/attachment.sig>