10 Aug, 2010

3 commits

  • Essentially, the minimal variant of ->evict_inode(). It's
    a trimmed-down clear_inode(), sans any fs callbacks. Once
    it returns we know that no async writeback will be happening;
    every ->evict_inode() instance should do that once and do that
    before doing anything ->write_inode() could interfere with
    (e.g. freeing the on-disk inode).

    Signed-off-by: Al Viro

    Al Viro
     
  • The first spoils - hugetlb can use default ->drop_inode() now.

    Signed-off-by: Al Viro

    Al Viro
     
  • Replace inode_setattr with opencoded variants of it in all callers. This
    moves the remaining call to vmtruncate into the filesystem methods where it
    can be replaced with the proper truncate sequence.

    In a few cases it was obvious that we would never end up calling vmtruncate
    so it was left out in the opencoded variant:

    spufs: explicitly checks for ATTR_SIZE earlier
    btrfs,hugetlbfs,logfs,dlmfs: explicitly clears ATTR_SIZE earlier
    ufs: contains an opencoded simple_seattr + truncate that sets the filesize just above

    In addition to that ncpfs called inode_setattr with handcrafted iattrs,
    which allowed to trim down the opencoded variant.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Al Viro

    Christoph Hellwig
     

28 May, 2010

1 commit

  • We don't name our generic fsync implementations very well currently.
    The no-op implementation for in-memory filesystems currently is called
    simple_sync_file which doesn't make too much sense to start with,
    the the generic one for simple filesystems is called simple_fsync
    which can lead to some confusion.

    This patch renames the generic file fsync method to generic_file_fsync
    to match the other generic_file_* routines it is supposed to be used
    with, and the no-op implementation to noop_fsync to make it obvious
    what to expect. In addition add some documentation for both methods.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Al Viro

    Christoph Hellwig
     

17 Dec, 2009

2 commits


24 Sep, 2009

