linux-kernel - RE: [PATCH v2] platform/x86: dell-laptop: Allocate buffer on heap rather than globally

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] [day] [month] [year] [list]

Date:   Wed, 7 Feb 2018 20:17:19 +0000
From:   <Mario.Limonciello@...l.com>
To:     <dvhart@...radead.org>
CC:     <andy.shevchenko@...il.com>, <pali.rohar@...il.com>,
        <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>
Subject: RE: [PATCH v2] platform/x86: dell-laptop: Allocate buffer on heap
 rather than globally

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@...radead.org]
> Sent: Monday, February 5, 2018 6:58 PM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: andy.shevchenko@...il.com; pali.rohar@...il.com; linux-
> kernel@...r.kernel.org; platform-driver-x86@...r.kernel.org
> Subject: Re: [PATCH v2] platform/x86: dell-laptop: Allocate buffer on heap rather
> than globally
> 
> On Mon, Feb 05, 2018 at 04:49:35PM +0000, Mario.Limonciello@...l.com wrote:
> > > -----Original Message-----
> > > From: Andy Shevchenko [mailto:andy.shevchenko@...il.com]
> > > Sent: Sunday, February 4, 2018 8:28 AM
> > > To: Pali Rohár <pali.rohar@...il.com>
> > > Cc: Limonciello, Mario <Mario_Limonciello@...l.com>; Darren Hart
> > > <dvhart@...radead.org>; LKML <linux-kernel@...r.kernel.org>; Platform
> Driver
> > > <platform-driver-x86@...r.kernel.org>
> > > Subject: Re: [PATCH v2] platform/x86: dell-laptop: Allocate buffer on heap
> rather
> > > than globally
> > >
> > > On Sun, Feb 4, 2018 at 2:09 PM, Pali Rohár <pali.rohar@...il.com> wrote:
> > > > On Wednesday 31 January 2018 11:47:35 Mario Limonciello wrote:
> > > >> There is no longer a need for the buffer to be defined in
> > > >> first 4GB physical address space.
> > > >>
> > > >> Furthermore there may be race conditions with multiple different functions
> > > >> working on a module wide buffer causing incorrect results.
> > > >>
> > > >> Fixes: 549b4930f057658dc50d8010e66219233119a4d8
> > >
> > > He-h, I had to notice this earlier...
> > >
> > > > Ok, you can add my:
> > > > Reviewed-by: Pali Rohár <pali.rohar@...il.com>
> > >
> > > Thanks and sorry, Pali, it's in for-next already, can't rebase.
> >
> > Andy,
> > Since it's already in for-next it's probably too late to add the stable CC too right?
> >
> > So what's the proper time now to send this to @stable?  And should I just forward
> existing
> > patch?
> 
> As a general rule, Andy and I should be adding Cc stable to most anything that
> includes a Fixes tag that isn't from this review cycle. I've forgotten in the
> past as well - sorry about that. Something we should add some tooling around I
> think, so we don't miss it when checking things in to our review branches.
> 
> As to timing. As soon as this is merged to Linus' master, it can go to stable.
> Instructions for doing this are in Documentation/process/stable-kernel-rules.rst
> 
> --

Thanks, I see it's in Linuses' tree today so I sent something to stable for it.