Sedat Dilek <sedat.dilek@xxxxxxxxx> 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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
