On Thu, Jul 2, 2020 at 10:18 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jul 2, 2020 at 12:58 PM Andreas Gruenbacher <agruenba@xxxxxxxxxx> wrote: > > > Of course, if you want to avoid both new reads to be submitted _and_ > > > avoid waiting for existing pending reads, you should just set both > > > flags, and you get the semantics you want. So for your case, this may > > > not make any difference. > > > > Indeed, in the gfs2 case, waiting for existing pending reads should be > > fine. I'll send an update after some testing. > > Do note that "wait for pending reads" very much does imply "wait for > those reads to _complete_". > > And maybe the IO completion handler itself ends up having to finalize > something and take the lock to do that? > > So in that case, even just "waiting" will cause a deadlock. Not > because the waiter itself needs the lock, but because the thing it > waits for might possibly need it. > > But in many simple cases, IO completion shouldn't need any filesystem > locks. I just don't know the gfs2 code at all, so I'm not even going > to guess. I just wanted to mention it. Yes, that makes sense. Luckily gfs2 doesn't do any such locking on IO completion. Thanks, Andreas
