linux-kernel - Re: Allow setting of number of raw devices as a module parameter

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: <20110430153452.GA21439@suse.de>
Date:	Sat, 30 Apr 2011 08:34:52 -0700
From:	Greg KH <gregkh@...e.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, Jan Kara <jack@...e.cz>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Allow setting of number of raw devices as a module parameter

On Sat, Apr 30, 2011 at 11:29:37AM +0100, Alan Cox wrote:
> On Fri, 29 Apr 2011 16:28:17 -0700
> Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
> > On Fri, 29 Apr 2011 00:24:29 +0200
> > Jan Kara <jack@...e.cz> wrote:
> > 
> > > Allow setting of maximal number of raw devices as a module parameter. This
> > > requires changing of static array into a vmalloced one (the array is going to
> > > be too large for kmalloc).
> 
> A large vmalloc array is very antisocial on a 32bit x86 box. It looks
> like almost all of it would become sane if there was an array of pointers
> to raw devices and the devices were initially allocated on need (even if
> for now only recovered on rmmod)

In practice, we've never seen a problem with this[1].  Machines that
want thousands of raw devices have plenty of memory to handle this
situation.

I doubt adding the complexity of dynamically allocating the devices
as-needed is worth it for the very few systems that ever use this
driver, compounded with the fact that we keep saying that this code
isn't to be used by "normal" people anyway.

thanks,

greg k-h

[1] Again, this has been shipping for years in SLES kernels with no
reported bug reports.  I know that's not really a valid reason to do
things, but it is a data point for the simplicity of this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/