lkml.org 
[lkml]   [2008]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Runaway loop with the current git.
    On Sun, Dec 07, 2008 at 11:58:20AM +0000, Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
    > > Which nevertheless should not break boot process...
    >
    > Now you are talking complete crap. If init crashes what happens. If I
    > have the wrong root fs listed what happens ?
    >
    > Gee it breaks. Early userspace actually does have to be correct.

    Heh, if userspace writes more than kernel's buffer size, what happens?
    We suddenly stopped to trust userspace? What if modprobe itself will do
    that? Do not differentiate bugs by the nature of not-bad and bad-enough:
    we do not trust userspace, even init, and it looking at the very end of
    the mail you will find again why this loading crap is a kernel problem.

    > > should not hung. Detect recursion, do not allow more than 1-2-3
    > > simultaneous modprobes, whatever, but do not say, that kernel behaves
    > > that bad just because userspace is allowed to do that.
    >
    > Please read the code: that is what we do. That is *WHY* you got the
    > runaway modprobe message. It was caught but despite that the broken
    > initrd failed to recover. We've had that feature for years.

    Apparently just reading the code does not magically fix kernel problems.
    What's the cosmic rays should initird check when it is asked by kernel
    to load the module? It tries to load it, which in turn tries to load it
    again. Since initird does not use libastral yet, it is up to kernel to
    decide what to load and when to ask userspace about that.

    > > And what's the argument of being close to a release? Do you propose to
    > > hide the head into the sand and point a finger to anyone else saying its
    > > not a kernel's problem? If prerelease has a bug, it should be fixed, and
    > > not hidden under the cover.
    >
    > Its an incredibly obscure corner case. It is not appropriate to totally
    > trash years of kernel testing by panic re-ordering some init functions
    > just before a release. You will undoubtedly harm more people than you'll
    > please.

    Registering purely software class device not being backed by real
    hardware since appropriate buses are not yet available? Apparently I
    know how to fix this problem: I will write a simple console driver
    called 'prayer', which will just sacrifice a little CPU's heat to the
    Raa-god when anyone tries to write something to console. And this driver
    will later be replaced with real console. Ooops, doesn't above patch
    from Kay do the same?

    > > What about storing a small stack of recently requested device ids, and
    > > if new request is about to ask one from that stack, return error? I can
    > > cook up the patch tomorrow.
    >
    > That would be an interesting experiment for 2.6.29 however we do requests
    > in lots of different formats so it might be a bit more complex. You could
    > store the last few strings. However the existing runaway code caught it
    > and will have resulted in the -ENXIO path occuring anyway so I don't see
    > what your "change" will achieve.

    It will not infinitely try to load module, which tries to load itself
    again via obscure kernel pathes, return error and continue.

    I remind again: all console/tty stuff in my setup is built-in, so there
    should be no module request at all, but since earlier registered code
    does not know that, kernel believes that console is somewhere in the
    module. Having dumb device registered first is a fix for this problem.

    --
    Evgeniy Polyakov


    \
     
     \ /
      Last update: 2008-12-07 14:13    [W:5.912 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site