linux-kernel - Re: [PATCH] char: misc: Allow minors values up to MINORMASK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 9 Sep 2022 20:25:55 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     D Scott Phillips <scott@...amperecomputing.com>
Cc:     Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] char: misc: Allow minors values up to MINORMASK

On Fri, Sep 09, 2022 at 11:18:54AM -0700, D Scott Phillips wrote:
> Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
> 
> > On Tue, Sep 06, 2022 at 12:52:13PM -0700, D Scott Phillips wrote:
> >> For per-cpu coresight_tmc devices, we can end up with hundreds of devices
> >> on large systems that all want a dynamic minor number.  Switch the dynamic
> >> minors allocator to an ida and add logic to allocate in the ranges [0..127]
> >> and [256..MINORMASK]. Allocations start from 127 growing downwards and then
> >> increasing from 256, so device numbering for the first 128 devices should
> >> be the same as before.
> >> 
> >> Signed-off-by: D Scott Phillips <scott@...amperecomputing.com>
> >> ---
> >>  drivers/char/misc.c | 41 ++++++++++++++++++++++++++++-------------
> >>  1 file changed, 28 insertions(+), 13 deletions(-)
> >
> > So you are adding more logic to the kernel for no change at all?
> >
> > Why is this needed?  What changed here except the underlying data
> > structure being used?
> 
> Hi Greg, the goal of the change I'm proposing here is to increase the
> maximum number of dynamic misc devices from 128 to 1048448.

You never said that anywhere in the changelog text :(

What would you like to see if you had to review such a change?  Please
fix up the changelog text to make sense when having to describe it to
someone who has no prior knowledge of what you were trying to do.

Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/SubmittingPatches for what is needed in order
to properly describe the change when you resend this.

thanks,

greg k-h