linux-kernel - Re: Reg the next LTS kernel (6.1?)

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]

Message-ID: <Y8FAFAwB9gBzQXQG@kroah.com>
Date:   Fri, 13 Jan 2023 12:27:16 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Michal Simek <michal.simek@....com>
Cc:     Kris Chaplin <kris.chaplin@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Reg the next LTS kernel (6.1?)

On Thu, Jan 12, 2023 at 01:26:28PM +0100, Michal Simek wrote:
> Hi Greg,
> 
> On 1/12/23 13:23, Kris Chaplin wrote:
> > Hello Greg,
> > 
> > > You tell me please.  How has your testing gone for 6.1 so far?  Does it
> > > work properly for you?  Are you and/or your company willing to test out
> > > the -rc releases and provide feedback if it works or not for your
> > > systems?  Do you have problems with 6.1.y vs. older kernels?  Is there
> > > anything missing in it that you feel needs to be addressed with a newer
> > > kernel instead?
> > 
> > We have been integrating and testing 6.1 on the Microblaze, ARM32 and
> > ARM64-bit architectures over the past few weeks.  These builds have
> > been successful and we are able to run our regression tests on hardware
> > targeting our FPGA SoC devices.
> > 
> > We're continuing our tests as new updates to the 6.1 kernel series
> > appear.
> 
> As Kris said AMD/Xilinx has already moved internal SOC tree to 6.1 based
> kernel in expectation that 6.1 will become next LTS.
> And I am not aware about any issue from testing team related to 6.1 kernel
> version. And we are covering our AMD/Xilinx SOCs based on arm32/arm64 and
> Microblaze CPUs.
> 
> It would be good to continue with the same strategy which using the latest
> kernel at that year which is what I am hearing all the time from others that
> 6.1 was last kernel at that year and it should be LTS.

Generally yes, I pick the last release of the year but we need people to
verify and validate that both it works for them, and that they are going
to be using it in their systems and can provide testing results to us
(as well as providing a way for their devices to actually be updated to
the new releases, we've had previous stable kernel releases that were
never actually shipped out to devices...)

> I didn't run any stats but normally also more patches are going to this
> version to be the part of LTS.

What do you mean by this?  The patches accepted so far since 6.1.0 was
released, or up until 6.1.0 was released?  For the patches since 6.1.0
was released, that's due to more developers/maintainers tagging patches
during the -rc1 merge window for stable releases (honestly they should
have gotten them into the -final release first), and due to us having
better tools in digging up potential stable patches (i.e. Sasha's
AUTOSEL bot work.)

thanks,

greg k-h