Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1171941 > unrolled thread

Re: [overlayfs] lockdep splat after mounting overlayfs over overlayfs

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [overlayfs] lockdep splat after mounting overlayfs over overlayfs Konstantin Khlebnikov <koct9i@gmail.com> - 2015-06-25 10:30 +0200
    Re: [overlayfs] lockdep splat after mounting overlayfs over  overlayfs Xu Wang <xuw@redhat.com> - 2015-06-26 05:30 +0200

#1171941 — Re: [overlayfs] lockdep splat after mounting overlayfs over overlayfs

On Thu, Jun 25, 2015 at 10:24 AM, Xu Wang <xuw@redhat.com> wrote:
>> I've accidentally mounted one overlayfs over another and got obvious
>> warning from lockdep: i_mutex lockdep classes are per-fs-type.
>>
>> # mount -t overlay overlay 1 -o
>> upperdir=1_upper,workdir=1_work,lowerdir=1_lower
>> # mount -t overlay overlay 2 -o upperdir=2_upper,workdir=2_work,lowerdir=1
>> # ls 2
>
> This reporting is positive, we are not in deadlock situation actually. The "2" dir
> of overlayfs will call iterate_dir->"1" dir of overlayfs->iterate_dir, and the nest
> iterate_dir happened on the same file system, so the warning came out.
>
> We'd better make the lower and upper in different fs instance, and this warning
> will disappear.
>
> And this lockdep warning happened when the nest iterate_dir call of same fs(I
> mean the same super block). The function check_deadlock in lockdep.c will
> report the nest lock of same process. If we make the 2_upper and 2_work in
> a different fs, no warning comes out.

Yep, it's not a deadlock. As I mentioned lockdep classes are per-fs-type so
lockdep cannot see difference between i_mutexes on different sb of the
same type.
But anyway this looks messy.

Probably it's safer to forbid overlayfs as lower or upper mount for overlayfs
because this have no sense. Nesting anyway is limited by the depth of kernel
stack and sb->s_stack_depth.

Or overlayfs could detect this situation and substitute layers of underlying
overlayfs into its own lower layers in appropriate place.

>
> Thanks,
>
> --
> George Wang 王旭
>
> Kernel Quantity Engineer
> Red Hat Software (Beijing) Co.,Ltd
> IRC:xuw
> Tel:+86-010-62608041
> Phone:15901231579
> 9/F, Tower C, Raycom
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1172575 — Re: [overlayfs] lockdep splat after mounting overlayfs over overlayfs

> On Thu, Jun 25, 2015 at 10:24 AM, Xu Wang <xuw@redhat.com> wrote:
> >> I've accidentally mounted one overlayfs over another and got obvious
> >> warning from lockdep: i_mutex lockdep classes are per-fs-type.
> >>
> >> # mount -t overlay overlay 1 -o
> >> upperdir=1_upper,workdir=1_work,lowerdir=1_lower
> >> # mount -t overlay overlay 2 -o upperdir=2_upper,workdir=2_work,lowerdir=1
> >> # ls 2
> >
> > This reporting is positive, we are not in deadlock situation actually. The
> > "2" dir
> > of overlayfs will call iterate_dir->"1" dir of overlayfs->iterate_dir, and
> > the nest
> > iterate_dir happened on the same file system, so the warning came out.
> >
> > We'd better make the lower and upper in different fs instance, and this
> > warning
> > will disappear.
> >
> > And this lockdep warning happened when the nest iterate_dir call of same
> > fs(I
> > mean the same super block). The function check_deadlock in lockdep.c will
> > report the nest lock of same process. If we make the 2_upper and 2_work in
> > a different fs, no warning comes out.
> 
> Yep, it's not a deadlock. As I mentioned lockdep classes are per-fs-type so
> lockdep cannot see difference between i_mutexes on different sb of the
> same type.
> But anyway this looks messy.
>
 
yes, you are right. The i_mutex_class is file_system_tye scale. I was puzzled by
the debug_locks mechanism during my quick tests. The nest iterate_dir is overlay
dir, neither upper nor lower.

> Probably it's safer to forbid overlayfs as lower or upper mount for overlayfs
> because this have no sense. Nesting anyway is limited by the depth of kernel
> stack and sb->s_stack_depth.
> 
> Or overlayfs could detect this situation and substitute layers of underlying
> overlayfs into its own lower layers in appropriate place.
> 

Can we add the lockdep_off/lockdep_on in this situation? For we know this is
just the false positive reporting of lockdep.


Thanks,

Xu Wang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web