From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com ([74.125.82.42]:35570 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753373AbcBYQtZ (ORCPT ); Thu, 25 Feb 2016 11:49:25 -0500 Received: by mail-wm0-f42.google.com with SMTP id c200so37497555wme.0 for ; Thu, 25 Feb 2016 08:49:19 -0800 (PST) Date: Thu, 25 Feb 2016 16:49:12 +0000 From: Matt Fleming To: Greg KH Cc: stable@vger.kernel.org, Ard Biesheuvel , Peter Jones , Matthew Garrett , joeyli Subject: Re: [PATCH 0/3] make efivarfs files immutable by default (for stable) Message-ID: <20160225164912.GC2772@codeblueprint.co.uk> References: <1456417906-21471-1-git-send-email-matt@codeblueprint.co.uk> <20160225164158.GA22865@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160225164158.GA22865@kroah.com> Sender: stable-owner@vger.kernel.org List-ID: On Thu, 25 Feb, at 04:41:59PM, Greg KH wrote: > On Thu, Feb 25, 2016 at 04:31:43PM +0000, Matt Fleming wrote: > > Stable folks, > > > > This is a backport of the efivarfs anti-bricking changes [1] for > > stable. Some fixing up was required because the series doesn't > > include the ucs2 cleanups that are in Linus' tree since they're not > > really stable material. > > What stable tree(s) do you want these applied to? Probably as far as back v3.10, if possible. That was when efivarfs support was merged and had we known about this issue then, we would have had this immutable feature from day one. > And if at all possible, I'd really prefer to take the original patches, > additional things and all, for stable kernels, as 95%[1] of the time > that we take "different" ones, there are bugs. OK, gotcha. > It also makes things easier for us to take additional changes later on > for other commits in the same area. So can we just take the originals > please? Sure, if that's what you'd prefer that's no problem. Would you like me to send a v2 series containing all the patches? > thanks, > > greg k-h > > [1] Totally made up number, I think the true number is 100%, but maybe > one or two patches have actually worked over the years. Most > relevant example of this is some crypto patches that were "made > simpler for stable" last week but were completely broken.