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


Groups > linux.kernel > #1500672

Re: [RFC][PATCH] mount: In mark_umount_candidates and __propogate_umount visit each mount once

From Andrey Vagin <avagin@openvz.org>
Newsgroups linux.kernel
Subject Re: [RFC][PATCH] mount: In mark_umount_candidates and __propogate_umount visit each mount once
Date 2016-10-14 04:40 +0200
Message-ID <ss0zD-3FR-5@gated-at.bofh.it> (permalink)
References <sqSb7-7sX-9@gated-at.bofh.it> <srRPH-6uS-7@gated-at.bofh.it> <srW30-AS-7@gated-at.bofh.it> <ss0zD-3FR-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Oct 13, 2016 at 2:46 PM, Andrei Vagin <avagin@virtuozzo.com> wrote:
> On Thu, Oct 13, 2016 at 02:53:46PM -0500, Eric W. Biederman wrote:
>>
>> Adrei Vagin pointed out that time to executue propagate_umount can go
>> non-linear (and take a ludicrious amount of time) when the mount
>> propogation trees of the mounts to be unmunted by a lazy unmount
>> overlap.
>>
>> Solve this in the most straight forward way possible, by adding a new
>> mount flag to mark parts of the mount propagation tree that have been
>> visited, and use that mark to skip parts of the mount propagation tree
>> that have already been visited during an unmount.  This guarantees
>> that each mountpoint in the possibly overlapping mount propagation
>> trees will be visited exactly once.
>>
>> Add the functions propagation_visit_next and propagation_revisit_next
>> to coordinate setting and clearling the visited mount mark.
>>
>> Here is a script to generate such mount tree:
>> $ cat run.sh
>> mount -t tmpfs test-mount /mnt
>> mount --make-shared /mnt
>> for i in `seq $1`; do
>>         mkdir /mnt/test.$i
>>         mount --bind /mnt /mnt/test.$i
>> done
>> cat /proc/mounts | grep test-mount | wc -l
>> time umount -l /mnt
>> $ for i in `seq 10 16`; do echo $i; unshare -Urm bash ./run.sh $i; done
>>
>> Here are the performance numbers with and without the patch:
>>
>> mounts | before | after (real sec)
>> -----------------------------
>>   1024 |  0.071 | 0.024
>>   2048 |  0.184 | 0.030
>>   4096 |  0.604 | 0.040
>>   8912 |  4.471 | 0.043
>>  16384 | 34.826 | 0.082
>>  32768 |        | 0.151
>>  65536 |        | 0.289
>> 131072 |        | 0.659
>>
>> Andrei Vagin fixing this performance problem is part of the
>> work to fix CVE-2016-6213.
>>
>> Cc: stable@vger.kernel.org
>> Reported-by: Andrei Vagin <avagin@openvz.org>
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>> ---
>>
>> Andrei can you take a look at this patch and see if you can see any
>> problems.  My limited testing suggests this approach does a much better
>> job of solving the problem you were seeing.  With the time looking
>> almost linear in the number of mounts now.
>
> I read this patch and I like the idea.
>
> Then I run my tests and one of them doesn't work with this patch.
> I haven't found a reason yet.

>> +     for (m = propagation_visit_next(parent, parent); m;
>> +                     m = propagation_visit_next(m, parent)) {
>>               struct mount *child = __lookup_mnt_last(&m->mnt,
>>                                               mnt->mnt_mountpoint);

The reason is that this loop is called for different "mnt", but
it is executed only once with this optimization.

So I think the idea to mark parent will not work, because one parent
can have a few children which have to be umounted.

>
> Here is the test:
>
> [root@fc24 mounts]# cat run.sh
> set -e
> mount -t tmpfs zdtm /mnt
> mkdir -p /mnt/1 /mnt/2
> mount -t tmpfs zdtm /mnt/1
> mount --make-shared /mnt/1
> for i in `seq $1`; do
>         mount --bind /mnt/1 `mktemp -d /mnt/1/test.XXXXXX`
> done
> mount --rbind /mnt/1 /mnt/2
> cat /proc/self/mountinfo | grep zdtm | wc -l
> time umount -l /mnt/1
> cat /proc/self/mountinfo | grep zdtm | wc -l
> umount /mnt/2
>
>
> [root@fc24 mounts]# unshare -Urm ./run.sh  5
> 65
>
> real    0m0.014s
> user    0m0.000s
> sys     0m0.004s
> 33
> umount: /mnt/2: target is busy
>         (In some cases useful info about processes that
>          use the device is found by lsof(8) or fuser(1).)
>
>>

Thanks,
Andrei

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH] [v3] mount: dont execute propagate_umount() many times for same mounts ebiederm@xmission.com (Eric W. Biederman) - 2016-10-13 19:20 +0200
  [RFC][PATCH] mount: In mark_umount_candidates and __propogate_umount visit each mount once ebiederm@xmission.com (Eric W. Biederman) - 2016-10-13 23:50 +0200
    Re: [RFC][PATCH] mount: In mark_umount_candidates and  __propogate_umount visit each mount once Andrey Vagin <avagin@openvz.org> - 2016-10-14 04:40 +0200
      Re: [RFC][PATCH] mount: In mark_umount_candidates and __propogate_umount visit each mount once ebiederm@xmission.com (Eric W. Biederman) - 2016-10-14 04:50 +0200
        [RFC][PATCH v2] mount: In mark_umount_candidates and __propogate_umount visit each mount once ebiederm@xmission.com (Eric W. Biederman) - 2016-10-14 20:40 +0200
          Re: [RFC][PATCH v2] mount: In mark_umount_candidates and __propogate_umount visit each mount once ebiederm@xmission.com (Eric W. Biederman) - 2016-10-18 09:00 +0200
            [REVIEW][PATCH] mount: In propagate_umount handle overlapping mount propagation trees ebiederm@xmission.com (Eric W. Biederman) - 2016-10-19 05:50 +0200
              Re: [REVIEW][PATCH] mount: In propagate_umount handle overlapping mount propagation trees ebiederm@xmission.com (Eric W. Biederman) - 2016-10-21 21:30 +0200
                [RFC][PATCH v2] mount: In propagate_umount handle overlapping mount propagation trees ebiederm@xmission.com (Eric W. Biederman) - 2016-10-22 21:50 +0200
                Re: [RFC][PATCH v2] mount: In propagate_umount handle overlapping mount propagation trees ebiederm@xmission.com (Eric W. Biederman) - 2016-10-25 23:50 +0200
                Re: [RFC][PATCH v2] mount: In propagate_umount handle overlapping mount propagation trees ebiederm@xmission.com (Eric W. Biederman) - 2016-10-26 03:50 +0200

csiph-web