From: Yu Kuai yukuai3@huawei.com
commit e4c4871a73944353ea23e319de27ef73ce546623 upstream.
commit b1a811633f73 ("block: nbd: add sanity check for first_minor") checks that 'first_minor' should not be greater than 0xff, which is wrong. Whitout the commit, the details that when user pass 0x100000, it ends up create sysfs dir "/sys/block/43:0" are as follows:
nbd_dev_add disk->first_minor = index << part_shift -> default part_shift is 5, first_minor is 0x2000000 device_add_disk ddev->devt = MKDEV(disk->major, disk->first_minor) -> (0x2b << 20) | (0x2000000) = 0x2b00000 device_add device_create_sys_dev_entry format_dev_t sprintf(buffer, "%u:%u", MAJOR(dev), MINOR(dev)); -> got 43:0 sysfs_create_link -> /sys/block/43:0
By the way, with the wrong fix, when part_shift is the default value, only 8 ndb devices can be created since 8 << 5 is greater than 0xff.
Since the max bits for 'first_minor' should be the same as what MKDEV() does, which is 20. Change the upper bound of 'first_minor' from 0xff to 0xfffff.
Fixes: b1a811633f73 ("block: nbd: add sanity check for first_minor") Signed-off-by: Yu Kuai yukuai3@huawei.com Reviewed-by: Josef Bacik josef@toxicpanda.com Link: https://lore.kernel.org/r/20211102015237.2309763-2-yebin10@huawei.com Signed-off-by: Jens Axboe axboe@kernel.dk Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Wen Yang wenyang.linux@foxmail.com --- drivers/block/nbd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index bf8148ebd858..bd05eaf04143 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -1773,11 +1773,11 @@ static int nbd_dev_add(int index) disk->major = NBD_MAJOR;
/* Too big first_minor can cause duplicate creation of - * sysfs files/links, since first_minor will be truncated to - * byte in __device_add_disk(). + * sysfs files/links, since MKDEV() expect that the max bits of + * first_minor is 20. */ disk->first_minor = index << part_shift; - if (disk->first_minor > 0xff) { + if (disk->first_minor > MINORMASK) { err = -EINVAL; goto out_free_idr; }
On Tue, Feb 21, 2023 at 02:04:47AM +0800, wenyang.linux@foxmail.com wrote:
From: Yu Kuai yukuai3@huawei.com
commit e4c4871a73944353ea23e319de27ef73ce546623 upstream.
<snip>
I never recieved patch 0/4 or 1/4 of this series saying what it is for (and neither did lore.kernel.org.)
Please fix up and resend a v2 series.
thanks,
greg k-h
On Thu, Feb 23, 2023 at 10:39:17AM +0100, Greg Kroah-Hartman wrote:
On Tue, Feb 21, 2023 at 02:04:47AM +0800, wenyang.linux@foxmail.com wrote:
From: Yu Kuai yukuai3@huawei.com
commit e4c4871a73944353ea23e319de27ef73ce546623 upstream.
<snip>
I never recieved patch 0/4 or 1/4 of this series saying what it is for (and neither did lore.kernel.org.)
Ah, now I found patch 1/4, your email threading got broken somehow, odd...
thanks
greg k-h
linux-stable-mirror@lists.linaro.org