On Mon, Dec 14, 2009 at 18:19, Jon Masters <jonathan@xxxxxxxxxxxxxx> wrote: > On Mon, 2009-12-14 at 13:42 +0100, Kay Sievers wrote: >> On Mon, Dec 14, 2009 at 12:30, Jon Masters <jonathan@xxxxxxxxxxxxxx> wrote: >> > On Mon, 2009-12-14 at 11:24 +0100, Kay Sievers wrote: >> >> On Mon, Dec 14, 2009 at 02:12, Jon Masters <jonathan@xxxxxxxxxxxxxx> wrote: >> >> > On Sat, 2009-12-12 at 04:29 -0500, Jon Masters wrote: >> >> > >> >> >> FYI I am diagnosing an unlikely locking issue on a RHEL system right now >> >> >> that triggers when you have a read-only filesystem and can't use file >> >> >> locks. I know we ripped out a lot of that code since in upstream but I >> >> >> might need to address this differently. I'll followup with my findings. >> >> > >> >> > I have written a sysV shared memory locking mechanism that using an shm >> >> > segment in the case that the filesystem is mounted read-only. I'll >> >> > finish the work on the RHEL bug and then forward port it, and post. We >> >> > can probably re-introduce this because it works in a read-only context >> >> > and can't be abused by a user to prevent module loading because the IPC >> >> > shm segment is user-specific. Only downside is (optional, I guess) >> >> > dependency on sysV shm. But I don't think we honestly have anyone >> >> > wanting to use m-i-t on a system without such things compiled in. >> >> >> >> Why would we need anything like that? Shouldn't the load syscall >> >> serialize all that properly? >> > >> > It doesn't quite though (in the 2.6.18 kernel I'm focusing on right now, >> > upstream has some slight changes in the module loader code since then). >> > We only run under stop machine during the actual link and unlink, >> >> I don't think we ever run under stop_machine > > 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? Kay -- 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
