From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:58832 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032974AbeBOO1o (ORCPT ); Thu, 15 Feb 2018 09:27:44 -0500 Date: Thu, 15 Feb 2018 15:27:46 +0100 From: Greg KH To: Mario.Limonciello@dell.com Cc: stable@vger.kernel.org, andriy.shevchenko@linux.intel.com Subject: Re: [PATCH] platform/x86: dell-laptop: Allocate buffer on heap rather than globally Message-ID: <20180215142746.GB4200@kroah.com> References: <1518550759-10600-1-git-send-email-mario.limonciello@dell.com> <20180213195132.GA22142@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: On Tue, Feb 13, 2018 at 07:54:10PM +0000, Mario.Limonciello@dell.com wrote: > > -----Original Message----- > > From: Greg KH [mailto:gregkh@linuxfoundation.org] > > Sent: Tuesday, February 13, 2018 1:52 PM > > To: Limonciello, Mario > > Cc: linux-stable ; Andy Shevchenko > > > > Subject: Re: [PATCH] platform/x86: dell-laptop: Allocate buffer on heap rather than > > globally > > > > On Tue, Feb 13, 2018 at 01:39:19PM -0600, 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. > > > > > > This commit has been backported from: > > > commit 9862b43624 upstream > > > > > > Fixes: 549b4930f057658dc50d8010e66219233119a4d8 > > > Suggested-by: Pali Rohar > > > Signed-off-by: Mario Limonciello > > > Signed-off-by: Andy Shevchenko > > > --- > > > drivers/platform/x86/dell-laptop.c | 188 ++++++++++++++++++++----------------- > > > 1 file changed, 103 insertions(+), 85 deletions(-) > > > > Why is this a stable patch? What bug does it fix? > > > > confused, > > > > greg k-h > > Greg, > > I realized I forgot to send this 2 weeks ago when you said a clean backport > didn't work. This was a follow up from a race condition that was seen in > the wild and submitted to platform-x86. Ok, what kernel tree(s) do you want it applied to? I need a hint please :) thanks, greg k-h