Hugh Dickins 353d5c30c6 mm: fix hugetlb bug due to user_shm_unlock call
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 <shuber2@gmail.com>
Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Tested-by: Stefan Huber <shuber2@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-24 12:53:01 -07:00
..
2009-06-17 19:41:52 +02:00
2009-06-18 08:46:47 +10:00
2009-06-30 18:56:00 -07:00
2009-07-12 12:22:34 -07:00
2009-06-17 00:36:36 -04:00
2009-06-30 18:55:58 -07:00
2009-07-29 19:10:35 -07:00
2009-06-22 10:12:35 +01:00
2009-07-12 12:22:34 -07:00
2009-07-12 13:02:10 -07:00
2009-06-22 10:12:30 +01:00
2009-06-22 10:12:35 +01:00
2009-06-17 09:33:49 -07:00
2009-07-08 09:18:05 -07:00
2009-06-24 08:17:04 -04:00
2009-06-30 18:56:00 -07:00
2009-08-24 14:58:23 +10:00
2009-06-18 18:40:18 -04:00
2009-06-30 20:12:24 +02:00
2009-06-18 13:04:05 -07:00
2009-07-12 12:22:34 -07:00
2009-06-29 08:59:10 +10:00
2009-06-18 13:03:57 -07:00
2009-07-31 08:55:48 +02:00
2009-06-18 13:03:56 -07:00
2009-06-22 10:12:35 +01:00
2009-06-23 20:21:39 +01:00
2009-07-30 16:03:45 +09:30
2009-07-28 21:07:09 -04:00
2009-06-16 19:47:57 -07:00
2009-06-16 19:47:48 -07:00
2009-07-08 09:31:56 -07:00
2009-06-18 13:03:57 -07:00
2009-06-17 18:02:11 -07:00
2009-06-17 18:02:11 -07:00
2009-06-17 12:24:34 -07:00
2009-08-12 08:21:39 -07:00
2009-06-17 12:24:34 -07:00
2009-06-17 18:02:11 -07:00
2009-06-29 12:14:51 -07:00
2009-06-30 18:55:59 -07:00
2009-06-18 13:04:04 -07:00
2009-07-29 19:10:36 -07:00
2009-07-12 12:22:34 -07:00
2009-06-24 08:17:06 -04:00
2009-08-18 16:31:13 -07:00
2009-06-24 08:17:06 -04:00
2009-06-16 19:47:48 -07:00
2009-06-23 12:50:05 -07:00
2009-07-06 13:57:03 -07:00
2009-07-12 15:16:39 -07:00