On Sun, Jan 15, 2023 at 09:01:22AM -0800, Darrick J. Wong wrote: > On Tue, Jan 10, 2023 at 01:34:16PM +0000, Matthew Wilcox wrote: > > 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. > > Sorry, I'm not following this at all -- where in buffered-io.c does > anyone pass FGP_ENTRY? Andreas' code doesn't seem to introduce it > either...? Oh, never mind, I worked out that the conflict is between iomap not passing FGP_ENTRY and wanting a pointer or a negative errno; and someone who does FGP_ENTRY, in which case the xarray value can be confused for a negative errno. OFC now I wonder, can we simply say that the return value is "The found folio or NULL if you set FGP_ENTRY; or the found folio or a negative errno if you don't" ? --D > --D
