linux/ipc, branch v2.6.32

const: mark struct vm_struct_operations

2009-09-27T18:39:25Z

* mark struct vm_area_struct::vm_ops as const * mark vm_ops in AGP code But leave TTM code alone, something is fishy there with global vm_ops being used. Signed-off-by: Alexey Dobriyan Signed-off-by: Linus Torvalds

sysctl: remove "struct file *" argument of ->proc_handler

2009-09-24T14:21:04Z

It's unused. It isn't needed -- read or write flag is already passed and sysctl shouldn't care about the rest. It _was_ used in two places at arch/frv for some reason. Signed-off-by: Alexey Dobriyan Cc: David Howells Cc: "Eric W. Biederman" Cc: Al Viro Cc: Ralf Baechle Cc: Martin Schwidefsky Cc: Ingo Molnar Cc: "David S. Miller" Cc: James Morris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

seq_file: constify seq_operations

2009-09-23T14:39:29Z

Make all seq_operations structs const, to help mitigate against revectoring user-triggerable function pointers. This is derived from the grsecurity patch, although generated from scratch because it's simpler than extracting the changes from there. Signed-off-by: James Morris Acked-by: Serge Hallyn Acked-by: Casey Schaufler Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

hugetlbfs: allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount

2009-09-22T14:17:41Z

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

const: mark remaining super_operations const

2009-09-22T14:17:24Z

Signed-off-by: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fix undefined reference to user_shm_unlock

2009-09-15T00:45:31Z

My 353d5c30c666580347515da609dd74a2b8e9b828 "mm: fix hugetlb bug due to user_shm_unlock call" broke the CONFIG_SYSVIPC !CONFIG_MMU build of both 2.6.31 and 2.6.30.6: "undefined reference to `user_shm_unlock'". gcc didn't understand my comment! so couldn't figure out to optimize away user_shm_unlock() from the error path in the hugetlb-less case, as it does elsewhere. Help it to do so, in a language it understands. Reported-by: Mike Frysinger Signed-off-by: Hugh Dickins Cc: stable@kernel.org Signed-off-by: Linus Torvalds

mm: fix hugetlb bug due to user_shm_unlock call

2009-08-24T19:53:01Z

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

integrity: ima mq_open imbalance msg fix

2009-06-28T22:56:46Z

This patch fixes an imbalance message as reported by Sanchin Sant. As we don't need to measure the message queue, just increment the counters. Reported-by: Sanchin Sant Signed-off-by: Mimi Zohar Acked-by: Serge Hallyn Signed-off-by: James Morris

ipc: unbreak 32-bit shmctl/semctl/msgctl

2009-06-21T19:48:43Z

31a985f "ipc: use __ARCH_WANT_IPC_PARSE_VERSION in ipc/util.h" would choose the implementation of ipc_parse_version() based on a symbol defined in . But it failed to also include this header and thus broke IPC_64-passing 32-bit userspace because the flag wasn't masked out properly anymore and the command not understood. Include to give the architecture a chance to ask for the no-no-op ipc_parse_version(). Signed-off-by: Johannes Weiner Acked-by: Arnd Bergmann Signed-off-by: Linus Torvalds

ipcns: move free_ipcs() proto

2009-06-18T20:03:56Z

Function is really private to ipc/ and avoid struct kern_ipc_perm forward declaration. Signed-off-by: Alexey Dobriyan Reviewed-by: WANG Cong Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds