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....)
Attachment:
pgpVtcJNr4r6c.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
