[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZEl3QmF1PYXKaBTz@casper.infradead.org>
Date: Wed, 26 Apr 2023 20:10:58 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Theodore Ts'o <tytso@....edu>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Dan Carpenter <error27@...il.com>
Subject: Re: [GIT PULL] ext4 changes for the 6.4 merge window
On Wed, Apr 26, 2023 at 10:03:37AM -0700, Linus Torvalds wrote:
> On Mon, Apr 24, 2023 at 9:18 PM Theodore Ts'o <tytso@....edu> wrote:
> >
> > Please note that after merging the mm and ext4 trees you will need to
> > apply the patch found here[1].
> >
> > [1] https://lore.kernel.org/r/20230419120923.3152939-1-willy@infradead.org
> >
> > This is due to a patch in the mm tree, "mm: return an ERR_PTR from
> > __filemap_get_folio" changing that function to returning an ERR_PTR
> > instead of returning NULL on an error.
>
> Side note, itr would be wonderful if we could mark the places that
> return an error pointer as returning "nonnull", and catch things like
> this automatically at build time where people compare an error pointer
> to NULL.
This feels like something smatch could catch. Adding Dan.
Unfortunately, I don't know that we have any buildbots that run smatch,
and most developers don't, so it'll always be an after-the-fact patch
to fix it rather than "anybody using W=1" or "anybody using C=1" will
catch it before it gets anywhere near a maintainer.
Powered by blists - more mailing lists