summaryrefslogtreecommitdiffstats
path: root/mm/msync.c
diff options
context:
space:
mode:
authorJoonsoo Kim <js1304@gmail.com>2013-04-29 15:07:32 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2013-04-29 15:54:34 -0700
commite81ce85f960c2e26efb5d0802d56c34533edb1bd (patch)
tree57e1d4ac1704a6311383403f8d11d51bbbd78961 /mm/msync.c
parentc69480adeea15883d9459a8adc3da3f6e8cb7a8c (diff)
downloadlinux-e81ce85f960c2e26efb5d0802d56c34533edb1bd.tar.gz
linux-e81ce85f960c2e26efb5d0802d56c34533edb1bd.tar.bz2
linux-e81ce85f960c2e26efb5d0802d56c34533edb1bd.zip
mm, vmalloc: iterate vmap_area_list, instead of vmlist in vread/vwrite()
Now, when we hold a vmap_area_lock, va->vm can't be discarded. So we can safely access to va->vm when iterating a vmap_area_list with holding a vmap_area_lock. With this property, change iterating vmlist codes in vread/vwrite() to iterating vmap_area_list. There is a little difference relate to lock, because vmlist_lock is mutex, but, vmap_area_lock is spin_lock. It may introduce a spinning overhead during vread/vwrite() is executing. But, these are debug-oriented functions, so this overhead is not real problem for common case. Signed-off-by: Joonsoo Kim <js1304@gmail.com> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> Cc: Chris Metcalf <cmetcalf@tilera.com> Cc: Dave Anderson <anderson@redhat.com> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn> Cc: Ingo Molnar <mingo@kernel.org> Cc: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/msync.c')
0 files changed, 0 insertions, 0 deletions