----- Ursprüngliche Mail ----- > Von: "richard" <richard@xxxxxx> > ----- 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
