Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1619165
| From | Dan Williams <dan.j.williams@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions |
| Date | 2017-04-08 02:00 +0200 |
| Message-ID | <ttLXj-64T-1@gated-at.bofh.it> (permalink) |
| References | <ttmPf-6c4-7@gated-at.bofh.it> <ttGbg-21h-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Apr 7, 2017 at 10:41 AM, Kani, Toshimitsu <toshi.kani@hpe.com> wrote: > On Thu, 2017-04-06 at 13:59 -0700, Dan Williams wrote: >> Before we rework the "pmem api" to stop abusing __copy_user_nocache() >> for memcpy_to_pmem() we need to fix cases where we may strand dirty >> data in the cpu cache. The problem occurs when copy_from_iter_pmem() >> is used for arbitrary data transfers from userspace. There is no >> guarantee that these transfers, performed by dax_iomap_actor(), will >> have aligned destinations or aligned transfer lengths. Backstop the >> usage __copy_user_nocache() with explicit cache management in these >> unaligned cases. >> >> Yes, copy_from_iter_pmem() is now too big for an inline, but >> addressing that is saved for a later patch that moves the entirety of >> the "pmem api" into the pmem driver directly. > > The change looks good to me. Should we also avoid cache flushing in > the case of size=4B & dest aligned by 4B? Yes, since you fixed the 4B aligned case we should skip cache flushing in that case. I'll send a v2.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions Dan Williams <dan.j.williams@intel.com> - 2017-04-06 23:10 +0200
Re: [PATCH] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions "Kani, Toshimitsu" <toshi.kani@hpe.com> - 2017-04-07 19:50 +0200
Re: [PATCH] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions Dan Williams <dan.j.williams@intel.com> - 2017-04-08 02:00 +0200
csiph-web