linux-kernel - Re: PROBLEM: 2.6.35.7 to 3.0 Inotify events missing

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: <20110821170714.GB9296@fieldses.org>
Date:	Sun, 21 Aug 2011 13:07:14 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	Al Viro <viro@...IV.linux.org.uk>,
	Sylvain Rochet <gradator@...dator.net>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-nfs@...r.kernel.org
Subject: Re: PROBLEM: 2.6.35.7 to 3.0 Inotify events missing

On Sat, Aug 20, 2011 at 04:03:35AM +0100, Jamie Lokier wrote:
> Well you still have your sense of humour...
> 
> I've never understood why you think it's about the file manager /
> desktop, or why you so strongly dislike the feature.  It originated
> there historically, but that is not it's primary use.
> 
> The implementation, sure, but you seem to dislike the very *principle*
> of subscribing to changes.
> 
> Every interesting use of inotify that I've seen is for some kind of
> cache support, to eliminate the majority of stat() calls, to remove
> disk I/O (no stat means no inode), to ensure correctness (st_mtime is
> coarse and unreliable),

It seems rather fragile as an mtime replacement unless it's also got
some sort of logging built in at a pretty low level so that you don't
lose events while you're not listening.

And of course events have to be defined very carefully to avoid problems
such as this one.

> and to avoid having to modify every
> application which might affect any file from which cached items are
> derived to explicitly notify all the applications which might use any
> of those files.
> 
> You like high performance, reliable and correct behaviour, and high
> scalability.  So I have never understood why you dislike the
> change-subscription principle so strongly, because it is a natural
> ally to those properties.

I don't think we've seen a design that does all of that yet.

--b.
--
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/