Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Tue, Aug 9, 2016 at 10:17 AM, Greg KH <greg@kroah.com> wrote:
> On Tue, Aug 09, 2016 at 10:08:07AM +0200, Daniel Vetter wrote:
>> On Thu, Aug 4, 2016 at 11:50 AM, Greg KH <greg@kroah.com> wrote:
>> > On Thu, Aug 04, 2016 at 11:22:23AM +0300, Jani Nikula wrote:
>> >> So I admit to being pretty clueless wrt the fine details of module
>> >> loading, but I'm wondering if there could be any way of the module being
>> >> loaded telling the kernel (via a call, not by returning from probe) to
>> >> hold its horses for a while, and keep loading other modules. Sort of
>> >> like deferred probe, but without the full cleanup-retry cycle. The call
>> >> would return to the module later (not unlike deferred probe retries the
>> >> probe), and you could try again whatever it was that made you realize
>> >> you need to defer.
>> >
>> > Nope, it doesn't work that way, sorry.
>>
>> Why? If I just postpone the entire driver load to an async worker and
>> then block if it's not there, that should work?
>
> Maybe, but the code patch from probe() in the driver core, and module
> loader, might be assuming that all is ok, only to have your async init
> later on realize that things are not ok.  How you could propagate that
> error back into the driver core might be difficult, if not impossible.

Hm, I hoped we've made progress on that entire idea of async driver
load, and userspace no longer depending upon accurate driver load
error codes from modprobe.

>> > Nice try, just unwind your initialization properly :)
>>
>> There's a slight pratical problem of this being hard to test. Sure in
>> theory it's easy, but given how often we bomb normal module unload
>> already (and that's something our CI tests) practice disagrees.
>
> probe()/disconnect()/probe() in the driver core as an option might be a
> fun way to stress this as others have pointed out here.

I didn't mean "hard to test" as in "I don't know how" - we have a
testcase in CI for this. More as in, among the bazillion bugs I'm
fighting, making driver load perfectly race-free in the face of load
failures (or eventual unloading) isn't a terrible high priority.
Especially since with an on-chip gpu it's pretty hard for normal users
to be able to even hit those paths ;-) If instead we'd be able to just
stall until the thing we need shows up, that would fix the problem
without sending the validation complexity through the roof.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch