From: David Howells <dhowells@redhat.com>
To: Tony Jones <tonyj@suse.de>
Cc: dhowells@redhat.com, linux-kernel@vger.kernel.org,
linux-audit@redhat.com, Eric Paris <eparis@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: PATCH [1/1]: audit: acquire creds selectively to reduce atomic op overhead
Date: Tue, 08 Mar 2011 18:02:53 +0000 [thread overview]
Message-ID: <18893.1299607373@redhat.com> (raw)
In-Reply-To: <20110307210656.GA1750@suse.de>
Tony Jones <tonyj@suse.de> wrote:
> Commit c69e8d9c01db added calls to get_task_cred and put_cred in
> audit_filter_rules. Profiling with a large number of audit rules active on
> the exit chain shows that we are spending upto 48% in this routine for
> syscall intensive tests, most of which is in the atomic ops.
>
> The following patch acquires the cred if a rule requires it. In our
> particular case above, most rules had no cred requirement and this dropped
> the time spent in audit_filter_rules down to ~12%. An alternative would be
> for the caller to acquire the cred just once for the whole chain and pass
> into audit_filter_rules. I can create an alternate patch doing this if
> required.
There's no actual need to get a ref on the named task's creds.
If tsk == current, no locking is needed at all.
If tsk != current, the RCU read lock is sufficient. See task_cred_xxx() in
include/linux/cred.h.
Hmmm... I wonder... The audit filter uses tsk->real_cred, but is that
correct? Should it be using tsk->cred? And is tsk always going to be
current?
> + const struct cred *cred=NULL;
Binary operators like '=' should have a space on each side.
David
next prev parent reply other threads:[~2011-03-08 18:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-07 21:06 PATCH [1/1]: audit: acquire creds selectively to reduce atomic op overhead Tony Jones
2011-03-08 18:02 ` David Howells [this message]
2011-03-10 20:25 ` Tony Jones
2011-03-11 16:33 ` David Howells
2011-03-15 17:38 ` Tony Jones
2011-03-15 17:44 ` Eric Paris
2011-03-15 20:11 ` David Howells
2011-03-17 18:11 ` Tony Jones
2011-03-21 13:57 ` Eric Paris
2011-04-27 13:12 ` Jiri Kosina
2011-04-27 16:26 ` Tony Jones
2011-03-15 20:04 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18893.1299607373@redhat.com \
--to=dhowells@redhat.com \
--cc=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tonyj@suse.de \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.