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] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 26 Apr 2023 10:03:37 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Theodore Ts'o" <tytso@....edu>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [GIT PULL] ext4 changes for the 6.4 merge window

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.

Howeder, it sadly turns out that compilers have gotten this completely wrong.

gcc apparently completely screwed things up, and "nonnull" is not a
warning aid, it's a "you can remove tests against NULL silently".

And clang does seem to have taken the same approach with
"returns_nonnull", which is really really sad, considering that
apparently they got it right for "_Nonnull" for function arguments
(where it's documented to cause a warning if you pass in a NULL
argument, rather than cause the compiler to generate sh*t buggy code)

Compiler people who think that "undefined behavior is a good way to
implement optimizations" are a menace, and should be shunned. They are
paste-eaters of the worst kind.

Is there any chance that somebody could hit compiler people with a big
clue-bat, and say "undefined behavior is not a feature, it's a bug",
and try to make them grow up?

Adding some clang people to the participants, since they at least seem
to have *almost* gotten it right.

            Linus

Powered by blists - more mailing lists