All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pete Wyckoff <pw@osc.edu>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: michaelc@cs.wisc.edu, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: bsg locking patches update
Date: Wed, 28 May 2008 10:18:48 -0400	[thread overview]
Message-ID: <20080528141848.GA17325@osc.edu> (raw)
In-Reply-To: <200805281351.m4SDpTIl030554@mbox.iij4u.or.jp>

fujita.tomonori@lab.ntt.co.jp wrote on Wed, 28 May 2008 22:51 +0900:
> From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Subject: Re: bsg locking patches update
> Date: Wed, 28 May 2008 21:00:56 +0900
> 
> > On Mon, 26 May 2008 12:53:18 -0400
> > Pete Wyckoff <pw@osc.edu> wrote:
> > 
> > > I finally got around to testing the set of lifetime management
> > > fixes you applied.  This is 2.6.26-rc3 with some varlen, bidi,
> > > iser patches, and iovec on bsg, but nothing that should affect
> > > the locking.
> > > 
> > > I can confirm that the first two of these three old bugs are
> > > no longer reproducable:
> > > 
> > >     http://marc.info/?l=linux-scsi&m=120508166505141&w=2
> > >     http://marc.info/?l=linux-scsi&m=120508177905365&w=2
> > >     http://marc.info/?l=linux-scsi&m=120508178005376&w=2
> > > 
> > > Thanks!  The third, however, is a hang that still can happen.  But
> > > it is very obscure and requires a bit of timing to get right.  As a
> > > reminder, here's the setup, and updated traces.
> > 
> > Ah, sorry about it. I didn't understand the third correctly.
> > 
> > 
> > > Maybe it is necessary to split up that bsg_mutex to use multiple
> > > finer-grained locks.
> > 
> > We could but we use bsg_mutex to protect bsg_device_list and idr. So I
> > think that we don't need hold bsg_mutex during
> > bsg_complete_all_commands. How about this?
> 
> On second thoughts, I realized that the previous patch leads to a race
> between bsg_put_device and __bsg_get_device (__bsg_get_device possibly
> finds a device that is being removed). Here's new one.

Looks good.  I can't see any problems with this approach.  And it
tests okay in my problem scenario, on top of 2.6.26-rc4.  You can
add my tested-by and submit as a bug fix to .26 safely, I think.
Thanks again!

		-- Pete

> diff --git a/block/bsg.c b/block/bsg.c
> index f0b7cd3..7cdec32 100644
> --- a/block/bsg.c
> +++ b/block/bsg.c
> @@ -724,8 +724,13 @@ static int bsg_put_device(struct bsg_device *bd)
>  	mutex_lock(&bsg_mutex);
>  
>  	do_free = atomic_dec_and_test(&bd->ref_count);
> -	if (!do_free)
> +	if (!do_free) {
> +		mutex_unlock(&bsg_mutex);
>  		goto out;
> +	}
> +
> +	hlist_del(&bd->dev_list);
> +	mutex_unlock(&bsg_mutex);
>  
>  	dprintk("%s: tearing down\n", bd->name);
>  
> @@ -741,10 +746,8 @@ static int bsg_put_device(struct bsg_device *bd)
>  	 */
>  	ret = bsg_complete_all_commands(bd);
>  
> -	hlist_del(&bd->dev_list);
>  	kfree(bd);
>  out:
> -	mutex_unlock(&bsg_mutex);
>  	kref_put(&q->bsg_dev.ref, bsg_kref_release_function);
>  	if (do_free)
>  		blk_put_queue(q);
> 

      reply	other threads:[~2008-05-28 14:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-26 16:53 bsg locking patches update Pete Wyckoff
2008-05-28 12:00 ` FUJITA Tomonori
2008-05-28 13:51   ` FUJITA Tomonori
2008-05-28 13:51     ` FUJITA Tomonori
2008-05-28 14:18     ` Pete Wyckoff [this message]

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=20080528141848.GA17325@osc.edu \
    --to=pw@osc.edu \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    /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.