On Mon, 2017-10-16 at 05:21:35 UTC, Balbir Singh wrote:
> When using the radix MMU on Power9 DD1, to work around a hardware
> problem, radix__pte_update() is required to do a two stage update of
> the PTE. First we write a zero value into the PTE, then we flush the
> TLB, and then we write the new PTE value.
>
> In the normal case that works OK, but it does not work if we're
> updating the PTE that maps the code we're executing, because the
> mapping is removed by the TLB flush and we can no longer execute from
> it. Unfortunately the STRICT_RWX code needs to do exactly that.
>
> The exact symptoms when we hit this case vary, sometimes we print an
> oops and then get stuck after that, but I've also seen a machine just
> get stuck continually page faulting with no oops printed. The variance
> is presumably due to the exact layout of the text and the page size
> used for the mappings. In all cases we are unable to boot to a shell.
>
> There are possible solutions such as creating a second mapping of the
> TLB flush code, executing from that, and then jumping back to the
> original. However we don't want to add that level of complexity for a
> DD1 work around.
>
> So just detect that we're running on Power9 DD1 and refrain from
> changing the permissions, effectively disabling STRICT_RWX on Power9
> DD1.
>
> Fixes: 7614ff3 ("powerpc/mm/radix: Implement STRICT_RWX/mark_rodata_ro() for
> Radix")
>
> Cc: sta...@vger.kernel.org
>
> Reported-by: Andrew Jeffery <and...@aj.id.au>
> [Changelog as suggested by Michael Ellerman <m...@ellerman.id.au>]
> Signed-off-by: Balbir Singh <bsinghar...@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f79ad50ea3c73fb1ea5b09e95c864e
cheers
