public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: Handling -ENOBUFS
Date: Wed, 5 Nov 2008 13:19:00 -0500	[thread overview]
Message-ID: <200811051319.00359.sgrubb@redhat.com> (raw)
In-Reply-To: <2c03f9590811050830wc551ca6g3a99c467c5e0b7@mail.gmail.com>

On Wednesday 05 November 2008 11:30:16 Lucas C. Villa Real wrote:
> I'm facing a situation where -ENOBUFS is returned from both
> audit_send() and audit_get_reply(). The system is under high stress,
> with 250k files being created and having creat() and chmod() syscalls
> audited.

Is this what you really wanted to audit? :)


> Looking the code at lib/netlink.c, I saw that audit_send() doesn't
> handle -ENOBUFS. Would it be possible to replace the condition from
> "while (retval < 0 && errno == EINTR)" to "while (retval < 0 && (errno
> == EINTR || errno == ENOBUFS))" to fix the problem when sending
> packets from userspace to kernel?

Have you tried that? Does it fix the problem or just hang the utility?


> My understanding for the problem in audit_get_reply() is that the I/O
> buffers are all full and auditd was just not scheduled at the expected
> rate, causing these buffers to overflow. Does that make sense?

If you go over the backlog limit, you get a syslog message about that unless 
you have it set to ignore. My guess would be that you have a general network 
memory pool depletion and is not related to audit specifically.


> If it does, do you have a suggestion about the best way to approach this
> problem, besides changing auditd's priority?

Increase the backlog and increase auditd's priority. I have not played with 
running auditd with a different scheduler policy than whatever the default 
is. But you may want to see if one of the other scheduler polices treat audit 
better. or maybe you want to tune  /proc/sys/kernel/sched_granularity_ns.


> One interesting thing which I noticed is that 'auditctl -s' doesn't
> report that messages were lost,

They weren't lost by the audit system so it doesn't know they didn't arrive.


> This is happening with an old kernel, 2.6.16.46 + a bunch of patches,
> and audit 1.7.4. I cannot completely upgrade it to a new release, but
> I can certainly backport audit specific bits if you remember having
> fixed something similar since then.

Well, that proc tunable is only available for the CFS scheduler. Not sure what 
you have for older kernels.

-Steve

  reply	other threads:[~2008-11-05 18:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-05 16:30 Handling -ENOBUFS Lucas C. Villa Real
2008-11-05 18:19 ` Steve Grubb [this message]
2008-11-05 20:56   ` Lucas C. Villa Real
2008-11-05 22:05     ` Steve Grubb
2008-11-06 14:16     ` Eric Paris
2008-11-10 21:25       ` Lucas C. Villa Real

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=200811051319.00359.sgrubb@redhat.com \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.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