From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA31AC1B08C for ; Thu, 15 Jul 2021 14:05:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A988861374 for ; Thu, 15 Jul 2021 14:05:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238348AbhGOOIe (ORCPT ); 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.