On Friday 2010-11-26 21:05, Jozsef Kadlecsik wrote: >> > >> >Why don't you lock the tables during dumping? That way the tables won't >> >change, whatever long time the dump takes. Snapshotting the table looks as >> >wasting memory and time. >> >> For that to work, I would have to use a locking primitive that can be >> held across returns to userspace, which leaves semaphores as the only >> option and, ya, I didn't quite feel like using _that_. Also sounds a >> bit like a killer if an admin cannot update a table just because he >> forgot some dumper process in the background in suspended state. :-/ > >There's already an internal mutex there (cb_mutex), to serialize dumping. >(It's unfortunate that cb_mutex cannot be accessed, for other purposes.) >And the kernel->userspace messaging is asynchronous, so I think suspended >dumping process won't hurt: the messages will wait it the queue, that's >all. It's not about serialization of dumps, but when a writer shows up: - process A starts a read operation dump - process A gets forgotten in whatever way - process B tries to do a _write_ operation on the table Locking writers out because a reader does not want to finish sounds bad. Letting A not take a lock, A can get back a non-atomic snapshot. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
