• Hugh Dickins's avatar
    mm: fix hugetlb bug due to user_shm_unlock call · 353d5c30
    Hugh Dickins authored
    2.6.30's commit 8a0bdec1
    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: default avatarStefan Huber <shuber2@gmail.com>
    Signed-off-by: default avatarHugh Dickins <hugh.dickins@tiscali.co.uk>
    Tested-by: default avatarStefan Huber <shuber2@gmail.com>
    Cc: stable@kernel.org
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
hugetlb.h 8.33 KB