linux-kernel - Re: [PATCH] ftrace: add an fsync tracer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.1.10.0811061020311.31011@gandalf.stny.rr.com>
Date:	Thu, 6 Nov 2008 10:34:50 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Arjan van de Ven <arjan@...radead.org>
cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, alan@...hat.com
Subject: Re: [PATCH] ftrace: add an fsync tracer


On Thu, 6 Nov 2008, Arjan van de Ven wrote:

> > 
> > The syscall tracer will also have told you about that open.
> 
> ok so now you're turning a simple problem into "also track all open,
> openat, dup, dup2, close, unix domain fs passing etc". That doesn't
> sound like an improvement to me.
> And even the "open/fd" family isn't enough, because the open will be
> relative pathnames, so I now also need to second guess the PWD, and
> then follow a chain of "chdir" calls as well and then resolve the
> ".."'s in the path. And follow symlinks that may no longer be the same
> symlink it used to be. Etc. Etc.
> 
> No sorry, this really is not a viable approach.
> 
> And that goes beyond the fsync tracer. Anybody who thinks that syscall
> tracing is the right approach needs to seriously think about it; it
> really looks like the same problem as with audit... it started out with
> a bad hack that did it at the syscall level but it was likewise shown
> to just not be the right level. I am rather certain that the same will
> be shown for tracing.

What I would like is a single "event tracer" that does all of this.
But add the ability to start and stop different events. We could start
with this tracer, and then add more events to this tracer. Have a
separate file to show which events are available.

This will keep the 'available_tracers' file small, but it would be fine
if the 'events' file grew large.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/