Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp520661pxv; Thu, 15 Jul 2021 09:21:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynr5nsPjPB8yebmg5eng/9pQwaSPKCtj3unVuSTyIE9JOldgs+rQMIU73sGijRMif0KLAB X-Received: by 2002:a92:8750:: with SMTP id d16mr3235041ilm.281.1626366073408; Thu, 15 Jul 2021 09:21:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626366073; cv=none; d=google.com; s=arc-20160816; b=G2/ax0zl5KnjQEgA0OsoJi2aQg9EE8wdz37pdFdgQ2haVPu0Cbz9FCo8yxovX7ISB/ tVuTIoPjgl8NoFVbfZWA3BGolLgul1450iCinkbCzPrRb7i9GVuLars9Il91Tj1UBPm0 yIUOuDDHm+Xm5ot6mryCXSGkYnFJehB/C5/5An40i5Z3Jr845ePTQvciKFxRriYFBM+F IgPXZn1/o4XbSE7Qq17yqCHhzdlYJb+t25fE9ulvloXKDuZkEpv8s9V5S4eCBh9XWtIc vjHFCBpWLoWmz8K0SH1wIqlftHQljw/9X5hIWa+SjXLy6mPL9tgkXZTfVqnkGVWHGKqo NvgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=wbruUvdNuIXUxOT6hmEiMmvzFTOGHR4h1kVMmBcbl7g=; b=vXhquM1WAAndfURrWNY8xZ0fSJTxPYLgEhvHH3NrcotbV+cOpUNX9v71ilCZcPPu9D SH1HA1OZSOU31xjfIGoaFes6exAGrsQWT978Gv1PgRp1eRqTJyBb1FeNzjBFWEbILbJo jowie/QEDWI1v79ZtHrB4JwzLHyvfkBIr4snthCdk66oZfi3mzk2Xi3muSDZrPWB0+ly c7y6ByWOdh/Q1RyoaCbTcCLwzrIz9ZETdsJ3ynGtq7rBdFCITRt5i+mK5DMW0Z1Lf5vN iDrVXcxpg4L5L3qLN3CnmhBWwNoF43eTtTzAfGdGlBnhVsvYdiIoKEdV+Mpu1ehZhgmz Ow4Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w21si7737937jah.86.2021.07.15.09.21.00; Thu, 15 Jul 2021 09:21:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238341AbhGOOIe (ORCPT + 99 others); Thu, 15 Jul 2021 10:08:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:57764 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232011AbhGOOIe (ORCPT ); Thu, 15 Jul 2021 10:08:34 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 446246127C; Thu, 15 Jul 2021 14:05:38 +0000 (UTC) Date: Thu, 15 Jul 2021 16:05:35 +0200 From: Christian Brauner To: Pavel Tikhomirov Cc: linux-fsdevel@vger.kernel.org, "Eric W . Biederman" , Alexander Viro , Mattias Nissler , Aleksa Sarai , Andrei Vagin , linux-api@vger.kernel.org, lkml Subject: Re: [PATCH v5 1/2] move_mount: allow to add a mount into an existing group Message-ID: <20210715140535.eypw5ekwd53kcbab@wittgenstein> References: <20210715100714.120228-1-ptikhomirov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210715100714.120228-1-ptikhomirov@virtuozzo.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 15, 2021 at 01:07:13PM +0300, Pavel Tikhomirov wrote: > Previously a sharing group (shared and master ids pair) can be only > inherited when mount is created via bindmount. This patch adds an > ability to add an existing private mount into an existing sharing group. > > With this functionality one can first create the desired mount tree from > only private mounts (without the need to care about undesired mount > propagation or mount creation order implied by sharing group > dependencies), and next then setup any desired mount sharing between > those mounts in tree as needed. > > This allows CRIU to restore any set of mount namespaces, mount trees and > sharing group trees for a container. > > We have many issues with restoring mounts in CRIU related to sharing > groups and propagation: > - reverse sharing groups vs mount tree order requires complex mounts > reordering which mostly implies also using some temporary mounts > (please see https://lkml.org/lkml/2021/3/23/569 for more info) > > - mount() syscall creates tons of mounts due to propagation > - mount re-parenting due to propagation > - "Mount Trap" due to propagation > - "Non Uniform" propagation, meaning that with different tricks with > mount order and temporary children-"lock" mounts one can create mount > trees which can't be restored without those tricks > (see https://www.linuxplumbersconf.org/event/7/contributions/640/) > > With this new functionality we can resolve all the problems with > propagation at once. > > Link: https://lore.kernel.org/r/20210715100714.120228-1-ptikhomirov@virtuozzo.com > Cc: Eric W. Biederman > Cc: Alexander Viro > Cc: Christian Brauner > Cc: Mattias Nissler > Cc: Aleksa Sarai > Cc: Andrei Vagin > Cc: linux-fsdevel@vger.kernel.org > Cc: linux-api@vger.kernel.org > Cc: lkml > Signed-off-by: Pavel Tikhomirov > --- Looks good, Acked-by: Christian Brauner I also took a look at mount-v2 for CRIU you linked below. Looks like clean approach. I'll compile and run the selftests now.