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@xxxxxxxxxxxxxxxxxx> 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@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@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@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 -- 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
