linux-kernel - Re: [PATCH] vfs: Add a trace point in the mark_inode

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]

Date:	Thu, 12 Nov 2009 08:22:17 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"Kok, Auke" <auke-jan.h.kok@...el.com>
Cc:	"Frank Ch. Eigler" <fche@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Jeff Garzik <jeff@...zik.org>,
	"Wu, Fengguang" <fengguang.wu@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH] vfs: Add a trace point in the mark_inode_dirty function

* Kok, Auke <auke-jan.h.kok@...el.com> wrote:

> If you already know what the file object is, sure. We're interested in 
> the case where we have no clue what the file object actually is to 
> begin with. Having a trace with a random inode number pop up and then 
> disappear into thin air won't help much at all, especially if we can't 
> map it back to something "real" on disk. in time.

Yep.

It's similar to PID/comm tracing, which we already do consistently for 
all major task events such as fork/exit, sleep/wakeup/context-switch, 
etc.

By the 'use inode numbers' argument it should be perfectly fine to only 
trace the physical PID itself, and look up the comm later in /proc, or 
to add a syscall to do it.

In reality it's not fine. Not just the unnecessary overhead (you have to 
look up something you already had) - but also that tasks will exit in 
high-freq workloads (so the comm is lost), the PID might not match up 
anymore, tasks can change their comm, etc.

The most important principle with event logging is that we want the most 
high quality information and we want to a trustable and simple data 
source: so for tasks we want the PID and the comm, and for files we want 
the top name component and perhaps also the inode number (plus a 
filesystem id), captured when the event happened.

	Ingo
--
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/