An oopsed task can leave behind various kernel structures in an
inconsistent state, such as unreleased locks, incorrect reference counts
and leaked objects. It is expected that the kernel may behave strangely
afterward and this can result in subsequent problems, such as deadlocks
or crashes.
Loading a module is a heavyweight operation that injects new code and
data into the kernel. If it ends in an oops, I think it is fair that no
additional modules can be inserted. I don't see that the module loader
is doing anything wrong or behaving differently from other kernel
components in this regard.
Makes sense. Hardening the module loader against a post-oops state is
indeed unnecessary. I'll drop this and go after the driver bugs instead.
Thanks for the review.
Cheers,
Mingyu
