Possible bug: detached mounts difficult to cleanup

[Krister Johansen]

On Thu, Jan 12, 2017 at 04:37:13PM -0800, Andrei Vagin wrote:
> On Tue, Jan 10, 2017 at 7:07 PM, Krister Johansen
> <kjlx at templeofstupid.com> wrote:
> > On Wed, Jan 11, 2017 at 03:04:22PM +1300, Eric W. Biederman wrote:
> >> Any chance you have a trivial reproducer script?
> >>
> >> From you description I don't quite see the problem.  I know where to
> >> look but if could give a script that reproduces the conditions you
> >> see that would make it easier for me to dig into, and would certainly
> >> would remove ambiguity.   Ideally such a script would be runnable
> >> under unshare -Urm for easy repeated testing.
> >
> > My apologies.  I don't have something that fits into a shell script, but
> > I can walk you through the simplest test case that I used when I was
> > debugging this.
> >
> > Create net a ns:
> >
> >     $ sudo unshare -n bash
> >     # echo $$
> >     2771
> >
> > In another terminal bind mount that ns onto a file:
> >
> >     # mkdir /run/testns
> >     # touch /run/testns/ns1
> >     # mount --bind /proc/2771/ns/net /run/testns/ns1
> >
> > Back in first terminal, create a new ns, pivot root, and umount detach:
> >
> >     # exit
> >     $ unshare -U -m -n --propagation slave --map-root-user bash
> >     # mkdir binddir
> >     # mount --bind binddir binddir
> >     # cp busybox binddir
> >     # mkdir binddir/old_root
> >     # cd binddir
> >     # pivot_root . old_root
> >     # ./busybox umount -l old_root
> 
> Hi,
> 
> But this process still has mappings from "old_root"
> [root at fc24 busybox]# cat /proc/$$/maps
> 5607360f1000-5607361e9000 r-xp 00000000 fd:02 1176793
>   /usr/bin/bash
> 5607363e8000-5607363ec000 r--p 000f7000 fd:02 1176793
>   /usr/bin/bash
> 5607363ec000-5607363f5000 rw-p 000fb000 fd:02 1176793
>   /usr/bin/bash
> ...
> 
> You have to call "exec ./busybox sh" to release all "old_root" mounts.
> And in this case I see that a net namespace is destroyed:
> 
> [root at fc24 busybox]# cat /proc/slabinfo | /bin/grep net_name
> net_namespace          5      8   6784    4    8 : tunables    0    0
>   0 : slabdata      2      2      0
> [root at fc24 busybox]# exec /bin/sh
> / # cat /proc/slabinfo | /bin/grep -- net
> net_namespace          4      8   6784    4    8 : tunables    0    0
>   0 : slabdata      2      2      0

Thanks.  This seems to be the part of the puzzle that I was missing.  I
went back and looked and found that the container pid 1 did have live
memory mappings to files that are mounted on the old_root.  Appreciate
the nudge in the right direction.

-K