On Thu, 16 Apr 2020 08:36:50 -0700 Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > On 4/16/20 7:59 AM, Claudio Imbrenda wrote: > > On Thu, 16 Apr 2020 07:20:48 -0700 > > Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > >> On 4/16/20 5:15 AM, Claudio Imbrenda wrote: > >>>> I assumed that this was all anonymous-only so it's always dirty > >>>> before writeback starts. > >>> it could also be mmapped > >> > >> Let's say you have a mmap()'d ramfs file. Another process calls > >> which doesn't have it mapped calls sys_write() and writes to the > >> file. > ... > >> Where is the arch_make_page_accessible() in this case on the ramfs > >> page? > > > > it's in the fault handler for the exception the CPU will get when > > attempting to write the data to the protected page > > Ahh, so this is *just* intended to precede I/O done on the page, when > a non-host entity is touching the memory? yep > That seems inconsistent with the process_vm_readv/writev() paths which > set FOLL_PIN on their pin_remote_user_pages() requests, but don't do > I/O to the memory. FOLL_PIN simply indicates potential access to the content of the page, not just for I/O. so yes, we are overdoing arch_make_page_accessible() in some cases, because we can't tell when a page will be used for I/O and when not. In most cases this will boil down to checking a flag and doing nothing, for example in case the page was already accessible. Also note that making the page accessible because of a FOLL_PIN in absence of I/O will probably later on spare us from triggering and handling the exception that would have caused us to make the page accessible anyway.
