Messages in this thread | | | Date | Thu, 20 Jan 2011 07:45:42 +1100 | Subject | Re: [patch] fs: aio fix rcu lookup | From | Nick Piggin <> |
| |
On Thu, Jan 20, 2011 at 7:32 AM, Jeff Moyer <jmoyer@redhat.com> wrote: > Nick Piggin <npiggin@gmail.com> writes: > >> On Thu, Jan 20, 2011 at 6:46 AM, Jeff Moyer <jmoyer@redhat.com> wrote: >>> Jeff Moyer <jmoyer@redhat.com> writes: >>> >>>> Jan Kara <jack@suse.cz> 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |