mm/damon/sysfs: kobject_del() directories that users can create/remove
Status from this message: [merged mm-stable] mm-damon-sysfs-schemes-kobject_del-region-for-populate_region-error.patch removed from -mm tree
Get series with b4
b4 am [email protected]Versions newest first
Changes from RFC v1 from the cover letter
- RFC v1: https://lore.kernel.org/[email protected]
- Add error path fixes.
Patches in v1 All 11 applied
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 00/11] mm/damon/sysfs: kobject_del() directories that users can create/remove
DAMON sysfs interface allows users to create and remove arbitrary number of directories on sysfs, using a few files having 'nr_' prefix. For example, 'nr_kdamonds'. When the user writes a number 'N' to the files, directories having name starting from '0' to 'N - 1' are created in the same directory. The pre-existing number-named directories are removed before creating the new directories.
For the removal of the existing directories, DAMON sysfs interface use only kobject_put(). Because DAMON sysfs interface is the only kernel component that manages the directories, there is no problem in normal situations. However, if CONFIG_DEBUG_KOBJECT_RELEASE is enabled, the removal of dirs are delayed. Let's suppose a user writes a non-zero number to the 'nr_*' files while there are pre-existing number-named directories, on the config enabled kernel. DAMON sysfs interface decreases the reference counts of the existing directories and immediately creates new directories. Because the removal of the sysfs directories is delayed, it shows some pre-existing directories of the same names when it tries to create the new directories, and fails.
For example, the issue can be triggered like below:
# grep DEBUG_KOBJECT_RELEASE /boot/config-$(uname -r)
CONFIG_DEBUG_KOBJECT_RELEASE=y
# ls
nr_kdamonds
# echo 1 > nr_kdamonds
# echo 1 > nr_kdamonds
bash: echo: write error: File exists
# dmesg
[...]
[ 300.880458] kobject: kobject_add_internal failed for 0 with -EEXIST, don't try to register things with the same name in the same directory.
[...]Some of the error handling paths of the directories also lack the kobject_del() call. If the user uses nr_* file right after the errors, similar issues can happen.
This doesn't cause catastrophic issues like kernel panics or memory corruptions. Users can work around by removing all directories first (write 0 to the nr_* files) and then create new directories after confirming the old directories are gone. But, this is definitely a bug that causes a bad user experience.
Fix the issues by calling kobject_del() before creating new directories.
Patches Sequence
================
There are a number of bugs of this class that are introduced by eleven different commits. The fixes are grouped and ordered for the introducing commits.
Changes from RFC v1.2
- RFC v1.2: https://lore.kernel.org/[email protected]
- Drop RFC tag.
- Rebase to latest mm-new.
Changes from RFC v1.1
- RFC v1.1: https://lore.kernel.org/[email protected]
- Add error path fix for damon_sysfs_schemes_add_dirs().
- Rebase to latest mm-new.
Changes from RFC v1
- RFC v1: https://lore.kernel.org/[email protected]
- Add error path fixes.
SJ Park (11):
mm/damon/sysfs: kobject_del() target (normal), context and kdamond
dirs
mm/damon/sysfs: kobject_del() region and target (error) dirs mm/damon/sysfs-schemes: kobject_del() scheme dirs mm/damon/sysfs-schemes: kobject_del() scheme region dirs mm/damon/sysfs-schemes: kobject_del() scheme filter dirs mm/damon/sysfs-schemes: kobject_del() scheme quota goal dirs mm/damon/sysfs-schemes: kobject_del() scheme action destination dirs mm/damon/sysfs: kobject_del() probe dirs
mm/damon/sysfs: kobject_del() probe filter dirs mm/damon/sysfs: kobject_del() probe dirs in probes_addd_dir error path mm/damon/sysfs-schemes: kobject_del() region for populate_region error
mm/damon/sysfs-schemes.c | 22 +++++++++++++++++----- mm/damon/sysfs.c | 25 ++++++++++++++++++++----- 2 files changed, 37 insertions(+), 10 deletions(-)
base-commit: d1f5e472273baa030bf7a4b6063aa67053e4287d
Signature · 1 line
2.47.3