From: Gao feng <gaofeng@cn.fujitsu.com>
To: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Cc: viro@zeniv.linux.org.uk, eparis@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [BUG][PATCH V3] audit: audit_log_start running on auditd should not stop
Date: Tue, 15 Oct 2013 17:41:02 +0800 [thread overview]
Message-ID: <525D0DAE.6000909@cn.fujitsu.com> (raw)
In-Reply-To: <20131015165857.aa1c68502180cb4b89d6226a@jp.fujitsu.com>
On 10/15/2013 03:58 PM, Toshiyuki Okajima wrote:
> The backlog cannot be consumed when audit_log_start is running on auditd
> even if audit_log_start calls wait_for_auditd to consume it.
> The situation is the deadlock because only auditd can consume the backlog.
> If the other process needs to send the backlog, it can be also stopped
> by the deadlock.
>
> So, audit_log_start running on auditd should not stop.
>
> You can see the deadlock with the following reproducer:
> # auditctl -a exit,always -S all
> # reboot
>
> Signed-off-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
> Cc: gaofeng@cn.fujitsu.com
> ---
> kernel/audit.c | 14 ++++++++------
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
Looks good to me, thanks!
Reviewed-by: Gao feng <gaofeng@cn.fujitsu.com>
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 7b0e23a..29cfc94 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1095,7 +1095,8 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
> struct audit_buffer *ab = NULL;
> struct timespec t;
> unsigned int uninitialized_var(serial);
> - int reserve;
> + int reserve = 5; /* Allow atomic callers to go up to five
> + entries over the normal backlog limit */
> unsigned long timeout_start = jiffies;
>
> if (audit_initialized != AUDIT_INITIALIZED)
> @@ -1104,11 +1105,12 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
> if (unlikely(audit_filter_type(type)))
> return NULL;
>
> - if (gfp_mask & __GFP_WAIT)
> - reserve = 0;
> - else
> - reserve = 5; /* Allow atomic callers to go up to five
> - entries over the normal backlog limit */
> + if (gfp_mask & __GFP_WAIT) {
> + if (audit_pid && audit_pid == current->pid)
> + gfp_mask &= ~__GFP_WAIT;
> + else
> + reserve = 0;
> + }
>
> while (audit_backlog_limit
> && skb_queue_len(&audit_skb_queue) > audit_backlog_limit + reserve) {
>
next prev parent reply other threads:[~2013-10-15 9:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 1:36 [BUG][PATCH][RFC] audit: hang up in audit_log_start executed on auditd Toshiyuki Okajima
2013-10-11 1:36 ` Toshiyuki Okajima
2013-10-11 9:33 ` Gao feng
2013-10-11 12:29 ` Toshiyuki Okajima (smtp-b.css)
2013-10-15 4:43 ` [BUG][PATCH] audit: audit_log_start running on auditd should not stop Toshiyuki Okajima
2013-10-15 6:30 ` Gao feng
2013-10-15 7:07 ` Toshiyuki Okajima
2013-10-15 7:58 ` [BUG][PATCH V3] " Toshiyuki Okajima
2013-10-15 9:41 ` Gao feng [this message]
2013-10-23 19:55 ` [BUG][PATCH] " Richard Guy Briggs
2013-10-24 5:55 ` Gao feng
2013-10-24 19:35 ` Richard Guy Briggs
2013-10-25 1:36 ` Toshiyuki Okajima
2013-10-25 15:12 ` Eric Paris
2013-10-28 9:20 ` Toshiyuki Okajima
2013-12-05 2:45 ` [PATCH 0/3] audit: remove audit_log_start() contention in AUDIT_USER type calls Richard Guy Briggs
2013-12-05 2:45 ` [PATCH 1/3] selinux: call WARN_ONCE() instead of calling audit_log_start() Richard Guy Briggs
2013-12-05 2:45 ` [PATCH 2/3] smack: " Richard Guy Briggs
2013-12-06 18:40 ` Casey Schaufler
2013-12-06 18:40 ` Casey Schaufler
2013-12-08 22:17 ` Richard Guy Briggs
2013-12-05 2:45 ` [PATCH 3/3] audit: drop audit_cmd_lock in AUDIT_USER family of cases Richard Guy Briggs
2013-12-05 2:45 ` Richard Guy Briggs
2013-12-09 2:31 ` Toshiyuki Okajima
2013-12-09 2:31 ` Toshiyuki Okajima
2013-12-05 7:15 ` [RESEND][BUG][PATCH V3] audit: audit_log_start running on auditd should not stop Toshiyuki Okajima
2013-12-05 7:15 ` Toshiyuki Okajima
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=525D0DAE.6000909@cn.fujitsu.com \
--to=gaofeng@cn.fujitsu.com \
--cc=eparis@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=toshi.okajima@jp.fujitsu.com \
--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.