All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Paul Moore <paul.moore@hp.com>
Cc: linux-audit@redhat.com
Subject: Re: [PATCH] ratelimit printk messages from the audit system
Date: Thu, 24 Jan 2008 13:13:05 -0500	[thread overview]
Message-ID: <1201198385.3256.20.camel@localhost.localdomain> (raw)
In-Reply-To: <200801241308.48709.paul.moore@hp.com>


On Thu, 2008-01-24 at 13:08 -0500, Paul Moore wrote:
> On Thursday 24 January 2008 1:01:12 pm Eric Paris wrote:
> > On Thu, 2008-01-24 at 12:52 -0500, Paul Moore wrote:
> > > On Wednesday 23 January 2008 5:06:53 pm Linda Knippers wrote:
> > > > Eric Paris wrote:
> > > > > On Wed, 2008-01-23 at 16:05 -0500, Linda Knippers wrote:
> > > > >> This is unrelated to your patch but I think it would be nice
> > > > >> if audit_lost represented the number of audit messages lost
> > > > >> since the last time the message came out or the last time an
> > > > >> audit record came out. Today its a cumulative count since the
> > > > >> system was booted.  Is it too much overhead to zero it?
> > > > >
> > > > > Shouldn't be too much overhead, we are already on a
> > > > > slow/unlikely path. What's the benefit though?  Just don't want
> > > > > to have to do a subtraction?
> > > >
> > > > Well that, plus if the system is up for a long time (which we
> > > > hope) and the message is infrequent (which we also hope), then it
> > > > could take me a while to find the previous message in order to do
> > > > the subtraction.
> > > >
> > > > > If we are dropping the 'we lost some messages' message 0'ing
> > > > > the counter at that time would be a bad idea, certainly not
> > > > > unsolvable, but I don't see what it buys us.
> > > >
> > > > I wouldn't want to lose the message, just make it more useful. 
> > > > And if we zero it we don't have to worry about it wrapping.  As
> > > > it is now, its really just the count since the last time it
> > > > wrapped.
> > >
> > > I like Linda's idea of zero'ing the lost message counter once we
> > > are able to start sending messages again for all the reasons listed
> > > above. I haven't looked at the audit message sending code, but we
> > > are only talking about adding an extra conditional in the common
> > > case and in the worst case a conditional and an assignment. 
> > > Granted they are atomic ops, but everyone keeps telling me that
> > > atomic ops are pretty quick on almost all of the platforms that
> > > Linux supports ...
> >
> > Delivery of audit lost messages is through printk/syslog.  Assuming
> > we can assure it gets out of printk when we reset the counter we
> > can't assure that it made it to syslog.  That means we could lose
> > that message and have no record of it at all, nor any chance that in
> > the future it would get recorded that it was lost either.
> 
> That sort of begs the question - why do we even bother printing the 
> audit record lost message?
> 
>  :)

Hey its best effort what can I say.  At least without reseting the
counter we could realize one of them didn't make it sometime later.  Not
worth much I admit   :)
-Eric

      reply	other threads:[~2008-01-24 18:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-23 19:50 [PATCH] ratelimit printk messages from the audit system Eric Paris
2008-01-23 21:05 ` Linda Knippers
2008-01-23 21:41   ` Eric Paris
2008-01-23 22:06     ` Linda Knippers
2008-01-24 17:52       ` Paul Moore
2008-01-24 18:01         ` Eric Paris
2008-01-24 18:08           ` Paul Moore
2008-01-24 18:13             ` Eric Paris [this message]

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=1201198385.3256.20.camel@localhost.localdomain \
    --to=eparis@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=paul.moore@hp.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.