Re: Runaway loop with the current git.

[Alan Cox]

> > So we have a buggy modprobe... 
> 
> 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.

> 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.

> 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.

> 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.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/