From: Ming Lei <ming.lei@redhat.com>
To: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mingfangsen <mingfangsen@huawei.com>, Guiyao <guiyao@huawei.com>,
zhangsaisai <zhangsaisai@huawei.com>,
"wubo (T)" <wubo40@huawei.com>
Subject: Re: [PATCH V2] brd: check parameter validation before register_blkdev func
Date: Tue, 14 Jan 2020 17:16:57 +0800 [thread overview]
Message-ID: <20200114091456.GA22268@ming.t460p> (raw)
In-Reply-To: <8b32ff09-74aa-3b92-38e4-aab12f47597b@huawei.com>
On Mon, Jan 13, 2020 at 09:43:23PM +0800, Zhiqiang Liu wrote:
> In brd_init func, rd_nr num of brd_device are firstly allocated
> and add in brd_devices, then brd_devices are traversed to add each
> brd_device by calling add_disk func. When allocating brd_device,
> the disk->first_minor is set to i * max_part, if rd_nr * max_part
> is larger than MINORMASK, two different brd_device may have the same
> devt, then only one of them can be successfully added.
It is just because disk->first_minor is >= 0x100000, then same dev_t
can be allocated in blk_alloc_devt().
MKDEV(disk->major, disk->first_minor + part->partno)
But block layer does support extended dynamic devt allocation, and brd
sets flag of GENHD_FL_EXT_DEVT too.
So I think the correct fix is to fallback to extended dynamic allocation
when running out of consecutive minor space.
How about the following approach?
And of course, ext devt allocation may fail too, but that is another
generic un-solved issue: error handling isn't done for adding disk.
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index a8730cc4db10..9aa7ce7c9abf 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -398,7 +398,16 @@ static struct brd_device *brd_alloc(int i)
if (!disk)
goto out_free_queue;
disk->major = RAMDISK_MAJOR;
- disk->first_minor = i * max_part;
+
+ /*
+ * Clear .minors when running out of consecutive minor space since
+ * GENHD_FL_EXT_DEVT is set, and we can allocate from extended devt
+ */
+ if ((i * disk->minors) & ~MINORMASK)
+ disk->minors = 0;
+ else
+ disk->first_minor = i * disk->minors;
+
disk->fops = &brd_fops;
disk->private_data = brd;
disk->flags = GENHD_FL_EXT_DEVT;
Thanks,
Ming
next prev parent reply other threads:[~2020-01-14 9:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-13 13:43 Zhiqiang Liu
2020-01-14 9:16 ` Ming Lei [this message]
2020-01-14 9:45 ` Ming Lei
2020-01-14 11:38 ` Zhiqiang Liu
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=20200114091456.GA22268@ming.t460p \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=guiyao@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuzhiqiang26@huawei.com \
--cc=mingfangsen@huawei.com \
--cc=wubo40@huawei.com \
--cc=zhangsaisai@huawei.com \
/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
all inboxes | Powered by JetHome®