On Mon, 2009-12-14 at 18:29 +0100, Kay Sievers wrote: > On Mon, Dec 14, 2009 at 18:19, Jon Masters <jonathan@xxxxxxxxxxxxxx> wrote: > > Let me be clear, "we" do in the sense that the kernel module.c code > > requires a stop_machine in order to perform the actual link/unlink > > operation of the module. And certainly more so in older kernels. But > > anyway, we don't use it very much in any case, so we're mostly able to > > run other modprobe instances that might come along. > > It's a stop_machine_create() not a stop_machine() isn't it? Previously, in the older kernel I was looking at it was a stop_machine_run. It is changed in current upstream. The specific problem I was seeing even after I replaced the locking with an SYSV SHM based alternative approach was that I might also happen to exceed the maximum number of open files in my stress test, then the module locking routine fails the open() call and we catch it, return, but don't set the "rc" error at the same time, so we then continue to load other modules. I'll fix the upstream, just in case that happens. Also, there's an abrt reported crash on full filesystems. I plan to give a lot of love to upstream over the holiday period :) Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
