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-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Vinicius Costa Gomes <vinicius.gomes@intel.com>
Subject: [PATCH v2 00/16] overlayfs: Optimize override/revert creds
Date: Wed, 21 Aug 2024 18:25:07 -0700 [thread overview]
Message-ID: <20240822012523.141846-1-vinicius.gomes@intel.com> (raw)
Hi,
Changes from v1:
- Re-organized the series to be easier to follow, more details below
(Miklos Szeredi and Amir Goldstein);
The series now reads as follows:
Patch 1: Introduce the _light() version of the override/revert cred operations;
Patch 2: Convert backing-file.c to use those;
Patch 3: Introduce the overlayfs specific _light() helper;
Patch 4: Document the cases that the helper cannot be used (critical
section may change the cred->usage counter);
Patch 5: Convert the "rest" of overlayfs to the _light() helpers (mostly mechanical);
Patch 6: Introduce the GUARD() helpers;
Patch 7: Convert backing-file.c to the GUARD() helpers;
Patch 8-15: Convert each overlayfs/ file to use the GUARD() helpers,
also explain the cases in which the scoped_guard() helper is
used. Note that a 'goto' jump that crosses the guard() should
fail to compile, gcc has a bug that fails to detect the
error[1].
Patch 16: Remove the helper introduced in Patch 3 to close the series,
as it is no longer used, everything was converted to use the
safer/shorter GUARD() helpers.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91951
This bug was also noticed here:
https://lore.kernel.org/all/20240730050927.GC5334@ZenIV/
Link to v1:
https://lore.kernel.org/r/20240403021808.309900-1-vinicius.gomes@intel.com/
Changes from RFC v3:
- Removed the warning "fixes" patches, as they could hide potencial
bugs (Christian Brauner);
- Added "cred-specific" macros (Christian Brauner), from my side,
added a few '_' to the guards to signify that the newly introduced
helper macros are preferred.
- Changed a few guard() to scoped_guard() to fix the clang (17.0.6)
compilation error about 'goto' bypassing variable initialization;
Link to RFC v3:
https://lore.kernel.org/r/20240216051640.197378-1-vinicius.gomes@intel.com/
Changes from RFC v2:
- Added separate patches for the warnings for the discarded const
when using the cleanup macros: one for DEFINE_GUARD() and one for
DEFINE_LOCK_GUARD_1() (I am uncertain if it's better to squash them
together);
- Reordered the series so the backing file patch is the first user of
the introduced helpers (Amir Goldstein);
- Change the definition of the cleanup "class" from a GUARD to a
LOCK_GUARD_1, which defines an implicit container, that allows us
to remove some variable declarations to store the overriden
credentials (Amir Goldstein);
- Replaced most of the uses of scoped_guard() with guard(), to reduce
the code churn, the remaining ones I wasn't sure if I was changing
the behavior: either they were nested (overrides "inside"
overrides) or something calls current_cred() (Amir Goldstein).
New questions:
- The backing file callbacks are now called with the "light"
overriden credentials, so they are kind of restricted in what they
can do with their credentials, is this acceptable in general?
- in ovl_rename() I had to manually call the "light" the overrides,
both using the guard() macro or using the non-light version causes
the workload to crash the kernel. I still have to investigate why
this is happening. Hints are appreciated.
Link to the RFC v2:
https://lore.kernel.org/r/20240125235723.39507-1-vinicius.gomes@intel.com/
Original cover letter (lightly edited):
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/5 and 2/5 are 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 (16):
cred: Add a light version of override/revert_creds()
fs/backing-file: Convert to revert/override_creds_light()
fs/overlayfs: Introduce ovl_override_creds_light()
overlayfs: Document critical override_creds() operations
overlayfs: Use ovl_override_creds_light()/revert_creds_light()
cred: Introduce cred_guard() and cred_scoped_guard() helpers
fs/backing-file: Convert to cred_guard()
overlayfs/copy_up: Convert to cred_guard()
overlayfs/dir: Convert to cred_guard()
overlayfs/file: Convert to cred_guard()
overlayfs/inode: Convert to cred_guard()
overlayfs/namei: Convert to cred_guard()
overlayfs/readdir: Convert to cred_guard()
overlayfs/xattrs: Convert to cred_guard()
overlayfs/util: Convert to cred_guard()
overlayfs: Remove ovl_override_creds_light()
fs/backing-file.c | 22 +++----------
fs/overlayfs/copy_up.c | 10 +++---
fs/overlayfs/dir.c | 20 ++++++------
fs/overlayfs/file.c | 64 +++++++++++++++---------------------
fs/overlayfs/inode.c | 73 ++++++++++++++++--------------------------
fs/overlayfs/namei.c | 20 +++---------
fs/overlayfs/readdir.c | 16 +++------
fs/overlayfs/util.c | 24 ++++++--------
fs/overlayfs/xattrs.c | 32 ++++++++----------
include/linux/cred.h | 25 +++++++++++++++
kernel/cred.c | 6 ++--
11 files changed, 134 insertions(+), 178 deletions(-)
--
2.46.0
next reply other threads:[~2024-08-22 1:25 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-22 1:25 Vinicius Costa Gomes [this message]
2024-08-22 1:25 ` [PATCH v2 01/16] cred: Add a light version of override/revert_creds() Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 02/16] fs/backing-file: Convert to revert/override_creds_light() Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 03/16] fs/overlayfs: Introduce ovl_override_creds_light() Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 04/16] overlayfs: Document critical override_creds() operations Vinicius Costa Gomes
2024-08-22 8:14 ` Miklos Szeredi
2024-08-26 22:48 ` Vinicius Costa Gomes
2024-09-24 21:13 ` Vinicius Costa Gomes
2024-09-25 9:57 ` Christian Brauner
2024-09-25 14:17 ` Vinicius Costa Gomes
2024-10-07 11:12 ` Amir Goldstein
2024-10-07 16:13 ` Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 05/16] overlayfs: Use ovl_override_creds_light()/revert_creds_light() Vinicius Costa Gomes
2024-08-22 8:26 ` Miklos Szeredi
2024-08-26 22:57 ` Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 06/16] cred: Introduce cred_guard() and cred_scoped_guard() helpers Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 07/16] fs/backing-file: Convert to cred_guard() Vinicius Costa Gomes
2024-08-22 8:31 ` Miklos Szeredi
2024-08-26 22:58 ` Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 08/16] overlayfs/copy_up: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 09/16] overlayfs/dir: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 10/16] overlayfs/file: " Vinicius Costa Gomes
2024-08-22 8:41 ` Miklos Szeredi
2024-08-26 23:12 ` Vinicius Costa Gomes
2024-08-22 11:06 ` Amir Goldstein
2024-08-26 23:18 ` Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 11/16] overlayfs/inode: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 12/16] overlayfs/namei: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 13/16] overlayfs/readdir: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 14/16] overlayfs/xattrs: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 15/16] overlayfs/util: " Vinicius Costa Gomes
2024-08-22 1:25 ` [PATCH v2 16/16] overlayfs: Remove ovl_override_creds_light() Vinicius Costa Gomes
2024-08-22 8:59 ` Miklos Szeredi
2024-08-26 23:21 ` Vinicius Costa Gomes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240822012523.141846-1-vinicius.gomes@intel.com \
--to=vinicius.gomes@intel.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=hu1.chen@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=lizhen.you@intel.com \
--cc=malini.bhandaru@intel.com \
--cc=mikko.ylinen@intel.com \
--cc=miklos@szeredi.hu \
--cc=tim.c.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®