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

[Greg KH]

On Wed, Mar 14, 2018 at 12:32:21PM -0400, valdis.kletnieks at vt.edu wrote:
> > > 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.

Not to be "chatty", but that "USB memory stick" is one of the most
complex USB devices out there from a protocol standpoint.  Only USB
video cameras get close to just how complex those things are.  Remember,
this is really a full SCSI controller talking SCSI commands over USB in
a serial manner, which implements a block device, which you then layer a
filesystem on top of.

It's such a complex beast, in the 2.4 days we had someone write a
"simple" driver just to try to cut out the whole SCSI layer as it was
not handling device removal/insertion well, if at all, in a dynamic
fashion and we wanted to try to avoid dealing with all of the
complexities SCSI provides.  In the end, it never really worked and we
had to use the full SCSI stack instead just to get all devices to work
properly, and that driver was deleted from the tree.

With USB 3, those USB devices are even more complex, offering up
multiple "streams" in which you can pump multiple commands down at the
same time, to try to increase the throughput of the device.  If you sit
on the linux-usb mailing list for any amount of time, you will see the
smattering of odd bug reports we get for these devices due to the crazy
interactions between SCSI, storage devices, and the xhci (USB 3) driver.

So you need a better example of a "simple" device.  What about a serial
port?  Oh wait, that's over 10k lines, kernel programming is hard, let's
go shopping...

Sorry for the rant/wall-of-text, it's just something I have strong
feelings about :)

thanks,

greg k-h