All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@linux.intel.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: akpm@osdl.org, netdev@vger.kernel.org, mingo@elte.hu, bcrl@kvack.org
Subject: Re: [patch 7/8] lock validator: fix ns83820.c irq-flags bug
Date: Sun, 11 Jun 2006 09:12:17 -0700	[thread overview]
Message-ID: <448C40E1.8080705@linux.intel.com> (raw)
In-Reply-To: <448C4021.80102@garzik.org>

Jeff Garzik wrote:
> Arjan van de Ven wrote:
>> Jeff Garzik wrote:
>>> The driver's locking is definitely wrong, but I don't think this is 
>>> the fix, 
>>
>> it's an obvious correct fix in the correctness sense though...
>>
>>>
>>> Jesus, the locking here is awful.  No wonder there are bugs.
>>
>>
>> ... which given that fact, is for 2.6.17 probably the right thing, 
>> pending
>> a nicer fix for 2.6.18
> 
> I disagree, the patch is wrong too.

wrong as in "not quite optimal", not wrong as in "buggy".

> For normal PCI hardware, the in-ISR paths should all use spin_lock(), 

only for per hardware locks obviously, not for per driver locks ;)


you are right that it's a lot nicer to do what you describe. No argument
from me on that part. But to call it "wrong" or "incorrect" is not quite
ok.  In terms of changing/fixing the approach we did was the simplest one.
Not the "make it look nice" one. Fix it by making the bug go away in the light
of a LOT of fishy locking.

You can demand that we first fix all the fishy locking first, and I can even
in part agree with that, but for -stable and 2.6.17 that is obviously out
of scope while a simple "make the bug go away" fix is not.


  reply	other threads:[~2006-06-11 16:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200606090519.k595JmDG032032@shell0.pdx.osdl.net>
2006-06-11 14:55 ` [patch 7/8] lock validator: fix ns83820.c irq-flags bug Jeff Garzik
2006-06-11 15:00   ` Arjan van de Ven
2006-06-11 16:09     ` Jeff Garzik
2006-06-11 16:12       ` Arjan van de Ven [this message]
2006-06-11 17:01 ` Jeff Garzik
2006-06-11 17:02   ` Arjan van de Ven
2006-06-11 20:28   ` Benjamin LaHaise

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=448C40E1.8080705@linux.intel.com \
    --to=arjan@linux.intel.com \
    --cc=akpm@osdl.org \
    --cc=bcrl@kvack.org \
    --cc=jeff@garzik.org \
    --cc=mingo@elte.hu \
    --cc=netdev@vger.kernel.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 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.