linux-kernel - [PATCH 0/3] mm,vdso: preallocate new vmas

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1382057438-3306-1-git-send-email-davidlohr@hp.com>
Date:	Thu, 17 Oct 2013 17:50:35 -0700
From:	Davidlohr Bueso <davidlohr@...com>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Michel Lespinasse <walken@...gle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Rik van Riel <riel@...hat.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>, aswin@...com,
	linux-mm <linux-mm@...ck.org>, linux-kernel@...r.kernel.org,
	Davidlohr Bueso <davidlohr@...com>
Subject: [PATCH 0/3] mm,vdso: preallocate new vmas

Linus recently pointed out[1] some of the amount of unnecessary work 
being done with the mmap_sem held. This patchset is a very initial 
approach on reducing some of the contention on this lock, and moving
work outside of the critical region.

Patch 1 adds a simple helper function.

Patch 2 moves out some trivial setup logic in mlock related calls.

Patch 3 allows managing new vmas without requiring the mmap_sem for
vdsos. While it's true that there are many other scenarios where
this can be done, few are actually as straightforward as this in the
sense that we *always* end up allocating memory anyways, so there's really
no tradeoffs. For this reason I wanted to get this patch out in the open.

There are a few points to consider when preallocating vmas at the start
of system calls, such as how many new vmas (ie: callers of split_vma can
end up calling twice, depending on the mm state at that point) or the probability
that we end up merging the vma instead of having to create a new one, like the 
case of brk or copy_vma. In both cases the overhead of creating and freeing
memory at every syscall's invocation might outweigh what we gain in not holding
the sem.

[1] https://lkml.org/lkml/2013/10/9/665 

Thanks!

Davidlohr Bueso (3):
  mm: add mlock_future_check helper
  mm/mlock: prepare params outside critical region
  vdso: preallocate new vmas

 arch/arm/kernel/process.c          | 22 +++++++++----
 arch/arm64/kernel/vdso.c           | 21 ++++++++++---
 arch/hexagon/kernel/vdso.c         | 16 +++++++---
 arch/mips/kernel/vdso.c            | 10 +++++-
 arch/powerpc/kernel/vdso.c         | 11 +++++--
 arch/s390/kernel/vdso.c            | 19 +++++++++---
 arch/sh/kernel/vsyscall/vsyscall.c | 11 ++++++-
 arch/tile/kernel/vdso.c            | 13 ++++++--
 arch/um/kernel/skas/mmu.c          | 16 +++++++---
 arch/unicore32/kernel/process.c    | 17 +++++++---
 arch/x86/um/vdso/vma.c             | 18 ++++++++---
 arch/x86/vdso/vdso32-setup.c       | 16 +++++++++-
 arch/x86/vdso/vma.c                | 10 +++++-
 include/linux/mm.h                 |  3 +-
 kernel/events/uprobes.c            | 14 +++++++--
 mm/mlock.c                         | 18 ++++++-----
 mm/mmap.c                          | 63 ++++++++++++++++++--------------------
 17 files changed, 213 insertions(+), 85 deletions(-)

-- 
1.8.1.4

--
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/