Nick Piggin <npiggin@xxxxxxxxx> writes: > 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. Now you've really lost me. ;-) Processes which utilize the in-kernel aio interface typically create an ioctx at process startup, use that for submitting all of their io, then destroy it on exit. Think of a database. Every time you call io_submit, you're doing a lookup of the ioctx. > 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. Above it sounded like you didn't think AIO should be using RCU at all. Here it sounds like you are just against synchronize_rcu. Which is it? And if the latter, then please tell me in what cases you feel one would be justified in calling synchronize_rcu. For now, I simply disagree with you. As I said before, you're already potentially waiting for disk I/O to complete. It doesn't get much worse than that for latency. Cheers, Jeff -- 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
