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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxx> 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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux