Hi On Tue, Oct 31, 2017 at 7:40 PM, Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> wrote: > Implements memfd sealing, similar to shmem: > - WRITE: deny fallocate(PUNCH_HOLE). mmap() write is denied in > memfd_add_seals(). write() doesn't exist for hugetlbfs. > - SHRINK: added similar check as shmem_setattr() > - GROW: added similar check as shmem_setattr() & shmem_fallocate() > > Except write() operation that doesn't exist with hugetlbfs, that > should make sealing as close as it can be to shmem support. SEAL, SHRINK, and GROW look fine to me. Regarding WRITE you need to make sure there are no page references left around. For instance, on shmem any process might trigger the kernel to GUP mapped shmem pages for asynchronous IO, then unmap the file and request F_SEAL_WRITE. In this case the seal must be rejected *iff* the pages are still pinned. shmem does this by requiring the page-refcounts to be 0. Preferably there would be some better infrastructure that tells us whether someone operates on those pages, but this does not exist right now. See shmem_wait_for_pins() for details. I have little knowledge on how hugetlbs integrate with the page-cache and radix-tree, hence I'd prefer if someone can explicitly ACK that shmem_wait_for_pins() is suitable for hugetlbfs. Otherwise, this series looks good to me (minus the #ifdef mess..). Thanks David -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href
