All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Erdfelt <johannes@erdfelt.com>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: linux-kernel@vger.kernel.org, t.sailer@alumni.ethz.ch
Subject: Re: Patch for bizzare oops in USB
Date: Tue, 21 Aug 2001 00:01:26 -0400	[thread overview]
Message-ID: <20010821000125.A28638@sventech.com> (raw)
In-Reply-To: <20010818013101.A7058@devserv.devel.redhat.com> <3B80FBA9.556B7B2B@scs.ch> <20010820174448.A1299@devserv.devel.redhat.com>
In-Reply-To: <20010820174448.A1299@devserv.devel.redhat.com>; from zaitcev@redhat.com on Mon, Aug 20, 2001 at 05:44:48PM -0400

On Mon, Aug 20, 2001, Pete Zaitcev <zaitcev@redhat.com> wrote:
> A prolifiration of subtly different versions of basic primitives
> is not an answer either. But wait, here's a better fix. The
> root of the evil is that the waiting thread accesses urb->status
> before a callback happened, which is unsafe.
> 
> BTW, I took a liberty to clean the thing up a bit. It looked as
> if the author of that fragment was not sure of what he was doing,
> and the style was quite dirty. I think a number of wrongs for
> such a small fragment was astonishing.
> 
>  - "status" was an errno in the begining, then 5 lines down
>    it's bool (== timeout), then it turns into system style once again.
>  - Wasted pointer to wait head
>  - Unused void *stuff.
>  - typedef without _t and unprefixed type name in global header.
>  - Urban legend of test for waitqueue_active() before wakeup.
>    This is one half wrong because so many people do it,
>    anyone has an idea why? Half a point deducted.
>  - Confused and redundant checking for -EINPROGRESS
>    (even if it was the cause of oops)
> 
> And the last one ...
>  - THE GOD DAMN RACE THAT OOPS - that's 10 hacker points down!
>    It only goes to show that replacing interruptible_sleep_on
>    with add_wait_queue/schedule/remove_wait_queue does not make
>    any racy code correct automatically.
> 
> Cheesh, I am surprised _anything_ in Linux kernel works.

So am I. To be honest, there's a bunch of things in the USB code I'm not
entirely happy.

I didn't see many of them until recently, but I guess with experience,
comes wisdom. I had intended to fix many of them in 2.5 when it finally
forks.

I like your patch, but since we have the new completion stuff now, we
should probably use that. I'll make the mod and send off the patch to
Linus when I get back from this business trip.

Thanks.

JE


  reply	other threads:[~2001-08-21  4:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-18  5:31 Patch for bizzare oops in USB Pete Zaitcev
2001-08-20 11:59 ` Thomas Sailer
2001-08-20 21:06   ` Pete Zaitcev
2001-08-21  8:29     ` Thomas Sailer
2001-08-20 21:44   ` Pete Zaitcev
2001-08-21  4:01     ` Johannes Erdfelt [this message]
2001-08-21  4:17       ` Pete Zaitcev
2001-08-20 22:12   ` Eugene Crosser

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=20010821000125.A28638@sventech.com \
    --to=johannes@erdfelt.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=t.sailer@alumni.ethz.ch \
    --cc=zaitcev@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.