Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp4192586imj; Tue, 12 Feb 2019 11:22:22 -0800 (PST) X-Google-Smtp-Source: AHgI3IYCvvK8Mf6H7Oe4ysnNuBCQ7JAmtNmkaw8EdQAXVcfxA1QjZOoUPksz61PL+K98jJFKTIcx X-Received: by 2002:a62:9604:: with SMTP id c4mr5446131pfe.200.1549999342180; Tue, 12 Feb 2019 11:22:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549999342; cv=none; d=google.com; s=arc-20160816; b=GPH+VOijAo0IinpgQ91/d3QoxOD64zRZpoBwQvuBdjB1mUUmUzKVrNmlIMGkjFkcrx uBXUs+I8RYw5N7plQDxrExTH/XtFNNfjlAjCc0yGJFq6cbYm9CSw1VHTZQvPgySqXqcv yOMhSrizP/lAjlbUtHZ36Lw5/oJ/7u89ySSG11B94cJrJGtKLLi/Kpcnt26qMSCqmYs2 1ra1ghEHcxdBQTvZZxkfibSs5dEqwtg6U+7da01yerGPfLDBJI/LbopHLt2L5FaXSVf8 2SfLZF8CvGb2WCCbHt6iP+yS4e64+eRFm2aQSR9Ahh7Ttikau2sX3xoHErwrvfwI8Elb hJzA== 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=O9p/osdmvH+FGObEvTNIIKCwetx3JRXzh/BssBbIhCw=; b=MlvvUrfIxhloEuH/Xo6GOWHiK17WQBoybgZ3//cOo1RX30x8H+4RXam/TDHNCYI6di k1AFSAhJSO53bEgwhU4YTuvljhQ+CN7qQHaftLZV2UqvqHmuLaIjFYUbrq2PH6EEbRhW 5odcYMrmS2J8t3DOWy0I8uQs/smAqu7jyouZlFDod6MvXRWlrAKO/WXYGTb9au1DtQA9 ht1Au/3Ri1Ow0FtPiNtn61LWs5msrbwniBBFOPCZ+qrhxCU9QdVTlx4h8kUXgmIplQQP rBqpeXSyaeh/znGR4hN+A6Z4UKq0KiKZvMjRZwksi8SGB7KEe5vHuPnKNFKStxD0tcsF eJKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=RPXynVxh; 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 p1si14270817pld.353.2019.02.12.11.22.06; Tue, 12 Feb 2019 11:22:22 -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=@kernel.org header.s=default header.b=RPXynVxh; 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 S1731668AbfBLSc3 (ORCPT + 99 others); Tue, 12 Feb 2019 13:32:29 -0500 Received: from mail.kernel.org ([198.145.29.99]:36036 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729933AbfBLSc3 (ORCPT ); Tue, 12 Feb 2019 13:32:29 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BEB40222BB; Tue, 12 Feb 2019 18:32:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549996348; bh=N0JPzLwjEXXG65mqj5yugZBr2I960YKVnANv7FcWrWk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RPXynVxhjNiiiBBVrOO+EdliNcu9g8ZMFEo9GMrPNk3boggiEVsKUBIGH9Fh44wlq 7lWktMAmzov/95+r8XzwPsiWFXJM010fJHGvkJkmm85DlAz2UG7y/6cZbZYa/HIwcj owNJfijgIFlLA/3DwXlpbgjcf4kIt44qHAAmfa8k= Date: Tue, 12 Feb 2019 19:32:25 +0100 From: Greg KH To: cgxu519 Cc: viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 2/2] chardev: showing minor range for chardev in the output of /proc/devices Message-ID: <20190212183225.GA14528@kroah.com> References: <20190212084739.27602-1-cgxu519@gmx.com> <20190212084739.27602-2-cgxu519@gmx.com> <20190212090212.GE31657@kroah.com> <20190212152053.GA25804@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 12, 2019 at 11:41:35PM +0800, cgxu519 wrote: > On 2/12/19 11:20 PM, Greg KH wrote: > > On Tue, Feb 12, 2019 at 11:18:22PM +0800, cgxu519 wrote: > > > On 2/12/19 5:02 PM, Greg KH wrote: > > > > On Tue, Feb 12, 2019 at 04:47:39PM +0800, Chengguang Xu wrote: > > > > > Currently chardev allows to share major, showing > > > > > major with minor range for chardev will be more > > > > > helpful. > > > > > > > > > > Signed-off-by: Chengguang Xu > > > > > --- > > > > > fs/char_dev.c | 4 +++- > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/fs/char_dev.c b/fs/char_dev.c > > > > > index b25b1da097d5..6f00acdeb308 100644 > > > > > --- a/fs/char_dev.c > > > > > +++ b/fs/char_dev.c > > > > > @@ -55,7 +55,9 @@ void chrdev_show(struct seq_file *f, off_t offset) > > > > > mutex_lock(&chrdevs_lock); > > > > > for (cd = chrdevs[major_to_index(offset)]; cd; cd = cd->next) { > > > > > if (cd->major == offset) > > > > > - seq_printf(f, "%3d %s\n", cd->major, cd->name); > > > > > + seq_printf(f, "%3d %s (%u-%u)\n", cd->major, cd->name, > > > > > + cd->baseminor, > > > > > + cd->baseminor + cd->minorct - 1); > > > > You are changing the format of a userspace file, what tools are going to > > > > break when you do this? > > > I'll remove this part in V2. Do you have any idea how to get the minor > > > range info for particular major? Or adding a similar file to somewhere > > > under /sys is acceptable? > > Why do you need to know the minor range? What can userspace do with > > this that actually matters? > > Assume that when we try to load a driver module and fail with -EBUSY > because of minor range overlapping, then what can we do for this case? > we even don't know what range has occupied and what range is available. Why would drivers ever have minor range overlapping? Either they are using a reserved range which is properly documented in the kernel file, or they are using a dynamic range and that will never overlap as they are allocated as needed. So when has this ever happened in the real world? > Also, I think we can obviously notice range overlapping bugs by showing > all registered minor ranges. Again, how can a range overlap? If so, that's a bug that we can fix now and has nothing to do with the proc file, which will not show an overlap as that can not happen at runtime. thanks, greg k-h