Re: [PATCH] ext3 [linux-2.6.2.]: accessing already freed inodes when under memory pressure

[viro@parcelfarce.linux.theplanet.co.uk]

On Fri, Apr 02, 2004 at 09:40:57PM +0100, Jamie Lokier wrote:
> The trouble with that is the many programs which assume that if
> st_nlink == 1, then the file has only one path.  This is a critical
> optimisation for any program which looks at a lot of files checking
> for equivalent files, and is widely assumed.  I've always thought it a
> reliable basic unix assumption.

Even aside of (in)accuracy of ->st_nlink, that assumption is obviously
racy.

> For example: rsync -H, cp -a, and Emacs backup-by-copying-when-linked.
> You may argue that using "rsync -H" or "cp -a" on a tree that contains
> bind mounts is broken by design.

What would you expect from cp -a in that case?  To create a link?  That
would be a bug, plain and simple...

> Then there are programs such as optimised Make and cacheing systems
> and servers which use dnotify.  dnotify is reliable for single-linked
> files, and when there are multiple links, it's still reliable if you
> discover all the st_nlink paths to a file.  However, it isn't reliable
> if there are any bind mounts, because you don't know whether you have
> all paths to a file (without grubbing inside /proc/mounts, and that
> has race conditions anyway).

dnotify is not reliable, period.  We do NOT generate any events on the
parent of target; only on parent of new link.  So "discover all the st_nlink
paths" is both racy and unreliable - you won't get notified when links are
created.

> The obvious strategy for such programs is to ignore bind mounts and
> give incorrect results if there are any.  However it would be much
> better if they could detect when a file has multiple paths that aren't
> mentioned in st_nlink, so they wouldn't depend on dnotify in such cases.

How would they detect when such paths appear in the future?  For that matter,
who said that you can see all paths in question?

> There's a precedent for different views of a filesystem having
> different st_dev values.  Think about loopback NFS: possibly multiple
> NFS filesystems, and a real one, all referring to the same set of
> files, and _all_ of them have different st_dev values.  Semantically a
> bind mount does not seem so different from that.

Except that bind mount is not different from "normal" one - same situation
as with hard links.