Re: [LTP] [PATCH 1/2 v2] containers: added mountns/mountns03.c

[Jan Stancek <jstancek@redhat.com>]

----- Original Message -----
> From: "Jiri Jaburek" <jjaburek@redhat.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: "Matus Marhefka" <mmarhefk@redhat.com>, ltp-list@lists.sourceforge.net
> Sent: Friday, 12 September, 2014 3:41:25 PM
> Subject: Re: [LTP] [PATCH 1/2 v2] containers: added mountns/mountns03.c
> 
> On 09/12/2014 02:59 PM, Jan Stancek wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Jiri Jaburek" <jjaburek@redhat.com>
> >> To: "Matus Marhefka" <mmarhefk@redhat.com>
> >> Cc: ltp-list@lists.sourceforge.net, "Jan Stancek" <jstancek@redhat.com>
> >> Sent: Thursday, 11 September, 2014 5:09:46 PM
> >> Subject: Re: [LTP] [PATCH 1/2 v2] containers: added mountns/mountns03.c
> > 
> >>>> +++ b/testcases/kernel/containers/mountns/mountns03.c
> >>>> @@ -0,0 +1,245 @@
> >>>> +/* Copyright (c) 2014 Red Hat, Inc.
> >>>> + *
> >>>> + * This program is free software: you can redistribute it and/or modify
> >>>> + * it under the terms of version 2 the GNU General Public License as
> >>>> + * published by the Free Software Foundation.
> >>>> + *
> >>>> + * This program is distributed in the hope that it will be useful,
> >>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >>>> + * GNU General Public License for more details.
> >>>> + *
> >>>> + * You should have received a copy of the GNU General Public License
> >>>> + * along with this program.  If not, see
> >>>> <http://www.gnu.org/licenses/>.
> >>>> +
> >>>> ***********************************************************************
> >>>> + * File: mountns03.c
> >>>> + *
> >>>> + * Tests a slave mount: slave mount is like a shared mount except that
> >>>> + * mount and umount events only propagate towards it.
> >>>> + * Description:
> >>>> + * 1. Creates directories "A", "B", "C", "D" and files "A/A", "B/B"
> >>>> + *    "C/C", "D/D"
> >>>> + * 2. Unshares mount namespace and makes it private (so mounts/umounts
> >>>> + *    have no effect on a real system)
> >>>
> >>> Hi,
> >>>
> >>>> + * 3. Bind mounts directory "A" to "A" and "B" to "B"
> >>>
> >>> is the "B" to "B" part necessary in this case? First thing child does is
> >>> it mounts A to B.
> >>>
> >>>> + * 4. Makes both directories ("A" and "B") shared
> >>>
> >>> related to above, is it necessary to make B shared?
> >>
> >> The obvious answer would be "yes", because ...
> > 
> > (atm. replying to this part only)
> > 
> > If you don't make B shared in parent, doesn't a bind operation in child
> > make
> > it shared regardless? You are bind mounting a shared mount to non-shared
> > one.
> 
> No, not really. Consider the following situation:
> 
>     parent  |  child
> ------------+-----------
> A (shared)  | A (shared)
> B (private) | B (shared)
> 
> (that is, you unshare a mount namespace from the parent and do
> MS_SHARED on B in the child)
> 
> The "sharedness" of B isn't propagated to the parent...

I was not implying it is. My point was that after bind in child,
mount "B" receives and forwards event propagations with mount "A" in parent.

> 
> The rule of thumb is that a private mountpoint cannot be affected by
> other (mount) namespaces. In this case, if the child were to spawn its
> own child, it would share B with it, but the original parent would still
> have its own B.
> 
> IOW bind mounting A to B in the child in the situation illustrated above
> would not affect the parent.
> 
> > 
> >    ---------------------------------------------------------------------------
> >    |         BIND MOUNT OPERATION
> >    |         |
> >    |**************************************************************************
> >    |source(A)->| shared       |       private  |       slave    |
> >    |unbindable |
> >    | dest(B)  |               |                |                |
> >    | |
> >    |   |      |               |                |                |            |
> >    |   v      |               |                |                |
> >    |   |
> >    |**************************************************************************
> >    |  shared  | shared        |     shared     | shared & slave |  invalid
> >    |  |
> >    |          |               |                |                |            |
> >    |non-shared| shared        |      private   |      slave     |  invalid
> >    ||
> >    ***************************************************************************
> 
> True, the mountpoint in the child is changed from private to shared,
> but such operation doesn't affect the private mountpoint of the parent.

I agree - I don't think we care what happens with "B" in parent, when test
is about "A".

> 
> > I modified the mountns03 testcase, so it doesn't bind and make B shared,
> > consider following strace output:
> > 
> > unshare(CLONE_NEWNS)                    = 0
> > mount("none", "/", "none", MS_REC|MS_PRIVATE, NULL) = 0
> > mount("A", "A", 0x407ab0, MS_BIND, NULL) = 0  --> bind mounts directory "A"
> > to "A"
> > mount("none", "A", "none", MS_SHARED, NULL) = 0  --> make "A" shared
> > access("A/C", F_OK)                     = -1 ENOENT (No such file or
> > directory)  --> there's no C file in "A"
> > clone(child_stack=0x2597030, flags=CLONE_NEWNS|SIGCHLD) = 2396
> > read(3, Process 2396 attached
> >  <unfinished ...>
> > [pid  2396] getpid()                    = 2396
> > [pid  2396] mount("A", "B", 0x407ab0, MS_BIND, NULL) = 0  --> bind shared
> > mount "A" to "B"
> 
> ... making B the same as A, so anything on B done directly on A.
> 
> > [pid  2396] mount("C", "B", 0x407ab0, MS_BIND, NULL) = 0  --> bind mount
> > "C" to "B"
> 
> ... which is essentially bind mount C to A.
> 
> > [pid  2396] write(4, "0", 1 <unfinished ...>
> > [pid  2394] <... read resumed> "0", 1)  = 1
> > [pid  2394] access("A/C", F_OK)         = 0  --> parent can see file "C" in
> > "A"
> 
> Indeed, but only because A was shared by the parent. This means the
> child can affect it in any way (bind mount any number of additional
> mountpoints to it, umount it, etc.). If you bind-mounted B to B and
> made it private, it would retain its B/B file.
> 
> The test works likely due to reasons I mentioned before,
> 
> On 09/11/2014 05:09 PM, Jiri Jaburek wrote:
> > This raises a question
> > - why do you need B at all? Why not do MS_SLAVE on A? In this sense,
> > B (child) is not a slave of B (parent), but a slave of A (parent), with
> > B (parent) being slave of A (parent) due to the shared propagation.
> 
> Meaning that B could be entirely omitted, because it's not used for
> anything in the parent, therefore it doesn't matter whether you
> bind-mount it or not. Meaning, in essence, that you were originally
> correct. :)
> 
> I would like to help Matus with this test case when he gets back to it.

Looking at the discussion this triggered, the more simple we can make it, the better :-)

Regards,
Jan

> 
> 
> I'm personally not a namespace kernel developer, so I may be wrong,
> but my testing using multiple shells + mount(8) seems to confirm my
> theories.
> 
> Jiri
> 
> 

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list