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
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
