On Wed, Nov 04 2009, Jens Axboe wrote: > > You also mentioned that you saw some kind of a race on io_u->flags > > today, do you by any chance know if you were using iodepth_low or > > iodepth_batch_complete or libaio engine options. > > I think I see an issue when using them and understand why it happens, > > but dont have a clean fix yet, will hopefully have one soon. I was > > wondering if its the same issue you are seeing. > > Basically the issue is we might think the queue is full (because we > > cannot allocate any more io_u (they are probably doing async verify)), > > but the code assumes that if the queue is full, then there is atleast > > one I/O that we can do "io_getevents" on. And that will cause a hang > > in the code. > > I didn't use libaio, I can reproduce it with the sync engine directly > and much easier if using fast "null" verifies. It triggers this assert > in put_io_u(): > > assert((io_u->flags & IO_U_F_FREE) == 0); > > and this in __get_io_u(): > > assert(io_u->flags & IO_U_F_FREE); > > The former I think is just a bug, it's likely a reput or something, but > not sure yet. The latter looks like a race on the flags, since it isn't > always locked down when manipulated. I think this is fixed now, committed a patch for it. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
