All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
	Arjan Van de Ven <arjanv@redhat.com>,
	Martin Peschke3 <MPESCHKE@de.ibm.com>, Jens Axboe <axboe@suse.de>,
	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: Sat, 17 Jan 2004 14:07:33 -0500	[thread overview]
Message-ID: <1074366452.13198.48.camel@compaq.xsintricity.com> (raw)
In-Reply-To: <20040117165828.A4977@infradead.org>

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
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.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc.
         1801 Varsity Dr.
         Raleigh, NC 27606



  reply	other threads:[~2004-01-17 19:12 UTC|newest]

Thread overview: 48+ 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 [this message]
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-17 20:54                       ` Christoph Hellwig
2004-01-20  7:53               ` Jens Axboe
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-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: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=1074366452.13198.48.camel@compaq.xsintricity.com \
    --to=dledford@redhat.com \
    --cc=MPESCHKE@de.ibm.com \
    --cc=arjanv@redhat.com \
    --cc=axboe@suse.de \
    --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 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.