summaryrefslogtreecommitdiffstats
path: root/drivers/crypto/s5p-sss.c
diff options
context:
space:
mode:
authorDan Williams <dan.j.williams@intel.com>2017-04-06 09:04:31 -0700
committerDan Williams <dan.j.williams@intel.com>2017-04-12 13:45:18 -0700
commit11e63f6d920d6f2dfd3cd421e939a4aec9a58dcd (patch)
tree83daf277166209e5b0bc01d0047e08ce3c4c17bb /drivers/crypto/s5p-sss.c
parent956a4cd2c957acf638ff29951aabaa9d8e92bbc2 (diff)
downloadlinux-11e63f6d920d6f2dfd3cd421e939a4aec9a58dcd.tar.bz2
x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions
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. Fixes: 5de490daec8b ("pmem: add copy_from_iter_pmem() and clear_pmem()") Cc: <stable@vger.kernel.org> Cc: <x86@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Matthew Wilcox <mawilcox@microsoft.com> Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Toshi Kani <toshi.kani@hpe.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Diffstat (limited to 'drivers/crypto/s5p-sss.c')
0 files changed, 0 insertions, 0 deletions