From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Dave Chinner <david@fromorbit.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 2/4] fs: Add IOCB_NOIO flag for generic_file_read_iter
Date: Thu, 2 Jul 2020 13:17:51 -0700 [thread overview]
Message-ID: <CAHk-=wiDA9wm09e1aOSwqq9=e5iTEP5ncheux=C=p62h7dWvbA@mail.gmail.com> (raw)
In-Reply-To: <CAHc6FU5_JnK=LHtLL9or6E2+XMwNgmftdM_V71hDqk8apawC4A@mail.gmail.com>
On Thu, Jul 2, 2020 at 12:58 PM Andreas Gruenbacher <agruenba@redhat.com> 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.
Linus
next prev parent reply other threads:[~2020-07-02 20:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-02 16:51 [RFC 0/4] Fix gfs2 readahead deadlocks Andreas Gruenbacher
2020-07-02 16:51 ` [RFC 1/4] gfs2: Revert readahead conversion Andreas Gruenbacher
2020-07-02 16:51 ` [RFC 2/4] fs: Add IOCB_NOIO flag for generic_file_read_iter Andreas Gruenbacher
2020-07-02 18:06 ` Linus Torvalds
2020-07-02 19:58 ` Andreas Gruenbacher
2020-07-02 20:17 ` Linus Torvalds [this message]
2020-07-03 9:45 ` Andreas Gruenbacher
2020-07-07 14:30 ` Andreas Gruenbacher
2020-07-02 16:51 ` [RFC 3/4] gfs2: Rework read and page fault locking Andreas Gruenbacher
2020-07-02 16:51 ` [RFC 4/4] gfs2: Reinstate readahead conversion Andreas Gruenbacher
2020-07-02 18:10 ` [RFC 0/4] Fix gfs2 readahead deadlocks Linus Torvalds
2020-07-02 18:23 ` Andreas Gruenbacher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wiDA9wm09e1aOSwqq9=e5iTEP5ncheux=C=p62h7dWvbA@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=agruenba@redhat.com \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).