kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: What will happen if I kill a process which is waiting for the retuan ioctl() syscall?
Date: Wed, 14 Mar 2018 17:46:16 +0100	[thread overview]
Message-ID: <20180314164616.GA27462@kroah.com> (raw)
In-Reply-To: <20035.1521045141@turing-police.cc.vt.edu>

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

  reply	other threads:[~2018-03-14 16:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-13 11:56 What will happen if I kill a process which is waiting for the retuan ioctl() syscall? Douglas Su
2018-03-14  3:27 ` Larry Chen
2018-03-14 14:01   ` Miles Fidelman
2018-03-14 14:15   ` Miles Fidelman
2018-03-14 16:32   ` valdis.kletnieks at vt.edu
2018-03-14 16:46     ` Greg KH [this message]
2018-03-14 16:55       ` valdis.kletnieks at vt.edu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180314164616.GA27462@kroah.com \
    --to=greg@kroah.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).