summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'driver-core-6.1-rc1' of ↵Linus Torvalds2022-10-0846-694/+1318
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the big set of driver core and debug printk changes for 6.1-rc1. Included in here is: - dynamic debug updates for the core and the drm subsystem. The drm changes have all been acked by the relevant maintainers - kernfs fixes for syzbot reported problems - kernfs refactors and updates for cgroup requirements - magic number cleanups and removals from the kernel tree (they were not being used and they really did not actually do anything) - other tiny cleanups All of these have been in linux-next for a while with no reported issues" * tag 'driver-core-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (74 commits) docs: filesystems: sysfs: Make text and code for ->show() consistent Documentation: NBD_REQUEST_MAGIC isn't a magic number a.out: restore CMAGIC device property: Add const qualifier to device_get_match_data() parameter drm_print: add _ddebug descriptor to drm_*dbg prototypes drm_print: prefer bare printk KERN_DEBUG on generic fn drm_print: optimize drm_debug_enabled for jump-label drm-print: add drm_dbg_driver to improve namespace symmetry drm-print.h: include dyndbg header drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro drm_print: interpose drm_*dbg with forwarding macros drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers. drm_print: condense enum drm_debug_category debugfs: use DEFINE_SHOW_ATTRIBUTE to define debugfs_regset32_fops driver core: use IS_ERR_OR_NULL() helper in device_create_groups_vargs() Documentation: ENI155_MAGIC isn't a magic number Documentation: NBD_REPLY_MAGIC isn't a magic number nbd: remove define-only NBD_MAGIC, previously magic number Documentation: FW_HEADER_MAGIC isn't a magic number Documentation: EEPROM_MAGIC_VALUE isn't a magic number ...
| * docs: filesystems: sysfs: Make text and code for ->show() consistentAndy Shevchenko2022-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | The documentation says that ->show() should only use sysfs_emit() or sysfs_emit_at(), but example keeps outdated code. Update the code to be consistent. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220928135741.54919-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: NBD_REQUEST_MAGIC isn't a magic numberнаб2022-09-274-4/+0
| | | | | | | | | | | | | | | | | | It's part of the line protocol, same as in commit 82805818898d ("Documentation: NBD_REPLY_MAGIC isn't a magic number") Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/20220927003727.slf4ofb7dgum6apt@tarta.nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * a.out: restore CMAGICнаб2022-09-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Part of UAPI and the on-disk format: this means that it's not a magic number per magic-number.rst, and it's best to leave it untouched to avoid breaking userspace and suffer the same fate as a.out in general Fixes: 53c2bd679017 ("a.out: remove define-only CMAGIC, previously magic number") Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/20220926151554.7gxd6unp5727vw3c@tarta.nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * device property: Add const qualifier to device_get_match_data() parameterAndy Shevchenko2022-09-242-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add const qualifier to the device_get_match_data() parameter. Some of the future users may utilize this function without forcing the type. All the same, dev_fwnode() may be used with a const qualifier. Reported-by: kernel test robot <lkp@intel.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220922135410.49694-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm_print: add _ddebug descriptor to drm_*dbg prototypesJim Cromie2022-09-242-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | upgrade the callchain to drm_dbg() and drm_dev_dbg(); add a struct _ddebug ptr parameter to them, and supply that additional param by replacing the '_no_desc' flavor of dyndbg Factory macro currently used with the flavor that supplies the descriptor. NOTES: The descriptor gives these fns access to the decorator flags, but they do none of the dynamic-prefixing done by dynamic_emit_prefix(), which is currently static. DRM already has conventions for logging/messaging; just tossing optional decorations on top probably wouldn't help. Instead, existing flags (or new ones, perhaps 'sd' ala lspci) can be used to make current message conventions optional. This suggests a new drmdbg_prefix_emit() to handle prefixing locally. For CONFIG_DRM_USE_DYNAMIC_DEBUG=N, just pass null descriptor. desc->class_id is redundant with category parameter, but its availability is dependent on desc. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-10-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm_print: prefer bare printk KERN_DEBUG on generic fnJim Cromie2022-09-241-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm_print.c calls pr_debug() just once, from __drm_printfn_debug(), which is a generic/service fn. The callsite is compile-time enabled by DEBUG in both DYNAMIC_DEBUG=y/n builds. For dyndbg builds, reverting this callsite back to bare printk is correcting a few anti-features: 1- callsite is generic, serves multiple drm users. it is soft-wired on currently by #define DEBUG could accidentally: #> echo -p > /proc/dynamic_debug/control 2- optional "decorations" by dyndbg are unhelpful/misleading here, they describe only the generic site, not end users IOW, 1,2 are unhelpful at best, and possibly confusing. reverting yields a nominal data and text shrink: text data bss dec hex filename 462583 36604 54592 553779 87333 /kernel/drivers/gpu/drm/drm.ko 462515 36532 54592 553639 872a7 -dirty/kernel/drivers/gpu/drm/drm.ko Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-9-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm_print: optimize drm_debug_enabled for jump-labelJim Cromie2022-09-242-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When CONFIG_DRM_USE_DYNAMIC_DEBUG=y, the drm.debug API (a macro stack, calling _+drm_*dbg() eventually) invokes a dyndbg Factory macro to create a descriptor for each callsite, thus making them individually >control-able. In this case, the calls to _drm_*dbg are unreachable unless the callsite is enabled. So those calls can short-circuit their early do-nothing returns. Provide and use __drm_debug_enabled(), to do this when config'd, or the _raw flags-check otherwize. And since dyndbg is in use, lets also instrument the remaining users of drm_debug_enabled, by wrapping the _raw in a macro with a: pr_debug("todo: is this frequent enough to optimize ?\n"); For CONFIG_DRM_USE_DYNAMIC_DEBUG=n, do no site instrumenting at all, since JUMP_LABEL might be off, and we don't want to make work. With drm, amdgpu, i915, nouveau loaded, heres remaining uses of drm_debug_enabled(), which costs ~1.5kb data to control the pr_debug("todo:..")s. Some of those uses might be ok to use __drm_debug_enabled() by inspection, others might warrant conversion to use dyndbg Factory macros, and that would want callrate data to estimate the savings possible. TBH, any remaining savings are probably small; drm.debug covers the vast bulk of the uses. Maybe "vblank" is the exception. :#> grep todo /proc/dynamic_debug/control | wc 21 168 2357 :#> grep todo /proc/dynamic_debug/control drivers/gpu/drm/drm_edid_load.c:178 [drm]edid_load =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:410 [drm]drm_crtc_accurate_vblank_count =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:787 [drm]drm_crtc_vblank_helper_get_vblank_timestamp_internal =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:1491 [drm]drm_vblank_restore =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:1433 [drm]drm_vblank_enable =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_plane.c:2168 [drm]drm_mode_setplane =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:1359 [drm_display_helper]drm_dp_mst_wait_tx_reply =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:2864 [drm_display_helper]process_single_tx_qlock =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:2909 [drm_display_helper]drm_dp_queue_down_tx =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:1686 [drm_display_helper]drm_dp_mst_update_slots =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_dp.c:1111 [i915]intel_dp_print_rates =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_backlight.c:5434 [i915]cnp_enable_backlight =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_backlight.c:5459 [i915]intel_backlight_device_register =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_opregion.c:43 [i915]intel_opregion_notify_encoder =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_opregion.c:53 [i915]asle_set_backlight =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_bios.c:1088 [i915]intel_bios_is_dsi_present =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_display_debugfs.c:6153 [i915]i915_drrs_ctl_set =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/intel_pcode.c:26 [i915]snb_pcode_read =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/i915_getparam.c:785 [i915]i915_getparam_ioctl =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:282 [amdgpu]vcn_v2_5_process_interrupt =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:433 [amdgpu]vcn_v2_0_process_interrupt =_ "todo: maybe avoid via dyndbg\n" :#> Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-8-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm-print: add drm_dbg_driver to improve namespace symmetryJim Cromie2022-09-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm_print defines all of these: drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres} but not drm_dbg_driver itself, since it was the original drm_dbg. To improve namespace symmetry, change the drm_dbg defn to drm_dbg_driver, and redef grandfathered name to symmetric one. This will help with nouveau, which uses its own stack of macros to construct calls to dev_info, dev_dbg, etc, for which adaptation means drm_dbg_##driver constructs. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-7-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm-print.h: include dyndbg headerJim Cromie2022-09-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lkp robot told me: >> drivers/gpu/drm/drm_ioc32.c:989:2: error: call to undeclared function '_dynamic_func_call_cls'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n", Since that macro is defined in drm_print.h, and under DRM_USE_DYN*=y configs, invokes dyndbg-factory macros, include dynamic_debug.h from there too, so that those configs have the definitions of all the macros in the callchain. This is done as a separate patch mostly to see how lkp sorts it. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-6-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm_print: wrap drm_*_dbg in dyndbg descriptor factory macroJim Cromie2022-09-243-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() & __drm_dev_dbg() in one of dyndbg's Factory macros: _dynamic_func_call_no_desc(). This adds the callsite descriptor into the code, and an entry for each into /proc/dynamic_debug/control. #> echo class DRM_UT_ATOMIC +p > /proc/dynamic_debug/control CONFIG_DRM_USE_DYNAMIC_DEBUG=y/n is configurable because of the .data footprint cost of per-callsite control; 56 bytes/site * ~2k for i915, ~4k callsites for amdgpu. This is large enough that a kernel builder might not want it. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-5-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm_print: interpose drm_*dbg with forwarding macrosJim Cromie2022-09-242-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | change drm_dev_dbg & drm_dbg to macros, which forward to the renamed functions (with __ prefix added). Those functions sit below the categorized layer of macros implementing the DRM debug.category API, and implement most of it. These are good places to insert dynamic-debug jump-label mechanics, which will allow DRM to avoid the runtime cost of drm_debug_enabled(). no functional changes. memory cost baseline: (unchanged) bash-5.1# drms_load [ 9.220389] dyndbg: 1 debug prints in module drm [ 9.224426] ACPI: bus type drm_connector registered [ 9.302192] dyndbg: 2 debug prints in module ttm [ 9.305033] dyndbg: 8 debug prints in module video [ 9.627563] dyndbg: 127 debug prints in module i915 [ 9.721505] AMD-Vi: AMD IOMMUv2 functionality not available on this system - This is not a bug. [ 10.091345] dyndbg: 2196 debug prints in module amdgpu [ 10.106589] [drm] amdgpu kernel modesetting enabled. [ 10.107270] amdgpu: CRAT table not found [ 10.107926] amdgpu: Virtual CRAT table created for CPU [ 10.108398] amdgpu: Topology: Add CPU node [ 10.168507] dyndbg: 3 debug prints in module wmi [ 10.329587] dyndbg: 3 debug prints in module nouveau Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-4-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers.Jim Cromie2022-09-247-3/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use DECLARE_DYNDBG_CLASSMAP across DRM: - in .c files, since macro defines/initializes a record - in drivers, $mod_{drv,drm,param}.c ie where param setup is done, since a classmap is param related - in drm/drm_print.c since existing __drm_debug param is defined there, and we ifdef it, and provide an elaborated alternative. - in drm_*_helper modules: dp/drm_dp - 1st item in makefile target drivers/gpu/drm/drm_crtc_helper.c - random pick iirc. Since these modules all use identical CLASSMAP declarations (ie: names and .class_id's) they will all respond together to "class DRM_UT_*" query-commands: :#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control NOTES: This changes __drm_debug from int to ulong, so BIT() is usable on it. DRM's enum drm_debug_category values need to sync with the index of their respective class-names here. Then .class_id == category, and dyndbg's class FOO mechanisms will enable drm_dbg(DRM_UT_KMS, ...). Though DRM needs consistent categories across all modules, thats not generally needed; modules X and Y could define FOO differently (ie a different NAME => class_id mapping), changes are made according to each module's private class-map. No callsites are actually selected by this patch, since none are class'd yet. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-3-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm_print: condense enum drm_debug_categoryJim Cromie2022-09-241-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | enum drm_debug_category has 10 categories, but is initialized with bitmasks which require 10 bits of underlying storage. By using natural enumeration, and moving the BIT(cat) into drm_debug_enabled(), the enum fits in 4 bits, allowing the category to be represented directly in pr_debug callsites, via the ddebug.class_id field. While this slightly pessimizes the bit-test in drm_debug_enabled(), using dyndbg with JUMP_LABEL will avoid the function entirely. NOTE: this change forecloses the possibility of doing: drm_dbg(DRM_UT_CORE|DRM_UT_KMS, "weird 2-cat experiment") but thats already strongly implied by the use of the enum itself; its not a normal enum if it can be 2 values simultaneously. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-2-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * debugfs: use DEFINE_SHOW_ATTRIBUTE to define debugfs_regset32_fopsChenXiaoSong2022-09-241-13/+3
| | | | | | | | | | | | | | | | Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code. Signed-off-by: ChenXiaoSong <chenxiaosong2@huawei.com> Link: https://lore.kernel.org/r/20220923102554.2443452-1-chenxiaosong2@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * driver core: use IS_ERR_OR_NULL() helper in device_create_groups_vargs()Yang Yingliang2022-09-241-1/+1
| | | | | | | | | | | | | | | | | | Use IS_ERR_OR_NULL() helper in device_create_groups_vargs() to simplify code and improve readiblity. No functional change. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220914140753.3799982-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: ENI155_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | | | | | | | | | It's part of the EEPROM format Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/5f1dfa09150be7f23fb275d170c9019b5197a79f.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: NBD_REPLY_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | | | | | | | | | It's part of the line protocol Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/a8afed8fb4d7df2c8fb95c3fa758240b2e46cdc8.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * nbd: remove define-only NBD_MAGIC, previously magic numberнаб2022-09-245-6/+0
| | | | | | | | | | | | | | | | | | | | commit f4507164e779 ("nbd: rename the nbd_device variable from lo to nbd") renamed LO_MAGIC to NBD_MAGIC; commit 5ea8d10802ec ("nbd: separate out the config information") removed the last users of that Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/10a80681c5966fed1a1afc696e3db114f481514c.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: FW_HEADER_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | | | | | | | | | It's a file format identifier Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/1b21808fb399931eb44f0dc26fda20a632ecc196.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: EEPROM_MAGIC_VALUE isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | | | | | | | | | It's an EEPROM checksum, not a magic number per magic-number.rst Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/8881090c8bf1850e1d3597cb352a8dd1757c94f1.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: COW_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | | | | | | | | | At least not in the magic-number.rst sense: it's part of a file format Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/f24a428d82713821ca571bf477a099252d06ae14.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: SAVEKMSG_MAGIC[12] aren't magic numbersнаб2022-09-244-8/+0
| | | | | | | | | | | | | | | | | | | | At least not in the magic-number.rst sense: they're used as part of delineating messages dumping dmesg into Chip RAM on the Amiga with debug=ram Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/c0fe3aadb700621eeee736f0ce6d73aa9d2cf856.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: RIEBL_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | | | | | | | | | | | | | At least not in the sense described in magic-number.rst: it determines whether the Atari VME Lance Ethernet card has a hardware MAC address or not, and is set thereby to indicate this Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/773e5a8fe80201bed0dff5cdb1ce6f4272b0cc92.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: FULL_DUPLEX_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | | | | | | | | | | | It's used to control a mysterious register on the DEC DE21040, see comment in drivers/net/ethernet/dec/tulip/de2104x.c Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/ff28a15f9154589788277807523aa71c45c24d28.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: CG_MAGIC isn't a magic numberнаб2022-09-244-4/+0
| | | | | | | | | | | | | | | | | | | | | | At least not in the sense described here: it delineates UFS cylinder groups, is never assigned, and the only macro that incorporates it (ufs_cg_chkmagic; the second one is unused) is used to detect CGs and protect from filesystem corruption Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/a508477cfeb18eca4a24c29836f809fe34f20467.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: zh: remove stale magic numbersнаб2022-09-242-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | English and it magic-number.rsts were updated when these were removed; the zh translations weren't This equalises these lists to be the same across all translations Automated: grep MAGIC Documentation/translations/process/zh_TW/magic-number.rst | while read -r mag _; do git grep -wF "$mag" | grep -vq \ '^Documentation.*magic-number.rst:' || sed -i "/^$mag/d" \ ./Documentation/{,translations/{zh_CN,zh_TW,it_IT}/}process/magic-number.rst ; done Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/5d9fa062178c45822a600a723f6f71fdb92011f3.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: zh: remove references to IrDAнаб2022-09-242-4/+0
| | | | | | | | | | | | | | | | | | | | These lines blame back to their first appearance which cites linux-2.6, and IrDA was finally fully removed in 4.17 with commit d64c2a76123f ("staging: irda: remove the irda network stack and drivers") Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/d07ce5b1bc173fd02b7e5b708beb81b9432745f8.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: sndmagic.h doesn't existнаб2022-09-244-17/+0
| | | | | | | | | | | | | | | | | | | | | | It was added in 2.5.5 and removed in a 2.6.9 "ALSA CVS update", pre-git, which states: Removal and replacement of magic memory allocators and casts (core part) Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/09e56999b0b323fb0add61f7dbd8c9f0a576561a.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: HFS is not a user of magic numbersнаб2022-09-244-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | In fs/hfs, the only magic is for delineating on-disk block types, of which HFS_DRVR_DESC_MAGIC HFS_MFS_SUPER_MAGIC are define-only, but they're out of scope for magic-number.rst Magic numbers as described there were all removed, along their defines, in the 2.6.4 "HFS rewrite", pre-git Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/e67cec702a7ab34a8c5f7966d930d793a097a90f.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * MIPS: remove define-only GDA_MAGIC, previously magic numberнаб2022-09-245-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The last user was removed in the 2.6.4 "MIPS mega-patch", pre-git Found with grep MAGIC Documentation/process/magic-number.rst | while read -r mag _; do git grep -wF "$mag" | grep -ve '^Documentation.*magic-number.rst:' \ -qe ':#define '"$mag" || git grep -wF "$mag" | while IFS=: read -r f _; do sed -i '/\b'"$mag"'\b/d' "$f"; done ; done Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/c2e7510beebdd698e20d0704712e623fad00fc1c.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Bluetooth: RFCOMM: remove define-only RFCOMM_TTY_MAGIC ex-magic-numberнаб2022-09-245-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Appeared in its present state in pre-git (2.5.41), never used Found with grep MAGIC Documentation/process/magic-number.rst | while read -r mag _; do git grep -wF "$mag" | grep -ve '^Documentation.*magic-number.rst:' \ -qe ':#define '"$mag" || git grep -wF "$mag" | while IFS=: read -r f _; do sed -i '/\b'"$mag"'\b/d' "$f"; done ; done Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/f6d375201dfd99416ea03b49b3dd40af56c1537e.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * a.out: remove define-only CMAGIC, previously magic numberнаб2022-09-245-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The last user was removed in 5.1 in commit 08300f4402ab ("a.out: remove core dumping support") but this is part of the UAPI headers, so this may want to either wait until a.out is removed entirely, or be removed from the magic number doc and silently remain in the header A cursory glance on DCS didn't show any user code actually using this value Found with grep MAGIC Documentation/process/magic-number.rst | while read -r mag _; do git grep -wF "$mag" | grep -ve '^Documentation.*magic-number.rst:' \ -qe ':#define '"$mag" || git grep -wF "$mag" | while IFS=: read -r f _; do sed -i '/\b'"$mag"'\b/d' "$f"; done ; done Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/9cbea062df7125ef43e2e0b2a67ede6ad1c5f27e.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Documentation: remove nonexistent magic numbersнаб2022-09-244-168/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The entire file blames back to the start of git (minus whitespace from the RST translation and a typo fix): * there are changelog comments for March 1994 through to Linux 2.5.74 * struct tty_ldisc is two pointers nowadays, so naturally no magic * GDA_MAGIC is defined but unused, and it's been this way since start-of-git * M3_CARD_MAGIC isn't defined, because commit d56b9b9c464a ("[PATCH] The scheduled removal of some OSS drivers") removed the entire driver in 2006 * CS_CARD_MAGIC likewise since commit b5d425c97f7d ("more scheduled OSS driver removal") in 2007 * KMALLOC_MAGIC and VMALLOC_MAGIC were removed in commit e38e0cfa48ac ("[ALSA] Remove kmalloc wrappers"), six months after start of git * SLAB_C_MAGIC has never even appeared in git (removed in 2.4.0-test3pre6) magic-number.rst is a low-value historial relic at best and misleading cruft at worst, so start with cleaning out ones that only appear therein Automated: grep MAGIC Documentation/process/magic-number.rst | while read -r mag _; do git grep -wF "$mag" | grep -vq '^Documentation.*magic-number.rst:' || sed -i "/^$mag/d" \ Documentation/{,translations/{zh_CN,zh_TW,it_IT}/}process/magic-number.rst done Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Link: https://lore.kernel.org/r/8389a7b85b5c660c6891b1740b5dacc53491a41b.1663280877.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * devcoredump : Serialize devcd_del workMukesh Ojha2022-09-241-2/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In following scenario(diagram), when one thread X running dev_coredumpm() adds devcd device to the framework which sends uevent notification to userspace and another thread Y reads this uevent and call to devcd_data_write() which eventually try to delete the queued timer that is not initialized/queued yet. So, debug object reports some warning and in the meantime, timer is initialized and queued from X path. and from Y path, it gets reinitialized again and timer->entry.pprev=NULL and try_to_grab_pending() stucks. To fix this, introduce mutex and a boolean flag to serialize the behaviour. cpu0(X) cpu1(Y) dev_coredump() uevent sent to user space device_add() ======================> user space process Y reads the uevents writes to devcd fd which results into writes to devcd_data_write() mod_delayed_work() try_to_grab_pending() del_timer() debug_assert_init() INIT_DELAYED_WORK() schedule_delayed_work() debug_object_fixup() timer_fixup_assert_init() timer_setup() do_init_timer() /* Above call reinitializes the timer to timer->entry.pprev=NULL and this will be checked later in timer_pending() call. */ timer_pending() !hlist_unhashed_lockless(&timer->entry) !h->pprev /* del_timer() checks h->pprev and finds it to be NULL due to which try_to_grab_pending() stucks. */ Link: https://lore.kernel.org/lkml/2e1f81e2-428c-f11f-ce92-eb11048cb271@quicinc.com/ Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/1663073424-13663-1-git-send-email-quic_mojha@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * debugfs: Only clobber mode/uid/gid on remount if askedBrian Norris2022-09-241-7/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <briannorris@chromium.org> Link: https://lore.kernel.org/r/20220912163042.v3.1.Icbd40fce59f55ad74b80e5d435ea233579348a78@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * kernfs: fix use-after-free in __kernfs_removeChristian A. Ehrhardt2022-09-241-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Syzkaller managed to trigger concurrent calls to kernfs_remove_by_name_ns() for the same file resulting in a KASAN detected use-after-free. The race occurs when the root node is freed during kernfs_drain(). To prevent this acquire an additional reference for the root of the tree that is removed before calling __kernfs_remove(). Found by syzkaller with the following reproducer (slab_nomerge is required): syz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0) r0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0) close(r0) pipe2(&(0x7f0000000140)={0xffffffffffffffff, <r1=>0xffffffffffffffff}, 0x800) mount$9p_fd(0x0, &(0x7f0000000040)='./file0\x00', &(0x7f00000000c0), 0x408, &(0x7f0000000280)={'trans=fd,', {'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c, {[{@cache_loose}, {@mmap}, {@loose}, {@loose}, {@mmap}], [{@mask={'mask', 0x3d, '^MAY_EXEC'}}, {@fsmagic={'fsmagic', 0x3d, 0x10001}}, {@dont_hash}]}}) Sample report: ================================================================== BUG: KASAN: use-after-free in kernfs_type include/linux/kernfs.h:335 [inline] BUG: KASAN: use-after-free in kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline] BUG: KASAN: use-after-free in __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 Read of size 2 at addr ffff8880088807f0 by task syz-executor.2/857 CPU: 0 PID: 857 Comm: syz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x6e/0x91 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x5e/0x5e5 mm/kasan/report.c:433 kasan_report+0xa3/0x130 mm/kasan/report.c:495 kernfs_type include/linux/kernfs.h:335 [inline] kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline] __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 __kernfs_remove fs/kernfs/dir.c:1356 [inline] kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589 sysfs_slab_add+0x133/0x1e0 mm/slub.c:5943 __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335 p9_client_create+0xd4d/0x1190 net/9p/client.c:993 v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126 legacy_get_tree+0xf1/0x200 fs/fs_context.c:610 vfs_get_tree+0x85/0x2e0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x675/0x1d00 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f725f983aed Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f725f0f7028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f725faa3f80 RCX: 00007f725f983aed RDX: 00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000 RBP: 00007f725f9f419c R08: 0000000020000280 R09: 0000000000000000 R10: 0000000000000408 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000006 R14: 00007f725faa3f80 R15: 00007f725f0d7000 </TASK> Allocated by task 855: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:470 kasan_slab_alloc include/linux/kasan.h:224 [inline] slab_post_alloc_hook mm/slab.h:727 [inline] slab_alloc_node mm/slub.c:3243 [inline] slab_alloc mm/slub.c:3251 [inline] __kmem_cache_alloc_lru mm/slub.c:3258 [inline] kmem_cache_alloc+0xbf/0x200 mm/slub.c:3268 kmem_cache_zalloc include/linux/slab.h:723 [inline] __kernfs_new_node+0xd4/0x680 fs/kernfs/dir.c:593 kernfs_new_node fs/kernfs/dir.c:655 [inline] kernfs_create_dir_ns+0x9c/0x220 fs/kernfs/dir.c:1010 sysfs_create_dir_ns+0x127/0x290 fs/sysfs/dir.c:59 create_dir lib/kobject.c:63 [inline] kobject_add_internal+0x24a/0x8d0 lib/kobject.c:223 kobject_add_varg lib/kobject.c:358 [inline] kobject_init_and_add+0x101/0x160 lib/kobject.c:441 sysfs_slab_add+0x156/0x1e0 mm/slub.c:5954 __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335 p9_client_create+0xd4d/0x1190 net/9p/client.c:993 v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126 legacy_get_tree+0xf1/0x200 fs/fs_context.c:610 vfs_get_tree+0x85/0x2e0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x675/0x1d00 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 857: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:367 [inline] ____kasan_slab_free mm/kasan/common.c:329 [inline] __kasan_slab_free+0x108/0x190 mm/kasan/common.c:375 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1754 [inline] slab_free_freelist_hook mm/slub.c:1780 [inline] slab_free mm/slub.c:3534 [inline] kmem_cache_free+0x9c/0x340 mm/slub.c:3551 kernfs_put.part.0+0x2b2/0x520 fs/kernfs/dir.c:547 kernfs_put+0x42/0x50 fs/kernfs/dir.c:521 __kernfs_remove.part.0+0x72d/0x960 fs/kernfs/dir.c:1407 __kernfs_remove fs/kernfs/dir.c:1356 [inline] kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589 sysfs_slab_add+0x133/0x1e0 mm/slub.c:5943 __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335 p9_client_create+0xd4d/0x1190 net/9p/client.c:993 v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126 legacy_get_tree+0xf1/0x200 fs/fs_context.c:610 vfs_get_tree+0x85/0x2e0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x675/0x1d00 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The buggy address belongs to the object at ffff888008880780 which belongs to the cache kernfs_node_cache of size 128 The buggy address is located 112 bytes inside of 128-byte region [ffff888008880780, ffff888008880800) The buggy address belongs to the physical page: page:00000000732833f8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8880 flags: 0x100000000000200(slab|node=0|zone=1) raw: 0100000000000200 0000000000000000 dead000000000122 ffff888001147280 raw: 0000000000000000 0000000000150015 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888008880680: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888008880700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff888008880780: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888008880800: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888008880880: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Acked-by: Tejun Heo <tj@kernel.org> Cc: stable <stable@kernel.org> # -rc3 Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> Link: https://lore.kernel.org/r/20220913121723.691454-1-lk@c--e.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Merge 1707c39ae309 ("Merge tag 'driver-core-6.0-rc7' of ↵Greg Kroah-Hartman2022-09-24366-2635/+3084
| |\ | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core") driver-core-next This merges the driver core changes in 6.0-rc7 into driver-core-next as they are needed here as well for testing. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * \ Merge 6.0-rc5 into driver-core-nextGreg Kroah-Hartman2022-09-12946-5079/+8849
| |\ \ | | | | | | | | | | | | | | | | | | | | We need the driver core and debugfs changes in this branch. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | driver core: remove make_class_name declarationGaosheng Cui2022-09-091-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | make_class_name has been removed since commit 39aba963d937 ("driver core: remove CONFIG_SYSFS_DEPRECATED_V2 but keep it for block devices"), so remove it. Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Link: https://lore.kernel.org/r/20220909063337.1146151-1-cuigaosheng1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | docs: update mediator information in CoC docsShuah Khan2022-09-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update mediator information in the CoC interpretation document. Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20220901212319.56644-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | Documentation: stable: Document alternative for referring upstream commit hashSalvatore Bonaccorso2022-09-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Additionally to the "commit <sha1> upstream." variant, "[ Upstream commit <sha1> ]" is used as well as alternative to refer to the upstream commit hash. Signed-off-by: Salvatore Bonaccorso <carnil@debian.org> Link: https://lore.kernel.org/r/20220901184328.4075701-1-carnil@debian.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | dyndbg: test DECLARE_DYNDBG_CLASSMAP, sysfs nodesJim Cromie2022-09-071-15/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Demonstrate use of DECLARE_DYNDBG_CLASSMAP macro, and expose them as sysfs-nodes for testing. For each of the 4 class-map-types: - declare a class-map of that type, - declare the enum corresponding to those class-names - share _base across 0..30 range - add a __pr_debug_cls() call for each class-name - declare 2 sysnodes for each class-map for 'p' flag, and future 'T' flag These declarations create the following sysfs parameter interface: :#> pwd /sys/module/test_dynamic_debug/parameters :#> ls T_disjoint_bits T_disjoint_names T_level_names T_level_num do_prints p_disjoint_bits p_disjoint_names p_level_names p_level_num NOTES: The local wrapper macro is an api candidate, but there are already too many parameters. OTOH, maybe related enum should be in there too, since it has _base inter-dependencies. The T_* params control the (future) T flag on the same class'd pr_debug callsites as their p* counterparts. Using them will fail, until the dyndbg-trace patches are added in. :#> echo 1 > T_disjoint [ 28.792489] dyndbg: disjoint: 0x1 > test_dynamic_debug.T_D2 [ 28.793848] dyndbg: query 0: "class D2_CORE +T" mod:* [ 28.795086] dyndbg: split into words: "class" "D2_CORE" "+T" [ 28.796467] dyndbg: op='+' [ 28.797148] dyndbg: unknown flag 'T' [ 28.798021] dyndbg: flags parse failed [ 28.798947] dyndbg: processed 1 queries, with 0 matches, 1 errs [ 28.800378] dyndbg: bit_0: -22 matches on class: D2_CORE -> 0x1 [ 28.801959] dyndbg: test_dynamic_debug.T_D2: updated 0x0 -> 0x1 [ 28.803974] dyndbg: total matches: -22 Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220904214134.408619-22-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | dyndbg: add drm.debug style (drm/parameters/debug) bitmap supportJim Cromie2022-09-072-0/+233
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add kernel_param_ops and callbacks to use a class-map to validate and apply input to a sysfs-node, which allows users to control classes defined in that class-map. This supports uses like: echo 0x3 > /sys/module/drm/parameters/debug IE add these: - int param_set_dyndbg_classes() - int param_get_dyndbg_classes() - struct kernel_param_ops param_ops_dyndbg_classes Following the model of kernel/params.c STANDARD_PARAM_DEFS, these are non-static and exported. This might be unnecessary here. get/set use an augmented kernel_param; the arg refs a new struct ddebug_class_param, which contains: - A ptr to user's state-store; a union of &ulong for drm.debug, &int for nouveau level debug. By ref'g the client's bit-state _var, code coordinates with existing code (like drm_debug_enabled) which uses it, so existing/remaining calls can work unchanged. Changing drm.debug to a ulong allows use of BIT() etc. - FLAGS: dyndbg.flags toggled by changes to bitmap. Usually just "p". - MAP: a pointer to struct ddebug_classes_map, which maps those class-names to .class_ids 0..N that the module is using. This class-map is declared & initialized by DECLARE_DYNDBG_CLASSMAP. - map-type: 4 enums DD_CLASS_TYPE_* select 2 input forms and 2 meanings. numeric input: DD_CLASS_TYPE_DISJOINT_BITS integer input, independent bits. ie: drm.debug DD_CLASS_TYPE_LEVEL_NUM integer input, 0..N levels classnames-list (comma separated) input: DD_CLASS_TYPE_DISJOINT_NAMES each name affects a bit, others preserved DD_CLASS_TYPE_LEVEL_NAMES names have level meanings, like kern_levels.h _NAMES - comma-separated classnames (with optional +-) _NUM - numeric input, 0-N expected _BITS - numeric input, 0x1F bitmap form expected _DISJOINT - bits are independent _LEVEL - (x<y) on bit-pos. _DISJOINT treats input like a bit-vector (ala drm.debug), and sets each bit accordingly. LEVEL is layered on top of this. _LEVEL treats input like a bit-pos:N, then sets bits(0..N)=1, and bits(N+1..max)=0. This applies (bit<N) semantics on top of disjoint bits. USAGES: A potentially typical _DISJOINT_NAMES use: echo +DRM_UT_CORE,+DRM_UT_KMS,-DRM_UT_DRIVER,-DRM_UT_ATOMIC \ > /sys/module/drm/parameters/debug_catnames A naive _LEVEL_NAMES use, with one class, that sets all in the class-map according to (x<y): : problem seen echo +L7 > /sys/module/test_dynamic_debug/parameters/p_level_names : problem solved echo -L1 > /sys/module/test_dynamic_debug/parameters/p_level_names Note this artifact: : this is same as prev cmd (due to +/-) echo L0 > /sys/module/test_dynamic_debug/parameters/p_level_names : this is "even-more" off, but same wo __pr_debug_class(L0, ".."). echo -L0 > /sys/module/test_dynamic_debug/parameters/p_level_names A stress-test/make-work usage (kid toggling a light switch): echo +L7,L0,L7,L0,L7,L0,L7,L0,L7,L0,L7,L0,L7 \ > /sys/module/test_dynamic_debug/parameters/p_level_names ddebug_apply_class_bitmap(): inside-fn, works on bitmaps, receives new-bits, finds diffs vs client-bitvector holding "current" state, and issues exec_query to commit the adjustment. param_set_dyndbg_classes(): interface fn, sends _NAMES to param_set_dyndbg_classnames() and returns, falls thru to handle _BITS, _NUM internally, and calls ddebug_apply_class_bitmap(). Finishes by updating state. param_set_dyndbg_classnames(): handles classnames-list in loop, calls ddebug_apply_class_bitmap for each, then updates state. NOTES: _LEVEL_ is overlay on _DISJOINT_; inputs are converted to a bitmask, by the callbacks. IOW this is possible, and possibly confusing: echo class V3 +p > control echo class V1 -p > control IMO thats ok, relative verbosity is an interface property. _LEVEL_NUM maps still need class-names, even though the names are not usable at the sysfs interface (unlike with _NAMES style). The names are the only way to >control the classes. - It must have a "V0" name, something below "V1" to turn "V1" off. __pr_debug_cls(V0,..) is printk, don't do that. - "class names" is required at the >control interface. - relative levels are not enforced at >control _LEVEL_NAMES bear +/- signs, which alters the on-bit-pos by 1. IOW, +L2 means L0,L1,L2, and -L2 means just L0,L1. This kinda spoils the readback fidelity, since the L0 bit gets turned on by any use of any L*, except "-L0". All the interface uncertainty here pertains to the _NAMES features. Nobody has actually asked for this, so its practical (if a little tedious) to split it out. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220904214134.408619-21-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | doc-dyndbg: edit dynamic-debug-howto for brevity, audienceJim Cromie2022-09-071-118/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rework/modernize docs: - use /proc/dynamic_debug/control in examples its *always* there (when dyndbg is config'd), even when <debugfs> is not. drop <debugfs> talk, its a distraction here. - alias ddcmd='echo $* > /proc/dynamic_debug/control focus on args: declutter, hide boilerplate, make pwd independent. - swap sections: Viewing before Controlling. control file as Catalog. - focus on use by a system administrator add an alias to make examples more readable drop grep-101 lessons, admins know this. - use init/main.c as 1st example, thread it thru doc where useful. everybodys kernel boots, runs these. - add *prdbg* api section to the bottom of the file, its for developers more than admins. move list of api functions there. - simplify - drop extra words, phrases, sentences. - add "decorator" flags line to unify "prefix", trim fmlt descriptions CC: linux-doc@vger.kernel.org Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220904214134.408619-20-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | doc-dyndbg: describe "class CLASS_NAME" query supportJim Cromie2022-09-071-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an explanation of the new "class CLASS_NAME" syntax and meaning, noting that the module determines if CLASS_NAME applies to it. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220904214134.408619-19-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | dyndbg: validate class FOO by checking with moduleJim Cromie2022-09-071-8/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add module-to-class validation: #> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control If a query has "class FOO", then ddebug_find_valid_class(), called from ddebug_change(), requires that FOO is known to module X, otherwize the query is skipped entirely for X. This protects each module's class-space, other than the default:31. The authors' choice of FOO is highly selective, giving isolation and/or coordinated sharing of FOOs. For example, only DRM modules should know and respond to DRM_UT_KMS. So this, combined with module's opt-in declaration of known classes, effectively privatizes the .class_id space for each module (or coordinated set of modules). Notes: For all "class FOO" queries, ddebug_find_valid_class() is called, it returns the map matching the query, and sets valid_class via an *outvar). If no "class FOO" is supplied, valid_class = _CLASS_DFLT. This insures that legacy queries do not trample on new class'd callsites, as they get added. Also add a new column to control-file output, displaying non-default class-name (when found) or the "unknown _id:", if it has not been (correctly) declared with one of the declarator macros. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220904214134.408619-18-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | dyndbg: add ddebug_attach_module_classesJim Cromie2022-09-071-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add ddebug_attach_module_classes(), call it from ddebug_add_module(). It scans the classes/section its given, finds records where the module-name matches the module being added, and adds them to the module's maps list. No locking here, since the record isn't yet linked into the ddebug_tables list. It is called indirectly from 2 sources: - from load_module(), where it scans the module's __dyndbg_classes section, which contains DYNAMIC_DEBUG_CLASSES definitions from just the module. - from dynamic_debug_init(), where all DYNAMIC_DEBUG_CLASSES definitions of each builtin module have been packed together. This is why ddebug_attach_module_classes() checks module-name. NOTES Its (highly) likely that builtin classes will be ordered by module name (just like prdbg descriptors are in the __dyndbg section). So the list can be replaced by a vector (ptr + length), which will work for loaded modules too. This would imitate whats currently done for the _ddebug descriptors. That said, converting to vector,len is close to pointless; a small minority of modules will ever define a class-map, and almost all of them will have only 1 or 2 class-maps, so theres only a couple dozen pointers to save. TODO: re-evaluate for lines removable. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220904214134.408619-17-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | kernel/module: add __dyndbg_classes sectionJim Cromie2022-09-074-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add __dyndbg_classes section, using __dyndbg as a model. Use it: vmlinux.lds.h: KEEP the new section, which also silences orphan section warning on loadable modules. Add (__start_/__stop_)__dyndbg_classes linker symbols for the c externs (below). kernel/module/main.c: - fill new fields in find_module_sections(), using section_objs() - extend callchain prototypes to pass classes, length load_module(): pass new info to dynamic_debug_setup() dynamic_debug_setup(): new params, pass through to ddebug_add_module() dynamic_debug.c: - add externs to the linker symbols. ddebug_add_module(): - It currently builds a debug_table, and *will* find and attach classes. dynamic_debug_init(): - add class fields to the _ddebug_info cursor var: di. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220904214134.408619-16-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | | dyndbg: add DECLARE_DYNDBG_CLASSMAP macroJim Cromie2022-09-071-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using DECLARE_DYNDBG_CLASSMAP, modules can declare up to 31 classnames. By doing so, they authorize dyndbg to manipulate class'd prdbgs (ie: __pr_debug_cls, and soon drm_*dbg), ala:: :#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control The macro declares and initializes a static struct ddebug_class_map:: - maps approved class-names to class_ids used in module, by array order. forex: DRM_UT_* - class-name vals allow validation of "class FOO" queries using macro is opt-in - enum class_map_type - determines interface, behavior Each module has its own class-type and class_id space, and only known class-names will be authorized for a manipulation. Only DRM modules should know and respont to this: :#> echo class DRM_UT_CORE +p > control # across all modules pr_debugs (with default class_id) are still controllable as before. DECLARE_DYNDBG_CLASSMAP(_var, _maptype, _base, classes...) is:: _var: name of the static struct var. user passes to module_param_cb() if they want a sysfs node. _maptype: this is hard-coded to DD_CLASS_TYPE_DISJOINT_BITS for now. _base: usually 0, it allows splitting 31 classes into subranges, so that multiple classes / sysfs-nodes can share the module's class-id space. classes: list of class_name strings, these are mapped to class-ids starting at _base. This class-names list must have a corresponding ENUM, with SYMBOLS that match the literals, and 1st enum val = _base. enum class_map_type has 4 values, on 2 factors:: - classes are disjoint/independent vs relative/x<y/verbosity. disjoint is basis, verbosity by overlay. - input NUMBERS vs [+-]CLASS_NAMES uints, ideally hex. vs +DRM_UT_CORE,-DRM_UT_KMS DD_CLASS_TYPE_DISJOINT_BITS: classes are separate, one per bit. expecting hex input. built for drm.debug, basis for other types. DD_CLASS_TYPE_DISJOINT_NAMES: input is a CSV of [+-]CLASS_NAMES, classes are independent, like DISJOINT DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0-N. 0 implies silence. use printk to break that. relative levels applied on bitmaps. DD_CLASS_TYPE_LEVEL_NAMES: input is a CSV of [+-]CLASS_NAMES, names like: ERR,WARNING,NOTICE,INFO,DEBUG avoiding EMERG,ALERT,CRIT,ERR - no point. NOTES: The macro places the initialized struct ddebug_class_map into the __dyndbg_classes section. That draws an 'orphan' warning which we handle in the next commit. The struct attributes are necessary: __aligned(8) fixed null-ptr derefs, and __used is needed by drm drivers, which declare class-maps, but don't also declare a sysfs-param, and thus dont ref the classmap. The __used insures that the linkage is made, then the class-map is found at load-time. While its possible to handle both NAMES and NUMBERS in the same sys-interface, there is ambiguity to avoid, by disallowing them together. Later, if ambiguities are resolved, 2 new enums can permit both inputs, on verbose & independent types separately, and authors can select the interface style they like. The plan is to implement LEVELS in the callbacks, outside of ddebug_exec_query(), which for simplicity will treat the CLASSES in the map as disjoint. The callbacks can see map-type, and apply ++/-- loops (or bitops) to force the relative meanings across the class-bitmap. RFC: That leaves 2 issues: 1. doing LEVELs in callbacks means that the native >control interface doesn't enforce the LEVELS relationship, so you could confusingly have V3 enabled, but V1 disabled. OTOH, the control iface already allows infinite tweaking of the underlying callsites; sysfs node readback can only tell the user what they previously wrote. 2. All dyndbg >control reduces to a query/command, includes +/-, which is at-root a kernel patching operation with +/- semantics. And the _NAMES handling exposes it to the user, making it API-adjacent. And its not just >control where +/- gets used (which is settled), the new place is with sysfs-nodes exposing _*_NAMES classes, and here its subtly different. _DISJOINT_NAMES: is simple, independent _LEVEL_NAMES: masks-on bits 0 .. N-1, N..max off # turn on L3,L2,L1 others off echo +L3 > /sys/module/test_dynamic_debug/parameters/p_level_names # turn on L2,L1 others off echo -L3 > /sys/module/test_dynamic_debug/parameters/p_level_names IOW, the - changes the threshold-on bitpos by 1. Alternatively, we could treat the +/- as half-duplex, where -L3 turns off L>2 (and ignores L1), and +L2 would turn on L<=2 (and ignore others). Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220904214134.408619-15-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-11 17:22:41 +0100