Re: [linux-usb-devel] Once again about usb-uhci and locks

> From: Georg Acher <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Reply-To: [EMAIL PROTECTED] > Date: Tue, 5 Jun 2001 13:48:01 +0200 > > On Mon, Jun 04, 2001 at 03:46:29PM -0400, Pete Zaitcev wrote: > <...> > > The urb->lock is used intelligently in uhci.c, > > but usb-uhci does not use it at al

Re: [linux-usb-devel] Once again about usb-uhci and locks

On Mon, Jun 04, 2001 at 03:46:29PM -0400, Pete Zaitcev wrote: <...> > The urb->lock is used intelligently in uhci.c, > but usb-uhci does not use it at all. Everywhere > usb-uhci asserts urb->lock, s->urb_list_lock is > taken already, so urb->lock is totally redundant. > [Side note: process_urb is

Re: [linux-usb-devel] Once again about usb-uhci and locks

On Tue, Jun 05, 2001 at 12:42:21AM -0400, Johannes Erdfelt wrote: > On Mon, Jun 04, 2001, David Brownell <[EMAIL PROTECTED]> wrote: > > > > > I had to look at usb-uhci and locking in it once again; > > > > > this time I know what is wrong with David-B's "fix" > > > ... > > > > > > Your fix blows

Re: [linux-usb-devel] Once again about usb-uhci and locks

> > > Based on the above, I think that unlinking and completition > > > cannot work together as long as they abuse urb->status to signal > > > if the urb is referenced. > > > > If access or modification of urb->status were consistently > > protected by grabbing urb->lock, I'd think that suffices

Re: [linux-usb-devel] Once again about usb-uhci and locks

> From: David Brownell <[EMAIL PROTECTED]> > Date: Mon, 04 Jun 2001 19:22:47 -0700 > > The best way, IMHO, would be to prohibit it altogether. > > E.g. if URB is submitted (returned from usb_submit_urb > > successfuly), then it cannot be unlinked until completition > > is called [see note about c

Re: [linux-usb-devel] Once again about usb-uhci and locks

On Mon, Jun 04, 2001, David Brownell <[EMAIL PROTECTED]> wrote: > > > > I had to look at usb-uhci and locking in it once again; > > > > this time I know what is wrong with David-B's "fix" > > ... > > > > Your fix blows up on ia64 and we are going to ship something > > like this for the RH 7.1/ia6

Re: [linux-usb-devel] Once again about usb-uhci and locks

> The best way, IMHO, would be to prohibit it altogether. > E.g. if URB is submitted (returned from usb_submit_urb > successfuly), then it cannot be unlinked until completition > is called [see note about cancel below]. Pete, if that's effectively suggesting that usb_unlink_urb() be removed from

Re: [linux-usb-devel] Once again about usb-uhci and locks

> > > I had to look at usb-uhci and locking in it once again; > > > this time I know what is wrong with David-B's "fix" > ... > > Your fix blows up on ia64 and we are going to ship something > like this for the RH 7.1/ia64: Strange -- what does IA64 do differently? What does the explosion look

Re: [linux-usb-devel] Once again about usb-uhci and locks

On Mon, Jun 04, 2001, David Brownell <[EMAIL PROTECTED]> wrote: > > > So I'm not quite sure that urb->lock can really disappear. > > > Though I'd agree that it's one of several chunks of urb data > > > that aren't clearly enough specified. > > > > He specifically said usb-uhci and nothing about h

Re: [linux-usb-devel] Once again about usb-uhci and locks

> From: Georg Acher <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] Once again about usb-uhci and locks > Reply-To: [EMAIL PROTECTED] > Date: Mon, 4 Jun 2001 22:33:18 +0200 > > If problems crop up so thick, surely something is very wron

Re: [linux-usb-devel] Once again about usb-uhci and locks

> > So I'm not quite sure that urb->lock can really disappear. > > Though I'd agree that it's one of several chunks of urb data > > that aren't clearly enough specified. > > He specifically said usb-uhci and nothing about hcd or any other > drivers. OK, but I'll explicitly say that many of the U

Re: [linux-usb-devel] Once again about usb-uhci and locks

On Sun, Jun 03, 2001 at 10:01:00PM -0400, Pete Zaitcev wrote: > If problems crop up so thick, surely something is very wrong, > so I started to make lists and charts, and found something curious. > > It seems to me that all places where urb is locked by itself are > under the list lock too. The

Re: [linux-usb-devel] Once again about usb-uhci and locks

> From: David Brownell <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Reply-To: [EMAIL PROTECTED] > Date: Sun, 03 Jun 2001 23:32:47 -0700 > > I had to look at usb-uhci and locking in it once again; > > this time I know what is wrong with David-B's "fix" > >

Re: [linux-usb-devel] Once again about usb-uhci and locks

On Sun, Jun 03, 2001, David Brownell <[EMAIL PROTECTED]> wrote: > > I suggest we get rid of any instances of urb->lock in usb-uhci. > > It does not serve any useful purpose, and is a terrible bug > > generator. > > The "hcd" layer (used right now only for EHCI) uses that > lock when it's switchin

Re: [linux-usb-devel] Once again about usb-uhci and locks

> I had to look at usb-uhci and locking in it once again; > this time I know what is wrong with David-B's "fix" > Hey, all I claimed to do was fix an oops I'd been hitting. Are you claiming I was imagining the oops, and then i

[linux-usb-devel] Once again about usb-uhci and locks

I had to look at usb-uhci and locking in it once again; this time I know what is wrong with David-B's "fix" Look at the original code and you will see that it was a sure way to deadlock. Our order is list --> urb, but here we