Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4981251ybl; Tue, 14 Jan 2020 01:18:29 -0800 (PST) X-Google-Smtp-Source: APXvYqxK4sN0QY73jziMKS9M0GMNrCRnwFM6I98GBxLVyp4vCmy/1ezIBSGaKI98+XZCgx99Urjd X-Received: by 2002:aca:4587:: with SMTP id s129mr15381711oia.124.1578993509180; Tue, 14 Jan 2020 01:18:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578993509; cv=none; d=google.com; s=arc-20160816; b=t9aoNu8BIIULlT2xpBYGtFuHFGQTnZCImBq06gk0t3OknDY/didd0t5lw0CrHB7byy Hhp5GsvleRmbLuXMdog/krC0E8muBQya9OEii2kIkBi+Y7V/kaz9eRYi3I8OJ8t40PPx drZ9kADolGjICE5Clf0ouR2m6zE6Ry77Ar5QNqJSZt0Am+VgNsA0uHriKRAPWfNPrGER Pjk3ertDPUnisXhW/pywrC2Jre1LLdiqFlNrRgxeCEPoHoBSNP2Qh/g8074lxYd3l4JE vYLfDCWgwG+H3mkTPqUEvhgfJ8g12ofiMt4XUNhzrWDE45i+9VRyAIxxqqsBvma7RlqC pgpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=8EBCXj/eGLlwqN/DCPQsauNTZOGi8UpIemA9DO6Kwow=; b=XigDx0n2+dIYliYmuP0Ih6hkUQKi8n5go8eDZD/H1bbTcjTTJJqa28wIiwJ1PvYC+B SVYhNStw9gQCD286waP90dgYeIPN7xAaVg2flR14BvtvL8eNtMKfeQLRSUzXTkspG1V1 kOqWITvLpe6sOBQTwn7rdaXtGO0FUsvRarvXu4BnARhS7VdTb5zNZOkycla1/il+Xgk4 hCDfSKfLY7IR2FduqBfdcewrCqKmgbjgtLFJizKWF+VXoI61zu/ZwLF3R52Mfd7dcQda vSXIj7DMjjdXWMqzXTNlrOWgU3ljdyrm6KCis48IVqUU56dmaUCMEjzQ3qY2sFbRfzkb OMuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="E/gaxXT7"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h64si7845884oif.215.2020.01.14.01.18.17; Tue, 14 Jan 2020 01:18:29 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="E/gaxXT7"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728558AbgANJRR (ORCPT + 99 others); Tue, 14 Jan 2020 04:17:17 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:33765 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725820AbgANJRQ (ORCPT ); Tue, 14 Jan 2020 04:17:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578993435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8EBCXj/eGLlwqN/DCPQsauNTZOGi8UpIemA9DO6Kwow=; b=E/gaxXT7DvemEDkij5K2TxOwSWy60VWTcWHqlvDOOsv6kLydnscpBkwpnCWyOwbT3EhYuv ItSDxBU+WcOn1DJMKuEa1x92wwQRXDSp8wu4ixPolsvErveVJp1yUz1frMt1JQYL8/A3gA d4fv6s3AtRojxmbHuM/SJlFexRKSqcw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-167-nducgHoPO2ilQSImbti2UQ-1; Tue, 14 Jan 2020 04:17:12 -0500 X-MC-Unique: nducgHoPO2ilQSImbti2UQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CE708DBF7; Tue, 14 Jan 2020 09:17:10 +0000 (UTC) Received: from ming.t460p (ovpn-8-27.pek2.redhat.com [10.72.8.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8F3195DA80; Tue, 14 Jan 2020 09:17:01 +0000 (UTC) Date: Tue, 14 Jan 2020 17:16:57 +0800 From: Ming Lei To: Zhiqiang Liu Cc: axboe@kernel.dk, linux-block@vger.kernel.org, "linux-kernel@vger.kernel.org" , Mingfangsen , Guiyao , zhangsaisai , "wubo (T)" Subject: Re: [PATCH V2] brd: check parameter validation before register_blkdev func Message-ID: <20200114091456.GA22268@ming.t460p> References: <8b32ff09-74aa-3b92-38e4-aab12f47597b@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b32ff09-74aa-3b92-38e4-aab12f47597b@huawei.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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