linux-toradex.git/ipc, branch tegra-10.7.1

ipc ns: fix memory leak (idr)

2010-01-28T23:02:25+00:00

commit 7d6feeb287c61aafa88f06345387b1188edf4b86 upstream.

We have apparently had a memory leak since
7ca7e564e049d8b350ec9d958ff25eaa24226352 "ipc: store ipcs into IDRs" in
2007.  The idr of which 3 exist for each ipc namespace is never freed.

This patch simply frees them when the ipcns is freed.  I don't believe any
idr_remove() are done from rcu (and could therefore be delayed until after
this idr_destroy()), so the patch should be safe.  Some quick testing
showed no harm, and the memory leak fixed.

Caught by kmemleak.

Signed-off-by: Serge E. Hallyn 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Acked-by: Nick Piggin 
Signed-off-by: Greg Kroah-Hartman

untangle the do_mremap() mess

2010-01-18T18:19:11+00:00

This backports the following upstream commits all as one patch:
	54f5de709984bae0d31d823ff03de755f9dcac54
	ecc1a8993751de4e82eb18640d631dae1f626bd6
	1a0ef85f84feb13f07b604fcf5b90ef7c2b5c82f
	f106af4e90eadd76cfc0b5325f659619e08fb762
	097eed103862f9c6a97f2e415e21d1134017b135
	935874141df839c706cd6cdc438e85eb69d1525e
	0ec62d290912bb4b989be7563851bc364ec73b56
	c4caa778157dbbf04116f0ac2111e389b5cd7a29
	2ea1d13f64efdf49319e86c87d9ba38c30902782
	570dcf2c15463842e384eb597a87c1e39bead99b
	564b3bffc619dcbdd160de597b0547a7017ea010
	0067bd8a55862ac9dd212bd1c4f6f5bff1ca1301
	f8b7256096a20436f6d0926747e3ac3d64c81d24
	8c7b49b3ecd48923eb64ff57e07a1cdb74782970
	9206de95b1ea68357996ec02be5db0638a0de2c1
	2c6a10161d0b5fc047b5bd81b03693b9af99fab5
	05d72faa6d13c9d857478a5d35c85db9adada685
	bb52d6694002b9d632bb355f64daa045c6293a4e
	e77414e0aad6a1b063ba5e5750c582c75327ea6a
	aa65607373a4daf2010e8c3867b6317619f3c1a3

Backport done by Greg Kroah-Hartman.  Only minor tweaks were needed.

Cc: David S. Miller 
Cc: Hugh Dickins 
Cc: Paul Mundt 
Cc: Russell King 
Cc: Linus Torvalds 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

const: mark struct vm_struct_operations

2009-09-27T18:39:25+00:00

* 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:04+00:00

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:29+00:00

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:41+00:00

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:24+00:00

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:31+00:00

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:01+00:00

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:46+00:00

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