linux-kernel - Re: [RFC v2 0/6] driver-core: add asynch probe 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:	Fri, 5 Sep 2014 16:11:50 +0900
From:	Tejun Heo <tj@...nel.org>
To:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>, falcon@...zu.com,
	Takashi Iwai <tiwai@...e.de>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>, hare@...e.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Joseph Salisbury <joseph.salisbury@...onical.com>,
	bpoirier@...e.de, santosh@...lsio.com,
	"Luis R. Rodriguez" <mcgrof@...e.com>
Subject: Re: [RFC v2 0/6] driver-core: add asynch probe support

Hello,

On Thu, Sep 04, 2014 at 11:37:21PM -0700, Luis R. Rodriguez wrote:
> Tejun's concerns on this regressing some driver's scripts which expect
> the device to be available after loading remains valid, and the only
> thing we can do to help there is to annotate the expecations on the
> use of this "feature" to driver users. Scripts should be not be relying
> on the driver init anyway so that type of usage should be phased out
> and they should be hunting in udev for things popping up.

Ummm... I really don't think we can say that.  This was one of the
supported ways to wait for the probing of pre-existing devices on
driver load.  We can't simply go and declare that "scripts should not
be relying on the driver init anyway".  We just can't do that.

> I'm a bit concerned about this actually regressing load time on
> drivers that use this though instead of just having the module
> probe run off of finit_module() though. Even with a kthread alternative
> at least Santosh (Cc'd) has noted a regression in terms of time it
> takes to complete probe on cxgb4. I'll eventually get your exact
> numbers, but for now its an obvious regression *with* kthreads,
> this solution goes with:
>
> queue_work(system_unbound_wq, async_probe_work)
>
> This is surely going to make things even worse... We could
> use system_highpri_wq, or change the scheduling priority, but
> for that I'd prefer to get feedback and someone to decide what
> the right choice (TM) should be.

It shouldn't add any noticeable delays in probing.  If it does, we
should track down why that's happening and fix it.

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/