On 04.03.24 10:04, mawupeng wrote:
On 2024/3/4 16:57, David Hildenbrand wrote:
On 04.03.24 09:47, mawupeng wrote:
Hi Maintainers, kindly ping...
On 2024/2/28 9:55, mawupeng wrote:
On 2024/2/27 21:15, David Hildenbrand wrote:
On 27.02.24 14:00, David Hildenbrand wrote:
On 27.02.24 13:28, Wupeng Ma wrote:
We find that a warn will be produced during our test, the detail log is
shown in the end.
The core problem of this warn is that the first pfn of this pfnmap vma is
cleared during memory-failure. Digging into the source we find that this
problem can be triggered as following:
// mmap with MAP_PRIVATE and specific fd which hook mmap
mmap(MAP_PRIVATE, fd)
__mmap_region
remap_pfn_range
// set vma with pfnmap and the prot of pte is read only
Okay, so we get a MAP_PRIVATE VM_PFNMAP I assume.
What fd is that exactly? Often, we disallow private mappings in the
mmap() callback (for a good reason).
We found this problem in 5.10, Commit 9f78bf330a66 ("xsk: support use vaddr as ring") Fix this
problem during supporting vaddr by remap VM_PFNMAP by VM_MIXEDMAP. But other modules which
use remap_pfn_range may still have this problem.
I wrote a simple reproducer using MAP_PRIVATE of iouring queues on Friday.
It do seems wired for private mappings, What is the good reason?
I'm sure there are some use cases that require MAP_PRIVATE of such areas, and usually there is nothing wrong with that.
So MAP_PRIVATE for VM_PFNMAP area with write access is ok? What is the user case for this situation?
I recall that MAP_PRIVATE /dev/mem mappings were required for some use
cases. No details/ideas about other users, though.
Likely sufficient use case that people really thought about ways to get
it working -- see vm_normal_page() :)
--
Cheers,
David / dhildenb