3 commits

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
    truncate: use new helpers
    truncate: new helpers
    fs: fix overflow in sys_mount() for in-kernel calls
    fs: Make unload_nls() NULL pointer safe
    freeze_bdev: grab active reference to frozen superblocks
    freeze_bdev: kill bd_mount_sem
    exofs: remove BKL from super operations
    fs/romfs: correct error-handling code
    vfs: seq_file: add helpers for data filling
    vfs: remove redundant position check in do_sendfile
    vfs: change sb->s_maxbytes to a loff_t
    vfs: explicitly cast s_maxbytes in fiemap_check_ranges
    libfs: return error code on failed attr set
    seq_file: return a negative error code when seq_path_root() fails.
    vfs: optimize touch_time() too
    vfs: optimization for touch_atime()
    vfs: split generic_forget_inode() so that hugetlbfs does not have to copy it
    fs/inode.c: add dev-id and inode number for debugging in init_special_inode()
    libfs: make simple_read_from_buffer conventional

    Linus Torvalds
     
  • Commit 6bfde05bf5c ("hugetlbfs: allow the creation of files suitable for
    MAP_PRIVATE on the vfs internal mount") altered can_do_hugetlb_shm() to
    check if a file is being created for shared memory or mmap(). If this
    returns false, we then unconditionally call user_shm_lock() triggering a
    warning. This block should never be entered for MAP_HUGETLB. This
    patch partially reverts the problem and fixes the check.

    Signed-off-by: Eric B Munson
    Cc: David Rientjes
    Cc: Mel Gorman
    Cc: Adam Litke
    Cc: David Gibson
    Cc: Lee Schermerhorn
    Cc: Nick Piggin
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    From: Mel Gorman
     
  • Hugetlbfs needs to do special things instead of truncate_inode_pages().
    Currently, it copied generic_forget_inode() except for
    truncate_inode_pages() call which is asking for trouble (the code there
    isn't trivial). So create a separate function generic_detach_inode()
    which does all the list magic done in generic_forget_inode() and call
    it from hugetlbfs_forget_inode().

    Signed-off-by: Jan Kara
    Cc: Al Viro
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Al Viro

    Jan Kara
     

23 Sep, 2009

1 commit

  • Move various magic-number definitions into magic.h.

    Signed-off-by: Nick Black
    Acked-by: Pekka Enberg
    Cc: Al Viro
    Cc: "David S. Miller"
    Cc: Casey Schaufler
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nick Black
     

22 Sep, 2009

1 commit

  • This patchset adds a flag to mmap that allows the user to request that an
    anonymous mapping be backed with huge pages. This mapping will borrow
    functionality from the huge page shm code to create a file on the kernel
    internal mount and use it to approximate an anonymous mapping. The
    MAP_HUGETLB flag is a modifier to MAP_ANONYMOUS and will not work without
    both flags being preset.

    A new flag is necessary because there is no other way to hook into huge
    pages without creating a file on a hugetlbfs mount which wouldn't be
    MAP_ANONYMOUS.

    To userspace, this mapping will behave just like an anonymous mapping
    because the file is not accessible outside of the kernel.

    This patchset is meant to simplify the programming model. Presently there
    is a large chunk of boiler platecode, contained in libhugetlbfs, required
    to create private, hugepage backed mappings. This patch set would allow
    use of hugepages without linking to libhugetlbfs or having hugetblfs
    mounted.

    Unification of the VM code would provide these same benefits, but it has
    been resisted each time that it has been suggested for several reasons: it
    would break PAGE_SIZE assumptions across the kernel, it makes page-table
    abstractions really expensive, and it does not provide any benefit on
    architectures that do not support huge pages, incurring fast path
    penalties without providing any benefit on these architectures.

    This patch:

    There are two means of creating mappings backed by huge pages:

    1. mmap() a file created on hugetlbfs
    2. Use shm which creates a file on an internal mount which essentially
    maps it MAP_SHARED

    The internal mount is only used for shared mappings but there is very
    little that stops it being used for private mappings. This patch extends
    hugetlbfs_file_setup() to deal with the creation of files that will be
    mapped MAP_PRIVATE on the internal hugetlbfs mount. This extended API is
    used in a subsequent patch to implement the MAP_HUGETLB mmap() flag.

    Signed-off-by: Eric Munson
    Acked-by: David Rientjes
    Cc: Mel Gorman
    Cc: Adam Litke
    Cc: David Gibson
    Cc: Lee Schermerhorn
    Cc: Nick Piggin
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric B Munson
     

11 Sep, 2009

1 commit


25 Aug, 2009

1 commit

  • 2.6.30's commit 8a0bdec194c21c8fdef840989d0d7b742bb5d4bc removed
    user_shm_lock() calls in hugetlb_file_setup() but left the
    user_shm_unlock call in shm_destroy().

    In detail:
    Assume that can_do_hugetlb_shm() returns true and hence user_shm_lock()
    is not called in hugetlb_file_setup(). However, user_shm_unlock() is
    called in any case in shm_destroy() and in the following
    atomic_dec_and_lock(&up->__count) in free_uid() is executed and if
    up->__count gets zero, also cleanup_user_struct() is scheduled.

    Note that sched_destroy_user() is empty if CONFIG_USER_SCHED is not set.
    However, the ref counter up->__count gets unexpectedly non-positive and
    the corresponding structs are freed even though there are live
    references to them, resulting in a kernel oops after a lots of
    shmget(SHM_HUGETLB)/shmctl(IPC_RMID) cycles and CONFIG_USER_SCHED set.

    Hugh changed Stefan's suggested patch: can_do_hugetlb_shm() at the
    time of shm_destroy() may give a different answer from at the time
    of hugetlb_file_setup(). And fixed newseg()'s no_id error path,
    which has missed user_shm_unlock() ever since it came in 2.6.9.

    Reported-by: Stefan Huber
    Signed-off-by: Hugh Dickins
    Tested-by: Stefan Huber
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     

22 May, 2009

2 commits

  • Conflicts:
    fs/exec.c

    Removed IMA changes (the IMA checks are now performed via may_open()).

    Signed-off-by: James Morris

    James Morris
     
  • Based on discussion on lkml (Andrew Morton and Eric Paris),
    move ima_counts_get down a layer into shmem/hugetlb__file_setup().
    Resolves drm shmem_file_setup() usage case as well.

    HD comment:
    I still think you're doing this at the wrong level, but recognize
    that you probably won't be persuaded until a few more users of
    alloc_file() emerge, all wanting your ima_counts_get().

    Resolving GEM's shmem_file_setup() is an improvement, so I'll say

    Acked-by: Hugh Dickins
    Signed-off-by: Mimi Zohar
    Signed-off-by: James Morris

    Mimi Zohar
     

13 May, 2009

1 commit

  • The core VM assumes the page size used by the address_space in
    inode->i_mapping is PAGE_SIZE but hugetlbfs breaks this assumption by
    inserting pages into the page cache at offsets the core VM considers
    unexpected.

    This would not be a problem except that hugetlbfs also provide a
    ->readpage implementation. As it exists, the core VM can assume the
    base page size is being used, allocate pages on behalf of the
    filesystem, insert them into the page cache and call ->readpage to
    populate them. These pages are the wrong size and at the wrong offset
    for hugetlbfs causing confusion.

    This patch deletes the ->readpage implementation for hugetlbfs on the
    grounds the core VM should not be allocating and populating pages on
    behalf of hugetlbfs. There should be no existing users of the
    ->readpage implementation so it should not cause a regression.

    Signed-off-by: Mel Gorman
    Signed-off-by: Linus Torvalds

    Mel Gorman
     

22 Apr, 2009

1 commit

  • This fixes the following BUG:

    # mount -o size=MM -t hugetlbfs none /huge
    hugetlbfs: Bad value 'MM' for mount option 'size=MM'
    ------------[ cut here ]------------
    kernel BUG at fs/super.c:996!

    Due to

    BUG_ON(!mnt->mnt_sb);

    in vfs_kern_mount().

    Also, remove unused #include

    Cc: William Irwin
    Cc:
    Signed-off-by: Akinobu Mita
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

01 Apr, 2009

2 commits

  • Allow non root users with sufficient mlock rlimits to be able to allocate
    hugetlb backed shm for now. Deprecate this though. This is being
    deprecated because the mlock based rlimit checks for SHM_HUGETLB is not
    consistent with mmap based huge page allocations.

    Signed-off-by: Ravikiran Thirumalai
    Reviewed-by: Mel Gorman
    Cc: William Lee Irwin III
    Cc: Adam Litke
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ravikiran G Thirumalai
     
  • Fix hugetlb subsystem so that non root users belonging to
    hugetlb_shm_group can actually allocate hugetlb backed shm.

    Currently non root users cannot even map one large page using SHM_HUGETLB
    when they belong to the gid in /proc/sys/vm/hugetlb_shm_group. This is
    because allocation size is verified against RLIMIT_MEMLOCK resource limit
    even if the user belongs to hugetlb_shm_group.

    This patch
    1. Fixes hugetlb subsystem so that users with CAP_IPC_LOCK and users
    belonging to hugetlb_shm_group don't need to be restricted with
    RLIMIT_MEMLOCK resource limits
    2. This patch also disables mlock based rlimit checking (which will
    be reinstated and marked deprecated in a subsequent patch).

    Signed-off-by: Ravikiran Thirumalai
    Reviewed-by: Mel Gorman
    Cc: William Lee Irwin III
    Cc: Adam Litke
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ravikiran G Thirumalai
     

11 Feb, 2009

1 commit

  • When overcommit is disabled, the core VM accounts for pages used by anonymous
    shared, private mappings and special mappings. It keeps track of VMAs that
    should be accounted for with VM_ACCOUNT and VMAs that never had a reserve
    with VM_NORESERVE.

    Overcommit for hugetlbfs is much riskier than overcommit for base pages
    due to contiguity requirements. It avoids overcommiting on both shared and
    private mappings using reservation counters that are checked and updated
    during mmap(). This ensures (within limits) that hugepages exist in the
    future when faults occurs or it is too easy to applications to be SIGKILLed.

    As hugetlbfs makes its own reservations of a different unit to the base page
    size, VM_ACCOUNT should never be set. Even if the units were correct, we would
    double account for the usage in the core VM and hugetlbfs. VM_NORESERVE may
    be set because an application can request no reserves be made for hugetlbfs
    at the risk of getting killed later.

    With commit fc8744adc870a8d4366908221508bb113d8b72ee, VM_NORESERVE and
    VM_ACCOUNT are getting unconditionally set for hugetlbfs-backed mappings. This
    breaks the accounting for both the core VM and hugetlbfs, can trigger an
    OOM storm when hugepage pools are too small lockups and corrupted counters
    otherwise are used. This patch brings hugetlbfs more in line with how the
    core VM treats VM_NORESERVE but prevents VM_ACCOUNT being set.

    Signed-off-by: Mel Gorman
    Signed-off-by: Linus Torvalds

    Mel Gorman
     

07 Jan, 2009

1 commit

  • unsigned long ret cannot be negative, but ret can get -EFAULT.

    Signed-off-by: Roel Kluin
    Cc: Hugh Dickins
    Cc: Christoph Lameter
    Cc: Adam Litke
    Cc: David Gibson
    Cc: Ken Chen
    Cc: Nick Piggin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roel Kluin
     

06 Jan, 2009

1 commit


14 Nov, 2008

3 commits

  • Wrap current->cred and a few other accessors to hide their actual
    implementation.

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Separate the task security context from task_struct. At this point, the
    security data is temporarily embedded in the task_struct with two pointers
    pointing to it.

    Note that the Alpha arch is altered as it refers to (E)UID and (E)GID in
    entry.S via asm-offsets.

    With comment fixes Signed-off-by: Marc Dionne

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Wrap access to task credentials so that they can be separated more easily from
    the task_struct during the introduction of COW creds.

    Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().

    Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more
    sense to use RCU directly rather than a convenient wrapper; these will be
    addressed by later patches.

    Signed-off-by: David Howells
    Reviewed-by: James Morris
    Acked-by: Serge Hallyn
    Cc: William Irwin
    Signed-off-by: James Morris

    David Howells
     

14 Oct, 2008

1 commit

  • This is a much better version of a previous patch to make the parser
    tables constant. Rather than changing the typedef, we put the "const" in
    all the various places where its required, allowing the __initconst
    exception for nfsroot which was the cause of the previous trouble.

    This was posted for review some time ago and I believe its been in -mm
    since then.

    Signed-off-by: Steven Whitehouse
    Cc: Alexander Viro
    Signed-off-by: Linus Torvalds

    Steven Whitehouse
     

27 Jul, 2008

1 commit

  • Kmem cache passed to constructor is only needed for constructors that are
    themselves multiplexeres. Nobody uses this "feature", nor does anybody uses
    passed kmem cache in non-trivial way, so pass only pointer to object.

    Non-trivial places are:
    arch/powerpc/mm/init_64.c
    arch/powerpc/mm/hugetlbpage.c

    This is flag day, yes.

    Signed-off-by: Alexey Dobriyan
    Acked-by: Pekka Enberg
    Acked-by: Christoph Lameter
    Cc: Jon Tollefson
    Cc: Nick Piggin
    Cc: Matt Mackall
    [akpm@linux-foundation.org: fix arch/powerpc/mm/hugetlbpage.c]
    [akpm@linux-foundation.org: fix mm/slab.c]
    [akpm@linux-foundation.org: fix ubifs]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

25 Jul, 2008

4 commits

  • Add the ability to configure the hugetlb hstate used on a per mount basis.

    - Add a new pagesize= option to the hugetlbfs mount that allows setting
    the page size
    - This option causes the mount code to find the hstate corresponding to the
    specified size, and sets up a pointer to the hstate in the mount's
    superblock.
    - Change the hstate accessors to use this information rather than the
    global_hstate they were using (requires a slight change in mm/memory.c
    so we don't NULL deref in the error-unmap path -- see comments).

    [np: take hstate out of hugetlbfs inode and vma->vm_private_data]

    Acked-by: Adam Litke
    Acked-by: Nishanth Aravamudan
    Signed-off-by: Andi Kleen
    Signed-off-by: Nick Piggin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • The goal of this patchset is to support multiple hugetlb page sizes. This
    is achieved by introducing a new struct hstate structure, which
    encapsulates the important hugetlb state and constants (eg. huge page
    size, number of huge pages currently allocated, etc).

    The hstate structure is then passed around the code which requires these
    fields, they will do the right thing regardless of the exact hstate they
    are operating on.

    This patch adds the hstate structure, with a single global instance of it
    (default_hstate), and does the basic work of converting hugetlb to use the
    hstate.

    Future patches will add more hstate structures to allow for different
    hugetlbfs mounts to have different page sizes.

    [akpm@linux-foundation.org: coding-style fixes]
    Acked-by: Adam Litke
    Acked-by: Nishanth Aravamudan
    Signed-off-by: Andi Kleen
    Signed-off-by: Nick Piggin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • …n hugetlbfs will succeed

    After patch 2 in this series, a process that successfully calls mmap() for
    a MAP_PRIVATE mapping will be guaranteed to successfully fault until a
    process calls fork(). At that point, the next write fault from the parent
    could fail due to COW if the child still has a reference.

    We only reserve pages for the parent but a copy must be made to avoid
    leaking data from the parent to the child after fork(). Reserves could be
    taken for both parent and child at fork time to guarantee faults but if
    the mapping is large it is highly likely we will not have sufficient pages
    for the reservation, and it is common to fork only to exec() immediatly
    after. A failure here would be very undesirable.

    Note that the current behaviour of mainline with MAP_PRIVATE pages is
    pretty bad. The following situation is allowed to occur today.

    1. Process calls mmap(MAP_PRIVATE)
    2. Process calls mlock() to fault all pages and makes sure it succeeds
    3. Process forks()
    4. Process writes to MAP_PRIVATE mapping while child still exists
    5. If the COW fails at this point, the process gets SIGKILLed even though it
    had taken care to ensure the pages existed

    This patch improves the situation by guaranteeing the reliability of the
    process that successfully calls mmap(). When the parent performs COW, it
    will try to satisfy the allocation without using reserves. If that fails
    the parent will steal the page leaving any children without a page.
    Faults from the child after that point will result in failure. If the
    child COW happens first, an attempt will be made to allocate the page
    without reserves and the child will get SIGKILLed on failure.

    To summarise the new behaviour:

    1. If the original mapper performs COW on a private mapping with multiple
    references, it will attempt to allocate a hugepage from the pool or
    the buddy allocator without using the existing reserves. On fail, VMAs
    mapping the same area are traversed and the page being COW'd is unmapped
    where found. It will then steal the original page as the last mapper in
    the normal way.

    2. The VMAs the pages were unmapped from are flagged to note that pages
    with data no longer exist. Future no-page faults on those VMAs will
    terminate the process as otherwise it would appear that data was corrupted.
    A warning is printed to the console that this situation occured.

    2. If the child performs COW first, it will attempt to satisfy the COW
    from the pool if there are enough pages or via the buddy allocator if
    overcommit is allowed and the buddy allocator can satisfy the request. If
    it fails, the child will be killed.

    If the pool is large enough, existing applications will not notice that
    the reserves were a factor. Existing applications depending on the
    no-reserves been set are unlikely to exist as for much of the history of
    hugetlbfs, pages were prefaulted at mmap(), allocating the pages at that
    point or failing the mmap().

    [npiggin@suse.de: fix CONFIG_HUGETLB=n build]
    Signed-off-by: Mel Gorman <mel@csn.ul.ie>
    Acked-by: Adam Litke <agl@us.ibm.com>
    Cc: Andy Whitcroft <apw@shadowen.org>
    Cc: William Lee Irwin III <wli@holomorphy.com>
    Cc: Hugh Dickins <hugh@veritas.com>
    Cc: Nick Piggin <npiggin@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

    Mel Gorman
     
  • This patch reserves huge pages at mmap() time for MAP_PRIVATE mappings in
    a similar manner to the reservations taken for MAP_SHARED mappings. The
    reserve count is accounted both globally and on a per-VMA basis for
    private mappings. This guarantees that a process that successfully calls
    mmap() will successfully fault all pages in the future unless fork() is
    called.

    The characteristics of private mappings of hugetlbfs files behaviour after
    this patch are;

    1. The process calling mmap() is guaranteed to succeed all future faults until
    it forks().
    2. On fork(), the parent may die due to SIGKILL on writes to the private
    mapping if enough pages are not available for the COW. For reasonably
    reliable behaviour in the face of a small huge page pool, children of
    hugepage-aware processes should not reference the mappings; such as
    might occur when fork()ing to exec().
    3. On fork(), the child VMAs inherit no reserves. Reads on pages already
    faulted by the parent will succeed. Successful writes will depend on enough
    huge pages being free in the pool.
    4. Quotas of the hugetlbfs mount are checked at reserve time for the mapper
    and at fault time otherwise.

    Before this patch, all reads or writes in the child potentially needs page
    allocations that can later lead to the death of the parent. This applies
    to reads and writes of uninstantiated pages as well as COW. After the
    patch it is only a write to an instantiated page that causes problems.

    Signed-off-by: Mel Gorman
    Acked-by: Adam Litke
    Cc: Andy Whitcroft
    Cc: William Lee Irwin III
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     

30 Apr, 2008

1 commit

  • Add a new BDI capability flag: BDI_CAP_NO_ACCT_WB. If this flag is
    set, then don't update the per-bdi writeback stats from
    test_set_page_writeback() and test_clear_page_writeback().

    Misc cleanups:

    - convert bdi_cap_writeback_dirty() and friends to static inline functions
    - create a flag that includes all three dirty/writeback related flags,
    since almst all users will want to have them toghether

    Signed-off-by: Miklos Szeredi
    Cc: Peter Zijlstra
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Miklos Szeredi
     

28 Apr, 2008

2 commits

  • This patch replaces the mempolicy mode, mode_flags, and nodemask in the
    shmem_sb_info struct with a struct mempolicy pointer, initialized to NULL.
    This removes dependency on the details of mempolicy from shmem.c and hugetlbfs
    inode.c and simplifies the interfaces.

    mpol_parse_str() in mempolicy.c is changed to return, via a pointer to a
    pointer arg, a struct mempolicy pointer on success. For MPOL_DEFAULT, the
    returned pointer is NULL. Further, mpol_parse_str() now takes a 'no_context'
    argument that causes the input nodemask to be stored in the w.user_nodemask of
    the created mempolicy for use when the mempolicy is installed in a tmpfs inode
    shared policy tree. At that time, any cpuset contextualization is applied to
    the original input nodemask. This preserves the previous behavior where the
    input nodemask was stored in the superblock. We can think of the returned
    mempolicy as "context free".

    Because mpol_parse_str() is now calling mpol_new(), we can remove from
    mpol_to_str() the semantic checks that mpol_new() already performs.

    Add 'no_context' parameter to mpol_to_str() to specify that it should format
    the nodemask in w.user_nodemask for 'bind' and 'interleave' policies.

    Change mpol_shared_policy_init() to take a pointer to a "context free" struct
    mempolicy and to create a new, "contextualized" mempolicy using the mode,
    mode_flags and user_nodemask from the input mempolicy.

    Note: we know that the mempolicy passed to mpol_to_str() or
    mpol_shared_policy_init() from a tmpfs superblock is "context free". This
    is currently the only instance thereof. However, if we found more uses for
    this concept, and introduced any ambiguity as to whether a mempolicy was
    context free or not, we could add another internal mode flag to identify
    context free mempolicies. Then, we could remove the 'no_context' argument
    from mpol_to_str().

    Added shmem_get_sbmpol() to return a reference counted superblock mempolicy,
    if one exists, to pass to mpol_shared_policy_init(). We must add the
    reference under the sb stat_lock to prevent races with replacement of the mpol
    by remount. This reference is removed in mpol_shared_policy_init().

    [akpm@linux-foundation.org: build fix]
    [akpm@linux-foundation.org: another build fix]
    [akpm@linux-foundation.org: yet another build fix]
    Signed-off-by: Lee Schermerhorn
    Cc: Christoph Lameter
    Cc: David Rientjes
    Cc: Mel Gorman
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Lee Schermerhorn
     
  • With the evolution of mempolicies, it is necessary to support mempolicy mode
    flags that specify how the policy shall behave in certain circumstances. The
    most immediate need for mode flag support is to suppress remapping the
    nodemask of a policy at the time of rebind.

    Both the mempolicy mode and flags are passed by the user in the 'int policy'
    formal of either the set_mempolicy() or mbind() syscall. A new constant,
    MPOL_MODE_FLAGS, represents the union of legal optional flags that may be
    passed as part of this int. Mempolicies that include illegal flags as part of
    their policy are rejected as invalid.

    An additional member to struct mempolicy is added to support the mode flags:

    struct mempolicy {
    ...
    unsigned short policy;
    unsigned short flags;
    }

    The splitting of the 'int' actual passed by the user is done in
    sys_set_mempolicy() and sys_mbind() for their respective syscalls. This is
    done by intersecting the actual with MPOL_MODE_FLAGS, rejecting the syscall of
    there are additional flags, and storing it in the new 'flags' member of struct
    mempolicy. The intersection of the actual with ~MPOL_MODE_FLAGS is stored in
    the 'policy' member of the struct and all current users of pol->policy remain
    unchanged.

    The union of the policy mode and optional mode flags is passed back to the
    user in get_mempolicy().

    This combination of mode and flags within the same actual does not break
    userspace code that relies on get_mempolicy(&policy, ...) and either

    switch (policy) {
    case MPOL_BIND:
    ...
    case MPOL_INTERLEAVE:
    ...
    };

    statements or

    if (policy == MPOL_INTERLEAVE) {
    ...
    }

    statements. Such applications would need to use optional mode flags when
    calling set_mempolicy() or mbind() for these previously implemented statements
    to stop working. If an application does start using optional mode flags, it
    will need to mask the optional flags off the policy in switch and conditional
    statements that only test mode.

    An additional member is also added to struct shmem_sb_info to store the
    optional mode flags.

    [hugh@veritas.com: shmem mpol: fix build warning]
    Cc: Paul Jackson
    Cc: Christoph Lameter
    Cc: Lee Schermerhorn
    Cc: Andi Kleen
    Signed-off-by: David Rientjes
    Signed-off-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Rientjes
     

19 Mar, 2008

1 commit


09 Feb, 2008

1 commit

  • Add a .show_options super operation to hugetlbfs.

    Use generic_show_options() and save the complete option string in
    hugetlbfs_fill_super().

    Signed-off-by: Miklos Szeredi
    Cc: Adam Litke
    Cc: Badari Pulavarty
    Cc: Ken Chen
    Cc: William Lee Irwin III
    Cc: David Gibson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Miklos Szeredi
     

06 Feb, 2008

1 commit

  • Allow sticky directory mount option for hugetlbfs. This allows admin
    to create a shared hugetlbfs mount point for multiple users, while
    prevent accidental file deletion that users may step on each other.
    It is similiar to default tmpfs mount option, or typical option used
    on /tmp.

    Signed-off-by: Ken Chen
    Cc: Badari Pulavarty
    Cc: Adam Litke
    Cc: David Gibson
    Cc: William Lee Irwin III
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ken Chen
     

15 Nov, 2007

2 commits

  • Add a second parameter 'delta' to hugetlb_get_quota and hugetlb_put_quota to
    allow bulk updating of the sbinfo->free_blocks counter. This will be used by
    the next patch in the series.

    Signed-off-by: Adam Litke
    Cc: Ken Chen
    Cc: Andy Whitcroft
    Cc: Dave Hansen
    Cc: David Gibson
    Cc: William Lee Irwin III
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adam Litke
     
  • The hugetlbfs quota management system was never taught to handle MAP_PRIVATE
    mappings when that support was added. Currently, quota is debited at page
    instantiation and credited at file truncation. This approach works correctly
    for shared pages but is incomplete for private pages. In addition to
    hugetlb_no_page(), private pages can be instantiated by hugetlb_cow(); but
    this function does not respect quotas.

    Private huge pages are treated very much like normal, anonymous pages. They
    are not "backed" by the hugetlbfs file and are not stored in the mapping's
    radix tree. This means that private pages are invisible to
    truncate_hugepages() so that function will not credit the quota.

    This patch (based on a prototype provided by Ken Chen) moves quota crediting
    for all pages into free_huge_page(). page->private is used to store a pointer
    to the mapping to which this page belongs. This is used to credit quota on
    the appropriate hugetlbfs instance.

    Signed-off-by: Adam Litke
    Cc: Ken Chen
    Cc: Ken Chen
    Cc: Andy Whitcroft
    Cc: Dave Hansen
    Cc: David Gibson
    Cc: William Lee Irwin III
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adam Litke
     

17 Oct, 2007

1 commit

  • Why do we need r/o bind mounts?

    This feature allows a read-only view into a read-write filesystem. In the
    process of doing that, it also provides infrastructure for keeping track of
    the number of writers to any given mount.

    This has a number of uses. It allows chroots to have parts of filesystems
    writable. It will be useful for containers in the future because users may
    have root inside a container, but should not be allowed to write to
    somefilesystems. This also replaces patches that vserver has had out of the
    tree for several years.

    It allows security enhancement by making sure that parts of your filesystem
    read-only (such as when you don't trust your FTP server), when you don't want
    to have entire new filesystems mounted, or when you want atime selectively
    updated. I've been using the following script to test that the feature is
    working as desired. It takes a directory and makes a regular bind and a r/o
    bind mount of it. It then performs some normal filesystem operations on the
    three directories, including ones that are expected to fail, like creating a
    file on the r/o mount.

    This patch:

    Some filesystems forego the vfs and may_open() and create their own 'struct
    file's.

    This patch creates a couple of helper functions which can be used by these
    filesystems, and will provide a unified place which the r/o bind mount code
    may patch.

    Also, rename an existing, static-scope init_file() to a less generic name.

    Signed-off-by: Dave Hansen
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen