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]
Date:	Tue, 24 Aug 2010 16:48:39 -0400
From:	Valerie Aurora <vaurora@...hat.com>
To:	"J. R. Okajima" <hooanon05@...oo.co.jp>
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

On Tue, Aug 24, 2010 at 11:28:37AM +0900, J. R. Okajima wrote:
> 
> Thank you for explanation, very much.

You are welcome!

> 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).

No, that's not a sufficient description and leaves open questions
about all sorts of deadlocks and race conditions.  For example,
inotify events occur while holding locks only on one layer.  You
obviously need to lock the top layer to update the inheritance and
parent-child relationships.  Now you are locking the lower layer first
and the top layer second, which is the reverse of the usual order.
Also, it should not be an option.

If Al Viro says it's wrong, you need a very detailed explanation of
why it is right.  See Documentation/filesystem/directory-locking for
an example of the argument you have to make to show that moving things
around on the lower layer is safe.  In general, your first task is to
show a global lock ordering to prove lack of deadlocks (which I don't
think you should spend time on because most VFS experts think it is
impossible to do with two read-write layers).

I'm not going to explain any more how aufs is wrong; it's the
maintainer's job to convince Al Viro and other maintainers that aufs
is right.  But I hope this gave you a start and showed why union
mounts is a preferred approach for many people.

Thanks,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