On Fri, May 11, 2018 at 05:06:20PM +0100, Suzuki K Poulose wrote: > On 11/05/18 16:47, Greg KH wrote: > > On Fri, May 11, 2018 at 02:51:15PM +0100, Suzuki K Poulose wrote: > > > commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream > > > > > > Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer > > > from an erratum 1024718, which causes incorrect updates when DBM/AP > > > bits in a page table entry is modified without a break-before-make > > > sequence. The work around is to disable the hardware DBM feature > > > on the affected cores. The hardware Access Flag management features > > > is not affected. > > > > > > The hardware DBM feature is a non-conflicting capability, i.e, the > > > kernel could handle cores using the feature and those without having > > > the features running at the same time. So this work around is detected > > > at early boot time, rather than delaying it until the CPUs are brought > > > up into the kernel with MMU turned on. This also avoids other complexities > > > with late CPUs turning online, with or without the hardware DBM features. > > > > > > Cc: stable@xxxxxxxxxxxxxxx # v4.9 > > > Cc: Catalin Marinas <catalin.marinas@xxxxxxx> > > > Cc: Mark Rutland <mark.rutland@xxxxxxx> > > > Cc: Will Deacon <will.deacon@xxxxxxx> > > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx> > > > --- > > > Note: The upstream commit is on top of a reworked capability > > > infrastructure for arm64 heterogeneous systems, which allows > > > delaying the CPU model checks. This backport is based on the > > > original version of the patch [0], which checks the affected > > > CPU models during the early boot. > > > > > > [0] https://lkml.kernel.org/r/20180116102323.3470-1-suzuki.poulose@xxxxxxx > > > > Now applied, thanks. > > Greg, > > I have the backport for v4.4 ready. But it needs to cherry-pick a commit > (commit 30b5ba5cf33 : arm64: introduce mov_q macro to move a constant into a 64-bit register) > which adds the assembly helper and that seems to result in a conflict with > an obvious resolution. What do you prefer in this case ? > > 1) Go ahead with the cherry-pick Have 2 patches, the first be the cherry pick and the second be your backported other patch. I almost always want the original patches that are in Linus's tree, otherwise we always get the merging/squashing/rewrite wrong. thanks, greg k-h
