lkml.org 
[lkml]   [2013]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
    On Tue, Jan 15, 2013 at 9:36 AM, Linus Torvalds
    <torvalds@linux-foundation.org> wrote:
    >
    > This kind of "let's randomly encourage people to write subtly buggy
    > code that has magical timing dependencies, so that the developer won't
    > likely even see it because he has fast disks etc" code is totally
    > unacceptable. And this code was *designed* to be that kind of buggy.

    Btw, we could *possibly* do this the other way around. Wait for all
    async work by default, but then have a really hacky way to turn that
    off for modules that explicitly don't want it, because they know they
    can be loaded in async context, and they don't do any async work
    themselves. Then we could make the IO schedulers set that flag ("I
    know I'm loaded from async space, and I know I'm not myself doing any
    async init")

    Quite frankly, I'd still much rather prefer the automated approach -
    or even better, just avoiding the "load modules in async context"
    entirely. But at least the "I can put a huge comment about why I don't
    want to be waited on" would be much more acceptable than the "I need
    to explicitly tell the world that it needs to wait on me".

    So Ming Lei's patch was "easily subtly buggy by mistake" (showing that
    by the fact that it was indeed buggy), while the opposite model where
    you have to explicitly ask people not to wait for you could still be
    very buggy, but at least now it needs to explicitly do extra work in
    order to be buggy.

    So if an interface is fragile, it should aim to be fragile in the
    right way - making the fragility explicit, so that people can grep for
    it, and people can add comments to the particular code that marks it
    fragile. The default behavior should be the robust one.

    And if would be lovely to add a warning to the "people loaded a module
    from async context" case, so that we'd *see* this.

    Tejun, is there a good way for code to see "I'm running in async
    context"? Then we could do something like

    WARN_ON_ONCE(wait && system_state == SYSTEM_RUNNING && in_async_thread());

    in kernel/kmod.c (__request_module()). That should at least warn about
    this whole issue happening.

    Linus


    \
     
     \ /
      Last update: 2013-01-15 20:01    [W:4.382 / U:0.648 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site