public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Doug Ledford <dledford@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
	Arjan Van de Ven <arjanv@redhat.com>,
	Martin Peschke3 <MPESCHKE@de.ibm.com>,
	Peter Yao <peter@exavio.com.cn>,
	linux-kernel@vger.kernel.org,
	linux-scsi mailing list <linux-scsi@vger.kernel.org>,
	ihno@suse.de
Subject: Re: smp dead lock of io_request_lock/queue_lock patch
Date: Tue, 20 Jan 2004 08:53:36 +0100	[thread overview]
Message-ID: <20040120075336.GK16085@suse.de> (raw)
In-Reply-To: <1074366452.13198.48.camel@compaq.xsintricity.com>

On Sat, Jan 17 2004, Doug Ledford wrote:
> On Sat, 2004-01-17 at 11:58, Christoph Hellwig wrote:
> > On Sat, Jan 17, 2004 at 08:10:00AM -0500, Doug Ledford wrote:
> > > 4)  The last issue.  2.6 already has individual host locks for drivers. 
> > > The iorl patch for 2.4 adds the same thing.  So, adding the iorl patch
> > > to 2.4 makes it easier to have drivers be the same between 2.4 and 2.6. 
> > > Right now it takes some fairly convoluted #ifdef statements to get the
> > > locking right in a driver that supports both 2.4 and 2.6.  Adding the
> > > iorl patch allows driver authors to basically state that they don't
> > > support anything prior to whatever version of 2.4 it goes into and
> > > remove a bunch of #ifdef crap.
> > 
> > Well, no.  For one thing all the iorl patches miss the scsi_assign_lock
> > interface from 2.6 which makes drivers a big ifdef hell (especially
> > as the AS2.1 patch uses a different name for the lock as 3.0), and even
> > if it was there the use of that function is strongly discuraged in 2.6
> > in favour of just using the host_lock.
> 
> Yeah, I saw that too.  Of course, it's not like that's my fault :-P  I
> had the 2.4.9 version of the iorl patch before 2.5 had a host lock, so
> 2.5 *could* have followed the 2.4.9-iorl patch convention of using
> host->lock as the name instead of host->host_lock and then we wouldn't
> be here.  But, because 2.6 uses host->host_lock, and because usage of

First of all, ->lock is a _bad_ name. And secondly, we probably did this
at around the same time (the 2.5 block code was already "done" by the
time 2.5 opened, if you recall it was one of the first things merged in
2.5.1-pre1). The fact that I chose the better name (which is really a
rare incident, my names typically suck) is just history :-)

> the scsi_assign_lock() is discouraged, I made the iorl patch in RHEL3
> follow the 2.6 convention of using host->host_lock.  In hindsight, I
> should have just followed the 2.4.9-iorl patch convention.  Then a
> driver could have just done this:
> 
> #ifdef SCSI_HAS_HOST_LOCK
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
> 	adapter->lock_ptr = &adapter->lock;
> 	host->lock = &adapter->lock;
> #else
> 	adapter->lock_ptr = &adapter->lock;
> 	host->host_lock = &adapter->lock;
> #endif
> #else
> 	adapter->lock_ptr = &io_request_lock;
> #endif
> 
> Then you just always use adapter->lock_ptr for spin locks in the driver
> and you magically work in all kernel releases.  Now, by going to
> host->host_lock in 2.4 we get rid of one of the if statements.  This
> isn't impossible to do if both Red Hat and SuSE just release their next
> update kernel with host->lock changed to host->host_lock.

I can certainly help make that happen, I completely agree it's needed.

-- 
Jens Axboe


  parent reply	other threads:[~2004-01-20  7:54 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-12 15:07 smp dead lock of io_request_lock/queue_lock patch Martin Peschke3
2004-01-12 15:12 ` Arjan van de Ven
2004-01-12 19:48   ` Christoph Hellwig
2004-01-12 19:51     ` Doug Ledford
2004-01-12 20:03       ` Christoph Hellwig
2004-01-12 21:12         ` Jens Axboe
2004-01-13 20:55       ` Marcelo Tosatti
2004-01-17 13:10         ` Doug Ledford
2004-01-17 16:58           ` Christoph Hellwig
2004-01-17 19:07             ` Doug Ledford
2004-01-17 19:17               ` Christoph Hellwig
2004-01-17 19:21                 ` Doug Ledford
2004-01-17 19:29                   ` Christoph Hellwig
2004-01-17 20:36                     ` Doug Ledford
2004-01-20  7:53               ` Jens Axboe [this message]
2004-01-20  2:19           ` [2.4] scsi per-host lock was " Marcelo Tosatti
2004-01-20  3:21             ` Doug Ledford
2004-01-25  0:31           ` Kurt Garloff
2004-01-15 17:17       ` Bill Davidsen
2004-01-17 13:12         ` Doug Ledford
2004-01-17 15:16           ` Bill Davidsen
2004-01-17 16:07             ` Doug Ledford
  -- strict thread matches above, loose matches on Subject: below --
2004-01-19 21:36 Martin Peschke3
2004-03-08 21:25 ` Doug Ledford
     [not found] <1d6yN-6HH-17@gated-at.bofh.it>
     [not found] ` <1dasC-5Ww-5@gated-at.bofh.it>
     [not found]   ` <1ejkf-724-13@gated-at.bofh.it>
     [not found]     ` <1elvB-Jt-25@gated-at.bofh.it>
2004-01-16 15:40       ` Bill Davidsen
2004-01-12 16:32 Peter Yao
2004-01-12  9:08 ` Arjan van de Ven
2004-01-12  9:19   ` Jens Axboe
2004-01-12  9:19     ` Jens Axboe
2004-01-12  9:20       ` Arjan van de Ven
2004-01-12  9:22         ` Jens Axboe
2004-01-12 13:27           ` Doug Ledford
2004-01-15 17:01             ` Bill Davidsen
2004-01-15 17:05               ` Jens Axboe
2004-01-15 17:09               ` Arjan van de Ven
2004-01-15 19:30               ` Doug Ledford
2004-01-12 14:07 Martin Peschke3
2004-01-12 14:11 ` Arjan van de Ven
2004-01-12 14:13 ` Jens Axboe
2004-01-12 15:08   ` Doug Ledford
2004-01-12 15:24     ` James Bottomley
2004-01-12 15:43       ` Jens Axboe
2004-01-12 15:52         ` Doug Ledford
2004-01-12 16:04           ` James Bottomley
2004-01-12 16:05             ` Doug Ledford

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=20040120075336.GK16085@suse.de \
    --to=axboe@suse.de \
    --cc=MPESCHKE@de.ibm.com \
    --cc=arjanv@redhat.com \
    --cc=dledford@redhat.com \
    --cc=hch@infradead.org \
    --cc=ihno@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=marcelo.tosatti@cyclades.com \
    --cc=peter@exavio.com.cn \
    /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