From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Bradley Bolen <bradleybolen@gmail.com>
Cc: linux-mtd@lists.infradead.org, dedekind1@gmail.com,
richard@nod.at, marek.vasut@gmail.com,
cyrille.pitchen@wedev4u.fr, computersforpeace@gmail.com,
dwmw2@infradead.org,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Subject: Re: [PATCH] UBI: block: Must use a mutex when using idr_alloc/idr_remove
Date: Sun, 14 Jan 2018 15:39:15 +0100 [thread overview]
Message-ID: <20180114153915.4c6141a4@bbrezillon> (raw)
In-Reply-To: <1514946369-3674-1-git-send-email-bradleybolen@gmail.com>
+Ezequiel
Hi Bradley,
On Tue, 2 Jan 2018 21:26:09 -0500
Bradley Bolen <bradleybolen@gmail.com> wrote:
> This fixes a race condition where running ubiblock on multiple volumes
> simultaneously produces the following splat.
>
> kernel BUG at kernel-source/fs/sysfs/group.c:113!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> [<c01e4160>] (internal_create_group) from [<c01e43fc>]
> (sysfs_create_group+0x20/0x24)
> [<c01e43fc>] (sysfs_create_group) from [<c00e4800>]
> (blk_trace_init_sysfs+0x18/0x20)
> [<c00e4800>] (blk_trace_init_sysfs) from [<c02bc734>]
> (blk_register_queue+0x6c/0x154)
> [<c02bc734>] (blk_register_queue) from [<c02cd610>]
> (device_add_disk+0x2c8/0x450)
> [<c02cd610>] (device_add_disk) from [<c0430fac>]
> (ubiblock_create+0x254/0x2e4)
> [<c0430fac>] (ubiblock_create) from [<c0421a3c>]
> (vol_cdev_ioctl+0x3e0/0x564)
> [<c0421a3c>] (vol_cdev_ioctl) from [<c018a55c>] (vfs_ioctl+0x30/0x44)
> [<c018a55c>] (vfs_ioctl) from [<c018ad2c>] (do_vfs_ioctl+0x694/0x798)
> [<c018ad2c>] (do_vfs_ioctl) from [<c018ae74>] (SyS_ioctl+0x44/0x6c)
> [<c018ae74>] (SyS_ioctl) from [<c0010720>] (ret_fast_syscall+0x0/0x34)
>
Missing Fixes and Cc-stable tags.
> Signed-off-by: Bradley Bolen <bradleybolen@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
BTW, just had a quick look at the code, and I think the locking can be
simplified a bit by keeping the devices_lock for the whole
ubiblock_create() operation instead of acquiring/releasing it several
times in the function (see [1]). It makes sense to do fine grained
locking when operations protected by the lock are time sensitive, but I
don't think this is the case here.
Regards,
Boris
[1]http://code.bulix.org/ox2562-258097
> ---
> drivers/mtd/ubi/block.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
> index b210fdb..1c12370 100644
> --- a/drivers/mtd/ubi/block.c
> +++ b/drivers/mtd/ubi/block.c
> @@ -390,7 +390,9 @@ int ubiblock_create(struct ubi_volume_info *vi)
>
> gd->fops = &ubiblock_ops;
> gd->major = ubiblock_major;
> + mutex_lock(&devices_mutex);
> gd->first_minor = idr_alloc(&ubiblock_minor_idr, dev, 0, 0, GFP_KERNEL);
> + mutex_unlock(&devices_mutex);
> if (gd->first_minor < 0) {
> dev_err(disk_to_dev(gd),
> "block: dynamic minor allocation failed");
> @@ -452,7 +454,9 @@ int ubiblock_create(struct ubi_volume_info *vi)
> out_free_tags:
> blk_mq_free_tag_set(&dev->tag_set);
> out_remove_minor:
> + mutex_lock(&devices_mutex);
> idr_remove(&ubiblock_minor_idr, gd->first_minor);
> + mutex_unlock(&devices_mutex);
> out_put_disk:
> put_disk(dev->gd);
> out_free_dev:
> @@ -471,7 +475,9 @@ static void ubiblock_cleanup(struct ubiblock *dev)
> blk_cleanup_queue(dev->rq);
> blk_mq_free_tag_set(&dev->tag_set);
> dev_info(disk_to_dev(dev->gd), "released");
> + mutex_lock(&devices_mutex);
> idr_remove(&ubiblock_minor_idr, dev->gd->first_minor);
> + mutex_unlock(&devices_mutex);
> put_disk(dev->gd);
> }
>
next prev parent reply other threads:[~2018-01-14 14:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-03 2:26 [PATCH] UBI: block: Must use a mutex when using idr_alloc/idr_remove Bradley Bolen
2018-01-14 14:39 ` Boris Brezillon [this message]
2018-01-14 22:20 ` Ezequiel Garcia
2018-01-17 19:46 ` Bradley Bolen
2018-01-17 20:04 ` Richard Weinberger
2018-01-17 20:06 ` Ezequiel Garcia
2018-01-17 20:10 ` Boris Brezillon
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=20180114153915.4c6141a4@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=bradleybolen@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@wedev4u.fr \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=richard@nod.at \
/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