Hi, Your right, for io memory it does not make sense to do COW. Nevertheless we see a page fault for each page after mapping on first access. We also saw this at first when we used Xenomai 2.6 on 32bit arm, where it was fixed.
It now happened again when porting to Xenomai3. I was hoping the linux kernel whould now behave in an other way for io memory, but look like it stayed the same at least for 32Bit arm. So I checked how it was handled in mmap and copied the solution from there. Regards, Gunter > -----Original Message----- > From: Jan Kiszka <[email protected]> > Sent: Mittwoch, 15. Juni 2022 10:12 > To: Philippe Gerum <[email protected]>; Grau, Gunter > <[email protected]> > Cc: [email protected] > Subject: Re: [PATCH] rtdm/drvlib: Prevent pagefaults on arm on io mapping > > Caution: This e-mail originated from outside of Philips, be careful for > phishing. > > > On 15.06.22 09:54, Philippe Gerum wrote: > > > > Jan Kiszka via Xenomai <[email protected]> writes: > > > >> On 23.05.22 16:04, Gunter Grau via Xenomai wrote: > >>> From: Gunter Grau <[email protected]> > >>> > >>> When mapping io memory into userspace an extra simulated pagefault > >>> for all pages is added to prevent later pagefaults because of copy > >>> on write mechanisms. This happens only on architectures that have > >>> defined the needed cobalt_machine.prefault function. > >>> > >>> Signed-off-by: Gunter Grau <[email protected]> > >>> --- > >>> kernel/cobalt/rtdm/drvlib.c | 10 +++++++++- > >>> 1 file changed, 9 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/kernel/cobalt/rtdm/drvlib.c > >>> b/kernel/cobalt/rtdm/drvlib.c index 4eaf3a57c..db8431ee1 100644 > >>> --- a/kernel/cobalt/rtdm/drvlib.c > >>> +++ b/kernel/cobalt/rtdm/drvlib.c > >>> @@ -1761,6 +1761,7 @@ static int mmap_iomem_helper(struct > >>> vm_area_struct *vma, phys_addr_t pa) { > >>> pgprot_t prot = PAGE_SHARED; > >>> unsigned long len; > >>> + int ret; > >>> > >>> len = vma->vm_end - vma->vm_start; #ifndef CONFIG_MMU @@ > >>> -1774,8 +1775,15 @@ static int mmap_iomem_helper(struct > >>> vm_area_struct *vma, phys_addr_t pa) #endif > >>> vma->vm_page_prot = pgprot_noncached(prot); > >>> > >>> - return remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT, > >>> + ret = remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT, > >>> len, vma->vm_page_prot); > >>> + if (ret) > >>> + return ret; > >>> + > >>> + if (cobalt_machine.prefault) > >>> + cobalt_machine.prefault(vma); > >>> + > >>> + return ret; > >>> } > >>> > >>> static int mmap_buffer_helper(struct rtdm_fd *fd, struct > >>> vm_area_struct *vma) > >> > >> Wow, that was likely broken by the refactoring in c8e9e166, long ago. > >> > >> Applied to next > >> > > > > The prefault hook has always been specifically about COW-breaking, I/O > > memory has no business with this, so there is no point in having the > > iomem helper calling the prefaulting hook. > > > > I suspect that rtdm_mmap_to_user() should be called instead of > > rtdm_iomap_to_user() in the case at hand. > > > > If Gunter is mapping IO memory, rtdm_mmap_to_user is surely not the right > thing. > > Could it be that the prefault callback also has the side effect of setting all > page table entries that would otherwise only be filled lazily? > > Jan > > -- > Siemens AG, Technology > Competence Center Embedded Linux ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
