linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Nathan Chancellor <nathan@kernel.org>,
	linux-ext4@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [GIT PULL] ext4 changes for the 6.4 merge window
Date: Wed, 26 Apr 2023 10:34:27 -0700	[thread overview]
Message-ID: <CAKwvOdmXgThxzBaaL_Lt+gpc7yT1T-e7YgM8vU=c7sUita6aaw@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wiP0983VQYvhgJQgvk-VOwSfwNQUiy5RLr_ipz8tbaK4Q@mail.gmail.com>

On Wed, Apr 26, 2023 at 10:03 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Apr 24, 2023 at 9:18 PM Theodore Ts'o <tytso@mit.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.

That's what clang's _Nonnull attribute does (with -Wnullability-extension).
https://godbolt.org/z/6jo1zbMd9
But it's not toolchain portable, at the moment.  Would require changes
to clang to use the GNU C __attribute__ syntax, too (which I'm not
against adding support for).

>
> 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)

Heh, I just had this conversation maybe within the past month with
Bionic (Android's libc) developers.

Yeah, the nonnull attributes != _Nonnull "attributes." (Quotes because
IIUC _Nonnull doesn't use the __attribute__ GNU C extension syntax).
My understanding (which may be wrong) is that nonnull is implemented
for compatibility with GCC, while _Nonnull was likely implemented by
Apple (my guess; did not check) (so compatibility with GNU C
__attribute__ syntax probably wasn't considered in code review).

https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes

The Bionic developers are deploying _Nonnull throughout the codebase
and intentionally not using nonnull which is dangerous (a teammate
used the term "Developer Hostile Behavior"). nonnull has implications
on codegen, _Nonnull only affects diagnostics.

https://android-review.googlesource.com/q/owner:zijunzhao@google.com+Nullability

For examples. Works on return types, too.  So _Nonnull can be used on
return types rather than returns_nonnull.

>
> 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.

Thanks! :-*

>
> 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?

Good. I can feel your anger. Strike me down with all of your hatred,
and your journey to the dark side will be complete.  Your hate has
made you powerful.  Let the hate flow through you!

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



-- 
Thanks,
~Nick Desaulniers


  reply	other threads:[~2023-04-26 17:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25  4:18 Theodore Ts'o
2023-04-26 17:03 ` Linus Torvalds
2023-04-26 17:34   ` Nick Desaulniers [this message]
2023-04-26 17:36     ` Nick Desaulniers
2023-04-26 17:43       ` Nick Desaulniers
2023-04-26 18:11     ` Linus Torvalds
2023-04-26 18:22       ` Nick Desaulniers
2023-04-26 18:32         ` Linus Torvalds
2023-04-26 22:07           ` Nick Desaulniers
2023-04-26 22:31             ` Linus Torvalds
2023-04-28 21:02               ` Nick Desaulniers
2023-04-28 21:18                 ` Linus Torvalds
2023-04-26 23:16             ` Theodore Ts'o
2023-04-26 19:10   ` Matthew Wilcox
2023-04-26 19:38     ` Linus Torvalds
2023-04-26 23:12     ` Theodore Ts'o
2023-05-03  8:03     ` Dan Carpenter
2023-04-26 17:06 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKwvOdmXgThxzBaaL_Lt+gpc7yT1T-e7YgM8vU=c7sUita6aaw@mail.gmail.com' \
    --to=ndesaulniers@google.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nathan@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox