From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:46030 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726664AbeJKWgV (ORCPT ); Thu, 11 Oct 2018 18:36:21 -0400 Date: Thu, 11 Oct 2018 17:08:22 +0200 From: 'Greg KH' To: Daniel Sangorrin Cc: stable@vger.kernel.org Subject: Re: Backports that remove FPU lazy-mode deadcode for 4.9.y Message-ID: <20181011150822.GA31502@kroah.com> References: <1531354594-2236-1-git-send-email-daniel.sangorrin@toshiba.co.jp> <20180713145809.GA20331@kroah.com> <002701d41e40$018dd6c0$04a98440$@toshiba.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002701d41e40$018dd6c0$04a98440$@toshiba.co.jp> Sender: stable-owner@vger.kernel.org List-ID: On Wed, Jul 18, 2018 at 11:35:34AM +0900, Daniel Sangorrin wrote: > > From: Greg KH > > Sent: Friday, July 13, 2018 11:58 PM > > On Thu, Jul 12, 2018 at 09:16:33AM +0900, Daniel Sangorrin wrote: > > > Hello Greg, > > > > > > Please consider this backport for 4.9.y. It completes the removal > > > of FPU lazy-mode code, documentation and comments. > > > > > > [PATCH v3 4.9] x86/fpu: Remove use_eager_fpu() > > > > > > After applying the patch, please do the following: > > > - cherry-pick: 3913cc350757 ("x86/fpu: Remove struct fpu::counter") > > > - revert: f09a7b0eead7 ("perf: sync up x86/.../cpufeatures.h") > > > - Because the modification in this patch actually belongs to > > e63650840e8b ("x86/fpu: Finish excising 'eagerfpu'") > > > - cherry-pick: e63650840e8b ("x86/fpu: Finish excising 'eagerfpu'") > > > > That's a major pain. > > > > Tell me again why we are doing this for the stable trees? What does > > this buy us? It's nice cleanups sure, but are these going to be needed > > for future backports? Something else? > > They are mostly cleanups that complete the series of fpu patches that > was merged in stable recently, and a Documentation fix (remove > eagerfpu from the kernel parameters). Ben mentioned that the cleanups > could help with future backports, but if you prefer we can wait until > such future backports do exist. Ok, might as well get this over with now. All now queued up. thanks, greg k-h