[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72=yYDcG=ef9TxCCECwjSgW-5zFoTJqcjrWGOALCvaW0SA@mail.gmail.com>
Date: Mon, 21 Oct 2024 08:04:03 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Jan Hendrik Farr <kernel@...rr.cc>
Cc: Nathan Chancellor <nathan@...nel.org>, Bill Wendling <morbo@...gle.com>, Kees Cook <kees@...nel.org>,
Thorsten Blum <thorsten.blum@...lux.com>, kent.overstreet@...ux.dev,
regressions@...ts.linux.dev, linux-bcachefs@...r.kernel.org,
linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
ardb@...nel.org, ojeda@...nel.org
Subject: Re: [REGRESSION][BISECTED] erroneous buffer overflow detected in bch2_xattr_validate
On Mon, Oct 21, 2024 at 3:33 AM Jan Hendrik Farr <kernel@...rr.cc> wrote:
>
> I think I prefer
>
> depends on !(CC_IS_CLANG && CLANG_VERSION < 190103)
>
> to make it more clear that the purpose is to disable this for clang
> versions below 19.1.3, but keep it enabled for every other compiler
> including pre-release gcc versions that pass the compile test.
Do we want other tooling to see the attribute? i.e. if the build check
gets removed, then that `depends on` would mean other tooling would
see it, right?
> Also after gcc 15 is released I don't think a version check for gcc
> should be necessary. I only see an explicit version check as required
> when we know a certain version is broken. Otherwise I would prefer using
> the build test.
Yeah, build tests are nice, although they require spawning a process
and so on, which (as far as I understand) we try to minimize. Version
checks also have the advantage that it is easy to remember/check when
we can remove the checks themselves when we upgrade the minimum
versions.
> I guess an alternative would be to just create a
> CC_COUNTED_BY_BROKEN that is enabled for clang versions below 19.1.3
> and continue to use __has_attribute together with that option. That
> would make the build test unnecesarry. The downside is that it
> will require checking both __has_attribute and
> CONFIG_CC_COUNTED_BY_BROKEN for __counted_by support. So I think
> CC_HAS_COUNTED_BY is better.
Yeah, if we are going to need a new Kconfig symbol anyway, then let's
make that the only thing to check. Otherwise we are in the "worst of
both worlds", I would say.
> I'll submit it once Bill's fix is in the release/19.x branch. Which
> maintainer should I address this too? You (Nathan), Miguel, Kees, or
> someone else?
Sounds good -- if you want, you can send it to all of us and we can
figure that out later.
Thanks!
Cheers,
Miguel
Powered by blists - more mailing lists