linux-kernel - Re: [PATCH 14/39] union-mount: Union mounts documentation

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6881.1282616917@jrobl>
Date:	Tue, 24 Aug 2010 11:28:37 +0900
From:	"J. R. Okajima" <hooanon05@...oo.co.jp>
To:	Valerie Aurora <vaurora@...hat.com>
Cc:	Neil Brown <neilb@...e.de>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Miklos Szeredi <miklos@...redi.hu>,
	Jan Blunck <jblunck@...e.de>,
	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 14/39] union-mount: Union mounts documentation

Thank you for explanation, very much.

Valerie Aurora:
> First, my theory when writing any file system code is that whenever Al
> Viro says, "You can deadlock easily" or "It violates the locking
> rules" that I have to understand the problem and fix it.  I understand
> why union mounts doesn't have the problems unionfs had when Al wrote
> this email (because lower layers are not writable).  But since aufs
> allows directories on lower layers to be renamed in the way that
> creates the problems Al describes, I assume it has this same problem
> until the author understands the unionfs problem and can describe why
> aufs didn't inherit it (or fixed it, or whatever).

Basically agreed.

> Second, why isn't the most strict level of lookup the only option?  It
> seems like anything else is a bug.

Because users can hide the layers (such like UnionMount) if they want,
and it totally prohibits bypassing aufs. Additionally they modify on the
layer directly (bypassing aufs) only when it is really necessary. So the
default value of the option is not a strict one. And users can change
the option dynamically.

> Start with parent_dir1/child_dir1 covering parent_dir2/child_dir2
>  thread 1 does a union lookup and gets:
>   parent_dir1 covering parent_dir2
>   child_dir1 covering child_dir2
>   parent_dir1 parent of child_dir1
>   parent_dir2 parent of child_dir2
>  thread 2 swaps parent_dir2 with child_dir2 (using rename and a tmp dir)
>   now lower fs looks like: child_dir2/parent_dir2
>
> Who inherits what?  Does thread 1 see parent_dir2 as a descendant of
> child_dir2 which is a descendant of parent_dir2 through the union with
> parent_dir1?  Can you sanely define the behavior here?

When a rename happens on a layer directly, aufs receives a
inotify/fsnotify event. Following the event type, aufs makes the cached
dentry/inode obsoleted and they will be lookup-ed again in the
succeeding access. Finally aufs will know the upper parent_dir1 is not
covering the lower parent_dir2 anymore.
This notification is the main purpose of the strict option which is
called "udba=notify" (User's Direct Branch Access).

> Fourth, you have a potential deadlock now.  Say thread 1 is operating
	:::

No, deadlock will not happen since aufs knows the new parent-child
relationship. By using inotify/hinotify in above answer, I hope you
would agree with that.

> > Then I'd say it is an expected behaviour. Simply the upper file hides
> > the lower.
>
> I am not arguing with you and I agree that this is the expected
> behavior.  I wrote about this case just to show that there is a case
> in which what the user "wants" in an upgrade situation is impossible
> to do automatically in the file system.  So you need to have a smart
> tool to do an upgrade of the lower layer file system.  And I argue
> that smart tool should deal with all cases of a file copied up to the
> topmost file system that covers an updated file on the lower file
> system, instead of putting this policy decision into the VFS.

I am afraid that still I may not understand what you wrote well.
Do you mean that upgrading a package involves updating seveal files and
their version have to be matched with each other within the package, and
upgrading different package in both of upper and lower layer directly
causes mismatch among those files?

Although I don't think you are talking about an aufs utility aubrsync
which runs rsync between layers, I don't understand about "putting this
policy decision into the VFS". The simple rule "the upper file hides the
lower" is out of VFS.

J. R. Okajima
--
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/