From: David Howells <dhowells@redhat.com>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: dhowells@redhat.com,
"linux-cachefs@redhat.com" <linux-cachefs@redhat.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"willy@infradead.org" <willy@infradead.org>,
"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>,
"dwysocha@redhat.com" <dwysocha@redhat.com>
Subject: Re: Can the GFP flags to releasepage() be trusted? -- was Re: [PATCH v2 3/8] nfs: Move to using the alternate fallback fscache I/O API
Date: Tue, 05 Oct 2021 14:15:40 +0100 [thread overview]
Message-ID: <1080874.1633439740@warthog.procyon.org.uk> (raw)
In-Reply-To: <23033528036059af4633f60b8325e48eab95ac36.camel@hammerspace.com>
Trond Myklebust <trondmy@hammerspace.com> wrote:
> To elaborate a bit: we used to have code here that would check whether
> the page had been cleaned but was unstable, and if an argument of
> GFP_KERNEL or above was set, we'd try to call COMMIT to ensure the page
> was synched to disk on the server (and we'd wait for that call to
> complete).
>
> That code would end up deadlocking in all sorts of horrible ways, so we
> ended up having to pull it.
I don't think that a deadlock should be possible with this. PG_fscache is now
only being used to indicate that a DIO write to the cache is in progress on
the page. It will complete and remove the mark at some point.
David
next prev parent reply other threads:[~2021-10-05 13:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 15:04 [RFC PATCH v2 0/8] fscache: Replace and remove old I/O API v2 David Howells
2021-09-17 15:04 ` [PATCH v2 1/8] fscache: Generalise the ->begin_read_operation method David Howells
2021-09-17 15:04 ` [PATCH v2 2/8] fscache: Implement a fallback I/O interface to replace the old API David Howells
2021-09-17 15:04 ` [PATCH v2 3/8] nfs: Move to using the alternate fallback fscache I/O API David Howells
2021-09-29 14:44 ` David Wysochanski
2021-10-01 14:42 ` David Howells
[not found] ` <CALF+zO=165sRYRaxPpDS7DaQCpTe-YOa4FamSoMy5FV2uuG5Yg@mail.gmail.com>
2021-10-01 14:29 ` Trond Myklebust
2021-10-01 14:51 ` Can the GFP flags to releasepage() be trusted? -- was " David Howells
2021-10-01 15:04 ` Trond Myklebust
2021-10-01 19:42 ` Matthew Wilcox
2021-10-05 13:15 ` David Howells [this message]
2021-09-17 15:04 ` [PATCH v2 4/8] 9p: (untested) Convert to using the netfs helper lib to do reads and caching David Howells
2021-09-17 15:05 ` [PATCH v2 5/8] cifs: (untested) Move to using the alternate fallback fscache I/O API David Howells
2021-09-17 15:05 ` [PATCH v2 6/8] fscache: Remove the old " David Howells
2021-09-17 15:05 ` [PATCH v2 7/8] fscache: Remove stats that are no longer used David Howells
2021-09-17 15:05 ` [PATCH v2 8/8] fscache: Update the documentation to reflect I/O API changes David Howells
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=1080874.1633439740@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=anna.schumaker@netapp.com \
--cc=dwysocha@redhat.com \
--cc=linux-cachefs@redhat.com \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.