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? The only thing that should happen is needless work, that the failing syscall tells us to discard -- which is probably more reliable than any additional locking. I guess, that if userspace locking is really needed, something else must not work as expected? Anyway, explaining the problem you want to fix should probably be the first step before explaining a solution for a still unknown problem. :) Thanks, 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
