On Thu, Sep 11, 2014 at 10:48 PM, Tom Gundersen <teg@xxxxxxx> wrote: > On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez > <mcgrof@xxxxxxxxxxxxxxxx> wrote: >> On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen <teg@xxxxxxx> 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-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
