On Wed, Sep 16, 2020 at 3:57 AM Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > > On Tue, 15 Sep 2020, Mikulas Patocka wrote: > > > > > > > On Tue, 15 Sep 2020, Mikulas Patocka wrote: > > > > > > > - __copy_from_user_inatomic_nocache doesn't flush cache for leading and > > > > > trailing bytes. > > > > > > > > You want copy_user_flushcache(). See how fs/dax.c arranges for > > > > dax_copy_from_iter() to route to pmem_copy_from_iter(). > > > > > > Is it something new for the kernel 5.10? I see only __copy_user_flushcache > > > that is implemented just for x86 and arm64. > > > > > > There is __copy_from_user_flushcache implemented for x86, arm64 and power. > > > It is used in lib/iov_iter.c under > > > #ifdef CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE - so should I use this? Yes, but maybe not directly. > > > > > > Mikulas > > > > ... and __copy_user_flushcache is not exported for modules. So, I am stuck > > with __copy_from_user_inatomic_nocache. > > > > Mikulas > > I'm submitting this patch that adds the required exports (so that we could > use __copy_from_user_flushcache on x86, arm64 and powerpc). Please, queue > it for the next merge window. Why? This should go with the first user, and it's not clear that it needs to be relative to the current dax_operations export scheme. My first question about nvfs is how it compares to a daxfs with executables and other binaries configured to use page cache with the new per-file dax facility?
