All of lore.kernel.org
 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 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.