search for: mkwrite

...tically attached >> >>> to the userspace pte entries even through VM_WRITE + VM_SHARE. >> >>> The PTE_RDONLY needs to be cleared in vmf_insert_pfn_prot. However >> >>> vmf_insert_pfn_prot do not make the pte writable passing false >> >>> @mkwrite to insert_pfn. >> >> Question is why is arm64 doing this? As far as I can see they must >> >> have some hardware reason for that. >> >> >> >> The mkwrite parameter to insert_pfn() was added by commit >> >> b2770da642540 to make insert_pfn(...

...64 platform the PTE_RDONLY is automatically attached to >>> the userspace pte entries even through VM_WRITE + VM_SHARE. >>> The PTE_RDONLY needs to be cleared in vmf_insert_pfn_prot. However >>> vmf_insert_pfn_prot do not make the pte writable passing false >>> @mkwrite to insert_pfn. >> Question is why is arm64 doing this? As far as I can see they must have some >> hardware reason for that. >> >> The mkwrite parameter to insert_pfn() was added by commit >> b2770da642540 to make insert_pfn() look more like insert_pfn_pmd() so that &gt...

...bit more sense. > Because on arm64 platform the PTE_RDONLY is automatically attached to > the userspace pte entries even through VM_WRITE + VM_SHARE. > The PTE_RDONLY needs to be cleared in vmf_insert_pfn_prot. However > vmf_insert_pfn_prot do not make the pte writable passing false @mkwrite > to insert_pfn. Question is why is arm64 doing this? As far as I can see they must have some hardware reason for that. The mkwrite parameter to insert_pfn() was added by commit b2770da642540 to make insert_pfn() look more like insert_pfn_pmd() so that the DAX code can insert PTEs which are...

...nd immediate fault to the pfn due > to first dirty catching when the cpu re-execute the store > instruction. It could be that this is done to work around some hw behavior, but not because of dirty catching. > Normally if the drivers call vmf_insert_pfn_prot and also supply > 'pfn_mkwrite' callback within vm_operations_struct which requires > the pte to be dirty catching then the vmf_insert_pfn_prot and the > double fault are reasonable. It is not a problem. Well, as far as I can see that behavior absolutely doesn't make sense. When pfn_mkwrite is requested then the...

...table page writes. One workaround would be to use ext4 instead, or avoid the use of ext3.ko + DIF/DIX. Hopefully it doesn''t take long to sort out. Another thing I noticed is that there are several filesystems that call wait_on_page_writeback before returning VM_FAULT_LOCKED in their page_mkwrite delegates. It might be possible to convert some of these to wait_for_stable_pages unless there''s some other reason that we always want to wait for writeback. Finally, if a filesystem wants the VM to help it provide stable pages, it''s now possible to use the *_require_stable_page...

The fault code has been calling file_update_time after ->page_mkwrite after it drops the page lock, but this is annoying because this calls mark_inode_dirty which can fail in Btrfs, so we want to be able to do these updates in ->page_mkwrite so we can get an error back to the user. So get rid of the file_update_time calls in the fault code and push it into everyb...