On Wed, Oct 11, 2017 at 10:05:56PM +0200, Jan Kara wrote: > Define new MAP_SYNC flag and corresponding VMA VM_SYNC flag. As the > MAP_SYNC flag is not part of LEGACY_MAP_MASK, currently it will be > refused by all MAP_SHARED_VALIDATE map attempts and silently ignored for > everything else. > > Signed-off-by: Jan Kara <jack@xxxxxxx> > --- > arch/xtensa/include/uapi/asm/mman.h | 1 + > fs/proc/task_mmu.c | 1 + > include/linux/mm.h | 1 + > include/linux/mman.h | 3 ++- > include/uapi/asm-generic/mman.h | 1 + > 5 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/arch/xtensa/include/uapi/asm/mman.h b/arch/xtensa/include/uapi/asm/mman.h > index ec597900eec7..b62a7ce166fb 100644 > --- a/arch/xtensa/include/uapi/asm/mman.h > +++ b/arch/xtensa/include/uapi/asm/mman.h > @@ -56,6 +56,7 @@ > #define MAP_NONBLOCK 0x20000 /* do not block on IO */ > #define MAP_STACK 0x40000 /* give out an address that is best suited for process/thread stacks */ > #define MAP_HUGETLB 0x80000 /* create a huge page mapping */ > +#define MAP_SYNC 0x100000 /* perform synchronous page faults for the mapping */ Why define MAP_SYNC for this one architecture, but not for the rest that have their own arch/*/include/uapi/asm/mman.h? AFAIK xtensa doesn't support DAX, so has no need for MAP_SYNC? Other than this one question, this patch looks fine: Reviewed-by: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
