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

[Miles Fidelman]

On 3/13/18 11:27 PM, Larry Chen wrote:

> Hello Douglas,
>
> On 03/13/2018 07:56 PM, Douglas Su wrote:
>> If I have these:
>>
>> 1. I have implemented a simple ioctl() system call which just delay a 
>> period and return.
>> 2. Call this ioctl() from a userspace process, of course, this 
>> process will be blocked until ioctl() return.
>> 3. Before ioctl() return, use `kill -9 <pid>` command terminates the 
>> process.
>>
>> Question:
>>
>> 1. Can we instantly kill this process?
> Of course, you can. But whether your behavior will affect your process 
> depends on your implementation.
>> 2. If we can instantly kill this process, does ioctl() still keep 
>> delay after killing?
> It depends on your implementation of your ioctl.
> If your ioctl has some kind of mechanism to check whether there is a 
> signal received, you can let your ioctl return.
>> 3. If ioctl() still running even after we terminate this process, 
>> where does the return value ioctl() will return to?
> That sounds insane.
>> 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.
>

3 & 4 seem like perfectly obvious questions - and now I'm pretty 
curious.  It's been a while since I've done any i/o coding, and it 
wasn't under *nix (the last time might have been Zilos - which dates me 
a bit) - and this raises all kinds of interesting questions in my mind.

Re. 3:  One can easily imagine data being left on the call stack (can 
you say security hole?), or buffers being created and passed to <where?>.
Re. 4:  One certainly wants to write device drivers that behave 
predictably under error conditions (like having the calling process die)

Given that each ioctl() is different, and that there's stuff that 
happens in user space, kernel space, hardware - potentially multiple 
processes involved, handoff of data between user & kernel space, 
signals, and so forth....

One can envision all kinds of scenarios if the calling process is 
suspended or killed - orphaned processes, zombies, files left open, 
buffers copied and then handed to <whom?>, values left on the top of the 
stack, to be picked up by a now non-existent process (can you say 
security hole?), etc. ...

And none of this seems to be well documented, or even defined.

So...  what is the actual flow of control when a userspace process makes 
an ioctl?  Flow of data (arguments, return values, buffers, etc.)?  Flow 
of signals?  Side effects?  Things that block and things that don't?  
Who owns what data & processes - particularly if the calling process dies?

What is common to all ioctl() operations (and file operations in 
general)?  What are constraints on what an ioctl() can/might do?

To come back to the OP's question:  What are some best practices - to 
insure that bad things don't happen if a calling process goes away while 
an ioctl() is in process?

Probably not a topic that can be answered fully in an email - but 
references would be really nice!  (I did find this - which gives a lot 
of interesting info - but I can't vouch for it's accuracy - 
https://www.slideshare.net/EmertxeSlides/linux-device-drivers-45884477)

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra