On Tue, Apr 18, 2023 at 01:23:21PM -0700, Andrew Morton wrote:
> On Tue, 18 Apr 2023 21:06:35 +0100 "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx> wrote:
>
> > Commit "mm: return an ERR_PTR from __filemap_get_folio" changed from
> > returning NULL to returning an ERR_PTR(). This cannot be fixed in either
> > the ext4 tree or the mm tree, so this patch should be applied as part
> > of merging the two trees.
>
> Well that's awkward.
>
> > --- a/fs/ext4/inline.c
> > +++ b/fs/ext4/inline.c
> > @@ -566,8 +566,9 @@ static int ext4_convert_inline_data_to_extent(struct address_space *mapping,
> > * started */
> > folio = __filemap_get_folio(mapping, 0, FGP_WRITEBEGIN | FGP_NOFS,
> > mapping_gfp_mask(mapping));
> > - if (!folio) {
> > - ret = -ENOMEM;
> > + if (IS_ERR(folio)) {
> > + ret = PTR_ERR(folio);
> > + folio = NULL;
> > goto out;
> > }
>
> I suppose this could go into the ext4 tree, with IS_ERR_OR_NULL and a
> FIXME for later.
It looks really bad.
if (IS_ERR_OR_NULL(folio)) {
if (!folio)
ret = -ENOMEM;
else
ret = PTR_ERR(folio);
folio = NULL;
goto out;
}
> Or linux-next can carry it as one of its merge/build/other resolution
> patches?
That was my expectation. Very unfortunate collision. I'm sure Linus
will love it.
(Hold off on this precise version; running xfstests against it finds
something wrong)
