On Mon, 2009-12-14 at 06:30 -0500, Jon Masters 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, so > there's a possibility for a second modprobe to come along while another > is running. The existing code upstream was ripped out because there is a > possibility for the flocking to be abused by a user opening the module > file and because it's not normally a big deal if a second modprobe comes > along - worst case the module is already loaded by another instance and > we will fail harmlessly to load it a second time. Totally no problem. I should mention here, of course we serialize with respect to the actual "insmod" (within m-i-t) or init module operation in kernel for a specific module and we're not going to have the same module half loaded twice, but the situation I'm talking about is having multiple deps that haven't yet finished init you'd usually wait for within a single modprobe run now having multiple modprobes racing to load them. On the system I'm looking at there seems to be a small window during which we'll believe the deps are loaded (they're actually just in init and will soon fail that and return) and so continue to load a module for which we don't have deps loaded. We fail at that point, harmlessly. I'm tired out from a late night, hope that makes some sense. I'll share some more once I'm done poking at it and checking the current upstream kernel, and after sleeping. Hope life is going well today :) 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
