Messages in this thread Patch in this message | | | Date | Thu, 5 Oct 2023 22:46:41 +0200 (CEST) | From | Richard Weinberger <> | Subject | Re: [PATCH v4 5/8] mtd: ubi: attach MTD partition from device-tree |
| |
----- Ursprüngliche Mail ----- > Von: "richard" <richard@nod.at> > ----- Ursprüngliche Mail ----- >> diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c >> index e0618bbde3613..99b5f502c9dbc 100644 >> --- a/drivers/mtd/ubi/block.c >> +++ b/drivers/mtd/ubi/block.c >> @@ -470,7 +470,7 @@ int ubiblock_remove(struct ubi_volume_info *vi, bool force) >> } >> >> /* Found a device, let's lock it so we can check if it's busy */ >> - mutex_lock(&dev->dev_mutex); >> + mutex_lock_nested(&dev->dev_mutex, SINGLE_DEPTH_NESTING); > > The usage of mutex_lock_nested() in this patch looks fishy. > Can you please elaborate a bit more why all these mutexes can be taken twice? > (Any why not more often).
I think I figured myself. ubiblock_ops->open() and ->release() are both called with disk->open_mutex held. ubiblock_open() and ubiblock_release() take dev->dev_mutex. So, the locking order is open_mutex, followed by dev_mutex.
On the other hand, ubiblock_remove() is called via UBI notify. It takes first dev_mutex and then calls del_gendisk() which will trigger ubiblock_ops->release() under disk->open_mutex but takes dev_mutex again. So, we this not only takes a lock twice but also in reverse order. mutex_lock_nested() might silence lockdep but I'm not sure whether this is safe at all.
Thanks, //richard
| |