linux-ext4 - Re: [GIT PULL] ext4 changes for the 6.4 merge window

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 3 May 2023 11:03:10 +0300
From:   Dan Carpenter <dan.carpenter@...aro.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        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 08:10:58PM +0100, Matthew Wilcox wrote:
> 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.

There is a Smatch check for this but actually, looking at it now, it's
has some stupid stuff going on.  I will fix it up a bit.  But then you
still have to build the cross function DB which takes overnight on my
system.  I run Smatch on linux-next every day and I would have caught
this bug.

There are also people running Coccinelle scripts which do the same
thing.  If I didn't catch it they would have.

What I would like is an annotation in the comments that a Perl script
could parse:

Returns: Error pointers or valid pointer
Returns: Error pointers, NULL or valid pointer
Returns: Negative error codes or zero
Returns: -EINVAL, 0, 1

Smatch or Coccinelle could easily use this.

Btw, I have attached the Smatch warnings for this check.  It's almost
all dead code related to debugfs.  The correct thing there is just to
delete all the checking.

There are a couple false positives related to functions which return
both error pointers and NULL depending on the .config.

regards,
dan carpenter


View attachment "err-list" of type "text/plain" (7255 bytes)