Re: write fault on dax mapping and usage of set_pte_at.

["Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>]

"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:

> On 2/21/19 5:42 PM, Jan Kara wrote:
>> Hi Aneesh,
>> 
>> On Thu 21-02-19 12:52:39, Aneesh Kumar K.V wrote:
>>> We found this while testing dax with XFS, but i guess this is true for
>>> other file systems too. The stack trace looks as
>>>
> 
>>> I guess iomap code doesn't handle this correctly? Or am I missing
>>> some other ways we can end up flushing tlb?
>> 
>> So for RW->RO transition we use ptep_clear_flush() in dax_entry_mkclean()
>> so that one is certainly safe. Similarly for unmapping. The RO->RW
>> transition does not seem to have any TLB flush so there TLB could still
>> carry stale information but it's the same as with normal page faults on
>> invalid PTEs or with protection faults for normal pages (see e.g.
>> finish_mkwrite_fault()). 
>
> I am not sure i understood that. RO -> RW transition can have stale TLB 
> entries with RO mapping in them. So architecture do flush TLB during the 
> fault, some may not. We do have a NestMMU issue with that transition 
> which requires us to do mark the pte invalid and flush TLB for that 
> transition. (see commit bd5050e38aec3055ff4257ade987d808ac93b582 )
>
> For invalid PTEs we should have a TLB entry at all.

 For invalid PTEs we should not have a TLB entry at all.

-aneesh