11 Feb, 2020
1 commit
-
No one checks the return value of debugfs_create_regset32(), as it's not
needed, so make the return value void, so that no one tries to do so in
the future.Link: https://lore.kernel.org/r/20191122104453.GA2017837@kroah.com
Signed-off-by: Greg Kroah-Hartman
05 Feb, 2020
1 commit
-
Pull vfs recursive removal updates from Al Viro:
"We have quite a few places where synthetic filesystems do an
equivalent of 'rm -rf', with varying amounts of code duplication,
wrong locking, etc. That really ought to be a library helper.Only debugfs (and very similar tracefs) are converted here - I have
more conversions, but they'd never been in -next, so they'll have to
wait"* 'work.recursive_removal' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
simple_recursive_removal(): kernel-side rm -rf for ramfs-style filesystems
14 Jan, 2020
1 commit
-
When lockdown is enabled, debugfs_is_locked_down returns 1. It will then
trigger the following:WARNING: CPU: 48 PID: 3747
CPU: 48 PID: 3743 Comm: bash Not tainted 5.4.0-1946.x86_64 #1
Hardware name: Oracle Corporation ORACLE SERVER X7-2/ASM, MB, X7-2, BIOS 41060400 05/20/2019
RIP: 0010:do_dentry_open+0x343/0x3a0
Code: 00 40 08 00 45 31 ff 48 c7 43 28 40 5b e7 89 e9 02 ff ff ff 48 8b 53 28 4c 8b 72 70 4d 85 f6 0f 84 10 fe ff ff e9 f5 fd ff ff 0b 41 bf ea ff ff ff e9 3b ff ff ff 41 bf e6 ff ff ff e9 b4 fe
RSP: 0018:ffffb8740dde7ca0 EFLAGS: 00010202
RAX: ffffffff89e88a40 RBX: ffff928c8e6b6f00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff928dbfd97778 RDI: ffff9285cff685c0
RBP: ffffb8740dde7cc8 R08: 0000000000000821 R09: 0000000000000030
R10: 0000000000000057 R11: ffffb8740dde7a98 R12: ffff926ec781c900
R13: ffff928c8e6b6f10 R14: ffffffff8936e190 R15: 0000000000000001
FS: 00007f45f6777740(0000) GS:ffff928dbfd80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff95e0d5d8 CR3: 0000001ece562006 CR4: 00000000007606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
vfs_open+0x2d/0x30
path_openat+0x2d4/0x1680
? tty_mode_ioctl+0x298/0x4c0
do_filp_open+0x93/0x100
? strncpy_from_user+0x57/0x1b0
? __alloc_fd+0x46/0x150
do_sys_open+0x182/0x230
__x64_sys_openat+0x20/0x30
do_syscall_64+0x60/0x1b0
entry_SYSCALL_64_after_hwframe+0x170/0x1d5
RIP: 0033:0x7f45f5e5ce02
Code: 25 00 00 41 00 3d 00 00 41 00 74 4c 48 8d 05 25 59 2d 00 8b 00 85 c0 75 6d 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 3d 00 f0 ff ff 0f 87 a2 00 00 00 48 8b 4c 24 28 64 48 33 0c 25
RSP: 002b:00007fff95e0d2e0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 0000561178c069b0 RCX: 00007f45f5e5ce02
RDX: 0000000000000241 RSI: 0000561178c08800 RDI: 00000000ffffff9c
RBP: 00007fff95e0d3e0 R08: 0000000000000020 R09: 0000000000000005
R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000003 R14: 0000000000000001 R15: 0000561178c08800Change the return type to int and return -EPERM when lockdown is enabled
to remove the warning above. Also rename debugfs_is_locked_down to
debugfs_locked_down to make it sound less like it returns a boolean.Fixes: 5496197f9b08 ("debugfs: Restrict debugfs when the kernel is locked down")
Signed-off-by: Eric Snowberg
Reviewed-by: Matthew Wilcox (Oracle)
Cc: stable
Acked-by: James Morris
Link: https://lore.kernel.org/r/20191207161603.35907-1-eric.snowberg@oracle.com
Signed-off-by: Greg Kroah-Hartman
07 Jan, 2020
1 commit
-
Fix the following warnings:
fs/debugfs/inode.c:423: WARNING: Inline literal start-string without end-string.
fs/debugfs/inode.c:502: WARNING: Inline literal start-string without end-string.
fs/debugfs/inode.c:534: WARNING: Inline literal start-string without end-string.
fs/debugfs/inode.c:627: WARNING: Inline literal start-string without end-string.
fs/debugfs/file.c:496: WARNING: Inline literal start-string without end-string.
fs/debugfs/file.c:502: WARNING: Inline literal start-string without end-string.
fs/debugfs/file.c:581: WARNING: Inline literal start-string without end-string.
fs/debugfs/file.c:587: WARNING: Inline literal start-string without end-string.
fs/debugfs/file.c:846: WARNING: Inline literal start-string without end-string.
fs/debugfs/file.c:852: WARNING: Inline literal start-string without end-string.
fs/debugfs/file.c:899: WARNING: Inline literal start-string without end-string.
fs/debugfs/file.c:905: WARNING: Inline literal start-string without end-string.
fs/debugfs/file.c:1091: WARNING: Inline literal start-string without end-string.
fs/debugfs/file.c:1097: WARNING: Inline literal start-string without end-stringBy replacing %ERR_PTR with ERR_PTR.
Signed-off-by: Daniel W. S. Almeida
Link: https://lore.kernel.org/r/20191227010035.854913-1-dwlsalmeida@gmail.com
Signed-off-by: Greg Kroah-Hartman
11 Dec, 2019
1 commit
-
two requirements: no file creations in IS_DEADDIR and no cross-directory
renames whatsoever.Signed-off-by: Al Viro
07 Dec, 2019
1 commit
-
Pull vfs d_inode/d_flags memory ordering fixes from Al Viro:
"Fallout from tree-wide audit for ->d_inode/->d_flags barriers use.
Basically, the problem is that negative pinned dentries require
careful treatment - unless ->d_lock is locked or parent is held at
least shared, another thread can make them positive right under us.Most of the uses turned out to be safe - the main surprises as far as
filesystems are concerned were- race in dget_parent() fastpath, that might end up with the caller
observing the returned dentry _negative_, due to insufficient
barriers. It is positive in memory, but we could end up seeing the
wrong value of ->d_inode in CPU cache. Fixed.- manual checks that result of lookup_one_len_unlocked() is positive
(and rejection of negatives). Again, insufficient barriers (we
might end up with inconsistent observed values of ->d_inode and
->d_flags). Fixed by switching to a new primitive that does the
checks itself and returns ERR_PTR(-ENOENT) instead of a negative
dentry. That way we get rid of boilerplate converting negatives
into ERR_PTR(-ENOENT) in the callers and have a single place to
deal with the barrier-related mess - inside fs/namei.c rather than
in every caller out there.The guts of pathname resolution *do* need to be careful - the race
found by Ritesh is real, as well as several similar races.
Fortunately, it turns out that we can take care of that with fairly
local changes in there.The tree-wide audit had not been fun, and I hate the idea of repeating
it. I think the right approach would be to annotate the places where
we are _not_ guaranteed ->d_inode/->d_flags stability and have sparse
catch regressions. But I'm still not sure what would be the least
invasive way of doing that and it's clearly the next cycle fodder"* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
fs/namei.c: fix missing barriers when checking positivity
fix dget_parent() fastpath race
new helper: lookup_positive_unlocked()
fs/namei.c: pull positivity check into follow_managed()
16 Nov, 2019
1 commit
-
Most of the callers of lookup_one_len_unlocked() treat negatives are
ERR_PTR(-ENOENT). Provide a helper that would do just that. Note
that a pinned positive dentry remains positive - it's ->d_inode is
stable, etc.; a pinned _negative_ dentry can become positive at any
point as long as you are not holding its parent at least shared.
So using lookup_one_len_unlocked() needs to be careful;
lookup_positive_unlocked() is safer and that's what the callers
end up open-coding anyway.Signed-off-by: Al Viro
03 Nov, 2019
2 commits
-
No one checks the return value of debugfs_create_atomic_t(), as it's not
needed, so make the return value void, so that no one tries to do so in
the future.Link: https://lore.kernel.org/r/20191016130332.GA28240@kroah.com
Signed-off-by: Greg Kroah-Hartman -
No one checks the return value of debugfs_create_x8(), as it's not
needed, so make the return value void, so that no one tries to do so in
the future.Link: https://lore.kernel.org/r/20191011132931.1186197-5-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman
16 Oct, 2019
3 commits
-
No one checks the return value of debugfs_create_x64(), as it's not
needed, so make the return value void, so that no one tries to do so in
the future.Link: https://lore.kernel.org/r/20191011132931.1186197-8-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman -
No one checks the return value of debugfs_create_x32(), as it's not
needed, so make the return value void, so that no one tries to do so in
the future.Link: https://lore.kernel.org/r/20191011132931.1186197-7-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman -
No one checks the return value of debugfs_create_x16(), as it's not
needed, so make the return value void, so that no one tries to do so in
the future.Link: https://lore.kernel.org/r/20191011132931.1186197-6-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman
14 Oct, 2019
4 commits
-
No one checks the return value of debugfs_create_size_t(), as it's not
needed, so make the return value void, so that no one tries to do so in
the future.Signed-off-by: Greg Kroah-Hartman
Link: https://lore.kernel.org/r/20191011132931.1186197-4-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman -
No one checks the return value of debugfs_create_u64(), as it's not
needed, so make the return value void, so that no one tries to do so in
the future.Signed-off-by: Greg Kroah-Hartman
Link: https://lore.kernel.org/r/20191011132931.1186197-3-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman -
No one checks the return value of debugfs_create_u16(), as it's not
needed, so make the return value void, so that no one tries to do so in
the future.Signed-off-by: Greg Kroah-Hartman
Link: https://lore.kernel.org/r/20191011132931.1186197-2-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman -
No one checks the return value of debugfs_create_u8(), as it's not
needed, so make the return value void, so that no one tries to do so in
the future.Signed-off-by: Greg Kroah-Hartman
Link: https://lore.kernel.org/r/20191011132931.1186197-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman
28 Sep, 2019
1 commit
-
Pull kernel lockdown mode from James Morris:
"This is the latest iteration of the kernel lockdown patchset, from
Matthew Garrett, David Howells and others.From the original description:
This patchset introduces an optional kernel lockdown feature,
intended to strengthen the boundary between UID 0 and the kernel.
When enabled, various pieces of kernel functionality are restricted.
Applications that rely on low-level access to either hardware or the
kernel may cease working as a result - therefore this should not be
enabled without appropriate evaluation beforehand.The majority of mainstream distributions have been carrying variants
of this patchset for many years now, so there's value in providing a
doesn't meet every distribution requirement, but gets us much closer
to not requiring external patches.There are two major changes since this was last proposed for mainline:
- Separating lockdown from EFI secure boot. Background discussion is
covered here: https://lwn.net/Articles/751061/- Implementation as an LSM, with a default stackable lockdown LSM
module. This allows the lockdown feature to be policy-driven,
rather than encoding an implicit policy within the mechanism.The new locked_down LSM hook is provided to allow LSMs to make a
policy decision around whether kernel functionality that would allow
tampering with or examining the runtime state of the kernel should be
permitted.The included lockdown LSM provides an implementation with a simple
policy intended for general purpose use. This policy provides a coarse
level of granularity, controllable via the kernel command line:lockdown={integrity|confidentiality}
Enable the kernel lockdown feature. If set to integrity, kernel features
that allow userland to modify the running kernel are disabled. If set to
confidentiality, kernel features that allow userland to extract
confidential information from the kernel are also disabled.This may also be controlled via /sys/kernel/security/lockdown and
overriden by kernel configuration.New or existing LSMs may implement finer-grained controls of the
lockdown features. Refer to the lockdown_reason documentation in
include/linux/security.h for details.The lockdown feature has had signficant design feedback and review
across many subsystems. This code has been in linux-next for some
weeks, with a few fixes applied along the way.Stephen Rothwell noted that commit 9d1f8be5cf42 ("bpf: Restrict bpf
when kernel lockdown is in confidentiality mode") is missing a
Signed-off-by from its author. Matthew responded that he is providing
this under category (c) of the DCO"* 'next-lockdown' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (31 commits)
kexec: Fix file verification on S390
security: constify some arrays in lockdown LSM
lockdown: Print current->comm in restriction messages
efi: Restrict efivar_ssdt_load when the kernel is locked down
tracefs: Restrict tracefs when the kernel is locked down
debugfs: Restrict debugfs when the kernel is locked down
kexec: Allow kexec_file() with appropriate IMA policy when locked down
lockdown: Lock down perf when in confidentiality mode
bpf: Restrict bpf when kernel lockdown is in confidentiality mode
lockdown: Lock down tracing and perf kprobes when in confidentiality mode
lockdown: Lock down /proc/kcore
x86/mmiotrace: Lock down the testmmiotrace module
lockdown: Lock down module params that specify hardware parameters (eg. ioport)
lockdown: Lock down TIOCSSERIAL
lockdown: Prohibit PCMCIA CIS storage when the kernel is locked down
acpi: Disable ACPI table override if the kernel is locked down
acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
ACPI: Limit access to custom_method when the kernel is locked down
x86/msr: Restrict MSR access when the kernel is locked down
x86: Lock down IO port access when the kernel is locked down
...
20 Aug, 2019
1 commit
-
Disallow opening of debugfs files that might be used to muck around when
the kernel is locked down as various drivers give raw access to hardware
through debugfs. Given the effort of auditing all 2000 or so files and
manually fixing each one as necessary, I've chosen to apply a heuristic
instead. The following changes are made:(1) chmod and chown are disallowed on debugfs objects (though the root dir
can be modified by mount and remount, but I'm not worried about that).(2) When the kernel is locked down, only files with the following criteria
are permitted to be opened:- The file must have mode 00444
- The file must not have ioctl methods
- The file must not have mmap(3) When the kernel is locked down, files may only be opened for reading.
Normal device interaction should be done through configfs, sysfs or a
miscdev, not debugfs.Note that this makes it unnecessary to specifically lock down show_dsts(),
show_devs() and show_call() in the asus-wmi driver.I would actually prefer to lock down all files by default and have the
the files unlocked by the creator. This is tricky to manage correctly,
though, as there are 19 creation functions and ~1600 call sites (some of
them in loops scanning tables).Signed-off-by: David Howells
cc: Andy Shevchenko
cc: acpi4asus-user@lists.sourceforge.net
cc: platform-driver-x86@vger.kernel.org
cc: Matthew Garrett
cc: Thomas Gleixner
Cc: Greg KH
Cc: Rafael J. Wysocki
Signed-off-by: Matthew Garrett
Signed-off-by: James Morris
13 Jul, 2019
1 commit
-
Pull driver core and debugfs updates from Greg KH:
"Here is the "big" driver core and debugfs changes for 5.3-rc1It's a lot of different patches, all across the tree due to some api
changes and lots of debugfs cleanups.Other than the debugfs cleanups, in this set of changes we have:
- bus iteration function cleanups
- scripts/get_abi.pl tool to display and parse Documentation/ABI
entries in a simple way- cleanups to Documenatation/ABI/ entries to make them parse easier
due to typos and other minor things- default_attrs use for some ktype users
- driver model documentation file conversions to .rst
- compressed firmware file loading
- deferred probe fixes
All of these have been in linux-next for a while, with a bunch of
merge issues that Stephen has been patient with me for"* tag 'driver-core-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (102 commits)
debugfs: make error message a bit more verbose
orangefs: fix build warning from debugfs cleanup patch
ubifs: fix build warning after debugfs cleanup patch
driver: core: Allow subsystems to continue deferring probe
drivers: base: cacheinfo: Ensure cpu hotplug work is done before Intel RDT
arch_topology: Remove error messages on out-of-memory conditions
lib: notifier-error-inject: no need to check return value of debugfs_create functions
swiotlb: no need to check return value of debugfs_create functions
ceph: no need to check return value of debugfs_create functions
sunrpc: no need to check return value of debugfs_create functions
ubifs: no need to check return value of debugfs_create functions
orangefs: no need to check return value of debugfs_create functions
nfsd: no need to check return value of debugfs_create functions
lib: 842: no need to check return value of debugfs_create functions
debugfs: provide pr_fmt() macro
debugfs: log errors when something goes wrong
drivers: s390/cio: Fix compilation warning about const qualifiers
drivers: Add generic helper to match by of_node
driver_find_device: Unify the match function with class_find_device()
bus_find_device: Unify the match callback with class_find_device
...
08 Jul, 2019
1 commit
-
When a file/directory is already present in debugfs, and it is attempted
to be created again, be more specific about what file/directory is being
created and where it is trying to be created to give a bit more help to
developers to figure out the problem.Cc: Stephen Rothwell
Cc: Rafael J. Wysocki
Cc: Mark Brown
Cc: Takashi Iwai
Reviewed-by: Mark Brown
Link: https://lore.kernel.org/r/20190706154256.GA2683@kroah.com
Signed-off-by: Greg Kroah-Hartman
03 Jul, 2019
2 commits
-
Use a common "debugfs: " prefix for all pr_* calls in a single place.
Cc: Mark Brown
Reviewed-by: Takashi Iwai
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
Link: https://lore.kernel.org/r/20190703071653.2799-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman -
As it is not recommended that debugfs calls be checked, it was pointed
out that major errors should still be logged somewhere so that
developers and users have a chance to figure out what went wrong. To
help with this, error logging has been added to the debugfs core so that
it is not needed to be present in every individual file that calls
debugfs.Reported-by: Mark Brown
Reported-by: Takashi Iwai
Reviewed-by: Mark Brown
Reviewed-by: Takashi Iwai
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
Link: https://lore.kernel.org/r/20190703071653.2799-2-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman
20 Jun, 2019
2 commits
-
This will allow generating fsnotify delete events after the
fsnotify_nameremove() hook is removed from d_delete().Cc: Greg Kroah-Hartman
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Amir Goldstein
Signed-off-by: Jan Kara -
Move simple_unlink()+d_delete() from __debugfs_remove_file() into
caller __debugfs_remove() and rename helper for post remove file to
__debugfs_file_removed().This will simplify adding fsnotify_unlink() hook.
Cc: Greg Kroah-Hartman
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Amir Goldstein
Signed-off-by: Jan Kara
03 Jun, 2019
1 commit
-
The single user of debugfs_create_u32_array() does not care about the
return value of it, so make it return void as there is no need to do
anything with the return value.Signed-off-by: Greg Kroah-Hartman
21 May, 2019
1 commit
-
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:GPL-2.0-only
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
08 May, 2019
2 commits
-
Pull misc dcache updates from Al Viro:
"Most of this pile is putting name length into struct name_snapshot and
making use of it.The beginning of this series ("ovl_lookup_real_one(): don't bother
with strlen()") ought to have been split in two (separate switch of
name_snapshot to struct qstr from overlayfs reaping the trivial
benefits of that), but I wanted to avoid a rebase - by the time I'd
spotted that it was (a) in -next and (b) close to 5.1-final ;-/"* 'work.dcache' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
audit_compare_dname_path(): switch to const struct qstr *
audit_update_watch(): switch to const struct qstr *
inotify_handle_event(): don't bother with strlen()
fsnotify: switch send_to_group() and ->handle_event to const struct qstr *
fsnotify(): switch to passing const struct qstr * for file_name
switch fsnotify_move() to passing const struct qstr * for old_name
ovl_lookup_real_one(): don't bother with strlen()
sysv: bury the broken "quietly truncate the long filenames" logics
nsfs: unobfuscate
unexport d_alloc_pseudo() -
Pull driver core/kobject updates from Greg KH:
"Here is the "big" set of driver core patches for 5.2-rc1There are a number of ACPI patches in here as well, as Rafael said
they should go through this tree due to the driver core changes they
required. They have all been acked by the ACPI developers.There are also a number of small subsystem-specific changes in here,
due to some changes to the kobject core code. Those too have all been
acked by the various subsystem maintainers.As for content, it's pretty boring outside of the ACPI changes:
- spdx cleanups
- kobject documentation updates
- default attribute groups for kobjects
- other minor kobject/driver core fixesAll have been in linux-next for a while with no reported issues"
* tag 'driver-core-5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (47 commits)
kobject: clean up the kobject add documentation a bit more
kobject: Fix kernel-doc comment first line
kobject: Remove docstring reference to kset
firmware_loader: Fix a typo ("syfs" -> "sysfs")
kobject: fix dereference before null check on kobj
Revert "driver core: platform: Fix the usage of platform device name(pdev->name)"
init/config: Do not select BUILD_BIN2C for IKCONFIG
Provide in-kernel headers to make extending kernel easier
kobject: Improve doc clarity kobject_init_and_add()
kobject: Improve docs for kobject_add/del
driver core: platform: Fix the usage of platform device name(pdev->name)
livepatch: Replace klp_ktype_patch's default_attrs with groups
cpufreq: schedutil: Replace default_attrs field with groups
padata: Replace padata_attr_type default_attrs field with groups
irqdesc: Replace irq_kobj_type's default_attrs field with groups
net-sysfs: Replace ktype default_attrs field with groups
block: Replace all ktype default_attrs with groups
samples/kobject: Replace foo_ktype's default_attrs field with groups
kobject: Add support for default attribute groups to kobj_type
driver core: Postpone DMA tear-down until after devres release for probe failure
...
02 May, 2019
1 commit
-
Signed-off-by: Al Viro
27 Apr, 2019
2 commits
-
note that in the second (RENAME_EXCHANGE) call of fsnotify_move() in
vfs_rename() the old_dentry->d_name is guaranteed to be unchanged
throughout the evaluation of fsnotify_move() (by the fact that the
parent directory is locked exclusive), so we don't need to fetch
old_dentry->d_name.name in the caller.Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
25 Apr, 2019
1 commit
-
Since commit ff9fb72bc077 ("debugfs: return error values, not NULL")
these helper functions do not return NULL anymore (with the exception
of debugfs_create_u32_array()).Fixes: ff9fb72bc077 ("debugfs: return error values, not NULL")
Signed-off-by: Ronald Tschalär
Signed-off-by: Greg Kroah-Hartman
01 Apr, 2019
1 commit
-
symlink body shouldn't be freed without an RCU delay. Switch debugfs to
->destroy_inode() and use of call_rcu(); free both the inode and symlink
body in the callback. Similar to solution for bpf, only here it's even
more obvious that ->evict_inode() can be dropped.Signed-off-by: Al Viro
11 Feb, 2019
1 commit
-
We need the debugfs fixes in here as well.
Signed-off-by: Greg Kroah-Hartman
30 Jan, 2019
2 commits
-
Lots of callers of debugfs_lookup() were just checking NULL to see if
the file/directory was found or not. By changing this in ff9fb72bc077
("debugfs: return error values, not NULL") we caused some subsystems to
easily crash.Fixes: ff9fb72bc077 ("debugfs: return error values, not NULL")
Reported-by: syzbot+b382ba6a802a3d242790@syzkaller.appspotmail.com
Reported-by: Tetsuo Handa
Cc: Omar Sandoval
Cc: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
When an error happens, debugfs should return an error pointer value, not
NULL. This will prevent the totally theoretical error where a debugfs
call fails due to lack of memory, returning NULL, and that dentry value
is then passed to another debugfs call, which would end up succeeding,
creating a file at the root of the debugfs tree, but would then be
impossible to remove (because you can not remove the directory NULL).So, to make everyone happy, always return errors, this makes the users
of debugfs much simpler (they do not have to ever check the return
value), and everyone can rest easy.Reported-by: Gary R Hook
Reported-by: Heiko Carstens
Reported-by: Masami Hiramatsu
Reported-by: Michal Hocko
Reported-by: Sebastian Andrzej Siewior
Reported-by: Ulf Hansson
Reviewed-by: Masami Hiramatsu
Reviewed-by: Sebastian Andrzej Siewior
Signed-off-by: Greg Kroah-Hartman
25 Jan, 2019
1 commit
-
debugfs_rename() needs to check that the dentries passed into it really
are valid, as sometimes they are not (i.e. if the return value of
another debugfs call is passed into this one.) So fix this up by
properly checking if the two parent directories are errors (they are
allowed to be NULL), and if the dentry to rename is not NULL or an
error.Cc: stable
Signed-off-by: Greg Kroah-Hartman
22 Jan, 2019
1 commit
-
debugfs_use_file_start() and debugfs_use_file_finish() do not exist
since commit c9afbec27089 ("debugfs: purge obsolete SRCU based removal
protection"); tweak debugfs_create_file_unsafe() comment.Signed-off-by: Sergey Senozhatsky
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
13 Jun, 2018
1 commit
-
This reverts commit 95cde3c59966f6371b6bcd9e4e2da2ba64ee9775.
The commit had good intentions, but it breaks kvm-tool and qemu-kvm.
With it in place, "lkvm run" just fails with
Error: KVM_CREATE_VM ioctl
Warning: Failed init: kvm__initwhich isn't a wonderful error message, but bisection pinpointed the
problematic commit.The problem is almost certainly due to the special kvm debugfs entries
created dynamically by kvm under /sys/kernel/debug/kvm/. See
kvm_create_vm_debugfs()Bisected-and-reported-by: Linus Torvalds
Cc: Wanpeng Li
Cc: Greg Kroah-Hartman
Cc: Thomas Richter
Cc: Kees Cook
Signed-off-by: Linus Torvalds
14 May, 2018
1 commit
-
Currently function debugfs_create_dir() creates a new
directory in the debugfs (usually mounted /sys/kernel/debug)
with permission rwxr-xr-x. This is hard coded.Change this to use the parent directory permission.
Output before the patch:
root@s8360047 ~]# tree -dp -L 1 /sys/kernel/debug/
/sys/kernel/debug/
├── [drwxr-xr-x] bdi
├── [drwxr-xr-x] block
├── [drwxr-xr-x] dasd
├── [drwxr-xr-x] device_component
├── [drwxr-xr-x] extfrag
├── [drwxr-xr-x] hid
├── [drwxr-xr-x] kprobes
├── [drwxr-xr-x] kvm
├── [drwxr-xr-x] memblock
├── [drwxr-xr-x] pm_qos
├── [drwxr-xr-x] qdio
├── [drwxr-xr-x] s390
├── [drwxr-xr-x] s390dbf
└── [drwx------] tracing14 directories
[root@s8360047 linux]#Output after the patch:
[root@s8360047 ~]# tree -dp -L 1 /sys/kernel/debug/
sys/kernel/debug/
├── [drwx------] bdi
├── [drwx------] block
├── [drwx------] dasd
├── [drwx------] device_component
├── [drwx------] extfrag
├── [drwx------] hid
├── [drwx------] kprobes
├── [drwx------] kvm
├── [drwx------] memblock
├── [drwx------] pm_qos
├── [drwx------] qdio
├── [drwx------] s390
├── [drwx------] s390dbf
└── [drwx------] tracing14 directories
[root@s8360047 linux]#Here is the full diff output done with:
[root@s8360047 ~]# diff -u treefull.before treefull.after |
sed 's-^- # -' > treefull.diff
# --- treefull.before 2018-04-27 13:22:04.532824564 +0200
# +++ treefull.after 2018-04-27 13:24:12.106182062 +0200
# @@ -1,55 +1,55 @@
# /sys/kernel/debug/
# -├── [drwxr-xr-x] bdi
# -│ ├── [drwxr-xr-x] 1:0
# -│ ├── [drwxr-xr-x] 1:1
# -│ ├── [drwxr-xr-x] 1:10
# -│ ├── [drwxr-xr-x] 1:11
# -│ ├── [drwxr-xr-x] 1:12
# -│ ├── [drwxr-xr-x] 1:13
# -│ ├── [drwxr-xr-x] 1:14
# -│ ├── [drwxr-xr-x] 1:15
# -│ ├── [drwxr-xr-x] 1:2
# -│ ├── [drwxr-xr-x] 1:3
# -│ ├── [drwxr-xr-x] 1:4
# -│ ├── [drwxr-xr-x] 1:5
# -│ ├── [drwxr-xr-x] 1:6
# -│ ├── [drwxr-xr-x] 1:7
# -│ ├── [drwxr-xr-x] 1:8
# -│ ├── [drwxr-xr-x] 1:9
# -│ └── [drwxr-xr-x] 94:0
# -├── [drwxr-xr-x] block
# -├── [drwxr-xr-x] dasd
# -│ ├── [drwxr-xr-x] 0.0.e18a
# -│ ├── [drwxr-xr-x] dasda
# -│ └── [drwxr-xr-x] global
# -├── [drwxr-xr-x] device_component
# -├── [drwxr-xr-x] extfrag
# -├── [drwxr-xr-x] hid
# -├── [drwxr-xr-x] kprobes
# -├── [drwxr-xr-x] kvm
# -├── [drwxr-xr-x] memblock
# -├── [drwxr-xr-x] pm_qos
# -├── [drwxr-xr-x] qdio
# -│ └── [drwxr-xr-x] 0.0.f5f2
# -├── [drwxr-xr-x] s390
# -│ └── [drwxr-xr-x] stsi
# -├── [drwxr-xr-x] s390dbf
# -│ ├── [drwxr-xr-x] 0.0.e18a
# -│ ├── [drwxr-xr-x] cio_crw
# -│ ├── [drwxr-xr-x] cio_msg
# -│ ├── [drwxr-xr-x] cio_trace
# -│ ├── [drwxr-xr-x] dasd
# -│ ├── [drwxr-xr-x] kvm-trace
# -│ ├── [drwxr-xr-x] lgr
# -│ ├── [drwxr-xr-x] qdio_0.0.f5f2
# -│ ├── [drwxr-xr-x] qdio_error
# -│ ├── [drwxr-xr-x] qdio_setup
# -│ ├── [drwxr-xr-x] qeth_card_0.0.f5f0
# -│ ├── [drwxr-xr-x] qeth_control
# -│ ├── [drwxr-xr-x] qeth_msg
# -│ ├── [drwxr-xr-x] qeth_setup
# -│ ├── [drwxr-xr-x] vmcp
# -│ └── [drwxr-xr-x] vmur
# +├── [drwx------] bdi
# +│ ├── [drwx------] 1:0
# +│ ├── [drwx------] 1:1
# +│ ├── [drwx------] 1:10
# +│ ├── [drwx------] 1:11
# +│ ├── [drwx------] 1:12
# +│ ├── [drwx------] 1:13
# +│ ├── [drwx------] 1:14
# +│ ├── [drwx------] 1:15
# +│ ├── [drwx------] 1:2
# +│ ├── [drwx------] 1:3
# +│ ├── [drwx------] 1:4
# +│ ├── [drwx------] 1:5
# +│ ├── [drwx------] 1:6
# +│ ├── [drwx------] 1:7
# +│ ├── [drwx------] 1:8
# +│ ├── [drwx------] 1:9
# +│ └── [drwx------] 94:0
# +├── [drwx------] block
# +├── [drwx------] dasd
# +│ ├── [drwx------] 0.0.e18a
# +│ ├── [drwx------] dasda
# +│ └── [drwx------] global
# +├── [drwx------] device_component
# +├── [drwx------] extfrag
# +├── [drwx------] hid
# +├── [drwx------] kprobes
# +├── [drwx------] kvm
# +├── [drwx------] memblock
# +├── [drwx------] pm_qos
# +├── [drwx------] qdio
# +│ └── [drwx------] 0.0.f5f2
# +├── [drwx------] s390
# +│ └── [drwx------] stsi
# +├── [drwx------] s390dbf
# +│ ├── [drwx------] 0.0.e18a
# +│ ├── [drwx------] cio_crw
# +│ ├── [drwx------] cio_msg
# +│ ├── [drwx------] cio_trace
# +│ ├── [drwx------] dasd
# +│ ├── [drwx------] kvm-trace
# +│ ├── [drwx------] lgr
# +│ ├── [drwx------] qdio_0.0.f5f2
# +│ ├── [drwx------] qdio_error
# +│ ├── [drwx------] qdio_setup
# +│ ├── [drwx------] qeth_card_0.0.f5f0
# +│ ├── [drwx------] qeth_control
# +│ ├── [drwx------] qeth_msg
# +│ ├── [drwx------] qeth_setup
# +│ ├── [drwx------] vmcp
# +│ └── [drwx------] vmur
# └── [drwx------] tracing
# ├── [drwxr-xr-x] events
# │ ├── [drwxr-xr-x] alarmtimerFixes: edac65eaf8d5c ("debugfs: take mode-dependent parts of debugfs_get_inode() into callers")
Signed-off-by: Thomas Richter
Reviewed-by: Kees Cook
Signed-off-by: Greg Kroah-Hartman
