06 Oct, 2018

1 commit

  • ARM64 architecture also supports 32MB and 512MB HugeTLB page sizes. This
    just adds mmap() system call argument encoding for them.

    Link: http://lkml.kernel.org/r/1537841300-6979-1-git-send-email-anshuman.khandual@arm.com
    Signed-off-by: Anshuman Khandual
    Acked-by: Punit Agrawal
    Acked-by: Mike Kravetz
    Cc: Michal Hocko
    Cc: Will Deacon
    Cc: Catalin Marinas
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Anshuman Khandual
     

02 Nov, 2017

1 commit

  • Many user space API headers are missing licensing information, which
    makes it hard for compliance tools to determine the correct license.

    By default are files without license information under the default
    license of the kernel, which is GPLV2. Marking them GPLV2 would exclude
    them from being included in non GPLV2 code, which is obviously not
    intended. The user space API headers fall under the syscall exception
    which is in the kernels COPYING file:

    NOTE! This copyright does *not* cover user programs that use kernel
    services by normal system calls - this is merely considered normal use
    of the kernel, and does *not* fall under the heading of "derived work".

    otherwise syscall usage would not be possible.

    Update the files which contain no license information with an SPDX
    license identifier. The chosen identifier is 'GPL-2.0 WITH
    Linux-syscall-note' which is the officially assigned identifier for the
    Linux syscall exception. SPDX license identifiers are a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne. See the previous patch in this series for the
    methodology of how this patch was researched.

    Reviewed-by: Kate Stewart
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

07 Sep, 2017

1 commit

  • This patch came out of discussions in this e-mail thread:
    http://lkml.kernel.org/r/1499357846-7481-1-git-send-email-mike.kravetz%40oracle.com

    The Oracle JVM team is developing a new garbage collection model. This
    new model requires multiple mappings of the same anonymous memory. One
    straight forward way to accomplish this is with memfd_create. They can
    use the returned fd to create multiple mappings of the same memory.

    The JVM today has an option to use (static hugetlb) huge pages. If this
    option is specified, they would like to use the same garbage collection
    model requiring multiple mappings to the same memory. Using hugetlbfs,
    it is possible to explicitly mount a filesystem and specify file paths
    in order to get an fd that can be used for multiple mappings. However,
    this introduces additional system admin work and coordination.

    Ideally they would like to get a hugetlbfs fd without requiring explicit
    mounting of a filesystem. Today, mmap and shmget can make use of
    hugetlbfs without explicitly mounting a filesystem. The patch adds this
    functionality to memfd_create.

    Add a new flag MFD_HUGETLB to memfd_create() that will specify the file
    to be created resides in the hugetlbfs filesystem. This is the generic
    hugetlbfs filesystem not associated with any specific mount point. As
    with other system calls that request hugetlbfs backed pages, there is
    the ability to encode huge page size in the flag arguments.

    hugetlbfs does not support sealing operations, therefore specifying
    MFD_ALLOW_SEALING with MFD_HUGETLB will result in EINVAL.

    Of course, the memfd_man page would need updating if this type of
    functionality moves forward.

    Link: http://lkml.kernel.org/r/1502149672-7759-2-git-send-email-mike.kravetz@oracle.com
    Signed-off-by: Mike Kravetz
    Acked-by: Michal Hocko
    Cc: Hugh Dickins
    Cc: Andrea Arcangeli
    Cc: "Kirill A . Shutemov"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Kravetz
     

09 Aug, 2014

1 commit

  • memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
    that you can pass to mmap(). It can support sealing and avoids any
    connection to user-visible mount-points. Thus, it's not subject to quotas
    on mounted file-systems, but can be used like malloc()'ed memory, but with
    a file-descriptor to it.

    memfd_create() returns the raw shmem file, so calls like ftruncate() can
    be used to modify the underlying inode. Also calls like fstat() will
    return proper information and mark the file as regular file. If you want
    sealing, you can specify MFD_ALLOW_SEALING. Otherwise, sealing is not
    supported (like on all other regular files).

    Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not
    subject to a filesystem size limit. It is still properly accounted to
    memcg limits, though, and to the same overcommit or no-overcommit
    accounting as all user memory.

    Signed-off-by: David Herrmann
    Acked-by: Hugh Dickins
    Cc: Michael Kerrisk
    Cc: Ryan Lortie
    Cc: Lennart Poettering
    Cc: Daniel Mack
    Cc: Andy Lutomirski
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Herrmann