lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 28 Mar 2011 09:58:52 +0800 From: Shaohua Li <shaohua.li@...el.com> To: Andrew Morton <akpm@...ux-foundation.org> Cc: linux-mm <linux-mm@...ck.org>, lkml <linux-kernel@...r.kernel.org>, Rik van Riel <riel@...hat.com>, Hugh Dickins <hughd@...gle.com> Subject: [PATCH]mmap: avoid unnecessary anon_vma lock If we only change vma->vm_end, we can avoid taking anon_vma lock even 'insert' isn't NULL, which is the case of split_vma. >From my understanding, we need the lock before because rmap must get the 'insert' VMA when we adjust old VMA's vm_end (the 'insert' VMA is linked to anon_vma list in __insert_vm_struct before). But now this isn't true any more. The 'insert' VMA is already linked to anon_vma list in __split_vma(with anon_vma_clone()) instead of __insert_vm_struct. There is no race rmap can't get required VMAs. So the anon_vma lock is unnecessary, and this can reduce one locking in brk case and improve scalability. Signed-off-by: Shaohua Li<shaohua.li@...el.com> --- mm/mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/mm/mmap.c =================================================================== --- linux.orig/mm/mmap.c 2011-03-24 09:08:27.000000000 +0800 +++ linux/mm/mmap.c 2011-03-24 09:14:03.000000000 +0800 @@ -605,7 +605,7 @@ again: remove_next = 1 + (end > next-> * lock may be shared between many sibling processes. Skipping * the lock for brk adjustments makes a difference sometimes. */ - if (vma->anon_vma && (insert || importer || start != vma->vm_start)) { + if (vma->anon_vma && (importer || start != vma->vm_start)) { anon_vma = vma->anon_vma; anon_vma_lock(anon_vma); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists