linux-kernel - Re: [PATCH =-v3 07/21] fanotify: fastpath to ignore certain in core inodes

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] [day] [month] [year] [list]

Message-ID: <80skblmqwt.fsf@merkur.tec.linutronix.de>
Date:	Tue, 08 Dec 2009 16:22:42 +0100
From:	John Ogness <dazukocode@...ess.net>
To:	Eric Paris <eparis@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	viro@...iv.linux.org.uk, arjan@...radead.org, greg@...ah.com,
	tytso@....edu, akpm@...ux-foundation.org
Subject: Re: [PATCH =-v3 07/21] fanotify: fastpath to ignore certain in core inodes

On 2008-11-12, Eric Paris <eparis@...hat.com> wrote:
> Kernel Build on a 32 way machine:
> Stock kernel: 9 minutes 12 seconds
> fanotify no in kernel fastpath: 95 minutes 12 seconds
> Only events AV wants with in kernel fastpath: 10 minutes 35 seconds

Can you provide the number of calls into the listeners for each type of
fanotify event? It would provide a better picture of the scope of the
issue.

I find your non-fastpath numbers quite alarming.

The DazukoFS stackable filesystem can also be used for userspace
listeners to acknowledge/handle filesystem events. (I only mention
DazukoFS here so that there is some kind of metric comparison that can
be used.) I find a 15% overhead in communication to be too
expensive. And a 934.7% performance hit is... well...

The DazukoFS stackable filesystem only provides file open events, but
its numbers may still be of interest here:

kernel build on tmpfs:          72m36.884s
kernel build on tmpfs+DazukoFS: 75m30.569s

That is an overhead of 4%. Your results show that fanotify (with
fastpaths!) has an overhead of 15%.

My test was done using Linux 2.6.32 and DazukoFS 3.1.2. The Linux source
and build were located on tmpfs to minimize hard drive hits. The machine
was a 600MHz PowerPC, which is why the build times were so long.

During the test, the DazukoFS listeners recorded a total of 991,907 file
open events.

IMHO event filtering should happen in userspace. My experience is that
the context switches can be quite cheap. Perhaps if we know which
fanotify events (and how many) occur within your test, we can begin to
understand why your results are what they are.

John Ogness
--
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/