linux-kernel - Re: Unionmount fallthru directory entries

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: <BANLkTinr18+f12kyMZdiYAu+hNqH+5XyXQ@mail.gmail.com>
Date:	Wed, 11 May 2011 12:28:49 -0700
From:	Valerie Aurora <valerie.aurora@...il.com>
To:	David Howells <dhowells@...hat.com>
Cc:	viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Unionmount fallthru directory entries

On Wed, May 11, 2011 at 10:00 AM, David Howells <dhowells@...hat.com> wrote:
>
> What are unionmount fallthru directory entries for and why are they needed?

The long version of this answer is in:

http://lwn.net/Articles/325369/

The short version is that fallthrus allow you to generate and use a
32-bit d_off in readdir() using the topmost file system's native
readdir() implementation.  It lets you process duplicates and
whiteouts only once per directory, instead of every time you open it,
and does not require pinning O(size of all unioned dirs) memory while
the directory is open, and does not require a d_off generating hack
when readdir() runs off the end of the first dir (which no one has
made fs-agnostic so far).  The problems with previous approaches are
summarized in that article.

> I'm guess that what they do is indicate that the dirent in question must be
> looked up in the corresponding directory on the underlying fs.

Yes, if you are doing something that isn't just readdir().

> As to why they are needed, am I right in thinking that unionmount caches a
> copy of all the lower directory's entries in the upper directory with fallthru
> markers set on the first call to readdir?

Yes, but actually on the first lookup, not first readdir(), if I
recall correctly.  The duplicate and whiteout processing are done
exactly once, on first lookup of the directory, and then the directory
is marked opaque.

It's the best solution I've seen so far, but that doesn't mean it
can't be improved.

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