linux-kernel - Re: [PATCH 3/3] misc: use a proper range for minor number dynamic allocation

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20091110164536.GA3628@vespa.holoscopio.com>
Date:	Tue, 10 Nov 2009 14:45:37 -0200
From:	Thadeu Lima de Souza Cascardo <cascardo@...oscopio.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org, device@...ana.org,
	akpm@...ux-foundation.org, rubini@...dd.com, gregkh@...e.de
Subject: Re: [PATCH 3/3] misc: use a proper range for minor number dynamic
	allocation

On Mon, Nov 09, 2009 at 04:34:07PM -0800, H. Peter Anvin wrote:
> On 11/09/2009 04:30 PM, Thadeu Lima de Souza Cascardo wrote:
> > The current dynamic allocation of minor number for misc devices has some
> > drawbacks.
> > 
> > First of all, the range for dynamic numbers include some statically
> > allocated numbers. It goes from 63 to 0, and we have numbers in the
> > range from 1 to 15 already allocated. Although, it gives priority to the
> > higher and not allocated numbers, we may end up in a situation where we
> > must reject registering a driver which got a static number because a
> > driver got its number with dynamic allocation. Considering fs/dlm/user.c
> > allocates as many misc devices as lockspaces are created, and that we
> > have more than 50 users around, it's not unreasonable to reach that
> > situation.
> > 
> > The proposed solution uses the not yet reserved range from 64 to 127. If
> > more devices are needed, we may push 64 to 16.
> > 
> 
> Again, why not push these up above 256?
> 
> 	-hpa

I don't have a problem with this. However, as Alan has pointed out,
there may be old setups that rely on minor numbers below 256. I have
thought of that, but I'm sure there's argument against it. I've decided
to submit it more closely to what is done today, that is, 64 devices. As
I said, there's still space for 48 more devices, and, besides DLM, I
couldn't find at first glance any other user that requests more than one
single device.

Anyway, the only thing that worries me when pushing it above 256 is
that, right now, the bitmap is statically allocated, and I think a
single page would be pretty more than we have and we need right now.
Otherwise, I would suggest using a dynamic allocation system, which
would be less simple than what we have right now, and Andrew has pointed
out.

Best Regards,
Cascardo.

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)