[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190212183225.GA14528@kroah.com>
Date: Tue, 12 Feb 2019 19:32:25 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: cgxu519 <cgxu519@....com>
Cc: viro@...iv.linux.org.uk, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH 2/2] chardev: showing minor range for chardev in the
output of /proc/devices
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 <cgxu519@....com>
> > > > > ---
> > > > > 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
Powered by blists - more mailing lists