public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rusty Lynch <rusty@linux.jf.intel.com>
To: Chris Friesen <cfriesen@nortelnetworks.com>
Cc: "Sabharwal, Atul" <atul.sabharwal@intel.com>,
	Chris Wright <chrisw@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [Announce] Non Invasive Kernel Monitor for threads/processes
Date: Wed, 16 Jun 2004 10:36:38 -0700	[thread overview]
Message-ID: <20040616173638.GA29548@penguin2.jf.intel.com> (raw)
In-Reply-To: <40D058F3.5070109@nortelnetworks.com>

On Wed, Jun 16, 2004 at 10:28:03AM -0400, Chris Friesen wrote:
> Sabharwal, Atul wrote:
> 
> >How does auditing work in the event of a process failure ? There would
> >be
> >no system call triggered in that case.  Also, my initial thoughts are
> >that the non-invasive Kmonitor is lesser performance impact when
> >compared
> >to auditing. I would spend some time developing sample code to confirm
> >it.
> 
> Just to put in my $.02.  We developed a very simple (even simpler than 
> Kmonitor in that it didn't track fork/exec) way for a process to get 
> notified when other processes exited (properly or otherwise).  We want to 
> use this in the field for a lifecycle monitoring function (a sort of 
> super-init) so it needs to be as lightweight as possible.  I'd love to be 
> able to use something from the mainline kernel, but it has to be 
> field-runnable without slowing stuff down.
> 
> Chris

I think your requriement is the core requirement that we were tackling, and
the tracking for fork/exec was more of a feature creap thing.

So far suggestions include...

PAGG: never heard of it, but will look into it
LTT: I think this will cause too much overhead from all the hooks that
     we don't need, but we need to verify this.
Auditing:  Working on some very simple examples to understand how to use
           this correctly, and to understand if this is good enough, or if
           there are some modifications that could be made that would make it
           fit this very limited use of auditing.

    --rusty

  reply	other threads:[~2004-06-16 17:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-16  0:54 [Announce] Non Invasive Kernel Monitor for threads/processes Sabharwal, Atul
2004-06-16  1:12 ` Chris Wright
2004-06-16 14:28 ` Chris Friesen
2004-06-16 17:36   ` Rusty Lynch [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-06-15 22:48 Sabharwal, Atul
2004-06-15 18:38 Atul Sabharwal
2004-06-15 19:54 ` Atul Sabharwal
     [not found] ` <40CF5D39.1060701@linux.jf.intel.com>
     [not found]   ` <20040615142304.5d9591d5.akpm@osdl.org>
2004-06-16  0:25     ` Atul Sabharwal
2004-06-16  1:01       ` Rusty Lynch
2004-06-16  0:39 ` Chris Wright
2004-06-16 12:32 ` Karim Yaghmour

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=20040616173638.GA29548@penguin2.jf.intel.com \
    --to=rusty@linux.jf.intel.com \
    --cc=atul.sabharwal@intel.com \
    --cc=cfriesen@nortelnetworks.com \
    --cc=chrisw@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /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