mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Greg KH <greg@kroah.com>
Cc: Alex Shi <alex.shi@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	stable@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/29] arm meltdown fix backporting review for lts 4.9
Date: Tue, 6 Mar 2018 14:26:34 +0000	[thread overview]
Message-ID: <20180306142634.GC13586@sirena.org.uk> (raw)
In-Reply-To: <20180305130859.GB17802@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]

On Mon, Mar 05, 2018 at 02:08:59PM +0100, Greg KH wrote:

> I know there is lots more than Android to ARM, but the huge majority by
> quantity is Android.

> What I'm saying here is look at all of the backports that were required
> to get this working in the android tree.  It was non-trivial by a long
> shot, and based on that work, this series feels really "small" and I'm
> really worried that it's not really working or solving the problem here.

Unfortunately what's been coming over was just the bit about using
android-common, not the bit about why you're worried about the code.  :(

> There are major features that were backported to the android trees for
> ARM that the upstream features for Spectre and Meltdown built on top of
> to get their solution.  To not backport all of that is a huge risk,
> right?

I'm not far enough into the details to comment on the specifics here;
there's other people in the CCs who are.  Let's let people look at the
code and see if they think some of the fixes are useful in LTS.  The
Android tree does have things beyond what's in LTS and there's been more
time for analysis since the changes were made there.

> So that's why I keep pointing people at the android trees.  Look at what
> they did there.  There's nothing stoping anyone who is really insistant
> on staying on these old kernel versions from pulling from those branches
> to get these bugfixes in a known stable, and tested, implementation.

I think there's enough stuff going on in the Android tree to make that
unpalatable for a good segment of users.

> Or just move to 4.14.y.  Seriously, that's probably the safest thing in
> the long run for anyone here.  And when you realize you can't do that,
> go yell at your SoC for forcing you into the nightmare that they conned
> you into by their 3+ million lines added to their kernel tree.  You were
> always living on borowed time, and it looks like that time is finally
> up...

Yes, there are some people who are stuck with enormous out of tree patch
sets on most architectures (just look at the enterprise distros!) - but
there are also people who are at or very close to vanilla and just
trying to control their validation costs by not changing too much when
they don't need to.  There's a good discussion to be had about it being
sensible for people to accept more change in that segment of the market
but equally those same attitudes have been an important part of the
pressure that's been placed on vendors long term to get things in
mainline.  

> [1] It's also why I keep doing the LTS merges into the android-common
>     trees within days of the upstream LTS release (today being an
>     exception).  That way once you do a pull/merge, you can just keep
>     always merging to keep a secure device that is always up to date
>     with the latest LTS releases in a simple way.  How much easier can I
>     make it for the ARM ecosystem here, really?

