From: Christoph Hellwig <hch@lst.de>
To: Anatoliy Glagolev <glagolig@gmail.com>
Cc: linux-block@vger.kernel.org,
"James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
Jens Axboe <axboe@kernel.dk>,
linux-scsi@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] block: fix bsg_unregister and bsg_open race
Date: Thu, 14 Jun 2018 10:38:06 +0200 [thread overview]
Message-ID: <20180614083806.GA18966@lst.de> (raw)
In-Reply-To: <20180613221417.GA22778@xldev-tmpl.dev.purestorage.com>
On Wed, Jun 13, 2018 at 04:14:18PM -0600, Anatoliy Glagolev wrote:
> The existing implementation allows races between bsg_unregister and
> bsg_open paths. bsg_ungegister and request_queue cleanup and
> deletion may start and complete right after bsg_get_device (in bsg_open path)
> retrieves bsg_class_device and releases the mutex. Then bsg_open path
> touches freed memory of bsg_class_device and request_queue.
>
> One possible fix is to hold the mutex all the way through bsg_get_device
> instead of releasing it after bsg_class_device retrieval.
This looks generally fine to me. Nitpicks below:
> @@ -746,16 +745,18 @@ static struct bsg_device *bsg_get_device(struct inode *inode, struct file *file)
> */
> mutex_lock(&bsg_mutex);
> bcd = idr_find(&bsg_minor_idr, iminor(inode));
> - mutex_unlock(&bsg_mutex);
>
> if (!bcd)
> return ERR_PTR(-ENODEV);
This needs to unlock the mutex. E.g.
if (!bcd) {
bd = ERR_PTR(-ENODEV);
goto out_unlock;
}
> bd = __bsg_get_device(iminor(inode), bcd->queue);
> + if (bd) {
> + mutex_unlock(&bsg_mutex);
> return bd;
> + }
>
> bd = bsg_add_device(inode, bcd->queue, file);
> + mutex_unlock(&bsg_mutex);
>
> return bd;
I'd simply do:
bd = __bsg_get_device(iminor(inode), bcd->queue);
if (!bd)
bd = bsg_add_device(inode, bcd->queue, file);
out_unlock:
mutex_unlock(&bsg_mutex);
return bd;
next prev parent reply other threads:[~2018-06-14 8:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-13 22:14 [PATCH] block: fix bsg_unregister and bsg_open race Anatoliy Glagolev
2018-06-13 22:14 ` Anatoliy Glagolev
2018-06-14 8:38 ` Christoph Hellwig [this message]
2018-06-14 23:47 ` [PATCHv2] " Anatoliy Glagolev
2018-06-14 23:47 ` Anatoliy Glagolev
2018-06-15 9:27 ` Christoph Hellwig
2018-06-15 14:16 ` Jens Axboe
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=20180614083806.GA18966@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=glagolig@gmail.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@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.