linux-kernel - Re: Unionmount and overlayfs testsuite

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: <15839.1401786056@warthog.procyon.org.uk>
Date:	Tue, 03 Jun 2014 10:00:56 +0100
From:	David Howells <dhowells@...hat.com>
To:	sedat.dilek@...il.com
Cc:	dhowells@...hat.com, "J. R. Okajima" <hooanon05g@...il.com>,
	Miklos Szeredi <miklos@...redi.hu>,
	Al Viro <viro@...iv.linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>, apw@...onical.com,
	Felix Fietkau <nbd@...nwrt.org>, neilb@...e.de,
	jordipujolp@...il.com, ezk@....cs.sunysb.edu, mszeredi@...e.cz
Subject: Re: Unionmount and overlayfs testsuite

Sedat Dilek <sedat.dilek@...il.com> wrote:

> [ Re-Tested with 3.15.0-rc8-1-iniza-lockdep ]
> 
> Running the impermissible test on OverlayFS with TERMSLASH=1 is
> successful here

That's not very surprising.  utimensat() doesn't even get out of pathwalk if
the filename has a terminal slash and the fs_op macro correctly overrides the
expected error code in this case.

> (TERMSLASH=0 still fails):

It's possible that the test is wrong.  utimes is icky, at least on unionmount,
because the copy up has to be done before we call notify_change() - but
notify_change() can still reject the operation (in which case we didn't want
to copy up at all).  The problem is that notify_change() has i_mutex.

Ideally, we'd do copy-up inside notify_change() - but we can't do that in
unionmount.  I imagine you can do that in overlayfs.

> # LC_ALL=C TEST_OVERLAYFS=1 TERMSLASH=1 ./run.sh
> 
> [ NOTE-1: I still see the reported call-trace which you Dave see as a
> problem in OverlayFS. ]

There should be zero lockdep complaints.  It may be a real locking problem or
it may just be a missing nesting annotation.

One problem I had with unionmounts that I don't think applies to overlayfs is
that i_{,mdir_}mutex on inodes on the upper (union) layer and the lower layers
may come from the same superblock and thus have the same lockdep class keys
(which are per struct file_system_type).  This means that lockdep thinks
they're conflicting - when actually they are not.  What I did was to give
i_{,dir_}mutex in the upper layer different lockdep classes.

The reason this works for unionmounts is that there unionmounting is done by
the VFS and the upper/glue layer is an ordinary superblock (tmpfs, ext2, ...)
and I get to meddle with the lockdep classes of the upper superblock during
mount before any inodes exist.

I don't think this would work for overlayfs for two reasons: (1) the top layer
is an overlayfs superblock and would have different lockdep classes anyway and
(2) you cannot change the lockdep class once inodes exist in the filesystem -
and overlayfs requires both the upper and lower layers to exist prior to the
glue layer being mounted.

My suspicion is that overlayfs is doing stuff to the lower layer whilst
holding a lock on the upper layer or vice versa.

> [ NOTE-2: The call-trace I have seen once (TERMSLASH=0). ]

Do you know for which operation?

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