| Message ID | 152416215323.6262.188669847137941145.stgit@djiang5-desk3.ch.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
I'll change the "allowing" to "allow" in the subject so we don't have a gerund phrase. On Thu, Apr 19, 2018 at 11:22 AM, Dave Jiang <dave.jiang@intel.com> wrote: > MAP_SYNC is basically a nop for device-dax. However allowing the MAP_SYNC Not "bascially", it *is* a nop for device-dax. I'll change this second sentence to start "Allow MAP_SYNC to succeed on device-dax to eliminate special casing between device-dax and fs-dax as to when the flag can be specified." > flag to succeed on device-dax would make it consistent with fs-dax and > reduces confusion for the application writer. This allows the application to > assume that it does not need to call fsync() after writes to device-dax > mappings. I'll change this last sentence to say "Device-dax users already implicitly assume that they do not need to call fsync(), enable them to explicitly check for this capability".
diff --git a/drivers/dax/device.c b/drivers/dax/device.c index 37be5a306c8f..374b6718f6c5 100644 --- a/drivers/dax/device.c +++ b/drivers/dax/device.c @@ -19,6 +19,7 @@ #include <linux/dax.h> #include <linux/fs.h> #include <linux/mm.h> +#include <linux/mman.h> #include "dax-private.h" #include "dax.h" @@ -530,6 +531,7 @@ static const struct file_operations dax_fops = { .release = dax_release, .get_unmapped_area = dax_get_unmapped_area, .mmap = dax_mmap, + .mmap_supported_flags = MAP_SYNC, }; static void dev_dax_release(struct device *dev)
MAP_SYNC is basically a nop for device-dax. However allowing the MAP_SYNC flag to succeed on device-dax would make it consistent with fs-dax and reduces confusion for the application writer. This allows the application to assume that it does not need to call fsync() after writes to device-dax mappings. Signed-off-by: Dave Jiang <dave.jiang@intel.com> --- drivers/dax/device.c | 2 ++ 1 file changed, 2 insertions(+)