linux-kernel - Re: [RFC v1 0/3] driver-core: add asynch module loading support

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:	Sun, 31 Aug 2014 19:03:06 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>, falcon@...zu.com,
	tiwai@...e.de, linux-kernel@...r.kernel.org, oleg@...hat.com,
	akpm@...ux-foundation.org, penguin-kernel@...ove.sakura.ne.jp,
	joseph.salisbury@...onical.com, bpoirier@...e.de,
	"Luis R. Rodriguez" <mcgrof@...e.com>
Subject: Re: [RFC v1 0/3] driver-core: add asynch module loading support

Hello, Dmitry.

On Sun, Aug 31, 2014 at 03:51:40PM -0700, Dmitry Torokhov wrote:
> > > Luis, care to redo the patches in this way?  It should be a lot simpler
> > > (no messing around with init levels and linker fun...)
> > 
> > I don't think binding that switch to the driver is gonna work.  This
> > is mainly about the behavior expected by the entity which initiated
> > module loading not about specific drivers.
> 
> Why would you say that? In my particular userspace we do not have modules.

Heh, I think we're just thinking about different problems.  For me,
this is all from the bug report that I was cc'd on where systemd times
out module load after 30s and sends SIG_KILL to the module loading
thread which aborts module loading which in turn leads to nasty
things.  The logical way to address that is separating out module
loading and device probing.  Given the way we associate drivers with
devices these days, it makes a lot of sense to separate them out
anyway.

> >  I'm fairly certain that
> > there are userland scripts which depend on synchronous device probing
> > on module loading, especially for storage devices, so we can't simply
> > mark, say, libata as needing async probing and do it always
> > asynchronously.
> 
> Right. But for many devices (input ones for example, USB as well, etc) that are
> essentially hot-pluggable userspace has been long ready to handle async order.

Sure, all modern userspace should be completely fine without ordering
but there are niche userspaces out in the wild which don't do much of
the dynamic things and just expect devices to be assigned consistent
nodes across multiple boots, so keeping the order is mostly about
backward compatibility.

Thanks.

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