]> err.no Git - linux-2.6/commit
[PATCH] hugetlb: fix race in set_max_huge_pages for multiple updaters of nr_huge_pages
authorEric Paris <eparis@redhat.com>
Tue, 22 Nov 2005 05:32:28 +0000 (21:32 -0800)
committerLinus Torvalds <torvalds@g5.osdl.org>
Tue, 22 Nov 2005 17:13:43 +0000 (09:13 -0800)
commit0bd0f9fb190a0fc0fb25b764c8b04869711f7657
tree0bd7b58c037b5905cf834f27625bd4e0cbb2f3f2
parent5ef897c71a8985b62b7ec320a37376daaad364d0
[PATCH] hugetlb: fix race in set_max_huge_pages for multiple updaters of nr_huge_pages

If there are multiple updaters to /proc/sys/vm/nr_hugepages simultaneously
it is possible for the nr_huge_pages variable to become incorrect.  There
is no locking in the set_max_huge_pages function around
alloc_fresh_huge_page which is able to update nr_huge_pages.  Two callers
to alloc_fresh_huge_page could race against each other as could a call to
alloc_fresh_huge_page and a call to update_and_free_page.  This patch just
expands the area covered by the hugetlb_lock to cover the call into
alloc_fresh_huge_page.  I'm not sure how we could say that a sysctl section
is performance critical where more specific locking would be needed.

My reproducer was to run a couple copies of the following script
simultaneously

while [ true ]; do
echo 1000 > /proc/sys/vm/nr_hugepages
echo 500 > /proc/sys/vm/nr_hugepages
echo 750 > /proc/sys/vm/nr_hugepages
echo 100 > /proc/sys/vm/nr_hugepages
echo 0 > /proc/sys/vm/nr_hugepages
done

and then watch /proc/meminfo and eventually you will see things like

HugePages_Total:     100
HugePages_Free:      109

After applying the patch all seemed well.

Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: William Irwin <wli@holomorphy.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
mm/hugetlb.c