That's great for the Android ecosystem, it's fantastic work and is doing
a lot to overcome resistances people had there to merging up the LTS
which is going to help many people.  While that's a very large part of
ARM ecosystem it's not all of it, there are also chip vendors and system
integrators who have made deliberate choices to minimize out of tree
code just as we've been encouraging them to.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-03-06 14:26 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-28  3:56 Alex Shi
2018-02-28  3:56 ` [PATCH 01/29] arm64: mm: Use non-global mappings for kernel space Alex Shi
2018-02-28 12:08   ` Greg KH
2018-03-01 11:53     ` Alex Shi
2018-02-28  3:56 ` [PATCH 02/29] arm64: mm: Move ASID from TTBR0 to TTBR1 Alex Shi
2018-02-28  3:56 ` [PATCH 03/29] arm64: mm: Allocate ASIDs in pairs Alex Shi
2018-02-28  3:56 ` [PATCH 04/29] arm64: mm: Add arm64_kernel_unmapped_at_el0 helper Alex Shi
2018-02-28  3:56 ` [PATCH 05/29] arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI Alex Shi
2018-02-28  3:56 ` [PATCH 06/29] arm64: factor out entry stack manipulation Alex Shi
2018-02-28  3:56 ` [PATCH 07/29] arm64: entry.S: move SError handling into a C function for future expansion Alex Shi
2018-02-28  3:56 ` [PATCH 08/29] module: extend 'rodata=off' boot cmdline parameter to module mappings Alex Shi
2018-02-28  3:56 ` [PATCH 09/29] arm64: entry: Add exception trampoline page for exceptions from EL0 Alex Shi
2018-02-28  3:56 ` [PATCH 10/29] arm64: mm: Map entry trampoline into trampoline and kernel page tables Alex Shi
2018-02-28  3:56 ` [PATCH 11/29] arm64: entry: Explicitly pass exception level to kernel_ventry macro Alex Shi
2018-02-28  3:56 ` [PATCH 12/29] arm64: entry: Hook up entry trampoline to exception vectors Alex Shi
2018-02-28  3:56 ` [PATCH 13/29] arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks Alex Shi
2018-02-28  3:56 ` [PATCH 14/29] arm64: entry: Add fake CPU feature for unmapping the kernel at EL0 Alex Shi
2018-02-28  3:56 ` [PATCH 15/29] arm64: kaslr: Put kernel vectors address in separate data page Alex Shi
2018-02-28  3:56 ` [PATCH 16/29] arm64: use RET instruction for exiting the trampoline Alex Shi
2018-02-28  3:56 ` [PATCH 17/29] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 Alex Shi
2018-02-28  3:56 ` [PATCH 18/29] arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry Alex Shi
2018-02-28  3:56 ` [PATCH 19/29] arm64: Take into account ID_AA64PFR0_EL1.CSV3 Alex Shi
2018-02-28  3:56 ` [PATCH 20/29] arm64: Allow checking of a CPU-local erratum Alex Shi
2018-02-28  3:56 ` [PATCH 21/29] arm64: capabilities: Handle duplicate entries for a capability Alex Shi
2018-02-28  3:56 ` [PATCH 22/29] arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75 Alex Shi
2018-02-28  3:56 ` [PATCH 23/29] arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs Alex Shi
2018-02-28  3:56 ` [PATCH 24/29] arm64: Turn on KPTI only on CPUs that need it Alex Shi
2018-02-28  3:56 ` [PATCH 25/29] arm64: kpti: Make use of nG dependent on arm64_kernel_unmapped_at_el0() Alex Shi
2018-02-28  3:56 ` [PATCH 26/29] arm64: kpti: Add ->enable callback to remap swapper using nG mappings Alex Shi
2018-02-28  3:56 ` [PATCH 27/29] arm64: Force KPTI to be disabled on Cavium ThunderX Alex Shi
2018-02-28  3:56 ` [PATCH 28/29] arm64: entry: Reword comment about post_ttbr_update_workaround Alex Shi
2018-02-28  3:56 ` [PATCH 29/29] arm64: idmap: Use "awx" flags for .idmap.text .pushsection directives Alex Shi
2018-02-28  4:02 ` [PATCH 0/29] arm meltdown fix backporting review for lts 4.9 Alex Shi
2018-03-01 15:24 ` Greg KH
2018-03-02  9:14   ` Alex Shi
2018-03-02 10:32     ` Marc Zyngier
2018-03-02 16:54     ` Greg KH
2018-03-05 12:46       ` Mark Brown
2018-03-05 13:08         ` Greg KH
2018-03-06 14:26           ` Mark Brown [this message]
2018-03-06 17:25             ` Greg KH
2018-03-06 21:31               ` Mark Brown
2018-03-13 10:03                 ` Greg KH
2018-03-07  4:43               ` Alex Shi
2018-03-07  3:27           ` Alex Shi
2018-03-07 18:24       ` Ard Biesheuvel
2018-03-13 10:04         ` Greg KH
2018-03-13 10:13           ` Ard Biesheuvel
2018-03-13 10:38             ` Greg KH
2018-03-13 13:01               ` Ard Biesheuvel
2018-03-13 13:25                 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180306142634.GC13586@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alex.shi@linaro.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=greg@kroah.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome