[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1424304641-28965-1-git-send-email-dbueso@suse.de>
Date: Wed, 18 Feb 2015 16:10:38 -0800
From: Davidlohr Bueso <dbueso@...e.de>
To: akpm@...ux-foundation.org
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, dave@...olabs.net
Subject: [PATCH -part1 0/3] mm: improve handling of mm->exe_file
From: Davidlohr Bueso <dave@...olabs.net>
This series is the first in a few where I'm planning on removing
the mmap_sem need for exe_file serialization. This is absurd and
needs to have its own locking. Anyway, this is the final goal, and
this series is just the first of a few that deals with unifying users
of exe_file.
For now we only deal with audit and tomoyo, the most obvious naughty
users, which only take the mmap_sem for exe_file. Over the years,
relying on the mmap_sem for exe_file has made some callers increasingly
messy and it is not as straightforward.
Essentially, we want to convert:
down_read(&mm->mmap_sem);
do_something_with(mm->exe_file);
up_read(&mm->mmap_sem);
to:
exe_file = get_mm_exe_file(mm); <--- mmap_sem is only held here.
do_something_with(mm->exe_file);
fput(exe_file);
On its own, these patches already have value in that we reduce mmap_sem hold
times and critical region. Once all users are standardized, converting the
lock rules will be much easier.
Thanks!
Davidlohr Bueso (3):
kernel/audit: consolidate handling of mm->exe_file
kernel/audit: robustify handling of mm->exe_file
security/tomoyo: robustify handling of mm->exe_file
kernel/audit.c | 9 +--------
kernel/audit.h | 20 ++++++++++++++++++++
kernel/auditsc.c | 9 +--------
security/tomoyo/common.c | 41 ++++++++++++++++++++++++++++++++++++++---
security/tomoyo/common.h | 1 -
security/tomoyo/util.c | 22 ----------------------
6 files changed, 60 insertions(+), 42 deletions(-)
--
2.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/
Powered by blists - more mailing lists