On 2018-10-24 6:20 PM, James Bottomley wrote:
On Wed, 2018-10-24 at 17:56 +0200, Helge Deller wrote:
On 24.10.2018 17:45, Helge Deller wrote:
On 24.10.2018 17:03, John David Anglin wrote:
On 2018-10-24 7:59 AM, John David Anglin wrote:
The fault occured executing this instruction "stw r31,0(r25)".
Register r31 contains the following
instruction "pdtlb,l r0(sr1,r3)". This indicates the fault
occurred during alternative patching.
I suspect all kernel TLB entries need to be flushed prior to
alternative patching to ensure that kernel
pages are writeable.
Looks like this is a problem with set_kernel_text_rw(). Maybe
this causes problems:
int __flush_tlb_range(unsigned long sid, unsigned long start,
unsigned long end)
{
unsigned long flags;
if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) &&
end - start >= parisc_tlb_flush_threshold) {
flush_tlb_all();
return 1;
}
I believe that we need to disable this optimization until the
parisc_tlb_flush_threshold is
calculated. I think this crash is related to the occasional
crash in parisc_setup_cache_timing().
Maybe change in cache.c the initial define for
parisc_tlb_flush_threshold:
static unsigned long parisc_tlb_flush_threshold __read_mostly =
~0UL;
If it would run into flush_tlb_all(), then I'd expect that all TLBs
have been flushed and
we wouldn't see an issue.
Maybe the info in the cache_info struct, which is used in the
assembly of flush_tlb_all_local(),
hasn't been initialized yet and such the whole cache hasn't been
flushed?
Nope, cache_info has already been initialized then...
Nevertheless, flush_tlb_all_local() should have fully flushed the
TLB...
I don't think it does what you think: you're expecting it to flush the
TLB entries associated with the kernel. What it seems to do, in my
reading, is flush the TLB entries associated with the user space id,
which won't touch the kernel tlbs.
It uses space id 0 which is the space used by the kernel.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
