Message-ID: <CAB=NE6XS9pWmfO7xjTpLFG1OdOJ=UktbOK5pjJCK8hzfXagfXQ@mail.gmail.com>
Date:	Fri, 12 Sep 2014 13:09:57 -0700
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	Tom Gundersen <teg@...m.no>, Tejun Heo <tj@...nel.org>
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Takashi Iwai <tiwai@...e.de>, Kay Sievers <kay@...y.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Praveen Krishnamoorthy <praveen.krishnamoorthy@...gotech.com>,
	hare <hare@...e.com>,
	Nagalakshmi Nandigama <nagalakshmi.nandigama@...gotech.com>,
	Wu Zhangjin <falcon@...zu.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	"mpt-fusionlinux.pdl" <MPT-FusionLinux.pdl@...gotech.com>,
	Tim Gardner <tim.gardner@...onical.com>,
	Benjamin Poirier <bpoirier@...e.de>,
	Santosh Rastapur <santosh@...lsio.com>,
	Casey Leedom <leedom@...lsio.com>,
	Hariprasad S <hariprasad@...lsio.com>,
	Pierre Fersing <pierre-fersing@...rref.org>,
	Sreekanth Reddy <sreekanth.reddy@...gotech.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Abhijit Mahajan <abhijit.mahajan@...gotech.com>,
	systemd Mailing List <systemd-devel@...ts.freedesktop.org>,
	Linux SCSI List <linux-scsi@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Joseph Salisbury <joseph.salisbury@...onical.com>
Subject: Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Thu, Sep 11, 2014 at 10:48 PM, Tom Gundersen <teg@...m.no> wrote:
> On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez
> <mcgrof@...not-panic.com> wrote:
>> On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen <teg@...m.no> wrote:
>>> How about simply introducing a new flag to finit_module() to indicate
>>> that the caller does not care about asynchronicity. We could then pass
>>> this from udev, but existing scripts calling modprobe/insmod will not
>>> be affected.
>>
>> Do you mean that you *do want asynchronicity*?
>
> Precisely, udev would opt-in, but existing scripts etc would not.

Sure that's the other alternative that Tejun was mentioning.

>>> But isn't finit_module() taking a long time a serious problem given
>>> that it means no other module can be loaded in parallel?
>>
>> Indeed but having a desire to make the init() complete fast is
>> different than the desire to have the combination of both init and
>> probe fast synchronously.
>
> I guess no one is arguing that probe should somehow be required to be
> fast, but rather:
>
>> If userspace wants init to be fast and let
>> probe be async then userspace has no option but to deal with the fact
>> that async probe will be async, and it should then use other methods
>> to match any dependencies if its doing that itself.
>
> Correct. And this therefore likely needs to be opt-in behaviour per
> finit_module() invocation to avoid breaking old assumptions.

Sure.

>> For example
>> networking should not kick off after a network driver is loaded but
>> rather one the device creeps up on udev. We should be good with
>> networking dealing with this correctly today but not sure about other
>> subsystems. depmod should be able to load the required modules in
>> order and if bus drivers work right then probe of the remnant devices
>> should happen asynchronously. The one case I can think of that is a
>> bit different is modules-load.d things but those *do not rely on the
>> timeout*, but are loaded prior to a service requirement. Note though
>> that if those modules had probe and they then run async'd then systemd
>> service would probably need to consider that the requirements may not
>> be there until later. If this is not carefully considered that could
>> introduce regression to users of modules-load.d when async probe is
>> fully deployed. The same applies to systemd making assumptions of kmod
>> loading a module and a dependency being complete as probe would have
>> run it before.
>
> Yeah, these all needs to be considered when deciding whether or not to
> enable async in each specific case.

Yes and come to think of it I'd recommend opting out of async
functionality for modules-load.d given that it does *not* hooked with
the timeout and there is a good chances its users likely do want to
wait for probe to run at this point.

Given this I also am inclined now for the per module request to be
async or not (default) from userspace. The above would be a good
example starting use case.

>> I believe one concern here lies in on whether or not userspace
>> is properly equipped to deal with the requirements on module loading
>> doing async probing and that possibly failing. Perhaps systemd might
>> think all userspace is ready for that but are we sure that's the case?
>
> There almost certainly are custom things out there relying on the
> synchronous behaviour, but if we make it opt-in we should not have a
> problem.

Indeed.

BTW as for the cxgb4 device driver it fails to load because it relies
on get_vpd_params() on probe, that end sup calling
pci_vpd_pci22_wait() which will fail if if
fatal_signal_pending(current). This is an example now completely
unrelated to the OOM series, and any other uses of
fatal_signal_pending(current) should trigger similar failures on
device drivers.

  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/

Powered by blists - more mailing lists