public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-usb-devel@lists.sourceforge.net
Cc: Harald Welte <laforge@gnumonks.org>, linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] Re: [BUG] oops while completing async USB via usbdevio
Date: Mon, 30 May 2005 15:55:39 -0700	[thread overview]
Message-ID: <200505301555.39985.david-b@pacbell.net> (raw)
In-Reply-To: <20050530212641.GE25536@sunbeam.de.gnumonks.org>

On Monday 30 May 2005 2:26 pm, Harald Welte wrote:
> On Mon, May 30, 2005 at 09:44:44PM +0200, Harald Welte wrote:
> > I think there is currently no protection/locking/refcounting going on.
> > 
> > If a process issues an URB from userspace and starts to terminate before
> > the URB comes back, we run into the issue described above.  This is
> > because the urb saves a pointer to "current" when it is posted to the
> > device, but there's no guarantee that this pointer is still valid
> > afterwards.  

The logic closing an open usbfs file -- which is done before any task
exits with such an open file -- is supposed to block till all its URBs
complete.  So the pointer to the task "should" be valid for as long as
any URB it's submitted is active.

There have been some changes in that code since last I looked at it.
One obvious change was switching to usb_kill_urb(), but there've been
others too.


> > I'm not familiar with the scheduler code to decide what fix
> > is the way to go.  Is it sufficient to do {get,put}_task_struct() from
> > the usb code?

It's worth making that change in any case, to avoid such questions in
the future.  And if it does any good, more power to the patch!

Not that it helps at all, but I've never really trusted the usbfs async
I/O code.  "Real AIO" could be a lot more obviously correct.  And smaller.


> mh. it appears like it's sighand which disappears, not the task itself.
> ...

Odd.  Isn't that nulled only in __exit_sighand(), which gets called only
when the task itself is finally being freed?

- Dave


  reply	other threads:[~2005-05-30 23:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-30 19:44 [BUG] oops while completing async USB via usbdevio Harald Welte
2005-05-30 21:26 ` Harald Welte
2005-05-30 22:55   ` David Brownell [this message]
2005-05-30 23:09     ` [linux-usb-devel] " Oliver Neukum
2005-05-30 23:12       ` David Brownell
2005-05-31  8:04       ` Harald Welte
2005-05-31  8:48     ` Harald Welte
2005-05-31 11:45       ` Oliver Neukum
2005-05-31 18:53       ` David Brownell
2005-05-31 22:12         ` Harald Welte
2005-06-06 16:05           ` Harald Welte
2005-06-06 16:24             ` Alan Stern
2005-06-06 16:50               ` Harald Welte
2005-05-30 23:07   ` Oliver Neukum
2005-05-31  8:06     ` Harald Welte

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=200505301555.39985.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=laforge@gnumonks.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    /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