All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Andrew Morton <akpm@zip.com.au>
Cc: hogsberg@users.sourceforge.net, jamesg@filanet.com,
	"H . J . Lu" <hjl@lucon.org>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: sbp2.c on SMP
Date: Mon, 12 Nov 2001 18:34:42 +0100	[thread overview]
Message-ID: <20011112183442.H786@suse.de> (raw)
In-Reply-To: <3BEF27D1.7793AE8E@zip.com.au>
In-Reply-To: <3BEF27D1.7793AE8E@zip.com.au>

On Sun, Nov 11 2001, Andrew Morton wrote:
> Guys,
> 
> drivers/ieee1394/sbp2.c deadlocks immediately on SMP, because
> io_request_lock is not held over its call to scsi_old_done().
> 
> I don't know why scsi_old_done() actually requires io_request_lock;
> perhaps Jens could comment on whether I've taken the lock in the
> appropriate place?

Yes it looks fine, unfortunately the mid layer locking design is crappy
like that. Imposing locking downwards is just not good style :/

I've actually had quite good luck changing this for future kernels -- it
was required to remove io_request_lock anyways.

> The games which scsi_old_done() plays with spinlocks and interrupt
> enabling are really foul.  If someone calls it with interrupts disabled
> (sbp2 does this) then scsi_old_done() will enable interrupts for you.
> If, for example, you call scsi_old_done() under spin_lock_irqsave(), 
> the reenabling of interrupts will expose you to deadlocks.  Perhaps
> scsi_old_done() should just use spin_unlock()/spin_lock()?

Yep it's not nice either. I wouldn't change that without further
auditing though.

-- 
Jens Axboe


  parent reply	other threads:[~2001-11-12 17:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-12  1:37 sbp2.c on SMP Andrew Morton
2001-11-12  4:54 ` H . J . Lu
2001-11-12  5:14   ` Andrew Morton
2001-11-12  5:28     ` H . J . Lu
2001-11-12  8:50 ` Alan Cox
2001-11-12 17:34 ` Jens Axboe [this message]
2001-11-14  3:17 ` H . J . Lu
2001-11-14  7:21   ` Andrew Morton
2001-11-16  3:32     ` H . J . Lu
2001-11-16 16:15       ` Kristian Hogsberg
2001-11-16 16:30         ` H . J . Lu
2001-11-16 21:25         ` H . J . Lu
2001-11-16 22:40           ` Kristian Hogsberg
2001-11-26 15:43           ` Oops 2.4.15-pre1aa1 Sven Heinicke
  -- strict thread matches above, loose matches on Subject: below --
2001-11-12  4:49 sbp2.c on SMP Douglas Gilbert

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=20011112183442.H786@suse.de \
    --to=axboe@suse.de \
    --cc=akpm@zip.com.au \
    --cc=hjl@lucon.org \
    --cc=hogsberg@users.sourceforge.net \
    --cc=jamesg@filanet.com \
    --cc=linux-kernel@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.