On Fri, Mar 3, 2017 at 9:22 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Wed, Feb 8, 2017 at 9:42 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> On Tue, Jan 31, 2017 at 9:15 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >>> On Wed, Jan 11, 2017 at 12:07 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >>>> 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@xxxxxxxxx> >>>> --- >>>> fs/overlayfs/inode.c | 38 ++++++++++++++++++++++++++++++++++++++ >>>> 1 file changed, 38 insertions(+) >>>> >>>> v4: >>>> - further simplify by removing unneeded ofs->nested >>>> >>> >>> Miklos, >>> >>> This patch version addresses your review comments from previous merge cycle >>> and it has zero impact without CONFIG_LOCKDEP as you requested. >>> >> >> Ping. >> >> Would you mind queuing this one as well for 4.11? Sorry, missed this. I'll bundle this with the next pull; probably there will be other fixes before 4.11 final. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html