Message ID | 20240125235723.39507-1-vinicius.gomes@intel.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-39429-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:e09d:b0:103:945f:af90 with SMTP id gm29csp338518dyb; Thu, 25 Jan 2024 15:59:29 -0800 (PST) X-Google-Smtp-Source: AGHT+IG2CAhVucNrh8M+/uHlTmI60xvfQpKx2loPoScs30SKmFPH8N8WnHLLzHismkg6QvD/8cne X-Received: by 2002:a05:620a:4513:b0:783:e81:d616 with SMTP id t19-20020a05620a451300b007830e81d616mr629420qkp.132.1706227169743; Thu, 25 Jan 2024 15:59:29 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706227169; cv=pass; d=google.com; s=arc-20160816; b=OAnBSeolkqkD/kkFQp6cOhcYnNMxwlaAWijP/sxNAuBbSfJGyBCbqyh9nahc1bjAe4 93wZpqgK6vuwMseyw/fy17JBvFpJVhETGYik9yrtvzwm4pVQaJghDZsCg0zgCzwthwfu 7BTP9zBrnJjybEz+5NNYxJAnXp5gTiLbbJYoHRXFO5PKuQUwNRk/2UluZr3cXi/OTsg1 YiELagGhBr8DURrMgo28W33e7X1qudlDnBBRPbh+f/qGZB2vEGWRkHjY0urFRHC4qYUz /NCjJF8ddNqJrsVCFovm2r0NP97ZSOcFq7cF1i9UJGHiYbe7GCZn3nSB0ZcpI+5EnGXR BwCQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=9/WFK8fQFauwgXhLWMpNffplRpetKmDRjS4WORwUWFg=; fh=0u4WKmQXLbfFx7dTPMZn/CP58jbWkEI+fyqm6Dolj/A=; b=C3YF+SFrN7fKxxxv6Kqr9jD1lD7kODbeNTseUqlGaur49kPZFk33yF3AOhuMcMvOBE BhqJqHjjGsv0H9+7lbdFGjfpOL2pOE7d2uQJ//Qq3ChAkOYeRByFDFY331aFYGO9AHQL Sj0j+Xw29LLlo7LcFvKtVBG3XOWeR+jukyLSwMScXEjv5Ion2o9Fd3e0DG5tlJAc6oe0 m6EYLYvxhefDyKmG//n3J+FsPPAxxSXBNBnVQZZkfKwAPjCHZDWope0NIi41NPveDNlh gavaOswAlkQDcQAv/k0F9mvscuh+/sSnM2/kn4QwsrWiphBqxB/2rkR7VuDqDHZjJPHx 4z9g== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=KM6zBS97; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-39429-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-39429-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id s16-20020a05620a031000b007811c62b6f4si64605qkm.727.2024.01.25.15.59.29 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jan 2024 15:59:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-39429-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=KM6zBS97; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-39429-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-39429-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 873521C247C3 for <ouuuleilei@gmail.com>; Thu, 25 Jan 2024 23:59:29 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 03E801D692; Thu, 25 Jan 2024 23:57:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="KM6zBS97" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90EF218EA1; Thu, 25 Jan 2024 23:57:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706227057; cv=none; b=R/XM9D6j12Ij3WWtrcvaWOGMr/Xb56OIlz1nEFGZWfKDuzKeg/Xlj1a/g9HwLkwSB+d40oKNbt0rmUwFo8dQMvCTo4O77yD7ewzDa9rVplpuLBXuTfurOyGY5KrQM90E60dsHmYw/sko+L2CohZpiPdSFRRtCXT5PStaqPTVsrs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706227057; c=relaxed/simple; bh=3uFlompF9soIL+QzuHer4RVOjpFnG41ZrxgVyatxx8I=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=O+vpE8ilzi/M+7qJ8mUjH2jE9MnVpvmPALXGh04OW1m+mMzAkj3oqWxT0Gvy62wYdJ6UbjpkLPaXzGo255Gk++3l6fea8ie9me53V8wy5PADFRPE4gXS9JwoK93ajMnwCpIT4FhClUccv9pFAIq6HPUwip5fr2xpPsevtMOuYEA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=KM6zBS97; arc=none smtp.client-ip=192.198.163.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706227056; x=1737763056; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=3uFlompF9soIL+QzuHer4RVOjpFnG41ZrxgVyatxx8I=; b=KM6zBS977o27qcXCShMYAJlvcMarJx/DOFiaMuh2R85okz5H66PHZuH3 SXkp3p6ORLEwIbpEm73AklHagXcGMvyUDMs8BmOzPJ6PaDKIw/8V6FmzC kSFohTJBYqI2jtFr4oyFxAZkij5JgrvhbSYSBV+ZjHWq//xp96rqmAKaU 4wO4A6AC+SJCWo112bK48R5Lg22XsUnRJYvTnSvwQ4C+2WbY47/X2Gfwp Rs/nMxp2rMS+nGRdNnt4DoiP/JObf4/K9wnbW/LOt5n0M7Jeovu358J0k wHKkTeWbKS3pfdOaNlJLURdRfbY7iw+VRne24k4OA//+hz2uO8OusRUV7 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10964"; a="15867558" X-IronPort-AV: E=Sophos;i="6.05,216,1701158400"; d="scan'208";a="15867558" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jan 2024 15:57:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10964"; a="930191095" X-IronPort-AV: E=Sophos;i="6.05,216,1701158400"; d="scan'208";a="930191095" Received: from vcostago-mobl3.jf.intel.com ([10.24.14.99]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jan 2024 15:57:34 -0800 From: Vinicius Costa Gomes <vinicius.gomes@intel.com> To: brauner@kernel.org, amir73il@gmail.com, hu1.chen@intel.com Cc: miklos@szeredi.hu, malini.bhandaru@intel.com, tim.c.chen@intel.com, mikko.ylinen@intel.com, lizhen.you@intel.com, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org, Vinicius Costa Gomes <vinicius.gomes@intel.com> Subject: [RFC v2 0/4] overlayfs: Optimize override/revert creds Date: Thu, 25 Jan 2024 15:57:19 -0800 Message-ID: <20240125235723.39507-1-vinicius.gomes@intel.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789108860658567512 X-GMAIL-MSGID: 1789108860658567512 |
Series |
overlayfs: Optimize override/revert creds
|
|
Message
Vinicius Costa Gomes
Jan. 25, 2024, 11:57 p.m. UTC
Hi, It was noticed that some workloads suffer from contention on increasing/decrementing the ->usage counter in their credentials, those refcount operations are associated with overriding/reverting the current task credentials. (the linked thread adds more context) In some specialized cases, overlayfs is one of them, the credentials in question have a longer lifetime than the override/revert "critical section". In the overlayfs case, the credentials are created when the fs is mounted and destroyed when it's unmounted. In this case of long lived credentials, the usage counter doesn't need to be incremented/decremented. Add a lighter version of credentials override/revert to be used in these specialized cases. To make sure that the override/revert calls are paired, add a cleanup guard macro. This was suggested here: https://lore.kernel.org/all/20231219-marken-pochen-26d888fb9bb9@brauner/ With a small number of tweaks: - Used inline functions instead of macros; - A small change to store the credentials into the passed argument, the guard is now defined as (note the added '_T ='): DEFINE_GUARD(cred, const struct cred *, _T = override_creds_light(_T), revert_creds_light(_T)); - Allow "const" arguments to be used with these kind of guards; Some comments: - If patch 1/4 is not a good idea (adding the cast), the alternative I can see is using some kind of container for the credentials; - The only user for the backing file ops is overlayfs, so these changes make sense, but may not make sense in the most general case; For the numbers, some from 'perf c2c', before this series: (edited to fit) # # ----- HITM ----- Shared # Num RmtHitm LclHitm Symbol Object Source:Line Node # ..... ....... ....... .......................... ................ .................. .... # ------------------------- 0 412 1028 ------------------------- 41.50% 42.22% [k] revert_creds [kernel.vmlinux] atomic64_64.h:39 0 1 15.05% 10.60% [k] override_creds [kernel.vmlinux] atomic64_64.h:25 0 1 0.73% 0.58% [k] init_file [kernel.vmlinux] atomic64_64.h:25 0 1 0.24% 0.10% [k] revert_creds [kernel.vmlinux] cred.h:266 0 1 32.28% 37.16% [k] generic_permission [kernel.vmlinux] mnt_idmapping.h:81 0 1 9.47% 8.75% [k] generic_permission [kernel.vmlinux] mnt_idmapping.h:81 0 1 0.49% 0.58% [k] inode_owner_or_capable [kernel.vmlinux] mnt_idmapping.h:81 0 1 0.24% 0.00% [k] generic_permission [kernel.vmlinux] namei.c:354 0 ------------------------- 1 50 103 ------------------------- 100.00% 100.00% [k] update_cfs_group [kernel.vmlinux] atomic64_64.h:15 0 1 ------------------------- 2 50 98 ------------------------- 96.00% 96.94% [k] update_cfs_group [kernel.vmlinux] atomic64_64.h:15 0 1 2.00% 1.02% [k] update_load_avg [kernel.vmlinux] atomic64_64.h:25 0 1 0.00% 2.04% [k] update_load_avg [kernel.vmlinux] fair.c:4118 0 2.00% 0.00% [k] update_cfs_group [kernel.vmlinux] fair.c:3932 0 1 after this series: # # ----- HITM ----- Shared # Num RmtHitm LclHitm Symbol Object Source:Line Node # ..... ....... ....... .................... ................ ................ .... # ------------------------- 0 54 88 ------------------------- 100.00% 100.00% [k] update_cfs_group [kernel.vmlinux] atomic64_64.h:15 0 1 ------------------------- 1 48 83 ------------------------- 97.92% 97.59% [k] update_cfs_group [kernel.vmlinux] atomic64_64.h:15 0 1 2.08% 1.20% [k] update_load_avg [kernel.vmlinux] atomic64_64.h:25 0 1 0.00% 1.20% [k] update_load_avg [kernel.vmlinux] fair.c:4118 0 1 ------------------------- 2 28 44 ------------------------- 85.71% 79.55% [k] generic_permission [kernel.vmlinux] mnt_idmapping.h:81 0 1 14.29% 20.45% [k] generic_permission [kernel.vmlinux] mnt_idmapping.h:81 0 1 The contention is practically gone. Link: https://lore.kernel.org/all/20231018074553.41333-1-hu1.chen@intel.com/ Vinicius Costa Gomes (4): cleanup: Fix discarded const warning when defining guards cred: Add a light version of override/revert_creds() overlayfs: Optimize credentials usage fs: Optimize credentials reference count for backing file ops fs/backing-file.c | 124 +++++++++++++++++++--------------------- fs/overlayfs/copy_up.c | 4 +- fs/overlayfs/dir.c | 22 +++---- fs/overlayfs/file.c | 70 ++++++++++++----------- fs/overlayfs/inode.c | 60 ++++++++++--------- fs/overlayfs/namei.c | 21 ++++--- fs/overlayfs/readdir.c | 18 +++--- fs/overlayfs/util.c | 23 ++++---- fs/overlayfs/xattrs.c | 34 +++++------ include/linux/cleanup.h | 2 +- include/linux/cred.h | 21 +++++++ kernel/cred.c | 6 +- 12 files changed, 215 insertions(+), 190 deletions(-)
Comments
Hi Amir, Amir Goldstein <amir73il@gmail.com> writes: > cc: fsdevel > > On Fri, Jan 26, 2024 at 1:57 AM Vinicius Costa Gomes > <vinicius.gomes@intel.com> wrote: >> >> Hi, >> > > Hi Vinicius, > > I have some specific comments about the overlayfs patch, > but first I prefer to provide higher level feedback on the series. > >> It was noticed that some workloads suffer from contention on >> increasing/decrementing the ->usage counter in their credentials, >> those refcount operations are associated with overriding/reverting the >> current task credentials. (the linked thread adds more context) >> >> In some specialized cases, overlayfs is one of them, the credentials >> in question have a longer lifetime than the override/revert "critical >> section". In the overlayfs case, the credentials are created when the >> fs is mounted and destroyed when it's unmounted. In this case of long >> lived credentials, the usage counter doesn't need to be >> incremented/decremented. >> >> Add a lighter version of credentials override/revert to be used in >> these specialized cases. To make sure that the override/revert calls >> are paired, add a cleanup guard macro. This was suggested here: >> >> https://lore.kernel.org/all/20231219-marken-pochen-26d888fb9bb9@brauner/ >> >> With a small number of tweaks: >> - Used inline functions instead of macros; >> - A small change to store the credentials into the passed argument, >> the guard is now defined as (note the added '_T ='): >> >> DEFINE_GUARD(cred, const struct cred *, _T = override_creds_light(_T), >> revert_creds_light(_T)); >> >> - Allow "const" arguments to be used with these kind of guards; >> >> Some comments: >> - If patch 1/4 is not a good idea (adding the cast), the alternative >> I can see is using some kind of container for the credentials; >> - The only user for the backing file ops is overlayfs, so these >> changes make sense, but may not make sense in the most general >> case; >> >> For the numbers, some from 'perf c2c', before this series: >> (edited to fit) >> >> # >> # ----- HITM ----- Shared >> # Num RmtHitm LclHitm Symbol Object Source:Line Node >> # ..... ....... ....... .......................... ................ .................. .... >> # >> ------------------------- >> 0 412 1028 >> ------------------------- >> 41.50% 42.22% [k] revert_creds [kernel.vmlinux] atomic64_64.h:39 0 1 >> 15.05% 10.60% [k] override_creds [kernel.vmlinux] atomic64_64.h:25 0 1 >> 0.73% 0.58% [k] init_file [kernel.vmlinux] atomic64_64.h:25 0 1 >> 0.24% 0.10% [k] revert_creds [kernel.vmlinux] cred.h:266 0 1 >> 32.28% 37.16% [k] generic_permission [kernel.vmlinux] mnt_idmapping.h:81 0 1 >> 9.47% 8.75% [k] generic_permission [kernel.vmlinux] mnt_idmapping.h:81 0 1 >> 0.49% 0.58% [k] inode_owner_or_capable [kernel.vmlinux] mnt_idmapping.h:81 0 1 >> 0.24% 0.00% [k] generic_permission [kernel.vmlinux] namei.c:354 0 >> >> ------------------------- >> 1 50 103 >> ------------------------- >> 100.00% 100.00% [k] update_cfs_group [kernel.vmlinux] atomic64_64.h:15 0 1 >> >> ------------------------- >> 2 50 98 >> ------------------------- >> 96.00% 96.94% [k] update_cfs_group [kernel.vmlinux] atomic64_64.h:15 0 1 >> 2.00% 1.02% [k] update_load_avg [kernel.vmlinux] atomic64_64.h:25 0 1 >> 0.00% 2.04% [k] update_load_avg [kernel.vmlinux] fair.c:4118 0 >> 2.00% 0.00% [k] update_cfs_group [kernel.vmlinux] fair.c:3932 0 1 >> >> after this series: >> >> # >> # ----- HITM ----- Shared >> # Num RmtHitm LclHitm Symbol Object Source:Line Node >> # ..... ....... ....... .................... ................ ............... .... >> # >> ------------------------- >> 0 54 88 >> ------------------------- >> 100.00% 100.00% [k] update_cfs_group [kernel.vmlinux] atomic64_64.h:15 0 1 >> >> ------------------------- >> 1 48 83 >> ------------------------- >> 97.92% 97.59% [k] update_cfs_group [kernel.vmlinux] atomic64_64.h:15 0 1 >> 2.08% 1.20% [k] update_load_avg [kernel.vmlinux] atomic64_64.h:25 0 1 >> 0.00% 1.20% [k] update_load_avg [kernel.vmlinux] fairc:4118 0 1 >> >> ------------------------- >> 2 28 44 >> ------------------------- >> 85.71% 79.55% [k] generic_permission [kernel.vmlinux] mnt_idmapping.h:81 0 1 >> 14.29% 20.45% [k] generic_permission [kernel.vmlinux] mnt_idmapping.h:81 0 1 >> >> >> The contention is practically gone. > > That is very impressive. > Can you say which workloads were running during this test? > Specifically, I am wondering how much of the improvement came from > backing_file.c and how much from overlayfs/*.c. > I received the workload packaged from one of our customer teams, it's a docker image to run a wordpress/php/nginx thing, totally not my area and not sure that I can give much more details. The only think that I know is that this workload does *a lot* of faccessat(). Anyway, I did a experiment removing the backing ops patch, got this numbers (edited for clarity): # # ----- HITM ----- ------- Store Refs ------ Shared # Num RmtHitm LclHitm L1 Hit L1 Miss N/A Symbol Object Source:Line Node # ..... ....... ....... ....... ....... ....... ......................... ................. .................. .... # --------------------------------------------------- 0 79 97 0 0 0 --------------------------------------------------- 0.00% 1.03% 0.00% 0.00% 0.00% [k] revert_creds [kernel.kallsyms] atomic64_64.h:39 0 1 1.27% 0.00% 0.00% 0.00% 0.00% [k] init_file [kernel.kallsyms] atomic64_64.h:25 0 1 62.03% 71.13% 0.00% 0.00% 0.00% [k] generic_permission [kernel.kallsyms] mnt_idmapping.h:81 0 1 35.44% 26.80% 0.00% 0.00% 0.00% [k] generic_permission [kernel.kallsyms] mnt_idmapping.h:81 0 1 1.27% 0.00% 0.00% 0.00% 0.00% [k] generic_permission [kernel.kallsyms] mnt_idmapping.h:81 0 0.00% 1.03% 0.00% 0.00% 0.00% [k] generic_permission [kernel.kallsyms] namei.c:354 0 1 --------------------------------------------------- 1 52 103 0 0 0 --------------------------------------------------- 98.08% 98.06% 0.00% 0.00% 0.00% [k] update_cfs_group [kernel.kallsyms] atomic64_64.h:15 0 1 0.00% 1.94% 0.00% 0.00% 0.00% [k] update_load_avg [kernel.kallsyms] atomic64_64.h:25 0 1 1.92% 0.00% 0.00% 0.00% 0.00% [k] update_cfs_group [kernel.kallsyms] fair.c:3932 0 --------------------------------------------------- 2 59 77 0 0 0 --------------------------------------------------- 93.22% 98.70% 0.00% 0.00% 0.00% [k] update_cfs_group [kernel.kallsyms] atomic64_64.h:15 0 1 5.08% 1.30% 0.00% 0.00% 0.00% [k] update_cfs_group [kernel.kallsyms] fair.c:3932 0 1 1.69% 0.00% 0.00% 0.00% 0.00% [k] update_load_avg [kernel.kallsyms] atomic64_64.h:25 0 1 So, the main source of contention is not in the backing file ops (but there is still some). That seems to align with the numbers that Chen Hu provided[1], that most of the contention was in ovl_permission(). [1] https://lore.kernel.org/all/20231018074553.41333-1-hu1.chen@intel.com/ > The reason I am asking is because the overlayfs patch is quite large and can > take more time to review, so I am wondering out loud if we are not > better off this > course of action: > > 1. convert backing_file.c to use new helpers/guards > 2. convert overlayfs to use new helpers/guards > For this particular workload, (2) is more important. But I am open to propose (1) first, no problem at all. Also, if you think that some other way of spliting the series, for example, one patch per function being converted, would be easier/better, I can do that too. > #1 should definitely go in via Christian's tree and should get a wider review > from fsdevel (please CC fsdevel next time) > Of course. Will CC fsdevel. > #2 is contained for overlayfs reviewers. Once the helpers are merged > and used by backing_file helpers, overlayfs can be converted independently. > > #1 and #2 could both be merged in the same merge cycle, or not, it does not > matter. Most likely, #2 will go through Christian's tree as well, but I think we > need to work according to this merge order. > > We can also work on the review in parallel and you may keep the overlayfs > patch in following posts, just wanted us to be on the same page w.r.t to > the process. > > Thanks, > Amir. Cheers,