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...
Helge
