lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <1505418254.14842.7.camel@intel.com> Date: Thu, 14 Sep 2017 19:44:28 +0000 From: "Williams, Dan J" <dan.j.williams@...el.com> To: "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org> CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "hch@....de" <hch@....de>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>, "luto@...nel.org" <luto@...nel.org>, "julia.lawall@...6.fr" <julia.lawall@...6.fr>, "jack@...e.cz" <jack@...e.cz> Subject: [GIT PULL] MAP_SHARED_VALIDATE for 4.14 Hi Linus, please consider pulling: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/map-shared-validate-for-4.14 ...for 4.14 as a pre-requisite for the proposed mmap flags (MAP_SYNC and MAP_DIRECT) being developed for 4.15 consideration. As I highlighted in the last posting [1] these patches are based on a random point in the merge window (state of the tree 2 days ago). They have not been in -next. However, they have been exposed to the 0day kbuild robot with all reports fixed. A test merge with the state of the tree today finds no conflicts, nor new mmap handlers for the coccinelle script to convert. The only change since the last posting was clarifying in commit 4aac0d08f6d1 "mm: introduce MAP_SHARED_VALIDATE..." that MAP_SHARED_VALIDATE is just MAP_SHARED+validate, not a bitmap to be added to new flag values, and that it is a unique MAP_TYPE number not necessarily (MAP_SHARED|MAP_PRIVATE) (from Jan's review). Now, we could wait until 4.15 and do the same rebase, run coccinelle script, rinse, and repeat process for 4.15. I.e wait until we also have the MAP_SYNC and/or MAP_DIRECT to merge at the same time, but I think it is preferable to base that development on early 4.14-rc and get it some soak time in -next. Another alternative is to just get patch1, commit 403fee48224c "vfs: add flags...", in for 4.14 and save MAP_SHARED_VALIDATE to arrive in the next merge window coincident with the new flags implementation. Lastly, the alternative to all this thrash is carrying the flags in the vma. That bloats vm_area_struct everywhere and complicates vma splitting / merging for the handful of mmap implementations that will ever care about the new flags. [1]: https://lwn.net/Articles/733281/ --- The following changes since commit 8fac2f96ab86b0e14ec4e42851e21e9b518bdc55: Merge branch 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm (2017-09-12 06:10:44 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/map-shared-validate-for-4.14 for you to fetch changes up to 4aac0d08f6d1ae4475bbfe761b943d105e11b82a: mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags (2017-09-12 10:12:34 -0700) ---------------------------------------------------------------- MAP_SHARED_VALIDATE for 4.14 Preparation infrastructure for introducing new mmap flags: * Introduce MAP_SHARED_VALIDATE as an mmap(2) flag that in addition to creating a MAP_SHARED mapping also arranges for the @flags parameter of mmap(2) to be validated by the endpoint mmap-file-operation. I.e. new mmap flags require per mmap implementation opt-in and run time validation. * Make the @flags parameter available to all mmap implementations, both top-level 'struct file_operations' and sub-level leaf implementations. ---------------------------------------------------------------- Dan Williams (2): vfs: add flags parameter to all ->mmap() handlers mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags arch/alpha/include/uapi/asm/mman.h | 1 + arch/arc/kernel/arc_hostlink.c | 3 +- arch/mips/include/uapi/asm/mman.h | 1 + arch/mips/kernel/vdso.c | 2 +- arch/parisc/include/uapi/asm/mman.h | 1 + arch/powerpc/kernel/proc_powerpc.c | 3 +- arch/powerpc/kvm/book3s_64_vio.c | 3 +- arch/powerpc/platforms/cell/spufs/file.c | 21 +++++++---- arch/powerpc/platforms/powernv/memtrace.c | 3 +- arch/powerpc/platforms/powernv/opal-prd.c | 3 +- arch/tile/mm/elf.c | 3 +- arch/um/drivers/mmapper_kern.c | 3 +- arch/xtensa/include/uapi/asm/mman.h | 1 + drivers/android/binder.c | 3 +- drivers/auxdisplay/cfag12864bfb.c | 3 +- drivers/auxdisplay/ht16k33.c | 3 +- drivers/char/agp/frontend.c | 3 +- drivers/char/bsr.c | 3 +- drivers/char/hpet.c | 6 ++- drivers/char/mbcs.c | 3 +- drivers/char/mbcs.h | 3 +- drivers/char/mem.c | 11 ++++-- drivers/char/mspec.c | 9 +++-- drivers/char/uv_mmtimer.c | 6 ++- drivers/dax/device.c | 3 +- drivers/dma-buf/dma-buf.c | 11 ++++-- drivers/firewire/core-cdev.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 5 ++- drivers/gpu/drm/armada/armada_gem.c | 3 +- drivers/gpu/drm/ast/ast_drv.h | 3 +- drivers/gpu/drm/ast/ast_ttm.c | 3 +- drivers/gpu/drm/bochs/bochs.h | 3 +- drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +- drivers/gpu/drm/bochs/bochs_mm.c | 3 +- drivers/gpu/drm/cirrus/cirrus_drv.h | 3 +- drivers/gpu/drm/cirrus/cirrus_ttm.c | 3 +- drivers/gpu/drm/drm_fb_cma_helper.c | 8 ++-- drivers/gpu/drm/drm_gem.c | 4 +- drivers/gpu/drm/drm_gem_cma_helper.c | 8 ++-- drivers/gpu/drm/drm_prime.c | 5 ++- drivers/gpu/drm/drm_vm.c | 3 +- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 6 ++- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 11 +++--- drivers/gpu/drm/etnaviv/etnaviv_gem.h | 3 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 9 +++-- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 10 +++-- drivers/gpu/drm/exynos/exynos_drm_gem.h | 6 ++- drivers/gpu/drm/gma500/framebuffer.c | 3 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 3 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 3 +- drivers/gpu/drm/i810/i810_dma.c | 3 +- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 6 ++- drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 4 +- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 8 ++-- drivers/gpu/drm/mediatek/mtk_drm_gem.h | 5 ++- drivers/gpu/drm/mgag200/mgag200_drv.h | 3 +- drivers/gpu/drm/mgag200/mgag200_ttm.c | 3 +- drivers/gpu/drm/msm/msm_drv.h | 6 ++- drivers/gpu/drm/msm/msm_fbdev.c | 6 ++- drivers/gpu/drm/msm/msm_gem.c | 5 ++- drivers/gpu/drm/msm/msm_gem_prime.c | 3 +- drivers/gpu/drm/nouveau/nouveau_ttm.c | 5 ++- drivers/gpu/drm/nouveau/nouveau_ttm.h | 2 +- drivers/gpu/drm/omapdrm/omap_drv.h | 3 +- drivers/gpu/drm/omapdrm/omap_gem.c | 5 ++- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 +- drivers/gpu/drm/qxl/qxl_drv.h | 6 ++- drivers/gpu/drm/qxl/qxl_prime.c | 2 +- drivers/gpu/drm/qxl/qxl_ttm.c | 3 +- drivers/gpu/drm/radeon/radeon_drv.c | 3 +- drivers/gpu/drm/radeon/radeon_ttm.c | 3 +- drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 5 ++- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 7 ++-- drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 5 ++- drivers/gpu/drm/tegra/gem.c | 9 +++-- drivers/gpu/drm/tegra/gem.h | 3 +- drivers/gpu/drm/udl/udl_dmabuf.c | 3 +- drivers/gpu/drm/udl/udl_drv.h | 3 +- drivers/gpu/drm/udl/udl_fb.c | 3 +- drivers/gpu/drm/udl/udl_gem.c | 5 ++- drivers/gpu/drm/vc4/vc4_bo.c | 10 +++-- drivers/gpu/drm/vc4/vc4_drv.h | 6 ++- drivers/gpu/drm/vgem/vgem_drv.c | 10 +++-- drivers/gpu/drm/virtio/virtgpu_drv.h | 6 ++- drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +- drivers/gpu/drm/virtio/virtgpu_ttm.c | 3 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 3 +- drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 3 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 3 +- drivers/hsi/clients/cmt_speech.c | 3 +- drivers/hwtracing/intel_th/msu.c | 3 +- drivers/hwtracing/stm/core.c | 3 +- drivers/infiniband/core/uverbs_main.c | 3 +- drivers/infiniband/hw/hfi1/file_ops.c | 6 ++- drivers/infiniband/hw/qib/qib_file_ops.c | 5 ++- drivers/media/common/saa7146/saa7146_fops.c | 3 +- drivers/media/pci/bt8xx/bttv-driver.c | 3 +- drivers/media/pci/cx18/cx18-fileops.c | 3 +- drivers/media/pci/cx18/cx18-fileops.h | 3 +- drivers/media/pci/meye/meye.c | 3 +- drivers/media/pci/zoran/zoran_driver.c | 2 +- drivers/media/platform/davinci/vpfe_capture.c | 3 +- drivers/media/platform/exynos-gsc/gsc-m2m.c | 3 +- drivers/media/platform/fsl-viu.c | 3 +- drivers/media/platform/m2m-deinterlace.c | 3 +- drivers/media/platform/mx2_emmaprp.c | 3 +- drivers/media/platform/omap/omap_vout.c | 3 +- drivers/media/platform/omap3isp/ispvideo.c | 3 +- drivers/media/platform/s3c-camif/camif-capture.c | 3 +- drivers/media/platform/s5p-mfc/s5p_mfc.c | 3 +- drivers/media/platform/sh_veu.c | 3 +- drivers/media/platform/soc_camera/soc_camera.c | 3 +- drivers/media/platform/via-camera.c | 3 +- drivers/media/usb/cpia2/cpia2_v4l.c | 3 +- drivers/media/usb/cx231xx/cx231xx-417.c | 3 +- drivers/media/usb/cx231xx/cx231xx-video.c | 3 +- drivers/media/usb/gspca/gspca.c | 3 +- drivers/media/usb/stkwebcam/stk-webcam.c | 3 +- drivers/media/usb/tm6000/tm6000-video.c | 3 +- drivers/media/usb/usbvision/usbvision-video.c | 3 +- drivers/media/usb/uvc/uvc_v4l2.c | 3 +- drivers/media/usb/zr364xx/zr364xx.c | 3 +- drivers/media/v4l2-core/v4l2-dev.c | 5 ++- drivers/media/v4l2-core/v4l2-mem2mem.c | 3 +- drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +- drivers/media/v4l2-core/videobuf2-dma-sg.c | 2 +- drivers/media/v4l2-core/videobuf2-v4l2.c | 3 +- drivers/media/v4l2-core/videobuf2-vmalloc.c | 2 +- drivers/misc/aspeed-lpc-ctrl.c | 3 +- drivers/misc/cxl/api.c | 5 ++- drivers/misc/cxl/cxl.h | 3 +- drivers/misc/cxl/file.c | 3 +- drivers/misc/genwqe/card_dev.c | 3 +- drivers/misc/mic/scif/scif_fd.c | 3 +- drivers/misc/mic/vop/vop_vringh.c | 3 +- drivers/misc/sgi-gru/grufile.c | 3 +- drivers/mtd/mtdchar.c | 3 +- drivers/pci/proc.c | 3 +- drivers/rapidio/devices/rio_mport_cdev.c | 3 +- drivers/sbus/char/flash.c | 3 +- drivers/sbus/char/jsflash.c | 3 +- drivers/scsi/cxlflash/superpipe.c | 5 ++- drivers/scsi/sg.c | 3 +- drivers/staging/android/ashmem.c | 3 +- drivers/staging/android/ion/ion.c | 3 +- drivers/staging/comedi/comedi_fops.c | 3 +- .../staging/lustre/lustre/llite/llite_internal.h | 3 +- drivers/staging/lustre/lustre/llite/llite_mmap.c | 5 ++- .../media/atomisp/pci/atomisp2/atomisp_fops.c | 6 ++- drivers/staging/media/davinci_vpfe/vpfe_video.c | 3 +- drivers/staging/media/omap4iss/iss_video.c | 3 +- drivers/staging/vboxvideo/vbox_drv.h | 5 ++- drivers/staging/vboxvideo/vbox_prime.c | 3 +- drivers/staging/vboxvideo/vbox_ttm.c | 3 +- drivers/staging/vme/devices/vme_user.c | 3 +- drivers/tee/tee_shm.c | 3 +- drivers/uio/uio.c | 3 +- drivers/usb/core/devio.c | 3 +- drivers/usb/gadget/function/uvc_v4l2.c | 3 +- drivers/usb/mon/mon_bin.c | 3 +- drivers/vfio/vfio.c | 7 +++- drivers/video/fbdev/68328fb.c | 6 ++- drivers/video/fbdev/amba-clcd.c | 2 +- drivers/video/fbdev/aty/atyfb_base.c | 6 ++- drivers/video/fbdev/au1100fb.c | 3 +- drivers/video/fbdev/au1200fb.c | 3 +- drivers/video/fbdev/bw2.c | 5 ++- drivers/video/fbdev/cg14.c | 5 ++- drivers/video/fbdev/cg3.c | 5 ++- drivers/video/fbdev/cg6.c | 5 ++- drivers/video/fbdev/controlfb.c | 4 +- drivers/video/fbdev/core/fb_defio.c | 3 +- drivers/video/fbdev/core/fbmem.c | 5 ++- drivers/video/fbdev/ep93xx-fb.c | 3 +- drivers/video/fbdev/fb-puv3.c | 2 +- drivers/video/fbdev/ffb.c | 5 ++- drivers/video/fbdev/gbefb.c | 2 +- drivers/video/fbdev/igafb.c | 2 +- drivers/video/fbdev/leo.c | 5 ++- drivers/video/fbdev/omap/omapfb_main.c | 3 +- drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 3 +- drivers/video/fbdev/p9100.c | 6 ++- drivers/video/fbdev/ps3fb.c | 3 +- drivers/video/fbdev/pxa3xx-gcu.c | 3 +- drivers/video/fbdev/sa1100fb.c | 2 +- drivers/video/fbdev/sh_mobile_lcdcfb.c | 6 ++- drivers/video/fbdev/smscufx.c | 3 +- drivers/video/fbdev/tcx.c | 5 ++- drivers/video/fbdev/udlfb.c | 3 +- drivers/video/fbdev/vermilion/vermilion.c | 3 +- drivers/video/fbdev/vfb.c | 4 +- drivers/xen/gntalloc.c | 3 +- drivers/xen/gntdev.c | 3 +- drivers/xen/privcmd.c | 3 +- drivers/xen/xenbus/xenbus_dev_backend.c | 3 +- drivers/xen/xenfs/xenstored.c | 3 +- fs/9p/vfs_file.c | 10 +++-- fs/aio.c | 3 +- fs/btrfs/file.c | 4 +- fs/ceph/addr.c | 3 +- fs/ceph/super.h | 3 +- fs/cifs/cifsfs.h | 6 ++- fs/cifs/file.c | 10 +++-- fs/coda/file.c | 5 ++- fs/ecryptfs/file.c | 5 ++- fs/ext2/file.c | 5 ++- fs/ext4/file.c | 3 +- fs/f2fs/file.c | 3 +- fs/fuse/file.c | 8 ++-- fs/gfs2/file.c | 3 +- fs/hugetlbfs/inode.c | 3 +- fs/kernfs/file.c | 3 +- fs/ncpfs/mmap.c | 3 +- fs/ncpfs/ncp_fs.h | 2 +- fs/nfs/file.c | 5 ++- fs/nfs/internal.h | 2 +- fs/nilfs2/file.c | 3 +- fs/ocfs2/mmap.c | 3 +- fs/ocfs2/mmap.h | 3 +- fs/orangefs/file.c | 5 ++- fs/proc/inode.c | 7 ++-- fs/proc/vmcore.c | 6 ++- fs/ramfs/file-nommu.c | 6 ++- fs/romfs/mmap-nommu.c | 3 +- fs/ubifs/file.c | 5 ++- fs/xfs/xfs_file.c | 2 +- include/drm/drm_drv.h | 3 +- include/drm/drm_gem.h | 3 +- include/drm/drm_gem_cma_helper.h | 6 ++- include/drm/drm_legacy.h | 3 +- include/linux/dma-buf.h | 5 ++- include/linux/fb.h | 6 ++- include/linux/fs.h | 14 ++++--- include/linux/mm.h | 2 +- include/linux/mman.h | 44 ++++++++++++++++++++++ include/media/v4l2-dev.h | 2 +- include/media/v4l2-mem2mem.h | 3 +- include/media/videobuf2-v4l2.h | 3 +- include/misc/cxl.h | 3 +- include/uapi/asm-generic/mman-common.h | 1 + ipc/shm.c | 5 ++- kernel/events/core.c | 3 +- kernel/kcov.c | 3 +- kernel/relay.c | 4 +- mm/filemap.c | 15 +++++--- mm/mmap.c | 14 +++++-- mm/nommu.c | 4 +- mm/shmem.c | 3 +- net/socket.c | 6 ++- security/selinux/selinuxfs.c | 6 ++- sound/core/compress_offload.c | 3 +- sound/core/hwdep.c | 3 +- sound/core/info.c | 3 +- sound/core/init.c | 3 +- sound/core/oss/pcm_oss.c | 3 +- sound/core/pcm_native.c | 3 +- sound/oss/soundcard.c | 3 +- sound/oss/swarm_cs4297a.c | 3 +- tools/include/uapi/asm-generic/mman-common.h | 1 + virt/kvm/kvm_main.c | 3 +- 263 files changed, 722 insertions(+), 374 deletions(-) commit 403fee48224c8fd236a9ec23461e2d752c79101f Author: Dan Williams <dan.j.williams@...el.com> Date: Tue Sep 5 17:28:59 2017 -0700 vfs: add flags parameter to all ->mmap() handlers We are running running short of vma->vm_flags. We can avoid needing a new VM_* flag in some cases if the original @flags submitted to mmap(2) is made available to the ->mmap() 'struct file_operations' implementation. For example, the proposed addition of MAP_DIRECT can be implemented without taking up a new vm_flags bit. Another motivation to avoid vm_flags is that they appear in /proc/$pid/smaps, and we have seen software that tries to dangerously (TOCTOU) read smaps to infer the behavior of a virtual address range. Lastly, we may want to reject mmap attempts on a per-mmap-call basis. This conversion was performed by the following semantic patch. There were a few manual edits for oddities like proc_reg_mmap, call_mmap, drm_gem_cma_mmap, and cxl_fd_mmap. Thanks to Julia for helping me with coccinelle iteration to cover cases where the mmap routine is defined in a separate file from the operations instance that consumes it. // Usage: // spatch mmap.cocci --no-includes --include-headers --in-place ./ -j 40 --very-quiet virtual after_start @initialize:ocaml@ @@ let tbl = Hashtbl.create(100) let add_if_not_present fn = if not(Hashtbl.mem tbl fn) then Hashtbl.add tbl fn () @ a @ identifier fn; identifier ops; expression E1; @@ ( struct file_operations ops = { ..., .mmap = fn, ...}; | struct file_operations ops[E1] = { ..., { ..., .mmap = fn, ...}, ...}; | struct etnaviv_gem_ops ops = { ..., .mmap = fn, ...}; | struct dma_buf_ops ops = { ..., .mmap = fn, ...}; | struct drm_driver ops = { ..., .gem_prime_mmap = fn, ...}; | struct fb_ops ops = { ..., .fb_mmap = fn, ...}; | struct v4l2_file_operations ops = { ..., .mmap = fn, ...}; ) @script:ocaml@ fn << a.fn; @@ add_if_not_present fn @finalize:ocaml depends on !after_start@ tbls << merge.tbl; @@ List.iter (fun t -> Hashtbl.iter (fun f _ -> add_if_not_present f) t) tbls; Hashtbl.iter (fun f _ -> let it = new iteration() in it#add_virtual_rule After_start; it#add_virtual_identifier Fn f; it#register()) tbl @depends on after_start@ identifier virtual.fn; identifier x, y; type T; @@ int fn(T *x, struct vm_area_struct *y - ) + , unsigned long map_flags) { ... } @depends on after_start@ identifier virtual.fn; identifier x, y; type T; @@ int fn(T *x, struct vm_area_struct *y - ); + , unsigned long map_flags); @depends on after_start@ identifier virtual.fn; type T; @@ int fn(T *, struct vm_area_struct * - ); + , unsigned long); @depends on after_start@ identifier virtual.fn; expression E1, E2, E3; @@ E3 = fn(E1, E2 - ); + , map_flags); @depends on after_start@ identifier virtual.fn; expression E1, E2; @@ return fn(E1, E2 - ); + , map_flags); Cc: Takashi Iwai <tiwai@...e.com> Cc: Christoph Hellwig <hch@....de> Cc: David Airlie <airlied@...ux.ie> Cc: <dri-devel@...ts.freedesktop.org> Cc: Daniel Vetter <daniel.vetter@...el.com> Cc: Andrew Morton <akpm@...ux-foundation.org> Cc: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Mauro Carvalho Chehab <mchehab@...pensource.com> Cc: <linux-media@...r.kernel.org> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org> Suggested-by: Jan Kara <jack@...e.cz> Acked-by: Jan Kara <jack@...e.cz> Signed-off-by: Julia Lawall <julia.lawall@...6.fr> Signed-off-by: Dan Williams <dan.j.williams@...el.com> commit 4aac0d08f6d1ae4475bbfe761b943d105e11b82a Author: Dan Williams <dan.j.williams@...el.com> Date: Mon Aug 14 14:59:39 2017 -0700 mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags The mmap(2) syscall suffers from the ABI anti-pattern of not validating unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a mechanism to define new behavior that is known to fail on older kernels without the support. Define a new MAP_SHARED_VALIDATE flag pattern that is guaranteed to fail on all legacy mmap implementations. It is worth noting that the original proposal was for a standalone MAP_VALIDATE flag. However, when that could not be supported by all archs Linus observed: I see why you *think* you want a bitmap. You think you want a bitmap because you want to make MAP_VALIDATE be part of MAP_SYNC etc, so that people can do ret = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_SYNC, fd, 0); and "know" that MAP_SYNC actually takes. And I'm saying that whole wish is bogus. You're fundamentally depending on special semantics, just make it explicit. It's already not portable, so don't try to make it so. Rename that MAP_VALIDATE as MAP_SHARED_VALIDATE, make it have a value of 0x3, and make people do ret = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED_VALIDATE | MAP_SYNC, fd, 0); and then the kernel side is easier too (none of that random garbage playing games with looking at the "MAP_VALIDATE bit", but just another case statement in that map type thing. Boom. Done. Similar to ->fallocate() we also want the ability to validate the support for new flags on a per ->mmap() 'struct file_operations' instance basis. Towards that end arrange for flags to be generically validated against a mmap_supported_mask exported by 'struct file_operations'. By default all existing flags are implicitly supported, but new flags require MAP_SHARED_VALIDATE and per-instance-opt-in. Cc: Jan Kara <jack@...e.cz> Cc: Arnd Bergmann <arnd@...db.de> Cc: Andy Lutomirski <luto@...nel.org> Cc: Andrew Morton <akpm@...ux-foundation.org> Suggested-by: Christoph Hellwig <hch@....de> Suggested-by: Linus Torvalds <torvalds@...ux-foundation.org> Signed-off-by: Dan Williams <dan.j.williams@...el.com>
Powered by blists - more mailing lists