On Sun, Jun 18, 2017 at 1:28 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Fri, Jun 09, 2017 at 01:23:51PM -0700, Dan Williams wrote: >> Implement a __copy_from_user_inatomic_flushcache, memcpy_page_flushcache, and >> memcpy_flushcache, that guarantee that the destination buffer is not dirty in >> the cpu cache on completion. The new copy_from_iter_flushcache and sub-routines > > Wouldn't writethrough be a better name? I started with _writethrough, Ingo suggested _wt, and then Toshi rightly pointed out that _wt might lead applications to assume that the involved cache-lines are valid on return which may not be true. So we settled on _flushcache in this thread [1]. [1]: https://lkml.org/lkml/2017/5/6/99 >> will be used to replace the "pmem api" (include/linux/pmem.h + >> arch/x86/include/asm/pmem.h). The availability of copy_from_iter_flushcache() >> and memcpy_flushcache() are gated by the CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE >> config symbol, and fallback to copy_from_iter_nocache() and plain memcpy() >> otherwise. > > What is UACCESS about memcpy_flushcache? The uaccess part comes from the fact that the conversion provides all the _flushcache versions of the copy_from_iter() operations (__copy_from_user_flushcache, memcpy_page_flushcache, memcpy_flushcache). It also stems from Al asking that __copy_user_flushcache() live in arch/x86/lib/usercopy_64.c. That said, I wouldn't object to a different name for the config symbol.
