On Mon, May 29, 2023 at 8:44 AM Johan Hovold <johan@xxxxxxxxxx> wrote:
>
> Yes, those two changes are enough to make the problem go away.
Ok, good. Expected, but just verifying that it wasn't some silly
incidental thinko.
> > I do wonder what it is that is different in your setup, and maybe you
> > could also enable the
> >
> > pr_debug("finit_module: fd=%d, uargs=%p, flags=%i\n", fd, uargs, flags);
>
> Below is the corresponding output with a working kernel: 174 requests
> for the 131 modules that end up being loaded (without the revert there
> is only around 110 modules loaded).
Ok, your setup doesn't sound *too* different from mine. I have 176
kernel modules on my laptop right now, and that exclusive open
obviously worked fine for me.
But it could easily be some random small difference just from
different hardware, so...
And yeah, that dmesg output is useless, I didn't think of the fact
that it only prints out the file descriptor, not the actual path to
the file. In fact, without that change in place, the module code never
actually looks at the file and leaves it all to
kernel_read_file_from_fd().
With my change, it woul dhave been trivial to use "%pD" and point it
at the file pointer instead, and get the dentry name that way, but
never mind. I think you're entirely right that it's probably due to a
shared dependency module, and I just didn't happen to trigger that
case.
Sadly, the whole idea was to figure out the exclusion so early that we
don't have the module data structures lookup up yet, so there's no
really obvious thing to serialize the load on.
I'll have to think about this more. Serializing on a per-inode lock
would seem to be the simplest thing, but they are all for IO, and we
can't just take them over the read.
Linus
