Re: [PATCH] module: fix UAF and GPF in idempotent_init_module via heap allocation

> 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