From: Richard Guy Briggs <rgb@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: linux-audit@redhat.com
Subject: Re: [RFC PATCH 6/9] audit: rework audit_log_start()
Date: Fri, 25 Nov 2016 11:41:36 -0500 [thread overview]
Message-ID: <20161125164136.GA26673@madcap2.tricolour.ca> (raw)
In-Reply-To: <CAHC9VhQzMUWCRsqgVk8ScOtzYfMHP6vwH6ajZKWRKD6z5YjPoQ@mail.gmail.com>
On 2016-11-25 11:38, Paul Moore wrote:
> On Thu, Nov 24, 2016 at 1:41 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2016-11-23 20:42, Paul Moore wrote:
> >> From: Paul Moore <paul@paul-moore.com>
> >>
> >> The backlog queue handling in audit_log_start() is a little odd with
> >> some questionable design decisions, this patch attempts to rectify
> >> this with the following changes:
> >>
> >> * Never make auditd wait, ignore any backlog limits as we need auditd
> >> awake so it can drain the backlog queue.
> >>
> >> * When we hit a backlog limit and start dropping records, don't wake
> >> all the tasks sleeping on the backlog, that's silly. Instead, let
> >> kauditd_thread() take care of waking everyone once it has had a chance
> >> to drain the backlog queue.
> >>
> >> * Don't keep a global backlog timeout countdown, make it per-task. A
> >> per-task timer means we won't have all the sleeping tasks waking at
> >> the same time and hammering on an already stressed backlog queue.
> >>
> >> Signed-off-by: Paul Moore <paul@paul-moore.com>
> >> ---
> >> kernel/audit.c | 92 ++++++++++++++++++++++----------------------------------
>
> ...
>
> >> 1 file changed, 36 insertions(+), 56 deletions(-)
> >> + /* don't ever fail/sleep on auditd since we need auditd to drain the
> >> + * queue; also, when we are checking for auditd, compare PIDs using
> >> + * task_tgid_vnr() since auditd_pid is set in audit_receive_msg() using
> >> + * a PID anchored in the caller's namespace */
> >> + if (!(audit_pid && audit_pid == task_tgid_vnr(current))) {
> >
> > Could the change from task_tgid() [should be same as current->tgid] to
> > task_tgid_vnr() be pulled out into a seperate patch to make the
> > namespace behaviour change implicaiton much more clear?
>
> Considering the comment above the if-conditional I don't think there
> is much to be gained by splitting it out to a separate patch.
Except the ability to find it when someone goes looking for things that
change namespace behaviour, which this patch objective should not
include.
I agree it is well explained in the comment, but that change is
unrelated to the goal of the rest of the patch.
> paul moore
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
next prev parent reply other threads:[~2016-11-25 16:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-24 1:41 [RFC PATCH 0/9] Move the audit netlink multicast send to the kauditd_thread Paul Moore
2016-11-24 1:41 ` [RFC PATCH 1/9] audit: move kaudit thread start from auditd registration to kaudit init (#2) Paul Moore
2016-11-24 1:41 ` [RFC PATCH 2/9] audit: fixup audit_init() Paul Moore
2016-11-24 1:41 ` [RFC PATCH 3/9] audit: queue netlink multicast sends just like we do for unicast sends Paul Moore
2016-11-24 1:41 ` [RFC PATCH 4/9] audit: rename the queues and kauditd related functions Paul Moore
2016-11-24 1:41 ` [RFC PATCH 5/9] audit: rework the audit queue handling Paul Moore
2016-11-24 6:35 ` Richard Guy Briggs
2016-11-25 16:33 ` Paul Moore
2016-11-24 1:42 ` [RFC PATCH 6/9] audit: rework audit_log_start() Paul Moore
2016-11-24 6:41 ` Richard Guy Briggs
2016-11-25 16:38 ` Paul Moore
2016-11-25 16:41 ` Richard Guy Briggs [this message]
2016-11-25 16:50 ` Paul Moore
2016-11-24 1:42 ` [RFC PATCH 7/9] audit: wake up kauditd_thread after auditd registers Paul Moore
2016-11-24 1:42 ` [RFC PATCH 8/9] audit: handle a clean auditd shutdown with grace Paul Moore
2016-11-24 1:42 ` [RFC PATCH 9/9] audit: don't ever sleep on a command record/message Paul Moore
2016-11-29 22:08 ` [RFC PATCH 0/9] Move the audit netlink multicast send to the kauditd_thread Paul Moore
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=20161125164136.GA26673@madcap2.tricolour.ca \
--to=rgb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=paul@paul-moore.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox