linux-kernel - Re: [PATCH 8/8] driver-core: allow enabling async probing for all modules and builtins

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]

Date:	Thu, 21 May 2015 21:02:47 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Olof Johansson <olof@...om.net>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Subject: Re: [PATCH 8/8] driver-core: allow enabling async probing for all
 modules and builtins

On Wed, May 20, 2015 at 09:34:09PM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 20, 2015 at 09:44:59AM -0700, Dmitry Torokhov wrote:
> > On Wed, May 20, 2015 at 12:27:34AM -0700, Greg Kroah-Hartman wrote:
> > > On Mon, Mar 30, 2015 at 04:20:10PM -0700, Dmitry Torokhov wrote:
> > > > From: "Luis R. Rodriguez" <mcgrof@...e.com>
> > > > 
> > > > Folks wishing to test enabling async probe for all built-in drivers
> > > > and/or for all modules can use
> > > > __DEBUG__kernel_force_builtin_async_probe or
> > > > __DEBUG__kernel_force_modules_async_probe kernel parameters.
> > > > 
> > > > Activating either one will taint your kernel.
> > > > 
> > > > Signed-off-by: Luis R. Rodriguez <mcgrof@...e.com>
> > > > [Dmitry: split off from another patch, split into 2 parameters, moved
> > > > over to core_param_unsafe()]
> > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
> > > 
> > > I've dropped this from my tree as I don't want to add these options,
> > > only to have to remove them later on when it's found out that these were
> > > a bad idea.
> > 
> > OK.
> > 
> > >
> > > I don't want to create a user api that we have to keep around for
> > > forever, and this would be such a thing (specifying how the kernel
> > > probing works.)
> > 
> > Given that they are marked as __DEBUG and taint the kernel I do not
> > believe they shoudl be considered as an API/ABI. We can emphasise this
> > in docs and/or kernel messages.
> 
> But they are options a user can set on the command line, and changing
> command lines is a pain.  Yes, it's a bit odd name, but we don't have
> any other such naming scheme for command line options, so I don't know
> what to suggest here.

What if we document such prefixes are for loose things we can change
at any time? That is, not API and we treat as we do with debugfs.

> > >  For debugging, can't you just patch up your kernel and
> > 
> > I can, but I do not have all hardware in my possession to validate the
> > behavior.
> > 
> > > test this out?  What's the real use of this?  Who do you want to enable
> > > these?  And why?  What will you do with the information?
> > 
> > The expectation was that distribution developers might use these
> > switches when evaluating whether they are ready to switch to
> > asynchronous probing.
> 
> Distro developers will never do that, they have to support just too many
> different hardware types.  And there's no real gain here for them.

Maybe old distros, new distros like ChromeOS will and in this case have.
I think Dmitry did at least. I would bet that some mobile platform distros
might want to do this too.

  Luis
--
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/