On Thu, Jan 20, 2011 at 7:32 AM, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: > Nick Piggin <npiggin@xxxxxxxxx> writes: > >> On Thu, Jan 20, 2011 at 6:46 AM, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: >>> Jeff Moyer <jmoyer@xxxxxxxxxx> writes: >>> >>>> Jan Kara <jack@xxxxxxx> writes: >>>> >>>>> But there's the second race I describe making it possible >>>>> for new IO to be created after io_destroy() has waited for all IO to >>>>> finish... >>>> >>>> Can't that be solved by introducing memory barriers around the accesses >>>> to ->dead? >>> >>> Upon further consideration, I don't think so. >>> >>> Given the options, I think adding the synchronize rcu to the io_destroy >>> path is the best way forward. You're already waiting for a bunch of >>> queued I/O to finish, so there is no guarantee that you're going to >>> finish that call quickly. >> >> I think synchronize_rcu() is not something to sprinkle around outside >> very slow paths. It can be done without synchronize_rcu. > > I'm not sure I understand what you're saying. Do you mean to imply that > io_destroy is not a very slow path? Because it is. I prefer a solution > that doesn't re-architecht things in order to solve a theoretical issue > that's never been observed. Even something that happens once per process lifetime, like in fork/exit is not necessarily suitable for RCU. I don't know exactly how all programs use io_destroy -- of the small number that do, probably an even smaller number would care here. But I don't think it simplifies things enough to use synchronize_rcu for it. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
