CC: linux-modules
You haven't added your Signed-off-by; I believe it is customary for
one to do so when forwarding patches on behalf of another.
I will try to grok the code later. In general, I think the first
"safety precaution" patch is a really good idea. The second patch has
me confused right now; it would be nice if the code explained _why_ it
calls read_attribute() twice before falling back to /proc/modules.
Also we should try to ressurect the old test cases covering /proc/modules.
Thanks
Alan
<less useful verbiage follows>
...
> What's more,
> handling of module_in_kernel() failures could still be improved in order avoid
> similar problems when /sys is not mounted. Currently, if module_in_kernel()
> fails with -1, modprobe assumes the module is not present in the kernel.
Heh. ISTR a comment along the lines of 'if we're not sure, it's safe
to assume the module is not present'.
You're coy about which 'custom "install" sequences' trigger this fork
bomb... ah, I see it
oss-compat.conf:
install snd-pcm modprobe --ignore-install snd-pcm $CMDLINE_OPTS && {
modprobe --quiet snd-pcm-oss ; : ; }
mount --bind /mnt/empty /sys
modprobe snd-pcm
... (spins creating little modprobes)
and the cycle comes about because snd-pcm-oss depends on snd-pcm.
Adding "--ignore-install" to the second command wouldn't help, because
that option does not affect modules loaded to satisfy dependencies.
Andreas Robinson started some work to replace "install" commands like
this with a "soft dependency" directive, which included detection of
infinite recursion. I moaned about his initial proof-of-concept and
nothing further has been posted. I don't want to nag; I'll just say
that would be a really nice way to make sure these forkbombs can't
happen (provided the config files are updated to take advantage of
it).
--
To unsubscribe from this list: send the line "unsubscribe linux-modules" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
