Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4353430ybl; Mon, 3 Feb 2020 17:22:56 -0800 (PST) X-Google-Smtp-Source: APXvYqx4JGM3Gdh6hxPYIVAHs35R4NPV2F/ouiJpSZXWKS/CjMQQfTFnRZ9Jo2G1kqWLPIadaJim X-Received: by 2002:a9d:6952:: with SMTP id p18mr8013192oto.270.1580779376465; Mon, 03 Feb 2020 17:22:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580779376; cv=none; d=google.com; s=arc-20160816; b=RuNFNgfK8VkK5CYMecxXeyTfAsCLLfjl5wVbK2+MzydT79ZIndXHKWmSBWdK/TJmrs DCqBGcKwtrIYOz/yEN1B8VWWssVoxAdArSZlCy8wOw2xyJwxsroaHgWlDS3dKSU+pg99 FyF7xEV5rCX3QeFkMw9LiJQ0jgaPh5mMKduk1XAyQF+94L1qxEDjy3HGTwLyRkxrD0Pa k2kqP8yQB9zynUqPg68AfsAGiAeWebaPnVqhJgXKRiJ4fanG1/dvwz6hrFfLM4l4NdXO k3NCqnBPI0p1lvtnEY6GZ71g0deWBE9X/nYgYs9ZeL/F7+apsACRGtXaio6lk+UQtaog 6gBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=inSfO6g6fMkyORIsTrC1iA5o6n2oe4Zj34ttSSDteNc=; b=zPcNnNKL6Zp/xTbdKCwRz2A5ZU1jooVeDEKCODOBGYT4Zv45JZedxhUIUTv0ZFBN1m olZbDdoeBEqv4boI+eL4qWKCYfNG1OtHTulnZqvP1ZZ/kDXkvadf7jX7+sn+Zkm4VQQ5 wLjyaXtrasyEDn23ePH9p/wm/mMUnvaGVyDmYgI1wjpil3yyR7noXbYuwvBxeRz2BGH+ VCelNYqJvifSRcDpxZUvL/HFXn+ls7I2wEjqYGNvYGVlV4uVEzMlbzI+FSD0MuORe5So AV7MkE1gwPil0RKLI8BVUTeOeE0JrP+WtapbYlS6ZJwWEKVNrpR/vWS2QHzILO+fpIsY jUtA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i194si6238064oib.73.2020.02.03.17.22.40; Mon, 03 Feb 2020 17:22:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726992AbgBDBVm (ORCPT + 99 others); Mon, 3 Feb 2020 20:21:42 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:57692 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726369AbgBDBVl (ORCPT ); Mon, 3 Feb 2020 20:21:41 -0500 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 46FACBF277107A2ED144; Tue, 4 Feb 2020 09:21:39 +0800 (CST) Received: from [127.0.0.1] (10.173.220.183) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.439.0; Tue, 4 Feb 2020 09:21:29 +0800 Subject: Re: [PATCH V4] brd: check and limit max_part par To: Ming Lei CC: Jens Axboe , , "linux-kernel@vger.kernel.org" , Mingfangsen , Guiyao , Louhongxiang References: <76ad8074-c2ba-4bb3-3e8b-3a4925999964@huawei.com> <20200203122005.GB31450@ming.t460p> From: Zhiqiang Liu Message-ID: <9d82e25c-c909-3180-e987-260f53de51a4@huawei.com> Date: Tue, 4 Feb 2020 09:21:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20200203122005.GB31450@ming.t460p> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.220.183] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/2/3 20:26, Ming Lei wrote: > On Tue, Jan 21, 2020 at 12:04:41PM +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. >> when rmmod brd.ko, it will cause oops when calling brd_exit. >> >> +static inline void brd_check_and_reset_par(void) >> +{ >> + if (unlikely(!max_part)) >> + max_part = 1; >> + >> + if (max_part > DISK_MAX_PARTS) { >> + pr_info("brd: max_part can't be larger than %d, reset max_part = %d.\n", >> + DISK_MAX_PARTS, DISK_MAX_PARTS); >> + max_part = DISK_MAX_PARTS; >> + } >> + >> + /* >> + * make sure 'max_part' can be divided exactly by (1U << MINORBITS), >> + * otherwise, it is possiable to get same dev_t when adding partitions. >> + */ >> + if ((1U << MINORBITS) % max_part != 0) >> + max_part = 1UL << fls(max_part); >> +} > > You should move the above change before capping it to DISK_MAX_PARTS > since 1UL << fls() may increase 'max_part'. > Thanks for your suggestion. I will send the v5 patch.