Re: [PATCH] Compiler Attributes: counted_by: bump compiler versions
From: Kees Cook
Date: Tue Jan 09 2024 - 16:12:41 EST
On Tue, Jan 09, 2024 at 12:56:52PM -0700, Nathan Chancellor wrote:
> On Tue, Jan 09, 2024 at 08:42:24PM +0100, Miguel Ojeda wrote:
> > On Tue, Jan 9, 2024 at 4:32 PM Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
> > >
> > > It is still possible in theory for this feature to make clang-18, as the
> > > release/18.x branch is not scheduled to be cut until the fourth Tuesday
> > > in January, which is two weeks from now. I don't have a good feeling for
> > > how close that pull request is to being mergeable though, so this is
> > > fine for now. I assume this won't go to Linus immediately so we would
> > > have time to change it if necessary.
> >
> > Yeah, I was wondering about the deadline too. If LLVM's `-rc1` is the
> > latest time possible to merge it, we can wait the couple weeks (which
> > are conveniently the merge window) and I apply it afterwards with the
> > result :)
>
> If I understand the doucmentation at [1] correctly, the first round of
> testing starts with -rc1 and ends with -rc2, so if the feature is not
> merged by -rc2, it won't make that release cycle. I think counted_by
> might be a hard sell even after -rc1 because the feature is not exactly
> small but it is also not expansive (it is relatively self contained
> from what I can tell). So I think your plan is reasonable.
>
> Another alternative would be to split this patch in to three distinct
> patches, not sure if that would be overkill for this though.
>
> 1. Update the clang review link from reviews.llvm.org to github.com
> 2. Update the GCC version from 14 to 15.
> 3. Update the Clang version from 18 to 19.
>
> The first two patches could be picked up immediately and the third one
> could be sat on to see how the review and acceptance process works out
> over the next couple of weeks. Up to you/Sergey. Thanks for taking a
> look!
Yeah, I think either the above split or just wait until the Clang 18
cut, since we've got a while before the next kernel merge window.
--
Kees Cook