]> git.karo-electronics.de Git - karo-tx-linux.git/commit
ovl: lockdep annotate of nested stacked overlayfs inode lock
authorAmir Goldstein <amir73il@gmail.com>
Wed, 11 Jan 2017 10:07:46 +0000 (12:07 +0200)
committerMiklos Szeredi <mszeredi@redhat.com>
Wed, 8 Mar 2017 14:05:23 +0000 (15:05 +0100)
commitb1eaa950f7e905aaffca0454aa05101ce4f6446a
treec5eb599a2e2bb9c8a1c93159c12902eba74e5b6a
parentc1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201
ovl: lockdep annotate of nested stacked overlayfs inode lock

An overlayfs instance can be the lower layer of another overlayfs
instance. This setup triggers a lockdep splat of possible recursive
locking of sb->s_type->i_mutex_key in iterate_dir(). Trimmed snip:

 [ INFO: possible recursive locking detected ]
 bash/2468 is trying to acquire lock:
  &sb->s_type->i_mutex_key#14, at: iterate_dir+0x7d/0x15c
 but task is already holding lock:
  &sb->s_type->i_mutex_key#14, at: iterate_dir+0x7d/0x15c

One problem observed with this splat is that ovl_new_inode()
does not call lockdep_annotate_inode_mutex_key() to annotate
the dir inode lock as &sb->s_type->i_mutex_dir_key like other
fs do.

The other problem is that the 2 nested levels of overlayfs inode
lock are annotated using the same key, which is the cause of the
false positive lockdep warning.

Fix this by annotating overlayfs inode lock in ovl_fill_inode()
according to stack level of the super block instance and use
different key for dir vs. non-dir like other fs do.

Here is an edited snip from /proc/lockdep_chains after
iterate_dir() of nested overlayfs:

 [...] &ovl_i_mutex_dir_key[depth]   (stack_depth=2)
 [...] &ovl_i_mutex_dir_key[depth]#2 (stack_depth=1)
 [...] &type->i_mutex_dir_key        (stack_depth=0)

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
fs/overlayfs/inode.c