linux-kernel - Re: [PATCH 6/8] x86/platform/uv: Decode UVsystab Info

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:   Thu, 5 Sep 2019 18:56:23 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Mike Travis <mike.travis@....com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Borislav Petkov <bp@...en8.de>,
        Christoph Hellwig <hch@...radead.org>,
        Dimitri Sivanich <dimitri.sivanich@....com>,
        Russ Anderson <russ.anderson@....com>,
        Hedi Berriche <hedi.berriche@....com>,
        Steve Wahl <steve.wahl@....com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 6/8] x86/platform/uv: Decode UVsystab Info

On Thu, Sep 05, 2019 at 07:47:34AM -0700, Mike Travis wrote:
> 
> 
> On 9/5/2019 7:16 AM, Greg KH wrote:
> > On Thu, Sep 05, 2019 at 08:02:58AM -0500, Mike Travis wrote:
> > > Decode the hubless UVsystab passed from BIOS to the kernel saving
> > > pertinent info in a similar manner that hubbed UVsystabs are decoded.
> > > 
> > > Signed-off-by: Mike Travis <mike.travis@....com>
> > > Reviewed-by: Steve Wahl <steve.wahl@....com>
> > > Reviewed-by: Dimitri Sivanich <dimitri.sivanich@....com>
> > > To: Thomas Gleixner <tglx@...utronix.de>
> > > To: Ingo Molnar <mingo@...hat.com>
> > > To: H. Peter Anvin <hpa@...or.com>
> > > To: Andrew Morton <akpm@...ux-foundation.org>
> > > To: Borislav Petkov <bp@...en8.de>
> > > To: Christoph Hellwig <hch@...radead.org>
> > > Cc: Dimitri Sivanich <dimitri.sivanich@....com>
> > > Cc: Russ Anderson <russ.anderson@....com>
> > > Cc: Hedi Berriche <hedi.berriche@....com>
> > > Cc: Steve Wahl <steve.wahl@....com>
> > > Cc: x86@...nel.org
> > > Cc: linux-kernel@...r.kernel.org
> > > Cc: stable@...r.kernel.org
> > > ---
> > >   arch/x86/kernel/apic/x2apic_uv_x.c |   16 ++++++++++++++--
> > >   1 file changed, 14 insertions(+), 2 deletions(-)
> > 
> > If you are trying to get one of my automated "WTF: patch XXXX was
> > seriously submitted to be applied to the stable tree?" emails, you are
> > on track for it...
> > 
> > Please go read the documentation link I sent you last time and figure
> > out how you can justify any of this patch series for a stable kernel
> > tree.
> 
> Is it because it has fixes for new hardware?  If so, then I'll quit
> submitting them to stable (we've had requests from distros for all updates
> be in the stable tree for acceptance).  Otherwise I thought it does comply
> with:
> 
>    " - To have the patch automatically included in the stable tree,
>    add the tag
>      Cc: stable@...r.kernel.org
>    in the sign-off area. Once the patch is merged it will be applied
>    to the stable tree without anything else needing to be done by the
>    author or subsystem maintainer."
> 
> Or is there some other reason that I'm not understanding?

Yes, that's how you get a patch applied, but how in the world does all
of the patches in this series actually meet the requirements of a patch
that should be applied to the stable kernel tree?

I see no regression fixes, no new device ids, no bug fixes.  Only
support for new hardware, i.e. a new feature to the kernel for something
that never worked in the first place.

And yes, distros do request bugfixes to get added to stable trees,
that's great, but I fail to understand how any of these patches are "bug
fixes".  Maybe you need to work on your changelog texts...

good luck!

greg k-h