From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Date: Tue, 10 Jan 2023 13:34:16 +0000 Subject: [Cluster-devel] [RFC v6 04/10] iomap: Add iomap_get_folio helper In-Reply-To: References: <20230108213305.GO1971568@dread.disaster.area> <20230108194034.1444764-1-agruenba@redhat.com> <20230108194034.1444764-5-agruenba@redhat.com> <20230109124642.1663842-1-agruenba@redhat.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, Jan 10, 2023 at 12:46:45AM -0800, Christoph Hellwig wrote: > On Mon, Jan 09, 2023 at 01:46:42PM +0100, Andreas Gruenbacher wrote: > > We can handle that by adding a new IOMAP_NOCREATE iterator flag and > > checking for that in iomap_get_folio(). Your patch then turns into > > the below. > > Exactly. And as I already pointed out in reply to Dave's original > patch what we really should be doing is returning an ERR_PTR from > __filemap_get_folio instead of reverse-engineering the expected > error code. Ouch, we have a nasty problem. If somebody passes FGP_ENTRY, we can return a shadow entry. And the encodings for shadow entries overlap with the encodings for ERR_PTR, meaning that some shadow entries will look like errors. The way I solved this in the XArray code is by shifting the error values by two bits and encoding errors as XA_ERROR(-ENOMEM) (for example). I don't _object_ to introducing XA_ERROR() / xa_err() into the VFS, but so far we haven't, and I'd like to make that decision intentionally.