On Fri, Aug 11, 2017 at 3:26 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > On Fri, Aug 11, 2017 at 3:44 AM, Christoph Hellwig <hch@xxxxxx> wrote: >> Please explain how this interface allows for any sort of safe userspace >> DMA. > > So this is where I continue to see S_IOMAP_IMMUTABLE being able to > support applications that MAP_SYNC does not. Dave mentioned userspace > pNFS4 servers, but there's also Samba and other protocols that want to > negotiate a direct path to pmem outside the kernel. Xen support has > thus far not been able to follow in the footsteps of KVM enabling due > to a dependence on static M2P tables that assume a static > guest-physical to host-physical relationship [1]. Immutable files > would allow Xen to follow the same "mmap a file" semantic as KVM. One thing that makes me quite nervous about S_IOMAP_IMMUTABLE is the degree to which things go badly if one program relies on it while another program clears the flag: you risk corrupting unrelated filesystem metadata. I think a userspace interface to pin the extent mapping of a file really wants a way to reliably keep it pinned (or to reliably zap the userspace application if it gets unpinned). -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
