|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7 |
|
| #
f7862dfe |
| 12-Jan-2025 |
Al Viro <[email protected]> |
saner replacement for debugfs_rename()
Existing primitive has several problems: 1) calling conventions are clumsy - it returns a dentry reference that is either identical to its second argument or
saner replacement for debugfs_rename()
Existing primitive has several problems: 1) calling conventions are clumsy - it returns a dentry reference that is either identical to its second argument or is an ERR_PTR(-E...); in both cases no refcount changes happen. Inconvenient for users and bug-prone; it would be better to have it return 0 on success and -E... on failure. 2) it allows cross-directory moves; however, no such caller have ever materialized and considering the way debugfs is used, it's unlikely to happen in the future. What's more, any such caller would have fun issues to deal with wrt interplay with recursive removal. It also makes the calling conventions clumsier... 3) tautological rename fails; the callers have no race-free way to deal with that. 4) new name must have been formed by the caller; quite a few callers have it done by sprintf/kasprintf/etc., ending up with considerable boilerplate.
Proposed replacement: int debugfs_change_name(dentry, fmt, ...). All callers convert to that easily, and it's simpler internally.
IMO debugfs_rename() should go; if we ever get a real-world use case for cross-directory moves in debugfs, we can always look into the right way to handle that.
Signed-off-by: Al Viro <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| #
12c92098 |
| 12-Jan-2025 |
Al Viro <[email protected]> |
debugfs: allow to store an additional opaque pointer at file creation
Set by debugfs_create_file_aux(name, mode, parent, data, aux, fops). Plain debugfs_create_file() has it set to NULL. Accessed by
debugfs: allow to store an additional opaque pointer at file creation
Set by debugfs_create_file_aux(name, mode, parent, data, aux, fops). Plain debugfs_create_file() has it set to NULL. Accessed by debugfs_get_aux(file).
Convenience macros for numeric opaque data - debugfs_create_file_aux_num and debugfs_get_aux_num, resp.
Signed-off-by: Al Viro <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| #
95688800 |
| 12-Jan-2025 |
Al Viro <[email protected]> |
debugfs: don't mess with bits in ->d_fsdata
The reason we need that crap is the dual use ->d_fsdata has there - it's both holding a debugfs_fsdata reference after the first debugfs_file_get() (actua
debugfs: don't mess with bits in ->d_fsdata
The reason we need that crap is the dual use ->d_fsdata has there - it's both holding a debugfs_fsdata reference after the first debugfs_file_get() (actually, after the call of proxy ->open()) *and* it serves as a place to stash a reference to real file_operations from object creation to the first open. Oh, and it's triple use, actually - that stashed reference might be to debugfs_short_fops.
Bugger that for a game of solidiers - just put the operations reference into debugfs-private augmentation of inode. And split debugfs_full_file_operations into full and short cases, so that debugfs_get_file() could tell one from another.
Voila - ->d_fsdata holds NULL until the first (successful) debugfs_get_file() and a reference to struct debugfs_fsdata afterwards.
Signed-off-by: Al Viro <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| #
bacaaf83 |
| 12-Jan-2025 |
Al Viro <[email protected]> |
debugfs: move ->automount into debugfs_inode_info
... and don't bother with debugfs_fsdata for those. Life's simpler that way...
Signed-off-by: Al Viro <[email protected]> Reviewed-by: Chris
debugfs: move ->automount into debugfs_inode_info
... and don't bother with debugfs_fsdata for those. Life's simpler that way...
Signed-off-by: Al Viro <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| #
268b3611 |
| 12-Jan-2025 |
Al Viro <[email protected]> |
debugfs: separate cache for debugfs inodes
Embed them into container (struct debugfs_inode_info, with nothing else in it at the moment), set the cache up, etc.
Just the infrastructure changes letti
debugfs: separate cache for debugfs inodes
Embed them into container (struct debugfs_inode_info, with nothing else in it at the moment), set the cache up, etc.
Just the infrastructure changes letting us augment debugfs inodes here; adding stuff will come at the next step.
Signed-off-by: Al Viro <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v6.13-rc6, v6.13-rc5 |
|
| #
24edfbde |
| 29-Dec-2024 |
Al Viro <[email protected]> |
debugfs: fix missing mutex_destroy() in short_fops case
we need that in ->real_fops == NULL, ->short_fops != NULL case
Fixes: 8dc6d81c6b2a "debugfs: add small file operations for most files" Signed
debugfs: fix missing mutex_destroy() in short_fops case
we need that in ->real_fops == NULL, ->short_fops != NULL case
Fixes: 8dc6d81c6b2a "debugfs: add small file operations for most files" Signed-off-by: Al Viro <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1 |
|
| #
f8f25893 |
| 29-Nov-2024 |
Johannes Berg <[email protected]> |
fs: debugfs: differentiate short fops with proxy ops
Geert reported that my previous short fops debugfs changes broke m68k, because it only has mandatory alignement of two, so we can't stash the "is
fs: debugfs: differentiate short fops with proxy ops
Geert reported that my previous short fops debugfs changes broke m68k, because it only has mandatory alignement of two, so we can't stash the "is it short" information into the pointer (as we already did with the "is it real" bit.)
Instead, exploit the fact that debugfs_file_get() called on an already open file will already find that the fsdata is no longer the real fops but rather the allocated data that already distinguishes full/short ops, so only open() needs to be able to distinguish. We can achieve that by using two different open functions.
Unfortunately this requires another set of full file ops, increasing the size by 536 bytes (x86-64), but that's still a reasonable trade-off given that only converting some of the wireless stack gained over 28k. This brings the total cost of this to around 1k, for wins of 28k (all x86-64).
Reported-and-tested-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/CAMuHMdWu_9-L2Te101w8hU7H_2yobJFPXSwwUmGHSJfaPWDKiQ@mail.gmail.com Fixes: 8dc6d81c6b2a ("debugfs: add small file operations for most files") Signed-off-by: Johannes Berg <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5 |
|
| #
8dc6d81c |
| 22-Oct-2024 |
Johannes Berg <[email protected]> |
debugfs: add small file operations for most files
As struct file_operations is really big, but (most) debugfs files only use simple_open, read, write and perhaps seek, and don't need anything else,
debugfs: add small file operations for most files
As struct file_operations is really big, but (most) debugfs files only use simple_open, read, write and perhaps seek, and don't need anything else, this wastes a lot of space for NULL pointers.
Add a struct debugfs_short_fops and some bookkeeping code in debugfs so that users can use that with debugfs_create_file() using _Generic to figure out which function to use.
Converting mac80211 to use it where possible saves quite a bit of space:
1010127 205064 1220 1216411 128f9b net/mac80211/mac80211.ko (before) 981199 205064 1220 1187483 121e9b net/mac80211/mac80211.ko (after) ------- -28928 = ~28KiB
With a marginal space cost in debugfs:
8701 550 16 9267 2433 fs/debugfs/inode.o (before) 25233 325 32 25590 63f6 fs/debugfs/file.o (before) 8914 558 16 9488 2510 fs/debugfs/inode.o (after) 25380 325 32 25737 6489 fs/debugfs/file.o (after) --------------- +360 +8
(All on x86-64)
A simple spatch suggests there are more than 300 instances, not even counting the ones hidden in macros like in mac80211, that could be trivially converted, for additional savings of about 240 bytes for each.
Reviewed-by: Greg Kroah-Hartman <[email protected]> Link: https://patch.msgid.link/20241022151838.26f9925fb959.Ia80b55e934bbfc45ce0df42a3233d34b35508046@changeid Signed-off-by: Johannes Berg <[email protected]>
show more ...
|
|
Revision tags: v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3 |
|
| #
3a987b88 |
| 10-Aug-2024 |
Marc Aurèle La France <[email protected]> |
debugfs show actual source in /proc/mounts
After its conversion to the new mount API, debugfs displays "none" in /proc/mounts instead of the actual source. Fix this by recognising its "source" moun
debugfs show actual source in /proc/mounts
After its conversion to the new mount API, debugfs displays "none" in /proc/mounts instead of the actual source. Fix this by recognising its "source" mount option.
Signed-off-by: Marc Aurèle La France <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: a20971c18752 ("vfs: Convert debugfs to use the new mount API") Cc: [email protected] # 6.10.x: 49abee5991e1: debugfs: Convert to new uid/gid option parsing helpers Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
|
Revision tags: v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6 |
|
| #
49abee59 |
| 28-Jun-2024 |
Eric Sandeen <[email protected]> |
debugfs: Convert to new uid/gid option parsing helpers
Convert to new uid/gid option parsing helpers
Signed-off-by: Eric Sandeen <[email protected]> Link: https://lore.kernel.org/r/b2f44ee0-3cee-4
debugfs: Convert to new uid/gid option parsing helpers
Convert to new uid/gid option parsing helpers
Signed-off-by: Eric Sandeen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
|
Revision tags: v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2 |
|
| #
0c07c273 |
| 27-May-2024 |
Christian Brauner <[email protected]> |
debugfs: continue to ignore unknown mount options
Wolfram reported that debugfs remained empty on some of his boards triggering the message "debugfs: Unknown parameter 'auto'".
The root of the issu
debugfs: continue to ignore unknown mount options
Wolfram reported that debugfs remained empty on some of his boards triggering the message "debugfs: Unknown parameter 'auto'".
The root of the issue is that we ignored unknown mount options in the old mount api but we started rejecting unknown mount options in the new mount api. Continue to ignore unknown mount options to not regress userspace.
Fixes: a20971c18752 ("vfs: Convert debugfs to use the new mount API") Link: https://lore.kernel.org/r/20240527100618.np2wqiw5mz7as3vk@ninjato Reported-by: Wolfram Sang <[email protected]> Tested-by: Wolfram Sang <[email protected]> Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
|
Revision tags: v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8 |
|
| #
a20971c1 |
| 05-Mar-2024 |
David Howells <[email protected]> |
vfs: Convert debugfs to use the new mount API
Convert the debugfs filesystem to the new internal mount API as the old one will be obsoleted and removed. This allows greater flexibility in communica
vfs: Convert debugfs to use the new mount API
Convert the debugfs filesystem to the new internal mount API as the old one will be obsoleted and removed. This allows greater flexibility in communication of mount parameters between userspace, the VFS and the filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Signed-off-by: David Howells <[email protected]> Co-developed-by: Eric Sandeen <[email protected]> Signed-off-by: Eric Sandeen <[email protected]> [sandeen: forward port to modern kernel, fix remounting] Link: https://lore.kernel.org/r/[email protected] cc: Greg Kroah-Hartman <[email protected]> cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc7 |
|
| #
952c3fce |
| 29-Feb-2024 |
Johannes Berg <[email protected]> |
debugfs: fix wait/cancellation handling during remove
Ben Greear further reports deadlocks during concurrent debugfs remove while files are being accessed, even though the code in question now uses
debugfs: fix wait/cancellation handling during remove
Ben Greear further reports deadlocks during concurrent debugfs remove while files are being accessed, even though the code in question now uses debugfs cancellations. Turns out that despite all the review on the locking, we missed completely that the logic is wrong: if the refcount hits zero we can finish (and need not wait for the completion), but if it doesn't we have to trigger all the cancellations. As written, we can _never_ get into the loop triggering the cancellations. Fix this, and explain it better while at it.
Cc: [email protected] Fixes: 8c88a474357e ("debugfs: add API to allow debugfs operations cancellation") Reported-by: Ben Greear <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Tested-by: Madhan Sai <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Link: https://lore.kernel.org/r/20240229153635.6bfab7eb34d3.I6c7aeff8c9d6628a8bc1ddcf332205a49d801f17@changeid Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4 |
|
| #
88ac06a9 |
| 02-Dec-2023 |
Johannes Berg <[email protected]> |
Revert "debugfs: annotate debugfs handlers vs. removal with lockdep"
This reverts commit f4acfcd4deb1 ("debugfs: annotate debugfs handlers vs. removal with lockdep"), it appears to have false positi
Revert "debugfs: annotate debugfs handlers vs. removal with lockdep"
This reverts commit f4acfcd4deb1 ("debugfs: annotate debugfs handlers vs. removal with lockdep"), it appears to have false positives and really shouldn't have been in the -rc series with the fixes anyway.
Signed-off-by: Johannes Berg <[email protected]> Link: https://lore.kernel.org/r/20231202114936.fd55431ab160.I911aa53abeeca138126f690d383a89b13eb05667@changeid Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v6.7-rc3 |
|
| #
8c88a474 |
| 24-Nov-2023 |
Johannes Berg <[email protected]> |
debugfs: add API to allow debugfs operations cancellation
In some cases there might be longer-running hardware accesses in debugfs files, or attempts to acquire locks, and we want to still be able t
debugfs: add API to allow debugfs operations cancellation
In some cases there might be longer-running hardware accesses in debugfs files, or attempts to acquire locks, and we want to still be able to quickly remove the files.
Introduce a cancellations API to use inside the debugfs handler functions to be able to cancel such operations on a per-file basis.
Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
show more ...
|
| #
f4acfcd4 |
| 24-Nov-2023 |
Johannes Berg <[email protected]> |
debugfs: annotate debugfs handlers vs. removal with lockdep
When you take a lock in a debugfs handler but also try to remove the debugfs file under that lock, things can deadlock since the removal h
debugfs: annotate debugfs handlers vs. removal with lockdep
When you take a lock in a debugfs handler but also try to remove the debugfs file under that lock, things can deadlock since the removal has to wait for all users to finish.
Add lockdep annotations in debugfs_file_get()/_put() to catch such issues.
Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
show more ...
|
| #
0ed04a18 |
| 24-Nov-2023 |
Johannes Berg <[email protected]> |
debugfs: fix automount d_fsdata usage
debugfs_create_automount() stores a function pointer in d_fsdata, but since commit 7c8d469877b1 ("debugfs: add support for more elaborate ->d_fsdata") debugfs_r
debugfs: fix automount d_fsdata usage
debugfs_create_automount() stores a function pointer in d_fsdata, but since commit 7c8d469877b1 ("debugfs: add support for more elaborate ->d_fsdata") debugfs_release_dentry() will free it, now conditionally on DEBUGFS_FSDATA_IS_REAL_FOPS_BIT, but that's not set for the function pointer in automount. As a result, removing an automount dentry would attempt to free the function pointer. Luckily, the only user of this (tracing) never removes it.
Nevertheless, it's safer if we just handle the fsdata in one way, namely either DEBUGFS_FSDATA_IS_REAL_FOPS_BIT or allocated. Thus, change the automount to allocate it, and use the real_fops in the data to indicate whether or not automount is filled, rather than adding a type tag. At least for now this isn't actually needed, but the next changes will require it.
Also check in debugfs_file_get() that it gets only called on regular files, just to make things clearer.
Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
show more ...
|
|
Revision tags: v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5 |
|
| #
d21b3c32 |
| 04-Oct-2023 |
Jeff Layton <[email protected]> |
debugfs: convert to new timestamp accessors
Convert to using the new inode timestamp accessor functions.
Signed-off-by: Jeff Layton <[email protected]> Link: https://lore.kernel.org/r/202310041853
debugfs: convert to new timestamp accessors
Convert to using the new inode timestamp accessor functions.
Signed-off-by: Jeff Layton <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
|
Revision tags: v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1 |
|
| #
0f7bda3f |
| 05-Jul-2023 |
Jeff Layton <[email protected]> |
debugfs: convert to ctime accessor functions
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime
debugfs: convert to ctime accessor functions
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime.
Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Jeff Layton <[email protected]> Reviewed-by: Jan Kara <[email protected]> Message-Id: <[email protected]> Signed-off-by: Christian Brauner <[email protected]>
show more ...
|
|
Revision tags: v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1 |
|
| #
88cd618d |
| 20-Feb-2023 |
Bagas Sanjaya <[email protected]> |
debugfs: drop inline constant formatting for ERR_PTR(-ERROR)
Stephen Rothwell reported htmldocs warning when merging driver-core tree for linux-next:
Documentation/filesystems/api-summary:146: fs/d
debugfs: drop inline constant formatting for ERR_PTR(-ERROR)
Stephen Rothwell reported htmldocs warning when merging driver-core tree for linux-next:
Documentation/filesystems/api-summary:146: fs/debugfs/inode.c:804: WARNING: Inline literal start-string without end-string.
The warning is due to inline constant formatting (``%CONST``) doesn't play nice with complex-name constants like ERR_PTR(-ERROR).
Drop the formatting for that constant above to be consistent with similar error constants and also to fix the above warning.
Link: https://lore.kernel.org/lkml/[email protected]/ Fixes: d3002468cb5d5d ("debugfs: update comment of debugfs_rename()") Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Bagas Sanjaya <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v6.2, v6.2-rc8 |
|
| #
d3002468 |
| 08-Feb-2023 |
Qi Zheng <[email protected]> |
debugfs: update comment of debugfs_rename()
Since commit ff9fb72bc077 ("debugfs: return error values, not NULL") changed return value of debugfs_rename() in error cases from %NULL to %ERR_PTR(-ERROR
debugfs: update comment of debugfs_rename()
Since commit ff9fb72bc077 ("debugfs: return error values, not NULL") changed return value of debugfs_rename() in error cases from %NULL to %ERR_PTR(-ERROR), the comment of debugfs_rename should also be updated so as not to mislead readers.
Signed-off-by: Qi Zheng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4 |
|
| #
e18275ae |
| 13-Jan-2023 |
Christian Brauner <[email protected]> |
fs: port ->rename() to pass mnt_idmap
Convert to struct mnt_idmap.
Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just
fs: port ->rename() to pass mnt_idmap
Convert to struct mnt_idmap.
Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap.
Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs.
Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap.
Acked-by: Dave Chinner <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Christian Brauner (Microsoft) <[email protected]>
show more ...
|
| #
c1632a0f |
| 13-Jan-2023 |
Christian Brauner <[email protected]> |
fs: port ->setattr() to pass mnt_idmap
Convert to struct mnt_idmap.
Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just
fs: port ->setattr() to pass mnt_idmap
Convert to struct mnt_idmap.
Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap.
Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs.
Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap.
Acked-by: Dave Chinner <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Christian Brauner (Microsoft) <[email protected]>
show more ...
|
|
Revision tags: v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6 |
|
| #
b8de524c |
| 12-Sep-2022 |
Brian Norris <[email protected]> |
debugfs: Only clobber mode/uid/gid on remount if asked
Users may have explicitly configured their debugfs permissions; we shouldn't overwrite those just because a second mount appeared.
Only clobbe
debugfs: Only clobber mode/uid/gid on remount if asked
Users may have explicitly configured their debugfs permissions; we shouldn't overwrite those just because a second mount appeared.
Only clobber if the options were provided at mount time.
Existing behavior:
## Pre-existing status: debugfs is 0755. # chmod 755 /sys/kernel/debug/ # stat -c '%A' /sys/kernel/debug/ drwxr-xr-x
## New mount sets kernel-default permissions: # mount -t debugfs none /mnt/foo # stat -c '%A' /mnt/foo drwx------
## Unexpected: the original mount changed permissions: # stat -c '%A' /sys/kernel/debug drwx------
New behavior:
## Pre-existing status: debugfs is 0755. # chmod 755 /sys/kernel/debug/ # stat -c '%A' /sys/kernel/debug/ drwxr-xr-x
## New mount inherits existing permissions: # mount -t debugfs none /mnt/foo # stat -c '%A' /mnt/foo drwxr-xr-x
## Expected: old mount is unchanged: # stat -c '%A' /sys/kernel/debug drwxr-xr-x
Full test cases are being submitted to LTP.
Signed-off-by: Brian Norris <[email protected]> Link: https://lore.kernel.org/r/20220912163042.v3.1.Icbd40fce59f55ad74b80e5d435ea233579348a78@changeid Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v6.0-rc5, v6.0-rc4 |
|
| #
dec9b2f1 |
| 02-Sep-2022 |
Greg Kroah-Hartman <[email protected]> |
debugfs: add debugfs_lookup_and_remove()
There is a very common pattern of using debugfs_remove(debufs_lookup(..)) which results in a dentry leak of the dentry that was looked up. Instead of having
debugfs: add debugfs_lookup_and_remove()
There is a very common pattern of using debugfs_remove(debufs_lookup(..)) which results in a dentry leak of the dentry that was looked up. Instead of having to open-code the correct pattern of calling dput() on the dentry, create debugfs_lookup_and_remove() to handle this pattern automatically and properly without any memory leaks.
Cc: stable <[email protected]> Reported-by: Kuyo Chang <[email protected]> Tested-by: Kuyo Chang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|