[PATCH v9-resend 52/54] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN
end of official submission. Time for some quality CI Signed-off-by: Jim Cromie --- drivers/gpu/drm/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index d0aa277fc3bf..c508c0834641 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -56,8 +56,7 @@ config DRM_DEBUG_MM config DRM_USE_DYNAMIC_DEBUG bool "use dynamic debug to implement drm.debug" - default n - depends on BROKEN + default y depends on DRM depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE depends on JUMP_LABEL -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 42/54] drm-dyndbg: add DRM_CLASSMAP_USE to etnaviv
etnaviv has 5 DRM_UT_CORE debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module has class'd debugs as well as plain-old pr_debug()s Signed-off-by: Jim Cromie --- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c index 6500f3999c5f..1d1ddbedcb5a 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c @@ -25,6 +25,8 @@ #include "etnaviv_mmu.h" #include "etnaviv_perfmon.h" +DRM_CLASSMAP_USE(drm_debug_classes); + /* * DRM operations: */ -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 39/54] drm-dyndbg: add DRM_CLASSMAP_USE to virtio_gpu
virtio_gpu has 10 DRM_UT_CORE debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module has class'd debugs. Signed-off-by: Jim Cromie --- drivers/gpu/drm/virtio/virtgpu_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index 188e126383c2..d69d517de2a3 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -44,6 +44,8 @@ static const struct drm_driver driver; static int virtio_gpu_modeset = -1; +DRM_CLASSMAP_USE(drm_debug_classes); + MODULE_PARM_DESC(modeset, "Disable/Enable modesetting"); module_param_named(modeset, virtio_gpu_modeset, int, 0400); -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 36/54] drm-dyndbg: DRM_CLASSMAP_USE in nouveau
Following the dyndbg-api-fix, replace DECLARE_DYNDBG_CLASSMAP with DRM_CLASSMAP_USE. This refs the defined & exported classmap, rather than re-declaring it redundantly, and error-prone-ly. This resolves the appearance of "class:_UNKNOWN_" in the control file for the driver's drm_dbg()s. Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers.") Signed-off-by: Jim Cromie --- drivers/gpu/drm/nouveau/nouveau_drm.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index a947e1d5f309..27995c0c9b31 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -72,17 +72,7 @@ #include "nouveau_uvmm.h" #include "nouveau_sched.h" -DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0, - "DRM_UT_CORE", - "DRM_UT_DRIVER", - "DRM_UT_KMS", - "DRM_UT_PRIME", - "DRM_UT_ATOMIC", - "DRM_UT_VBL", - "DRM_UT_STATE", - "DRM_UT_LEASE", - "DRM_UT_DP", - "DRM_UT_DRMRES"); +DRM_CLASSMAP_USE(drm_debug_classes); MODULE_PARM_DESC(config, "option string to pass to driver core"); static char *nouveau_config; -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 45/54] drm-dyndbg: add DRM_CLASSMAP_USE to vmwgfx driver
The vmwgfx driver has a number of DRM_UT_* debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module uses them. Signed-off-by: Jim Cromie --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 823d8d2da17c..fd6cd62608a9 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -277,6 +277,8 @@ static int vmw_probe(struct pci_dev *, const struct pci_device_id *); static int vmwgfx_pm_notifier(struct notifier_block *nb, unsigned long val, void *ptr); +DRM_CLASSMAP_USE(drm_debug_classes); + MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages"); module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600); MODULE_PARM_DESC(force_coherent, "Force coherent TTM pages"); -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 35/54] drm-dyndbg: DRM_CLASSMAP_USE in drm_dp_helper
Following the dyndbg-api-fix, replace DECLARE_DYNDBG_CLASSMAP with DRM_CLASSMAP_USE. This refs the defined & exported classmap, rather than re-declaring it redundantly, and error-prone-ly. This resolves the appearance of "class:_UNKNOWN_" in the control file for the driver's drm_dbg()s. Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers.") Signed-off-by: Jim Cromie --- drivers/gpu/drm/display/drm_dp_helper.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c index 79a615667aab..26e01845531e 100644 --- a/drivers/gpu/drm/display/drm_dp_helper.c +++ b/drivers/gpu/drm/display/drm_dp_helper.c @@ -41,17 +41,7 @@ #include "drm_dp_helper_internal.h" -DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0, - "DRM_UT_CORE", - "DRM_UT_DRIVER", - "DRM_UT_KMS", - "DRM_UT_PRIME", - "DRM_UT_ATOMIC", - "DRM_UT_VBL", - "DRM_UT_STATE", - "DRM_UT_LEASE", - "DRM_UT_DP", - "DRM_UT_DRMRES"); +DRM_CLASSMAP_USE(drm_debug_classes); struct dp_aux_backlight { struct backlight_device *base; -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 44/54] drm-dyndbg: add DRM_CLASSMAP_USE to radeon
radeon has some DRM_UT_* debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg about its use of the class'd debugs. Signed-off-by: Jim Cromie --- drivers/gpu/drm/radeon/radeon_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 7bf08164140e..d22308328c76 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -247,6 +247,8 @@ int radeon_cik_support = 1; MODULE_PARM_DESC(cik_support, "CIK support (1 = enabled (default), 0 = disabled)"); module_param_named(cik_support, radeon_cik_support, int, 0444); +DRM_CLASSMAP_USE(drm_debug_classes); + static struct pci_device_id pciidlist[] = { radeon_PCI_IDS }; -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 43/54] drm-dyndbg: add DRM_CLASSMAP_USE to gma500 driver
The gma500 has 126 DRM_UT_* debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module has class'd debugs. Signed-off-by: Jim Cromie --- drivers/gpu/drm/gma500/psb_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c index 8b64f61ffaf9..5e03ac7ff433 100644 --- a/drivers/gpu/drm/gma500/psb_drv.c +++ b/drivers/gpu/drm/gma500/psb_drv.c @@ -39,6 +39,8 @@ static const struct drm_driver driver; static int psb_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent); +DRM_CLASSMAP_USE(drm_debug_classes); + /* * The table below contains a mapping of the PCI vendor ID and the PCI Device ID * to the different groups of PowerVR 5-series chip designs -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 47/54] drm-dyndbg: add DRM_CLASSMAP_USE to udl driver
The udl driver has a number of DRM_UT_* debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module uses them. Signed-off-by: Jim Cromie --- drivers/gpu/drm/udl/udl_main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c index 3ebe2ce55dfd..ba57c14454e5 100644 --- a/drivers/gpu/drm/udl/udl_main.c +++ b/drivers/gpu/drm/udl/udl_main.c @@ -19,6 +19,8 @@ #define NR_USB_REQUEST_CHANNEL 0x12 +DRM_CLASSMAP_USE(drm_debug_classes); + #define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE) #define WRITES_IN_FLIGHT (20) #define MAX_VENDOR_DESCRIPTOR_SIZE 256 -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 41/54] drm-dyndbg: add DRM_CLASSMAP_USE to bochs
tiny/bochs has 5 DRM_UT_* debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module has class'd debugs. Signed-off-by: Jim Cromie --- drivers/gpu/drm/tiny/bochs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c index c23c9f0cf49c..ee98fab5597e 100644 --- a/drivers/gpu/drm/tiny/bochs.c +++ b/drivers/gpu/drm/tiny/bochs.c @@ -54,6 +54,8 @@ static int bochs_modeset = -1; static int defx = 1024; static int defy = 768; +DRM_CLASSMAP_USE(drm_debug_classes); + module_param_named(modeset, bochs_modeset, int, 0444); MODULE_PARM_DESC(modeset, "enable/disable kernel modesetting"); -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 48/54] drm-dyndbg: add DRM_CLASSMAP_USE to mgag200 driver
The mgag200 driver has a number of DRM_UT_* debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module uses them. Signed-off-by: Jim Cromie --- drivers/gpu/drm/mgag200/mgag200_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c b/drivers/gpu/drm/mgag200/mgag200_drv.c index 573dbe256aa8..88c5e24cc894 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.c +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c @@ -25,6 +25,8 @@ static int mgag200_modeset = -1; MODULE_PARM_DESC(modeset, "Disable/Enable modesetting"); module_param_named(modeset, mgag200_modeset, int, 0400); +DRM_CLASSMAP_USE(drm_debug_classes); + int mgag200_init_pci_options(struct pci_dev *pdev, u32 option, u32 option2) { struct device *dev = >dev; -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 53/54] dyndbg: tighten up kdoc about DYNDBG_CLASSMAP_* macros
The DYNDBG_CLASSMAP_DEFINE expects a list of classnames, and maps them to consecutive classids starting at _base. That 1- list-of-classnames can be syntactically replaced by a 2- designated-initializers-list/map. But this creates ambiguity. The 1st thing the macro does: static const char *_var##_classnames[] = { __VA_ARGS__ }; This construct accepts either list form, cannot distinguish between them, and they place data differently. 1. puts the string values into array[0..N-1] 2. puts them into array[_base..N+_base-1] 2 wastes 0.._base-1 indices, and more importantly, also spec's _base twice: as a parameter, and then in the designated-initializers-list/map. Further, the code is written for a contiguous range of classnames and classids, and passing a map allows casual violation of this reasonable design choice. In particular, DRM_UT_* is a contiguous range, and each maps to a bit in drm.debug. The macro interface shouldn't suggest a sparse map is possible. So reword DYNDBG_CLASSMAP_* macro kdoc to more actively guide reader away from designated initializers here. TBD probably squash this back into the patchset. CC: ville.syrj...@linux.intel.com Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 52 +-- 1 file changed, 31 insertions(+), 21 deletions(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index c958085e0df4..d75a5d3ae388 100644 --- a/include/linux/dynamic_debug.h +++ b/include/linux/dynamic_debug.h @@ -80,15 +80,22 @@ struct ddebug_class_map { enum ddebug_class_map_type map_type; }; +/* + * modules using dyndbg-classmaps must invoke either + */ /** - * DYNDBG_CLASSMAP_DEFINE - define a set of debug-classes used by a module. + * DYNDBG_CLASSMAP_DEFINE - define debug classes used by a module. * @_var: name of the classmap, exported for other modules coordinated use. - * @_type: enum ddebug_class_map_type, chooses bits/verbose, numeric/names. - * @_base: offset of 1st class-name, used to share 0..62 classid space - * @classes: vals are stringified enum-vals, like DRM_UT_* + * @_type: enum ddebug_class_map_type: DISJOINT - independent, LEVEL - v2>v1 + * @_base: reserve N classids starting at _base, to split 0..62 classid space + * @classes: names of the N classes. * - * Defines and exports a struct ddebug_class_map whose @classes are - * used to validate a "class FOO .." >control command on the module + * This tells dyndbg what classids the module is using, by mapping + * names onto them. This qualifies "class NAME" >controls on the + * defining module, ignoring unknown names. + * + * The @classes also name the bits 0.. in any CLASSMAP_PARAM referring + * to the classmap. */ #define __DYNDBG_CLASSMAP_DEFINE(_var, _maptype, _base, ...) \ static const char *_var##_classnames[] = { __VA_ARGS__ }; \ @@ -131,9 +138,9 @@ struct ddebug_class_user { * DYNDBG_CLASSMAP_USE - refer to a classmap, DEFINEd elsewhere. * @_var: name of the exported classmap var * - * This registers a module's use of another module's classmap defn, so - * dyndbg can authorize "class DRM_CORE ..." >control commands upon - * this module. + * This tells dyndbg that the module has prdbgs with classids defined + * in the named classmap. This qualifies "class NAME" >controls on + * the user module, ignoring unknown names. */ #define DYNDBG_CLASSMAP_USE(_var) \ DYNDBG_CLASSMAP_USE_(_var, __UNIQUE_ID(ddebug_class_user)) @@ -165,27 +172,30 @@ struct ddebug_class_param { }; /** - * DYNDBG_CLASSMAP_PARAM - wrap a dyndbg-classmap with a controlling sys-param - * @_name sysfs node name - * @_var name of the struct classmap var defining the controlled classes - * @_flags flags to be toggled, typically just 'p' + * DYNDBG_CLASSMAP_PARAM - control a ddebug-classmap from a sys-param + * @_name: sysfs node name + * @_var: name of the classmap var defining the controlled classes/bits + * @_flags: flags to be toggled, typically just 'p' * * Creates a sysfs-param to control the classes defined by the - * classmap. Keeps bits in a private/static + * exported classmap, with bits 0..N-1 mapped to the classes named. + * This version keeps class-state in a private long int. */ #define DYNDBG_CLASSMAP_PARAM(_name, _var, _flags) \ static unsigned long _name##_bvec; \ __DYNDBG_CLASSMAP_PARAM(_name, _name##_bvec, _var, _flags) /** - * DYNDBG_CLASSMAP_PARAM_REF - wrap a dyndbg-classmap with a controlling sys-param - * @_name sysfs node name - * @_bits name of the module's unsigned long bit-vector, ex: __drm_debug - * @_var name of the struct classmap var defining the controlled classes - * @_flags flags to be toggled, typically just 'p' + * DYNDBG_CLASSMAP_PARAM_REF - wrap a classmap with a controlling sys-param + * @_name: sys
[PATCH v9-resend 54/54] docs-dyndbg: improve howto classmaps api section
reword the classmaps-api section to better explain how it supports DRM, and (a little bit) to steer clear of designated-inits in the _DEFINE description. probably just squash this back in Signed-off-by: Jim Cromie --- .../admin-guide/dynamic-debug-howto.rst | 64 +++ 1 file changed, 39 insertions(+), 25 deletions(-) diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index ccf3704f2143..1ffab6be07fc 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -390,42 +390,56 @@ in case ``prefix_str`` is built dynamically. Dynamic Debug classmaps === -Dyndbg allows selection/grouping of *prdbg* callsites using structural -info: module, file, function, line. Classmaps allow authors to add -their own domain-oriented groupings using class-names. Classmaps are -exported, so they referencable from other modules. +Classmaps adds the "class" keyword, which selects prdbgs based on +author supplied, domain-oriented names; this complements the code +organizational keywords: module, file, function, line. + +The main difference from the others: class'd prdbgs must be named to +be changed. This protects them from generic overwrite: + + # IOW this cannot undo any DRM.debug settings + :#> ddcmd -p + +So each class must be enabled individually (no wildcards): - # enable classes individually :#> ddcmd class DRM_UT_CORE +p :#> ddcmd class DRM_UT_KMS +p # or more selectively :#> ddcmd class DRM_UT_CORE module drm +p -The "class FOO" syntax protects class'd prdbgs from generic overwrite:: - - # IOW this doesn't wipe any DRM.debug settings - :#> ddcmd -p +Or the legacy/normal (convenient) way: -To support the DRM.debug parameter, DYNDBG_CLASSMAP_PARAM* updates all -classes in a classmap, mapping param-bits 0..N onto the classes: -DRM_UT_<*> for the DRM use-case. + :#> echo 0x1ff > /sys/module/drm/parameters/debug Dynamic Debug Classmap API == -DYNDBG_CLASSMAP_DEFINE - modules use this to create classmaps, naming -each of the classes (stringified enum-symbols: "DRM_UT_<*>"), and -type, and mapping the class-names to consecutive _class_ids. +The classmap API is closely modeled on DRM, which has: + +enum drm_debug_category: DRM_UT_* // 10 independent categories. +dyndbg's .classid encodes that directly, allowing 0..62 classes + +DRM has ~5k calls like: drm_dbg(DRM_UT_KMS, "kms msg"); +these are unchanged, even in argtype, since classid === category. + +DRM controls the classes together via sysfs; bits 0..9 control the +classes independently. + +Its expected that other classmap users will also provide debug-macros +using an enum-defined categorization scheme like DRM's, and dyndbg can +be adapted under them similarly. + +DYNDBG_CLASSMAP_DEFINE(var,type,_base,classnames) - this maps +classnames onto class-ids starting at _base, it also maps the +names onto CLASSMAP_PARAM bits 0..N. -By doing so, modules tell dyndbg that they have prdbgs with those -class_ids, and they authorize dyndbg to accept "class FOO" for the -module defining the classmap, and its contained classnames. +DYNDBG_CLASSMAP_USE(var) - modules call this to refer to the var +_DEFINEd elsewhere (and exported). -DYNDBG_CLASSMAP_USE - drm drivers invoke this to ref the CLASSMAP that -drm DEFINEs. This shares the classmap definition, and authorizes -dyndbg to apply changes to the user module's class'd pr_debugs. It -also tells dyndbg how to initialize the user's prdbgs at modprobe, -based upon the current setting of the parent's controlling param. +Classmaps are opt-in: modules invoke _DEFINE or _USE to authorize +dyndbg to update those classes. "class FOO" queries are validated +against the classes, this finds the classid to alter; classes are not +directly selectable by their classid. There are 2 types of classmaps: @@ -436,9 +450,9 @@ DYNDBG_CLASSMAP_PARAM - modelled after module_param_cb, it refers to a DEFINEd classmap, and associates it to the param's data-store. This state is then applied to DEFINEr and USEr modules when they're modprobed. -This interface also enforces the DD_CLASS_TYPE_LEVEL_NUM relation +The PARAM interface also enforces the DD_CLASS_TYPE_LEVEL_NUM relation amongst the contained classnames; all classes are independent in the -control parser itself. +control parser itself; there is no implied meaning in names like "V4". Modules or module-groups (drm & drivers) can define multiple classmaps, as long as they share the limited 0..62 per-module-group -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 28/54] dyndbg-selftest: reduce default verbosity
Remove the '-v' arg from the tests in test_mod_submod(). Setting V=1 in the environment turns it back on, for all tests. Signed-off-by: Jim Cromie --- .../dynamic_debug/dyndbg_selftest.sh | 23 +-- 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh index d09ef26b2308..b3d7155cb45c 100755 --- a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh +++ b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh @@ -168,7 +168,6 @@ function error_log_ref { } function ifrmmod { -lsmod | grep $1 2>&1>/dev/null || echo $1 not there lsmod | grep $1 2>&1>/dev/null && rmmod $1 } @@ -316,13 +315,13 @@ function test_mod_submod { # change classes again, this time submod too ddcmd class,D2_CORE,+mf%class,D2_KMS,+lt%class,D2_ATOMIC,+ml "# add some prefixes" -check_match_ct =pmf 1 -v -check_match_ct =plt 1 -v -check_match_ct =pml 1 -v +check_match_ct =pmf 1 +check_match_ct =plt 1 +check_match_ct =pml 1 # submod changed too -check_match_ct =mf 1 -v -check_match_ct =lt 1 -v -check_match_ct =ml 1 -v +check_match_ct =mf 1 +check_match_ct =lt 1 +check_match_ct =ml 1 # now work the classmap-params # fresh start, to clear all above flags (test-fn limits) @@ -333,25 +332,25 @@ function test_mod_submod { echo 1 > /sys/module/test_dynamic_debug/parameters/p_disjoint_bits echo 4 > /sys/module/test_dynamic_debug/parameters/p_level_num # 2 mods * ( V1-3 + D2_CORE ) -check_match_ct =p 8 -v +check_match_ct =p 8 echo 3 > /sys/module/test_dynamic_debug/parameters/p_disjoint_bits echo 0 > /sys/module/test_dynamic_debug/parameters/p_level_num # 2 mods * ( D2_CORE, D2_DRIVER ) -check_match_ct =p 4 -v +check_match_ct =p 4 echo 0x16 > /sys/module/test_dynamic_debug/parameters/p_disjoint_bits echo 0 > /sys/module/test_dynamic_debug/parameters/p_level_num # 2 mods * ( D2_DRIVER, D2_KMS, D2_ATOMIC ) -check_match_ct =p 6 -v +check_match_ct =p 6 # recap DRM_USE_DYNAMIC_DEBUG regression ifrmmod test_dynamic_debug_submod ifrmmod test_dynamic_debug # set super-mod params modprobe test_dynamic_debug p_disjoint_bits=0x16 p_level_num=5 -check_match_ct =p 7 -v +check_match_ct =p 7 modprobe test_dynamic_debug_submod # see them picked up by submod -check_match_ct =p 14 -v +check_match_ct =p 14 } tests_list=( -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 30/54] drm-dyndbg: adapt drm core to use dyndbg classmaps-v2
dyndbg's CLASSMAP-v1 api was broken; DECLARE_DYNDBG_CLASSMAP tried to do too much. Its replaced by DRM_CLASSMAP_DEFINE, which creates & EXPORTs the classmap when CONFIG_DRM_USE_DYNAMIC_DEBUG=y, for direct reference by drivers. The drivers still use DECLARE_DYNDBG_CLASSMAP for now, so they still redundantly re-declare the classmap, but we can convert the drivers later to DYNDBG_CLASSMAP_USE Signed-off-by: Jim Cromie --- drivers/gpu/drm/drm_print.c | 25 + include/drm/drm_print.h | 8 2 files changed, 21 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c index cf2efb44722c..41f167082042 100644 --- a/drivers/gpu/drm/drm_print.c +++ b/drivers/gpu/drm/drm_print.c @@ -55,18 +55,19 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug cat #if !defined(CONFIG_DRM_USE_DYNAMIC_DEBUG) module_param_named(debug, __drm_debug, ulong, 0600); #else -/* classnames must match vals of enum drm_debug_category */ -DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0, - "DRM_UT_CORE", - "DRM_UT_DRIVER", - "DRM_UT_KMS", - "DRM_UT_PRIME", - "DRM_UT_ATOMIC", - "DRM_UT_VBL", - "DRM_UT_STATE", - "DRM_UT_LEASE", - "DRM_UT_DP", - "DRM_UT_DRMRES"); +/* classnames must match value-symbols of enum drm_debug_category */ +DRM_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, + DRM_UT_CORE, + "DRM_UT_CORE", + "DRM_UT_DRIVER", + "DRM_UT_KMS", + "DRM_UT_PRIME", + "DRM_UT_ATOMIC", + "DRM_UT_VBL", + "DRM_UT_STATE", + "DRM_UT_LEASE", + "DRM_UT_DP", + "DRM_UT_DRMRES"); static struct ddebug_class_param drm_debug_bitmap = { .bits = &__drm_debug, diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index 089950ad8681..b467ee67a281 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -140,6 +140,14 @@ enum drm_debug_category { DRM_UT_DRMRES }; +#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG +#define DRM_CLASSMAP_DEFINE(...) DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__) +#define DRM_CLASSMAP_USE(name) DYNDBG_CLASSMAP_USE(name) +#else +#define DRM_CLASSMAP_DEFINE(...) +#define DRM_CLASSMAP_USE(name) +#endif + static inline bool drm_debug_enabled_raw(enum drm_debug_category category) { return unlikely(__drm_debug & BIT(category)); -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 29/54] drm: use correct ccflags-y spelling
Incorrectly spelled CFLAGS- failed to add -DDYNAMIC_DEBUG_MODULE, which broke builds with: CONFIG_DRM_USE_DYNAMIC_DEBUG=y CONFIG_DYNAMIC_DEBUG_CORE=y CONFIG_DYNAMIC_DEBUG=n Also add subdir-ccflags so that all drivers pick up the addition. Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro") Signed-off-by: Jim Cromie --- drivers/gpu/drm/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index f9ca4f8fa6c5..78b464cd4348 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -3,7 +3,8 @@ # Makefile for the drm device driver. This driver provides support for the # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. -CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE +ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG)+= -DDYNAMIC_DEBUG_MODULE +subdir-ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE # Unconditionally enable W=1 warnings locally # --- begin copy-paste W=1 warnings from scripts/Makefile.extrawarn -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 51/54] drm-dyndbg: add DRM_CLASSMAP_USE to the drm_gem_shmem_helper driver
The drm_gem_shmem_helper driver has a number of DRM_UT_* debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module uses them. Signed-off-by: Jim Cromie --- drivers/gpu/drm/drm_gem_shmem_helper.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 53c003983ad1..2b269ae9ea18 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -22,6 +22,8 @@ #include #include +DRM_CLASSMAP_USE(drm_debug_classes); + MODULE_IMPORT_NS(DMA_BUF); /** -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 49/54] drm-dyndbg: add DRM_CLASSMAP_USE to the gud driver
The gud driver has a number of DRM_UT_* debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module uses them. Signed-off-by: Jim Cromie --- drivers/gpu/drm/gud/gud_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c index 9d7bf8ee45f1..5b555045fce4 100644 --- a/drivers/gpu/drm/gud/gud_drv.c +++ b/drivers/gpu/drm/gud/gud_drv.c @@ -31,6 +31,8 @@ #include "gud_internal.h" +DRM_CLASSMAP_USE(drm_debug_classes); + /* Only used internally */ static const struct drm_format_info gud_drm_format_r1 = { .format = GUD_DRM_FORMAT_R1, -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 50/54] drm-dyndbg: add DRM_CLASSMAP_USE to the qxl driver
The qxl driver has a number of DRM_UT_* debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module uses them. Signed-off-by: Jim Cromie --- drivers/gpu/drm/qxl/qxl_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c index beee5563031a..1971bfa8a8a6 100644 --- a/drivers/gpu/drm/qxl/qxl_drv.c +++ b/drivers/gpu/drm/qxl/qxl_drv.c @@ -65,6 +65,8 @@ module_param_named(modeset, qxl_modeset, int, 0400); MODULE_PARM_DESC(num_heads, "Number of virtual crtcs to expose (default 4)"); module_param_named(num_heads, qxl_num_crtc, int, 0400); +DRM_CLASSMAP_USE(drm_debug_classes); + static struct drm_driver qxl_driver; static struct pci_driver qxl_pci_driver; -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 46/54] drm-dyndbg: add DRM_CLASSMAP_USE to vkms driver
The vkms driver has a number of DRM_UT_* debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module uses them. Signed-off-by: Jim Cromie --- drivers/gpu/drm/vkms/vkms_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c index dd0af086e7fa..086797c4b82b 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.c +++ b/drivers/gpu/drm/vkms/vkms_drv.c @@ -39,6 +39,8 @@ static struct vkms_config *default_config; +DRM_CLASSMAP_USE(drm_debug_classes); + static bool enable_cursor = true; module_param_named(enable_cursor, enable_cursor, bool, 0444); MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support"); -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 40/54] drm-dyndbg: add DRM_CLASSMAP_USE to simpledrm
tiny/simpledrm has 3 DRM_UT_DRIVER debugs, make them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module has class'd debugs. Signed-off-by: Jim Cromie --- drivers/gpu/drm/tiny/simpledrm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c index 1d8fa07572c5..69cb580ca9d1 100644 --- a/drivers/gpu/drm/tiny/simpledrm.c +++ b/drivers/gpu/drm/tiny/simpledrm.c @@ -34,6 +34,8 @@ #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 +DRM_CLASSMAP_USE(drm_debug_classes); + /* * Helpers for simplefb */ -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 38/54] drm-dyndbg: add DRM_CLASSMAP_USE to Xe driver
Invoke DRM_CLASSMAP_USE from xe_drm_client.c. When built with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, this tells dydnbg that Xe uses has drm.debug calls. Signed-off-by: Jim Cromie --- drivers/gpu/drm/xe/xe_drm_client.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/xe/xe_drm_client.c b/drivers/gpu/drm/xe/xe_drm_client.c index 08f0b7c95901..ffd6e237f3c6 100644 --- a/drivers/gpu/drm/xe/xe_drm_client.c +++ b/drivers/gpu/drm/xe/xe_drm_client.c @@ -15,6 +15,8 @@ #include "xe_drm_client.h" #include "xe_trace.h" +DRM_CLASSMAP_USE(drm_debug_classes); + /** * xe_drm_client_alloc() - Allocate drm client * @void: No arg -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 32/54] drm-dyndbg: DRM_CLASSMAP_USE in amdgpu driver
Following the dyndbg-api-fix, replace DECLARE_DYNDBG_CLASSMAP with DRM_CLASSMAP_USE. This refs the defined & exported classmap, rather than re-declaring it redundantly, and error-prone-ly. This resolves the appearance of "class:_UNKNOWN_" in the control file for the driver's drm_dbg()s. Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers.") Signed-off-by: Jim Cromie --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index ea14f1c8f430..83763d37566d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -217,17 +217,7 @@ int amdgpu_damage_clips = -1; /* auto */ static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work); -DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0, - "DRM_UT_CORE", - "DRM_UT_DRIVER", - "DRM_UT_KMS", - "DRM_UT_PRIME", - "DRM_UT_ATOMIC", - "DRM_UT_VBL", - "DRM_UT_STATE", - "DRM_UT_LEASE", - "DRM_UT_DP", - "DRM_UT_DRMRES"); +DRM_CLASSMAP_USE(drm_debug_classes); struct amdgpu_mgpu_info mgpu_info = { .mutex = __MUTEX_INITIALIZER(mgpu_info.mutex), -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 37/54] drm-print: workaround unused variable compiler meh
With CONFIG_DRM_USE_DYNAMIC_DEBUG=y, I'm getting an unused variable warning/error on 'category', though the usage follows immediately, in drm_debug_enabled(). This drops the local var and refs the field directly in the macro-call, which avoids the warning. For static-key optimized dyndbg, the macro doesn't actually check the category, since the static-key patches in the proper state. This is also likely why the auto var appears to be unused by the compiler. commit 9fd6f61a297e ("drm/print: add drm_dbg_printer() for drm device specific printer") CC: Jani Nikula Signed-off-by: Jim Cromie --- drivers/gpu/drm/drm_print.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c index c7455f2076b4..0980210a5146 100644 --- a/drivers/gpu/drm/drm_print.c +++ b/drivers/gpu/drm/drm_print.c @@ -183,11 +183,10 @@ void __drm_printfn_dbg(struct drm_printer *p, struct va_format *vaf) { const struct drm_device *drm = p->arg; const struct device *dev = drm ? drm->dev : NULL; - enum drm_debug_category category = p->category; const char *prefix = p->prefix ?: ""; const char *prefix_pad = p->prefix ? " " : ""; - if (!__drm_debug_enabled(category)) + if (!__drm_debug_enabled(p->category)) return; /* Note: __builtin_return_address(0) is useless here. */ -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 34/54] drm-dyndbg: DRM_CLASSMAP_USE in drm_crtc_helper
Following the dyndbg-api-fix, replace DECLARE_DYNDBG_CLASSMAP with DRM_CLASSMAP_USE. This refs the defined & exported classmap, rather than re-declaring it redundantly, and error-prone-ly. This resolves the appearance of "class:_UNKNOWN_" in the control file for the driver's drm_dbg()s. Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers.") Signed-off-by: Jim Cromie --- drivers/gpu/drm/drm_crtc_helper.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 0955f1c385dd..1d08d759f238 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -50,17 +50,7 @@ #include "drm_crtc_helper_internal.h" -DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0, - "DRM_UT_CORE", - "DRM_UT_DRIVER", - "DRM_UT_KMS", - "DRM_UT_PRIME", - "DRM_UT_ATOMIC", - "DRM_UT_VBL", - "DRM_UT_STATE", - "DRM_UT_LEASE", - "DRM_UT_DP", - "DRM_UT_DRMRES"); +DRM_CLASSMAP_USE(drm_debug_classes); /** * DOC: overview -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 31/54] drm-dyndbg: adapt DRM to invoke DYNDBG_CLASSMAP_PARAM
Invoke DYNDBG_CLASSMAP_PARAM to hook drm.debug (__drm_debug) to the DRM_UT_* classmap, replacing the ad-hoc wiring previously doing it. Signed-off-by: Jim Cromie --- drivers/gpu/drm/drm_print.c | 8 ++-- include/drm/drm_print.h | 6 -- 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c index 41f167082042..c7455f2076b4 100644 --- a/drivers/gpu/drm/drm_print.c +++ b/drivers/gpu/drm/drm_print.c @@ -69,12 +69,8 @@ DRM_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, "DRM_UT_DP", "DRM_UT_DRMRES"); -static struct ddebug_class_param drm_debug_bitmap = { - .bits = &__drm_debug, - .flags = "p", - .map = _debug_classes, -}; -module_param_cb(debug, _ops_dyndbg_classes, _debug_bitmap, 0600); +DRM_CLASSMAP_PARAM_REF(debug, __drm_debug, drm_debug_classes, p); + #endif void __drm_puts_coredump(struct drm_printer *p, const char *str) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index b467ee67a281..aa3708c7b6d8 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -141,11 +141,13 @@ enum drm_debug_category { }; #ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG -#define DRM_CLASSMAP_DEFINE(...) DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__) -#define DRM_CLASSMAP_USE(name) DYNDBG_CLASSMAP_USE(name) +#define DRM_CLASSMAP_DEFINE(...)DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__) +#define DRM_CLASSMAP_USE(name) DYNDBG_CLASSMAP_USE(name) +#define DRM_CLASSMAP_PARAM_REF(...) DYNDBG_CLASSMAP_PARAM_REF(__VA_ARGS__) #else #define DRM_CLASSMAP_DEFINE(...) #define DRM_CLASSMAP_USE(name) +#define DRM_CLASSMAP_PARAM_REF(...) #endif static inline bool drm_debug_enabled_raw(enum drm_debug_category category) -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 33/54] drm-dyndbg: DRM_CLASSMAP_USE in i915 driver
Following the dyndbg-api-fix, replace DECLARE_DYNDBG_CLASSMAP with DRM_CLASSMAP_USE. This refs the defined & exported classmap, rather than re-declaring it redundantly, and error-prone-ly. This resolves the appearance of "class:_UNKNOWN_" in the control file for the driver's drm_dbg()s. Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers.") Signed-off-by: Jim Cromie --- drivers/gpu/drm/i915/i915_params.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 8c00169e3ab7..a8f51f138895 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -29,17 +29,7 @@ #include "i915_params.h" #include "i915_drv.h" -DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0, - "DRM_UT_CORE", - "DRM_UT_DRIVER", - "DRM_UT_KMS", - "DRM_UT_PRIME", - "DRM_UT_ATOMIC", - "DRM_UT_VBL", - "DRM_UT_STATE", - "DRM_UT_LEASE", - "DRM_UT_DP", - "DRM_UT_DRMRES"); +DRM_CLASSMAP_USE(drm_debug_classes); #define i915_param_named(name, T, perm, desc) \ module_param_named(name, i915_modparams.name, T, perm); \ -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 23/54] docs/dyndbg: explain new delimiters: comma, percent
Add mention of comma and percent delimiters into the respective paragraphs describing their equivalents: space and newline. Signed-off-by: Jim Cromie --- .../admin-guide/dynamic-debug-howto.rst| 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 742eb4230c6e..7b570f29ae98 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -73,16 +73,18 @@ Command Language Reference == At the basic lexical level, a command is a sequence of words separated -by spaces or tabs. So these are all equivalent:: +by spaces, tabs, or commas. So these are all equivalent:: :#> ddcmd file svcsock.c line 1603 +p :#> ddcmd "file svcsock.c line 1603 +p" :#> ddcmd ' file svcsock.c line 1603 +p ' + :#> ddcmd file,svcsock.c,line,1603,+p -Command submissions are bounded by a write() system call. -Multiple commands can be written together, separated by ``;`` or ``\n``:: +Command submissions are bounded by a write() system call. Multiple +commands can be written together, separated by ``%``, ``;`` or ``\n``:: - :#> ddcmd "func pnpacpi_get_resources +p; func pnp_assign_mem +p" + :#> ddcmd func foo +p % func bar +p + :#> ddcmd func foo +p \; func bar +p :#> ddcmd <<"EOC" func pnpacpi_get_resources +p func pnp_assign_mem +p @@ -104,7 +106,6 @@ The match-spec's select *prdbgs* from the catalog, upon which to apply the flags-spec, all constraints are ANDed together. An absent keyword is the same as keyword "*". - A match specification is a keyword, which selects the attribute of the callsite to be compared, and a value to compare against. Possible keywords are::: @@ -128,7 +129,6 @@ keywords are::: ``line-range`` cannot contain space, e.g. "1-30" is valid range but "1 - 30" is not. - The meanings of each keyword are: func @@ -153,9 +153,11 @@ module The given string is compared against the module name of each callsite. The module name is the string as seen in ``lsmod``, i.e. without the directory or the ``.ko`` -suffix and with ``-`` changed to ``_``. Examples:: +suffix and with ``-`` changed to ``_``. + +Examples:: - module sunrpc + module,sunrpc # with ',' as token separator module nfsd module drm* # both drm, drm_kms_helper -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 27/54] selftests-dyndbg: check KCONFIG_CONFIG to avoid silly fails
Several tests are dependent upon config choices. Lets avoid failing where that is noise. The KCONFIG_CONFIG var exists to convey the config-file around. If the var names a file, read it and extract the relevant CONFIG items, and use them to skip the dependent tests, thus avoiding the fails that would follow, and the disruption to whatever CI is running these selftests. If the envar doesn't name a config-file, ".config" is assumed. CONFIG_DYNAMIC_DEBUG=y: basic-tests() and comma-terminator-tests() test for the presence of the builtin pr_debugs in module/main.c, which I deemed stable and therefore safe to count. That said, the test fails if only CONFIG_DYNAMIC_DEBUG_CORE=y is set. It could be rewritten to test against test-dynamic-debug.ko, but that just trades one config dependence for another. CONFIG_TEST_DYNAMIC_DEBUG=m As written, test_percent_splitting() modprobes test_dynamic_debug, enables several classes, and count them. It could be re-written to work for the builtin module also, but builtin test modules are not a common or desirable build/config. CONFIG_TEST_DYNAMIC_DEBUG=m && CONFIG_TEST_DYNAMIC_DEBUG_SUBMOD=m test_mod_submod() recaps the bug found in DRM-CI where drivers werent enabled by drm.debug=. It modprobes both test_dynamic_debug & test_dynamic_debug_submod, so it depends on a loadable modules config. It could be rewritten to work in a builtin parent config; DRM=y is common enough to be pertinent, but testing that config also wouldn't really test anything more fully than all-loadable modules, since they default together. Signed-off-by: Jim Cromie fixup-kconfig --- .../dynamic_debug/dyndbg_selftest.sh | 45 ++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh index fccd2012b548..d09ef26b2308 100755 --- a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh +++ b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh @@ -11,6 +11,30 @@ CYAN="\033[0;36m" NC="\033[0;0m" error_msg="" +[ -e /proc/dynamic_debug/control ] || { +echo -e "${RED}: this test requires CONFIG_DYNAMIC_DEBUG=y ${NC}" +exit 0 # nothing to test here, no good reason to fail. +} + +# need info to avoid failures due to untestable configs + +[ -f "$KCONFIG_CONFIG" ] || KCONFIG_CONFIG=".config" +if [ -f "$KCONFIG_CONFIG" ]; then +echo "# consulting KCONFIG_CONFIG: $KCONFIG_CONFIG" +grep -q "CONFIG_DYNAMIC_DEBUG=y" $KCONFIG_CONFIG ; LACK_DD_BUILTIN=$? +grep -q "CONFIG_TEST_DYNAMIC_DEBUG=m" $KCONFIG_CONFIG ; LACK_TMOD=$? +grep -q "CONFIG_TEST_DYNAMIC_DEBUG_SUBMOD=m" $KCONFIG_CONFIG ; LACK_TMOD_SUBMOD=$? +if [ $V -eq 1 ]; then + echo LACK_DD_BUILTIN: $LACK_DD_BUILTIN + echo LACK_TMOD: $LACK_TMOD + echo LACK_TMOD_SUBMOD: $LACK_TMOD_SUBMOD +fi +else +LACK_DD_BUILTIN=0 +LACK_TMOD=0 +LACK_TMOD_SUBMOD=0 +fi + function vx () { echo $1 > /sys/module/dynamic_debug/parameters/verbose } @@ -192,6 +216,10 @@ function check_err_msg() { function basic_tests { echo -e "${GREEN}# BASIC_TESTS ${NC}" +if [ $LACK_DD_BUILTIN -eq 1 ]; then + echo "SKIP" + return +fi ddcmd =_ # zero everything (except class'd sites) check_match_ct =p 0 # there are several main's :-/ @@ -214,6 +242,10 @@ EOF function comma_terminator_tests { echo -e "${GREEN}# COMMA_TERMINATOR_TESTS ${NC}" +if [ $LACK_DD_BUILTIN -eq 1 ]; then + echo "SKIP" + return +fi # try combos of spaces & commas check_match_ct '\[params\]' 4 -r ddcmd module,params,=_ # commas as spaces @@ -226,9 +258,12 @@ function comma_terminator_tests { ddcmd =_ } - function test_percent_splitting { echo -e "${GREEN}# TEST_PERCENT_SPLITTING - multi-command splitting on % ${NC}" +if [ $LACK_TMOD -eq 1 ]; then + echo "SKIP" + return +fi ifrmmod test_dynamic_debug_submod ifrmmod test_dynamic_debug ddcmd =_ @@ -248,6 +283,14 @@ function test_percent_splitting { function test_mod_submod { echo -e "${GREEN}# TEST_MOD_SUBMOD ${NC}" +if [ $LACK_TMOD -eq 1 ]; then + echo "SKIP" + return +fi +if [ $LACK_TMOD_SUBMOD -eq 1 ]; then + echo "SKIP" + return +fi ifrmmod test_dynamic_debug_submod ifrmmod test_dynamic_debug ddcmd =_ -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 26/54] dyndbg: change __dynamic_func_call_cls* macros into expressions
The Xe driver's XE_IOCTL_DBG macro calls drm_dbg() from inside an if (expression). This breaks when CONFIG_DRM_USE_DYNAMIC_DEBUG=y because the invoked macro has a do-while-0 wrapper. if (cond && (drm_dbg("expr-form"),1)) { ... do some more stuff } Fix it by changing __dynamic_func_call_cls{,_no_desc} macros into expressions, by replacing the do-while-0s with a ({ }) wrapper. In C, all legal expressions are also legal statements, as converted by the trailing semi-colon in a statement-style macro invocation: drm_dbg("statement form"); Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index 4a9b9cd53eb7..c958085e0df4 100644 --- a/include/linux/dynamic_debug.h +++ b/include/linux/dynamic_debug.h @@ -287,20 +287,20 @@ void __dynamic_ibdev_dbg(struct _ddebug *descriptor, * (|_cls):adds in _DPRINT_CLASS_DFLT as needed * (|_no_desc):former gets callsite descriptor as 1st arg (for prdbgs) */ -#define __dynamic_func_call_cls(id, cls, fmt, func, ...) do { \ +#define __dynamic_func_call_cls(id, cls, fmt, func, ...) ({\ DEFINE_DYNAMIC_DEBUG_METADATA_CLS(id, cls, fmt);\ if (DYNAMIC_DEBUG_BRANCH(id)) \ func(, ##__VA_ARGS__); \ -} while (0) +}) #define __dynamic_func_call(id, fmt, func, ...) \ __dynamic_func_call_cls(id, _DPRINTK_CLASS_DFLT, fmt, \ func, ##__VA_ARGS__) -#define __dynamic_func_call_cls_no_desc(id, cls, fmt, func, ...) do { \ +#define __dynamic_func_call_cls_no_desc(id, cls, fmt, func, ...) ({\ DEFINE_DYNAMIC_DEBUG_METADATA_CLS(id, cls, fmt);\ if (DYNAMIC_DEBUG_BRANCH(id)) \ func(__VA_ARGS__); \ -} while (0) +}) #define __dynamic_func_call_no_desc(id, fmt, func, ...) \ __dynamic_func_call_cls_no_desc(id, _DPRINTK_CLASS_DFLT,\ fmt, func, ##__VA_ARGS__) -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 25/54] dyndbg-doc: explain flags parse 1st
When writing queries to >control, flags are parsed 1st, since they are the only required field. So if the flags draw an error, then keyword errors aren't reported. This can be mildly confusing/annoying, so explain it instead. This note could be moved up to just after the grammar id's the flags, and before the match-spec is detailed. Opinions ? Signed-off-by: Jim Cromie --- Documentation/admin-guide/dynamic-debug-howto.rst | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 7b570f29ae98..ccf3704f2143 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -106,6 +106,16 @@ The match-spec's select *prdbgs* from the catalog, upon which to apply the flags-spec, all constraints are ANDed together. An absent keyword is the same as keyword "*". +Note: because the match-spec can be empty, the flags are checked 1st, +then the pairs of keyword values. Flag errs will hide keyword errs: + + bash-5.2# ddcmd mod bar +foo + dyndbg: read 13 bytes from userspace + dyndbg: query 0: "mod bar +foo" mod:* + dyndbg: unknown flag 'o' + dyndbg: flags parse failed + dyndbg: processed 1 queries, with 0 matches, 1 errs + A match specification is a keyword, which selects the attribute of the callsite to be compared, and a value to compare against. Possible keywords are::: -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 24/54] selftests-dyndbg: add test_mod_submod
This new test-fn runs 3 module/submodule modprobe scenarios, variously using both the generic dyndbg= modprobe arg, and the test-module's classmap-params to manipulate the test-mod*'s pr_debugs. In all cases, the current flag-settings are counted and tested vs expectations. The 3rd scenario recapitulates the DRM_USE_DYNAMIC_DEBUG=y failure. 1. 2 modprobes (super then sub), with separate dyndbg=class-settings check module specific flag settings 2. modprobe submod, supermod is auto-loaded set supermod class-params check expected enablements in super & submod 3. modprobe super, with param=setting (like drm.debug=0x1ef) modprobe submod validate submod's class'd pr_debugs get properly enabled The test uses multi-queries, with both commas and percents (to avoid spaces and quoting). This is the main reason the test wasn't earlier in the patchset, closer to the classmap patches its validating. With some tedium, the tests could be refactored to split out early tests which avoid multi-cmds, and test only the class-params. Signed-off-by: Jim Cromie --- .../dynamic_debug/dyndbg_selftest.sh | 67 +++ 1 file changed, 67 insertions(+) diff --git a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh index 996e6fdcfb52..fccd2012b548 100755 --- a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh +++ b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh @@ -246,10 +246,77 @@ function test_percent_splitting { ifrmmod test_dynamic_debug } +function test_mod_submod { +echo -e "${GREEN}# TEST_MOD_SUBMOD ${NC}" +ifrmmod test_dynamic_debug_submod +ifrmmod test_dynamic_debug +ddcmd =_ + +# modprobe with class enablements +modprobe test_dynamic_debug \ + dyndbg=class,D2_CORE,+pf%class,D2_KMS,+pt%class,D2_ATOMIC,+pm + +check_match_ct '\[test_dynamic_debug\]' 23 -r +check_match_ct =pf 1 +check_match_ct =pt 1 +check_match_ct =pm 1 + +modprobe test_dynamic_debug_submod +check_match_ct test_dynamic_debug_submod 23 -r +check_match_ct '\[test_dynamic_debug\]' 23 -r +check_match_ct test_dynamic_debug 46 -r + +# no enablements propagate here +check_match_ct =pf 1 +check_match_ct =pt 1 +check_match_ct =pm 1 + +# change classes again, this time submod too +ddcmd class,D2_CORE,+mf%class,D2_KMS,+lt%class,D2_ATOMIC,+ml "# add some prefixes" +check_match_ct =pmf 1 -v +check_match_ct =plt 1 -v +check_match_ct =pml 1 -v +# submod changed too +check_match_ct =mf 1 -v +check_match_ct =lt 1 -v +check_match_ct =ml 1 -v + +# now work the classmap-params +# fresh start, to clear all above flags (test-fn limits) +ifrmmod test_dynamic_debug_submod +ifrmmod test_dynamic_debug +modprobe test_dynamic_debug_submod # get supermod too + +echo 1 > /sys/module/test_dynamic_debug/parameters/p_disjoint_bits +echo 4 > /sys/module/test_dynamic_debug/parameters/p_level_num +# 2 mods * ( V1-3 + D2_CORE ) +check_match_ct =p 8 -v +echo 3 > /sys/module/test_dynamic_debug/parameters/p_disjoint_bits +echo 0 > /sys/module/test_dynamic_debug/parameters/p_level_num +# 2 mods * ( D2_CORE, D2_DRIVER ) +check_match_ct =p 4 -v +echo 0x16 > /sys/module/test_dynamic_debug/parameters/p_disjoint_bits +echo 0 > /sys/module/test_dynamic_debug/parameters/p_level_num +# 2 mods * ( D2_DRIVER, D2_KMS, D2_ATOMIC ) +check_match_ct =p 6 -v + +# recap DRM_USE_DYNAMIC_DEBUG regression +ifrmmod test_dynamic_debug_submod +ifrmmod test_dynamic_debug +# set super-mod params +modprobe test_dynamic_debug p_disjoint_bits=0x16 p_level_num=5 +check_match_ct =p 7 -v +modprobe test_dynamic_debug_submod +# see them picked up by submod +check_match_ct =p 14 -v +} + tests_list=( basic_tests +# these require test_dynamic_debug*.ko comma_terminator_tests test_percent_splitting +test_mod_submod ) # Run tests -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 19/54] dyndbg: treat comma as a token separator
Treat comma as a token terminator, just like a space. This allows a user to avoid quoting hassles when spaces are otherwise needed: :#> modprobe drm dyndbg=class,DRM_UT_CORE,+p\;class,DRM_UT_KMS,+p or as a boot arg: drm.dyndbg=class,DRM_UT_CORE,+p # todo: support multi-query here Given the many ways a boot-line +args can be assembled and then passed in/down/around shell based tools, this may allow side-stepping all sorts of quoting hassles thru those layers. existing query format: modprobe test_dynamic_debug dyndbg="class D2_CORE +p" new format: modprobe test_dynamic_debug dyndbg=class,D2_CORE,+p Signed-off-by: Jim Cromie Co-developed-by: Łukasz Bartosik Signed-off-by: Łukasz Bartosik --- lib/dynamic_debug.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index e9a95b0f3757..235d85765b63 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -290,6 +290,14 @@ static int ddebug_change(const struct ddebug_query *query, return nfound; } +static char *skip_spaces_and_commas(const char *str) +{ + str = skip_spaces(str); + while (*str == ',') + str = skip_spaces(++str); + return (char *)str; +} + /* * Split the buffer `buf' into space-separated words. * Handles simple " and ' quoting, i.e. without nested, @@ -303,8 +311,8 @@ static int ddebug_tokenize(char *buf, char *words[], int maxwords) while (*buf) { char *end; - /* Skip leading whitespace */ - buf = skip_spaces(buf); + /* Skip leading whitespace and comma */ + buf = skip_spaces_and_commas(buf); if (!*buf) break; /* oh, it was trailing whitespace */ if (*buf == '#') @@ -320,7 +328,7 @@ static int ddebug_tokenize(char *buf, char *words[], int maxwords) return -EINVAL; /* unclosed quote */ } } else { - for (end = buf; *end && !isspace(*end); end++) + for (end = buf; *end && !isspace(*end) && *end != ','; end++) ; if (end == buf) { pr_err("parse err after word:%d=%s\n", nwords, @@ -592,7 +600,8 @@ static int ddebug_exec_queries(char *query, const char *modname) if (split) *split++ = '\0'; - query = skip_spaces(query); + query = skip_spaces_and_commas(query); + if (!query || !*query || *query == '#') continue; -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 21/54] dyndbg: split multi-query strings with %
Since commit 85f7f6c0edb8 ("dynamic_debug: process multiple debug-queries on a line") Multi-query commands have been allowed: modprobe drm dyndbg="class DRM_UT_CORE +p; class DRM_UT_KMS +p" modprobe drm dyndbg=< [ 203.902703] dyndbg: query parse failed [ 203.902871] dyndbg: processed 2 queries, with 0 matches, 2 errs bash: echo: write error: Invalid argument The '%' splits the input into 2 queries, and both fail. Given the limited utility of matching against the working parts of a format string "foo: %d bar %s", nothing is actually lost here. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 235d85765b63..dcec7b3657bb 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -596,7 +596,7 @@ static int ddebug_exec_queries(char *query, const char *modname) int i, errs = 0, exitcode = 0, rc, nfound = 0; for (i = 0; query; query = split) { - split = strpbrk(query, ";\n"); + split = strpbrk(query, "%;\n"); if (split) *split++ = '\0'; -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 22/54] selftests-dyndbg: test_percent_splitting
This does basic testing of classmaps using '%' separated multi-queries. It modprobes test_dynamic_debug with several classes enabled, and counts to verify that the expected sites show the enablement in the control file. Signed-off-by: Jim Cromie --- .../dynamic_debug/dyndbg_selftest.sh | 21 +++ 1 file changed, 21 insertions(+) diff --git a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh index b4ba293ab227..996e6fdcfb52 100755 --- a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh +++ b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh @@ -226,9 +226,30 @@ function comma_terminator_tests { ddcmd =_ } + +function test_percent_splitting { +echo -e "${GREEN}# TEST_PERCENT_SPLITTING - multi-command splitting on % ${NC}" +ifrmmod test_dynamic_debug_submod +ifrmmod test_dynamic_debug +ddcmd =_ +modprobe test_dynamic_debug dyndbg=class,D2_CORE,+pf%class,D2_KMS,+pt%class,D2_ATOMIC,+pm +check_match_ct =pf 1 +check_match_ct =pt 1 +check_match_ct =pm 1 +check_match_ct test_dynamic_debug 23 -r +# add flags to those callsites +ddcmd class,D2_CORE,+mf%class,D2_KMS,+lt%class,D2_ATOMIC,+ml +check_match_ct =pmf 1 +check_match_ct =plt 1 +check_match_ct =pml 1 +check_match_ct test_dynamic_debug 23 -r +ifrmmod test_dynamic_debug +} + tests_list=( basic_tests comma_terminator_tests +test_percent_splitting ) # Run tests -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 20/54] selftests-dyndbg: add comma_terminator_tests
New fn validates parsing and effect of queries using combinations of commas and spaces to delimit the tokens. It manipulates pr-debugs in builtin module/params, so might have deps I havent foreseen on odd configurations. Signed-off-by: Jim Cromie --- .../selftests/dynamic_debug/dyndbg_selftest.sh | 14 ++ 1 file changed, 14 insertions(+) diff --git a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh index 1be70af26a38..b4ba293ab227 100755 --- a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh +++ b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh @@ -212,9 +212,23 @@ EOF ddcmd =_ } +function comma_terminator_tests { +echo -e "${GREEN}# COMMA_TERMINATOR_TESTS ${NC}" +# try combos of spaces & commas +check_match_ct '\[params\]' 4 -r +ddcmd module,params,=_ # commas as spaces +ddcmd module,params,+mpf # turn on module's pr-debugs +check_match_ct =pmf 4 +ddcmd ,module ,, , params, -p +check_match_ct =mf 4 +ddcmd " , module ,,, , params, -m"# +check_match_ct =f 4 +ddcmd =_ +} tests_list=( basic_tests +comma_terminator_tests ) # Run tests -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 18/54] dyndbg-doc: add classmap info to howto
Describe the 3 API macros providing dynamic_debug's classmaps DYNDBG_CLASSMAP_DEFINE - create, exports a module's classmap DYNDBG_CLASSMAP_USE- refer to exported map DYNDBG_CLASSMAP_PARAM - bind control param to the classmap DYNDBG_CLASSMAP_PARAM_REF + use module's storage - __drm_debug cc: linux-...@vger.kernel.org Signed-off-by: Jim Cromie --- v5 adjustments per Randy Dunlap v7 checkpatch fixes v8 more --- .../admin-guide/dynamic-debug-howto.rst | 63 ++- 1 file changed, 62 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 6a8ce5a34382..742eb4230c6e 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -225,7 +225,6 @@ the ``p`` flag has meaning, other flags are ignored. Note the regexp ``^[-+=][fslmpt_]+$`` matches a flags specification. To clear all flags at once, use ``=_`` or ``-fslmpt``. - Debug messages during Boot Process == @@ -375,3 +374,65 @@ just a shortcut for ``print_hex_dump(KERN_DEBUG)``. For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is its ``prefix_str`` argument, if it is constant string; or ``hexdump`` in case ``prefix_str`` is built dynamically. + +Dynamic Debug classmaps +=== + +Dyndbg allows selection/grouping of *prdbg* callsites using structural +info: module, file, function, line. Classmaps allow authors to add +their own domain-oriented groupings using class-names. Classmaps are +exported, so they referencable from other modules. + + # enable classes individually + :#> ddcmd class DRM_UT_CORE +p + :#> ddcmd class DRM_UT_KMS +p + # or more selectively + :#> ddcmd class DRM_UT_CORE module drm +p + +The "class FOO" syntax protects class'd prdbgs from generic overwrite:: + + # IOW this doesn't wipe any DRM.debug settings + :#> ddcmd -p + +To support the DRM.debug parameter, DYNDBG_CLASSMAP_PARAM* updates all +classes in a classmap, mapping param-bits 0..N onto the classes: +DRM_UT_<*> for the DRM use-case. + +Dynamic Debug Classmap API +== + +DYNDBG_CLASSMAP_DEFINE - modules use this to create classmaps, naming +each of the classes (stringified enum-symbols: "DRM_UT_<*>"), and +type, and mapping the class-names to consecutive _class_ids. + +By doing so, modules tell dyndbg that they have prdbgs with those +class_ids, and they authorize dyndbg to accept "class FOO" for the +module defining the classmap, and its contained classnames. + +DYNDBG_CLASSMAP_USE - drm drivers invoke this to ref the CLASSMAP that +drm DEFINEs. This shares the classmap definition, and authorizes +dyndbg to apply changes to the user module's class'd pr_debugs. It +also tells dyndbg how to initialize the user's prdbgs at modprobe, +based upon the current setting of the parent's controlling param. + +There are 2 types of classmaps: + + DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, like DRM.debug + DD_CLASS_TYPE_LEVEL_NUM: classes are relative, ordered (V3 > V2) + +DYNDBG_CLASSMAP_PARAM - modelled after module_param_cb, it refers to a +DEFINEd classmap, and associates it to the param's data-store. This +state is then applied to DEFINEr and USEr modules when they're modprobed. + +This interface also enforces the DD_CLASS_TYPE_LEVEL_NUM relation +amongst the contained classnames; all classes are independent in the +control parser itself. + +Modules or module-groups (drm & drivers) can define multiple +classmaps, as long as they share the limited 0..62 per-module-group +_class_id range, without overlap. + +``#define DEBUG`` will enable all pr_debugs in scope, including any +class'd ones. This won't be reflected in the PARAM readback value, +but the class'd pr_debug callsites can be forced off by toggling the +classmap-kparam all-on then all-off. -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 16/54] selftests-dyndbg: add tools/testing/selftests/dynamic_debug/*
Add a selftest script for dynamic-debug. The config requires CONFIG_TEST_DYNAMIC_DEBUG=m (and CONFIG_TEST_DYNAMIC_DEBUG_SUBMOD=m), which tacitly requires either CONFIG_DYNAMIC_DEBUG=y or CONFIG_DYNAMIC_DEBUG_CORE=y ATM this has just basic_tests(), it modifies pr_debug flags in a few builtins (init/main, params), counts the callsite flags changed, and verifies against expected values. This is backported from another feature branch; the support-fns (thx Lukas) have unused features at the moment, they'll get used shortly. The script enables simple virtme-ng testing: $> vng --verbose --name v6.8-32-g30d431000676 --user root \ --cwd ../.. -a dynamic_debug.verbose=2 -p 4 \ ./tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh virtme: waiting for virtiofsd to start virtme: use 'microvm' QEMU architecture ... [4.136168] virtme-init: Setting hostname to v6.8-32-g30d431000676... [4.240874] virtme-init: starting script test_dynamic_debug_submod not there test_dynamic_debug not there ... [4.474435] virtme-init: script returned {0} Powering off. [4.529318] ACPI: PM: Preparing to enter system sleep state S5 [4.529991] kvm: exiting hardware virtualization [4.530428] reboot: Power down And add dynamic_debug to TARGETS, so `make run_tests` sees it properly for the impatient, set TARGETS explicitly: bash-5.2# make TARGETS=dynamic_debug run_tests make[1]: ... TAP version 13 1..1 [ 35.552922] dyndbg: read 3 bytes from userspace [ 35.553099] dyndbg: query 0: "=_" mod:* [ 35.553544] dyndbg: processed 1 queries, with 1778 matches, 0 errs ... TLDR: This selftest is slightly naive wrt the init state of call-site flags. In particular, it fails if class'd pr_debugs have been set $ cat /etc/modprobe.d/drm-test.conf options drm dyndbg=class,DRM_UT_CORE,+mfslt%class,DRM_UT_KMS,+mf By Contract, class'd pr_debugs are protected from alteration by default (only by direct "class FOO" queries), so the "=_" logged above (TAP version 13) cannot affect the DRM_UT_CORE,KMS pr_debugs. These class'd flag-settings, added by modprobe, alter the counts of flag-matching patterns, breaking the tests' expectations. Signed-off-by: Jim Cromie Co-developed-by: Łukasz Bartosik Signed-off-by: Łukasz Bartosik --- MAINTAINERS | 1 + tools/testing/selftests/Makefile | 1 + .../testing/selftests/dynamic_debug/Makefile | 9 + tools/testing/selftests/dynamic_debug/config | 2 + .../dynamic_debug/dyndbg_selftest.sh | 231 ++ 5 files changed, 244 insertions(+) create mode 100644 tools/testing/selftests/dynamic_debug/Makefile create mode 100644 tools/testing/selftests/dynamic_debug/config create mode 100755 tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh diff --git a/MAINTAINERS b/MAINTAINERS index eb8312ea681f..a5197bac717f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7685,6 +7685,7 @@ S:Maintained F: include/linux/dynamic_debug.h F: lib/dynamic_debug.c F: lib/test_dynamic_debug*.c +F: tools/testing/selftest/dynamic_debug/* DYNAMIC INTERRUPT MODERATION M: Tal Gilboa diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile index 9039f3709aff..1b4826d5d09c 100644 --- a/tools/testing/selftests/Makefile +++ b/tools/testing/selftests/Makefile @@ -22,6 +22,7 @@ TARGETS += drivers/net/bonding TARGETS += drivers/net/team TARGETS += drivers/net/virtio_net TARGETS += dt +TARGETS += dynamic_debug TARGETS += efivarfs TARGETS += exec TARGETS += fchmodat2 diff --git a/tools/testing/selftests/dynamic_debug/Makefile b/tools/testing/selftests/dynamic_debug/Makefile new file mode 100644 index ..6d06fa7f1040 --- /dev/null +++ b/tools/testing/selftests/dynamic_debug/Makefile @@ -0,0 +1,9 @@ +# SPDX-License-Identifier: GPL-2.0-only +# borrowed from Makefile for user memory selftests + +# No binaries, but make sure arg-less "make" doesn't trigger "run_tests" +all: + +TEST_PROGS := dyndbg_selftest.sh + +include ../lib.mk diff --git a/tools/testing/selftests/dynamic_debug/config b/tools/testing/selftests/dynamic_debug/config new file mode 100644 index ..d080da571ac0 --- /dev/null +++ b/tools/testing/selftests/dynamic_debug/config @@ -0,0 +1,2 @@ +CONFIG_TEST_DYNAMIC_DEBUG=m +CONFIG_TEST_DYNAMIC_DEBUG_SUBMOD=m diff --git a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh new file mode 100755 index ..1be70af26a38 --- /dev/null +++ b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh @@ -0,0 +1,231 @@ +#!/bin/bash +# SPDX-License-Identifier: GPL-2.0-only + +V=${V:=0} # invoke as V=1 $0 for global verbose +RED="\033[0;31m" +GREEN="\033[0;32m" +YELLOW="\033[0;33m" +BLUE="\033[0;34m" +MAGENTA="\033[0;35m" +CYAN="\033[0;36m" +NC="\033[0;0
[PATCH v9-resend 17/54] dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API
move the DYNDBG_CLASSMAP_PARAM macro from test-dynamic-debug.c into the header, and refine it, by distinguishing the 2 use cases: 1.DYNDBG_CLASSMAP_PARAM_REF for DRM, to pass in extern __drm_debug by name. dyndbg keeps bits in it, so drm can still use it as before 2.DYNDBG_CLASSMAP_PARAM new user (test_dynamic_debug) doesn't need to share state, decls a static long unsigned int to store the bitvec. __DYNDBG_CLASSMAP_PARAM bottom layer - allocate,init a ddebug-class-param, module-param-cb. Also clean up and improve comments in test-code, and add MODULE_DESCRIPTIONs. Signed-off-by: Jim Cromie --- fixup drm-print.h add PARAM_REF forwarding macros with DYNDBG_CLASSMAP_PARAM_REF in the API, add DRM_ variant --- include/linux/dynamic_debug.h | 37 - lib/dynamic_debug.c | 70 ++--- lib/test_dynamic_debug.c| 50 +-- lib/test_dynamic_debug_submod.c | 9 - 4 files changed, 110 insertions(+), 56 deletions(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index 189e3f60c31a..4a9b9cd53eb7 100644 --- a/include/linux/dynamic_debug.h +++ b/include/linux/dynamic_debug.h @@ -91,7 +91,7 @@ struct ddebug_class_map { * used to validate a "class FOO .." >control command on the module */ #define __DYNDBG_CLASSMAP_DEFINE(_var, _maptype, _base, ...) \ - const char *_var##_classnames[] = { __VA_ARGS__ }; \ + static const char *_var##_classnames[] = { __VA_ARGS__ }; \ struct ddebug_class_map __aligned(8) __used \ __section("__dyndbg_classes") _var = { \ .mod = THIS_MODULE, \ @@ -164,6 +164,41 @@ struct ddebug_class_param { const struct ddebug_class_map *map; }; +/** + * DYNDBG_CLASSMAP_PARAM - wrap a dyndbg-classmap with a controlling sys-param + * @_name sysfs node name + * @_var name of the struct classmap var defining the controlled classes + * @_flags flags to be toggled, typically just 'p' + * + * Creates a sysfs-param to control the classes defined by the + * classmap. Keeps bits in a private/static + */ +#define DYNDBG_CLASSMAP_PARAM(_name, _var, _flags) \ + static unsigned long _name##_bvec; \ + __DYNDBG_CLASSMAP_PARAM(_name, _name##_bvec, _var, _flags) + +/** + * DYNDBG_CLASSMAP_PARAM_REF - wrap a dyndbg-classmap with a controlling sys-param + * @_name sysfs node name + * @_bits name of the module's unsigned long bit-vector, ex: __drm_debug + * @_var name of the struct classmap var defining the controlled classes + * @_flags flags to be toggled, typically just 'p' + * + * Creates a sysfs-param to control the classmap, keeping bitvec in user @_bits. + * This lets drm use __drm_debug elsewhere too. + */ +#define DYNDBG_CLASSMAP_PARAM_REF(_name, _bits, _var, _flags) \ + __DYNDBG_CLASSMAP_PARAM(_name, _bits, _var, _flags) + +#define __DYNDBG_CLASSMAP_PARAM(_name, _bits, _var, _flags)\ + static struct ddebug_class_param _name##_##_flags = { \ + .bits = &(_bits), \ + .flags = #_flags, \ + .map = &(_var), \ + }; \ + module_param_cb(_name, _ops_dyndbg_classes, \ + &_name##_##_flags, 0600) + /* * pr_debug() and friends are globally enabled or modules have selectively * enabled them. diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 9150e0e5145f..e9a95b0f3757 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -657,6 +657,30 @@ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp, #define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1) +static void ddebug_class_param_clamp_input(unsigned long *inrep, const struct kernel_param *kp) +{ + const struct ddebug_class_param *dcp = kp->arg; + const struct ddebug_class_map *map = dcp->map; + + switch (map->map_type) { + case DD_CLASS_TYPE_DISJOINT_BITS: + /* expect bits. mask and warn if too many */ + if (*inrep & ~CLASSMAP_BITMASK(map->length)) { + pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx, masking\n", + KP_NAME(kp), *inrep, CLASSMAP_BITMASK(map->length)); + *inrep &= CLASSMAP_BITMASK(map->length); + } + break; + case DD_CLASS_TYPE_LEVEL_NUM: + /* input is bitpos, of highest verbosity to be enabled */ + if (*inrep > map->length) { + pr_warn("%s: level:%
[PATCH v9-resend 15/54] dyndbg-API: fix DECLARE_DYNDBG_CLASSMAP
ogether, to better explain how they share the 0..62 class-id space available to a module (non-overlapping subranges). reorg macros 2,3 by name. This gives a tabular format, making it easy to see the pattern of repetition, and the points of change. And extend the test to replicate the 2-module (parent & dependent) scenario which caused the CONFIG_DRM_USE_DYNAMIC_DEBUG=y regression seen in drm & drivers. The _submod.c is a 2-line file: #define _SUBMOD, #include parent. This gives identical complements of prdbgs in parent & _submod, and thus identical print behavior when all of: >control, >params, and parent->_submod propagation are working correctly. It also puts all the parent/_submod declarations together in the same source, with the new ifdef _SUBMOD block invoking DYNDBG_CLASSMAP_USE for the 2 test-interfaces. I think this is clearer. These 2 modules are both tristate, allowing 3 super/sub combos: Y/Y, Y/M, M/M (not N/N). Y/Y testing exposed a missing __align(8) in the _METADATA macro, which M/M didn't see because the module-loader memory placement constrains it instead. DEBUG details: ``#define DEBUG`` in src enables all pr_debugs after it, including any class'd pr_debugs; its not necessarily all-or-nothing, unless you do the define in a header. Also, the only way to disable a class'd pr_debug is via the classmap-kparam or using "class foo" in control queries, to address the classes by name. NB: this patch ignores a checkpatch do-while warning; which is wrong for declarative macros like these: arch/powerpc/platforms/cell/spu_base.c 48:static DEFINE_SPINLOCK(spu_lock); 62:static DEFINE_SPINLOCK(spu_full_list_lock); 63:static DEFINE_MUTEX(spu_full_list_mutex); Fixes: aad0214f3026 ("dyndbg: add DECLARE_DYNDBG_CLASSMAP macro") Signed-off-by: Jim Cromie --- v8 - split drm parts to separate commits. preserve DECLARE_DYNDBG_CLASSMAP to decouple DRM, no flag day. fixup block comment v7 - previous submission-blocking bug: missing __align(8) in DYNAMIC_DEBUG_DECLARE_METADATA on ddebug_class_user caused corrupt records, but only for builtin modules; module loader code probably pinned allocations to the right alignment naturally, hiding the bug for typical builds. v6- get rid of WARN_ON_ONCE v?- fix _var expanded 2x in macro --- MAINTAINERS | 2 +- include/asm-generic/vmlinux.lds.h | 1 + include/linux/dynamic_debug.h | 62 -- kernel/module/main.c | 3 + lib/Kconfig.debug | 24 +++- lib/Makefile | 3 + lib/dynamic_debug.c | 184 ++ lib/test_dynamic_debug.c | 111 -- lib/test_dynamic_debug_submod.c | 10 ++ 9 files changed, 332 insertions(+), 68 deletions(-) create mode 100644 lib/test_dynamic_debug_submod.c diff --git a/MAINTAINERS b/MAINTAINERS index 958e935449e5..eb8312ea681f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7684,7 +7684,7 @@ M:Jim Cromie S: Maintained F: include/linux/dynamic_debug.h F: lib/dynamic_debug.c -F: lib/test_dynamic_debug.c +F: lib/test_dynamic_debug*.c DYNAMIC INTERRUPT MODERATION M: Tal Gilboa diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index 5703526d6ebf..05fbf9f05eb4 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -367,6 +367,7 @@ /* implement dynamic printk debug */\ . = ALIGN(8); \ BOUNDED_SECTION_BY(__dyndbg_classes, ___dyndbg_classes) \ + BOUNDED_SECTION_BY(__dyndbg_class_users, ___dyndbg_class_users) \ BOUNDED_SECTION_BY(__dyndbg, ___dyndbg) \ CODETAG_SECTIONS() \ LIKELY_PROFILE()\ diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index c8102e89beb2..189e3f60c31a 100644 --- a/include/linux/dynamic_debug.h +++ b/include/linux/dynamic_debug.h @@ -72,8 +72,8 @@ enum ddebug_class_map_type { }; struct ddebug_class_map { - struct module *mod; - const char *mod_name; /* needed for builtins */ + const struct module *mod; /* NULL for builtins */ + const char *mod_name; const char **class_names; const int length; const int base; /* index of 1st .class_id, allows split/shared space */ @@ -81,11 +81,34 @@ struct ddebug_class_map { }; /** - * DECLARE_DYNDBG_CLASSMAP - declare classnames known by a module - * @_var: a struct ddebug_class_map, passed to module_param_cb - * @_type: enum class_map_type, chooses bits/verbose, numeric/symbolic - * @_base: offset of 1st class-name. splits .class_id space - * @classes: class-names used to control class'd prdbgs + * DYNDBG_CLASSMAP_DEFINE -
[PATCH v9-resend 14/54] dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
Remove the NAMED class types; these 2 classmap types accept class names at the PARAM interface, for example: echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names The code works, but its only used by test-dynamic-debug, and wasn't asked for by anyone else, so reduce test-surface, simplify things. also rename enum class_map_type to enum ddebug_class_map_type. Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 23 ++-- lib/dynamic_debug.c | 102 +++--- lib/test_dynamic_debug.c | 26 - 3 files changed, 14 insertions(+), 137 deletions(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index e458d4b838ac..c8102e89beb2 100644 --- a/include/linux/dynamic_debug.h +++ b/include/linux/dynamic_debug.h @@ -58,27 +58,16 @@ struct _ddebug { #endif } __attribute__((aligned(8))); -enum class_map_type { +enum ddebug_class_map_type { DD_CLASS_TYPE_DISJOINT_BITS, /** -* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, one per bit. -* expecting hex input. Built for drm.debug, basis for other types. +* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, mapped to bits[0..N]. +* Expects hex input. Built for drm.debug, basis for other types. */ DD_CLASS_TYPE_LEVEL_NUM, /** -* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0-N. -* N turns on just bits N-1 .. 0, so N=0 turns all bits off. -*/ - DD_CLASS_TYPE_DISJOINT_NAMES, - /** -* DD_CLASS_TYPE_DISJOINT_NAMES: input is a CSV of [+-]CLASS_NAMES, -* classes are independent, like _DISJOINT_BITS. -*/ - DD_CLASS_TYPE_LEVEL_NAMES, - /** -* DD_CLASS_TYPE_LEVEL_NAMES: input is a CSV of [+-]CLASS_NAMES, -* intended for names like: INFO,DEBUG,TRACE, with a module prefix -* avoid EMERG,ALERT,CRIT,ERR,WARNING: they're not debug +* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0..N. +* Input N turns on bits 0..N-1 */ }; @@ -88,7 +77,7 @@ struct ddebug_class_map { const char **class_names; const int length; const int base; /* index of 1st .class_id, allows split/shared space */ - enum class_map_type map_type; + enum ddebug_class_map_type map_type; }; /** diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 43a8e04b8599..d5701207febc 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -636,76 +636,6 @@ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp, #define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1) -/* accept comma-separated-list of [+-] classnames */ -static int param_set_dyndbg_classnames(const char *instr, const struct kernel_param *kp) -{ - const struct ddebug_class_param *dcp = kp->arg; - const struct ddebug_class_map *map = dcp->map; - unsigned long curr_bits, old_bits; - char *cl_str, *p, *tmp; - int cls_id, totct = 0; - bool wanted; - - cl_str = tmp = kstrdup_and_replace(instr, '\n', '\0', GFP_KERNEL); - if (!tmp) - return -ENOMEM; - - /* start with previously set state-bits, then modify */ - curr_bits = old_bits = *dcp->bits; - vpr_info("\"%s\" > %s:0x%lx\n", cl_str, KP_NAME(kp), curr_bits); - - for (; cl_str; cl_str = p) { - p = strchr(cl_str, ','); - if (p) - *p++ = '\0'; - - if (*cl_str == '-') { - wanted = false; - cl_str++; - } else { - wanted = true; - if (*cl_str == '+') - cl_str++; - } - cls_id = match_string(map->class_names, map->length, cl_str); - if (cls_id < 0) { - pr_err("%s unknown to %s\n", cl_str, KP_NAME(kp)); - continue; - } - - /* have one or more valid class_ids of one *_NAMES type */ - switch (map->map_type) { - case DD_CLASS_TYPE_DISJOINT_NAMES: - /* the +/- pertains to a single bit */ - if (test_bit(cls_id, _bits) == wanted) { - v3pr_info("no change on %s\n", cl_str); - continue; - } - curr_bits ^= BIT(cls_id); - totct += ddebug_apply_class_bitmap(dcp, _bits, *dcp->bits, NULL); - *dcp->bits = curr_bits; - v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), cls_id, - map->class_names[cls_id]); - break; - case DD_CLASS_TYPE_
[PATCH v9-resend 13/54] dyndbg: reduce verbose=3 messages in ddebug_add_module
When modprobing a module, dyndbg currently logs/says "add-module", and then "skipping" if the module has no prdbgs. Instead just check 1st and return quietly. no functional change Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index d4a0ae31d059..43a8e04b8599 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -1245,11 +1245,10 @@ static int ddebug_add_module(struct _ddebug_info *di, const char *modname) { struct ddebug_table *dt; - v3pr_info("add-module: %s.%d sites\n", modname, di->num_descs); - if (!di->num_descs) { - v3pr_info(" skip %s\n", modname); + if (!di->num_descs) return 0; - } + + v3pr_info("add-module: %s %d sites\n", modname, di->num_descs); dt = kzalloc(sizeof(*dt), GFP_KERNEL); if (dt == NULL) { -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 11/54] dyndbg: tighten ddebug_class_name() 1st arg type
Change function's 1st arg-type, and deref in the caller. The fn doesn't need any other fields in the struct. no functional change. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 8320cadeb251..882354e1e78f 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -1120,12 +1120,12 @@ static void *ddebug_proc_next(struct seq_file *m, void *p, loff_t *pos) #define class_in_range(class_id, map) \ (class_id >= map->base && class_id < map->base + map->length) -static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug *dp) +static const char *ddebug_class_name(struct ddebug_table *dt, struct _ddebug *dp) { - struct ddebug_class_map *map = iter->table->classes; - int i, nc = iter->table->num_classes; + struct ddebug_class_map *map = dt->classes; + int i; - for (i = 0; i < nc; i++, map++) + for (i = 0; i < dt->num_classes; i++, map++) if (class_in_range(dp->class_id, map)) return map->class_names[dp->class_id - map->base]; @@ -1159,7 +1159,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p) seq_puts(m, "\""); if (dp->class_id != _DPRINTK_CLASS_DFLT) { - class = ddebug_class_name(iter, dp); + class = ddebug_class_name(iter->table, dp); if (class) seq_printf(m, " class:%s", class); else -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 12/54] dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
old_bits arg is currently a pointer to the input bits, but this could allow inadvertent changes to the input by the fn. Disallow this. And constify new_bits while here. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 882354e1e78f..d4a0ae31d059 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -597,7 +597,8 @@ static int ddebug_exec_queries(char *query, const char *modname) /* apply a new class-param setting */ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp, -unsigned long *new_bits, unsigned long *old_bits, +const unsigned long *new_bits, +const unsigned long old_bits, const char *query_modname) { #define QUERY_SIZE 128 @@ -606,12 +607,12 @@ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp, int matches = 0; int bi, ct; - if (*new_bits != *old_bits) + if (*new_bits != old_bits) v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, - *old_bits, query_modname ?: "'*'"); + old_bits, query_modname ?: "'*'"); for (bi = 0; bi < map->length; bi++) { - if (test_bit(bi, new_bits) == test_bit(bi, old_bits)) + if (test_bit(bi, new_bits) == test_bit(bi, _bits)) continue; snprintf(query, QUERY_SIZE, "class %s %c%s", map->class_names[bi], @@ -623,9 +624,9 @@ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp, v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi, ct, map->class_names[bi], *new_bits); } - if (*new_bits != *old_bits) + if (*new_bits != old_bits) v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, - *old_bits, query_modname ?: "'*'"); + old_bits, query_modname ?: "'*'"); return matches; } @@ -681,7 +682,7 @@ static int param_set_dyndbg_classnames(const char *instr, const struct kernel_pa continue; } curr_bits ^= BIT(cls_id); - totct += ddebug_apply_class_bitmap(dcp, _bits, dcp->bits, NULL); + totct += ddebug_apply_class_bitmap(dcp, _bits, *dcp->bits, NULL); *dcp->bits = curr_bits; v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), cls_id, map->class_names[cls_id]); @@ -691,7 +692,7 @@ static int param_set_dyndbg_classnames(const char *instr, const struct kernel_pa old_bits = CLASSMAP_BITMASK(*dcp->lvl); curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 )); - totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, NULL); + totct += ddebug_apply_class_bitmap(dcp, _bits, old_bits, NULL); *dcp->lvl = (cls_id + (wanted ? 1 : 0)); v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", KP_NAME(kp), cls_id, map->class_names[cls_id], old_bits, curr_bits); @@ -745,7 +746,7 @@ static int param_set_dyndbg_module_classes(const char *instr, inrep &= CLASSMAP_BITMASK(map->length); } v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", KP_NAME(kp)); - totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, modnm); + totct += ddebug_apply_class_bitmap(dcp, , *dcp->bits, modnm); *dcp->bits = inrep; break; case DD_CLASS_TYPE_LEVEL_NUM: @@ -758,7 +759,7 @@ static int param_set_dyndbg_module_classes(const char *instr, old_bits = CLASSMAP_BITMASK(*dcp->lvl); new_bits = CLASSMAP_BITMASK(inrep); v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, KP_NAME(kp)); - totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, modnm); + totct += ddebug_apply_class_bitmap(dcp, _bits, old_bits, modnm); *dcp->lvl = inrep; break; default: -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 07/54] dyndbg: split param_set_dyndbg_classes to _module & wrapper fns
Split api-fn: param_set_dyndbg_classes(), adding modname param and passing NULL in from api-fn. The new arg allows caller to specify that only one module is affected by a prdbgs update. This selectivity will be used later to narrow the scope of changes made. no functional change. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 37 ++--- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index a1fd2e9dbafb..4a48f830507f 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -711,18 +711,9 @@ static int param_set_dyndbg_classnames(const char *instr, const struct kernel_pa return 0; } -/** - * param_set_dyndbg_classes - class FOO >control - * @instr: string echo>d to sysfs, input depends on map_type - * @kp:kp->arg has state: bits/lvl, map, map_type - * - * Enable/disable prdbgs by their class, as given in the arguments to - * DECLARE_DYNDBG_CLASSMAP. For LEVEL map-types, enforce relative - * levels by bitpos. - * - * Returns: 0 or <0 if error. - */ -int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp) +static int param_set_dyndbg_module_classes(const char *instr, + const struct kernel_param *kp, + const char *modnm) { const struct ddebug_class_param *dcp = kp->arg; const struct ddebug_class_map *map = dcp->map; @@ -759,8 +750,8 @@ int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp) KP_NAME(kp), inrep, CLASSMAP_BITMASK(map->length)); inrep &= CLASSMAP_BITMASK(map->length); } - v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp)); - totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, NULL); + v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", KP_NAME(kp)); + totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, modnm); *dcp->bits = inrep; break; case DD_CLASS_TYPE_LEVEL_NUM: @@ -773,7 +764,7 @@ int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp) old_bits = CLASSMAP_BITMASK(*dcp->lvl); new_bits = CLASSMAP_BITMASK(inrep); v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, KP_NAME(kp)); - totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, NULL); + totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, modnm); *dcp->lvl = inrep; break; default: @@ -782,6 +773,22 @@ int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp) vpr_info("%s: total matches: %d\n", KP_NAME(kp), totct); return 0; } + +/** + * param_set_dyndbg_classes - class FOO >control + * @instr: string echo>d to sysfs, input depends on map_type + * @kp:kp->arg has state: bits/lvl, map, map_type + * + * Enable/disable prdbgs by their class, as given in the arguments to + * DECLARE_DYNDBG_CLASSMAP. For LEVEL map-types, enforce relative + * levels by bitpos. + * + * Returns: 0 or <0 if error. + */ +int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp) +{ + return param_set_dyndbg_module_classes(instr, kp, NULL); +} EXPORT_SYMBOL(param_set_dyndbg_classes); /** -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 10/54] dyndbg: silence debugs with no-change updates
In ddebug_apply_class_bitmap(), check for actual changes to the bits before announcing them, to declutter logs. no functional change. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 368381dbd266..8320cadeb251 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -595,7 +595,7 @@ static int ddebug_exec_queries(char *query, const char *modname) return nfound; } -/* apply a new bitmap to the sys-knob's current bit-state */ +/* apply a new class-param setting */ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp, unsigned long *new_bits, unsigned long *old_bits, const char *query_modname) @@ -606,8 +606,9 @@ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp, int matches = 0; int bi, ct; - v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, *old_bits, - query_modname ?: ""); + if (*new_bits != *old_bits) + v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, + *old_bits, query_modname ?: "'*'"); for (bi = 0; bi < map->length; bi++) { if (test_bit(bi, new_bits) == test_bit(bi, old_bits)) @@ -622,8 +623,9 @@ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp, v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi, ct, map->class_names[bi], *new_bits); } - v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, *old_bits, - query_modname ?: ""); + if (*new_bits != *old_bits) + v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, + *old_bits, query_modname ?: "'*'"); return matches; } -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 08/54] dyndbg: drop NUM_TYPE_ARRAY
ARRAY_SIZE works here, since array decl is complete. no functional change Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index 2b0057058ecf..e458d4b838ac 100644 --- a/include/linux/dynamic_debug.h +++ b/include/linux/dynamic_debug.h @@ -106,11 +106,9 @@ struct ddebug_class_map { .mod_name = KBUILD_MODNAME, \ .base = _base, \ .map_type = _maptype, \ - .length = NUM_TYPE_ARGS(char*, __VA_ARGS__),\ + .length = ARRAY_SIZE(_var##_classnames),\ .class_names = _var##_classnames, \ } -#define NUM_TYPE_ARGS(eltype, ...) \ -(sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype)) /* encapsulate linker provided built-in (or module) dyndbg data */ struct _ddebug_info { -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 09/54] dyndbg: reduce verbose/debug clutter
currently, for verbose=3, these are logged (blank lines for clarity): dyndbg: query 0: "class DRM_UT_CORE +p" mod:* dyndbg: split into words: "class" "DRM_UT_CORE" "+p" dyndbg: op='+' dyndbg: flags=0x1 dyndbg: *flagsp=0x1 *maskp=0x dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 class=... dyndbg: no matches for query dyndbg: no-match: func="" file="" module="" format="" lineno=0-0 class=... dyndbg: processed 1 queries, with 0 matches, 0 errs That is excessive, so this patch: - shrinks 3 lines of 2nd stanza to single line - drops 1st 2 lines of 3rd stanza 3rd line is like 1st, with result, not procedure. 2nd line is just status, retold in 4th, with more info. New output: dyndbg: query 0: "class DRM_UT_CORE +p" mod:* dyndbg: split into words: "class" "DRM_UT_CORE" "+p" dyndbg: op='+' flags=0x1 *flagsp=0x1 *maskp=0x dyndbg: no-match: func="" file="" module="" format="" lineno=0-0 class=... dyndbg: processed 1 queries, with 0 matches, 0 errs no functional change. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 14 +++--- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 4a48f830507f..368381dbd266 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -266,9 +266,6 @@ static int ddebug_change(const struct ddebug_query *query, } mutex_unlock(_lock); - if (!nfound && verbose) - pr_info("no matches for query\n"); - return nfound; } @@ -501,7 +498,6 @@ static int ddebug_parse_flags(const char *str, struct flag_settings *modifiers) pr_err("bad flag-op %c, at start of %s\n", *str, str); return -EINVAL; } - v3pr_info("op='%c'\n", op); for (; *str ; ++str) { for (i = ARRAY_SIZE(opt_array) - 1; i >= 0; i--) { @@ -515,7 +511,6 @@ static int ddebug_parse_flags(const char *str, struct flag_settings *modifiers) return -EINVAL; } } - v3pr_info("flags=0x%x\n", modifiers->flags); /* calculate final flags, mask based upon op */ switch (op) { @@ -531,7 +526,7 @@ static int ddebug_parse_flags(const char *str, struct flag_settings *modifiers) modifiers->flags = 0; break; } - v3pr_info("*flagsp=0x%x *maskp=0x%x\n", modifiers->flags, modifiers->mask); + v3pr_info("op='%c' flags=0x%x maskp=0x%x\n", op, modifiers->flags, modifiers->mask); return 0; } @@ -541,7 +536,7 @@ static int ddebug_exec_query(char *query_string, const char *modname) struct flag_settings modifiers = {}; struct ddebug_query query = {}; #define MAXWORDS 9 - int nwords, nfound; + int nwords; char *words[MAXWORDS]; nwords = ddebug_tokenize(query_string, words, MAXWORDS); @@ -559,10 +554,7 @@ static int ddebug_exec_query(char *query_string, const char *modname) return -EINVAL; } /* actually go and implement the change */ - nfound = ddebug_change(, ); - vpr_info_dq(, nfound ? "applied" : "no-match"); - - return nfound; + return ddebug_change(, ); } /* handle multiple queries in query string, continue on error, return -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 05/54] dyndbg: replace classmap list with a vector
Classmaps are stored in an elf section/array, but are individually list-linked onto dyndbg's per-module ddebug_table for operation. This is unnecessary; even when ddebug_attach_classmap() is handling the builtin section (with classmaps for multiple builtin modules), its contents are ordered, so a module's possibly multiple classmaps will be consecutive in the section, and could be treated as a vector/block, since both start-address and subrange length are in the ddebug_info arg. IOW, this treats classmaps similarly to _ddebugs, which are already kept as vector-refs (address+len). So this changes: struct ddebug_class_map drops list-head link. struct ddebug_table drops the list-head maps, and gets: classes & num_classes for the start-address and num_classes, placed to improve struct packing. The loading: in ddebug_attach_module_classes(), replace the for-the-modname list-add loop, with a forloop that finds the module's subrange (start,length) of matching classmaps within the possibly builtin classmaps vector, and saves those to the ddebug_table. The reading/using: change list-foreach loops in ddebug_class_name() & ddebug_find_valid_class() to walk the array from start to length. Also: Move #define __outvar up, above an added use in a fn-prototype. Simplify ddebug_attach_module_classes args, ref has both address & len. no functional changes Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 1 - lib/dynamic_debug.c | 61 ++- 2 files changed, 32 insertions(+), 30 deletions(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index b9afc7731b7c..2b0057058ecf 100644 --- a/include/linux/dynamic_debug.h +++ b/include/linux/dynamic_debug.h @@ -83,7 +83,6 @@ enum class_map_type { }; struct ddebug_class_map { - struct list_head link; struct module *mod; const char *mod_name; /* needed for builtins */ const char **class_names; diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 152b04c05981..46e4cdd8e6be 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[]; extern struct ddebug_class_map __stop___dyndbg_classes[]; struct ddebug_table { - struct list_head link, maps; + struct list_head link; const char *mod_name; - unsigned int num_ddebugs; struct _ddebug *ddebugs; + struct ddebug_class_map *classes; + unsigned int num_ddebugs, num_classes; }; struct ddebug_query { @@ -147,13 +148,15 @@ static void vpr_info_dq(const struct ddebug_query *query, const char *msg) query->first_lineno, query->last_lineno, query->class_string); } +#define __outvar /* filled by callee */ static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table const *dt, - const char *class_string, int *class_id) + const char *class_string, + __outvar int *class_id) { struct ddebug_class_map *map; - int idx; + int i, idx; - list_for_each_entry(map, >maps, link) { + for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) { idx = match_string(map->class_names, map->length, class_string); if (idx >= 0) { *class_id = idx + map->base; @@ -164,7 +167,6 @@ static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table cons return NULL; } -#define __outvar /* filled by callee */ /* * Search the tables for _ddebug's which match the given `query' and * apply the `flags' and `mask' to them. Returns number of matching @@ -1114,9 +1116,10 @@ static void *ddebug_proc_next(struct seq_file *m, void *p, loff_t *pos) static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug *dp) { - struct ddebug_class_map *map; + struct ddebug_class_map *map = iter->table->classes; + int i, nc = iter->table->num_classes; - list_for_each_entry(map, >table->maps, link) + for (i = 0; i < nc; i++, map++) if (class_in_range(dp->class_id, map)) return map->class_names[dp->class_id - map->base]; @@ -1200,30 +1203,31 @@ static const struct proc_ops proc_fops = { .proc_write = ddebug_proc_write }; -static void ddebug_attach_module_classes(struct ddebug_table *dt, -struct ddebug_class_map *classes, -int num_classes) +static void ddebug_attach_module_classes(struct ddebug_table *dt, struct _ddebug_info *di) { struct ddebug_class_map *cm; - int i, j, ct = 0; + int i, nc = 0; - for (cm = classes, i = 0; i
[PATCH v9-resend 06/54] dyndbg: ddebug_apply_class_bitmap - add module arg, select on it
Add param: query_module to ddebug_apply_class_bitmap(), and pass it thru to _ddebug_queries(), replacing NULL with query_module. This allows its caller to update just one module, or all (as currently). We'll use this later to propagate drm.debug to each USEr as they're modprobed. No functional change. Signed-off-by: Jim Cromie --- after `modprobe i915`, heres the module dependencies, though not all on drm.debug. bash-5.2# lsmod Module Size Used by i915 3133440 0 drm_buddy 20480 1 i915 ttm90112 1 i915 i2c_algo_bit 16384 1 i915 video 61440 1 i915 wmi32768 1 video drm_display_helper200704 1 i915 drm_kms_helper208896 2 drm_display_helper,i915 drm 606208 5 drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm cec57344 2 drm_display_helper,i915 --- lib/dynamic_debug.c | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 46e4cdd8e6be..a1fd2e9dbafb 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -605,7 +605,8 @@ static int ddebug_exec_queries(char *query, const char *modname) /* apply a new bitmap to the sys-knob's current bit-state */ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp, -unsigned long *new_bits, unsigned long *old_bits) +unsigned long *new_bits, unsigned long *old_bits, +const char *query_modname) { #define QUERY_SIZE 128 char query[QUERY_SIZE]; @@ -613,7 +614,8 @@ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp, int matches = 0; int bi, ct; - v2pr_info("apply: 0x%lx to: 0x%lx\n", *new_bits, *old_bits); + v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, *old_bits, + query_modname ?: ""); for (bi = 0; bi < map->length; bi++) { if (test_bit(bi, new_bits) == test_bit(bi, old_bits)) @@ -622,12 +624,15 @@ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp, snprintf(query, QUERY_SIZE, "class %s %c%s", map->class_names[bi], test_bit(bi, new_bits) ? '+' : '-', dcp->flags); - ct = ddebug_exec_queries(query, NULL); + ct = ddebug_exec_queries(query, query_modname); matches += ct; v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi, ct, map->class_names[bi], *new_bits); } + v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, *old_bits, + query_modname ?: ""); + return matches; } @@ -682,7 +687,7 @@ static int param_set_dyndbg_classnames(const char *instr, const struct kernel_pa continue; } curr_bits ^= BIT(cls_id); - totct += ddebug_apply_class_bitmap(dcp, _bits, dcp->bits); + totct += ddebug_apply_class_bitmap(dcp, _bits, dcp->bits, NULL); *dcp->bits = curr_bits; v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), cls_id, map->class_names[cls_id]); @@ -692,7 +697,7 @@ static int param_set_dyndbg_classnames(const char *instr, const struct kernel_pa old_bits = CLASSMAP_BITMASK(*dcp->lvl); curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 )); - totct += ddebug_apply_class_bitmap(dcp, _bits, _bits); + totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, NULL); *dcp->lvl = (cls_id + (wanted ? 1 : 0)); v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", KP_NAME(kp), cls_id, map->class_names[cls_id], old_bits, curr_bits); @@ -755,7 +760,7 @@ int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp) inrep &= CLASSMAP_BITMASK(map->length); } v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp)); - totct += ddebug_apply_class_bitmap(dcp, , dcp->bits); + totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, NULL); *dcp->bits = inrep; break; case DD_CLASS_TYPE_LEVEL_NUM: @@ -768,7 +773,7 @@ int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp) old_bits = CLASSMAP_BITMASK(*dcp->lvl); new_bits = CLASSM
[PATCH v9-resend 04/54] dyndbg: make ddebug_class_param union members same size
struct ddebug_class_param keeps a ref to the state-storage of the param; make both class-types use the same unsigned long storage type. ISTM this is simpler and safer; it avoids an irrelevant difference, and if 2 users somehow get class-type mixed up (or refer to the wrong union member), at least they will both see the same value. Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 2 +- lib/dynamic_debug.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index ff44ec346162..b9afc7731b7c 100644 --- a/include/linux/dynamic_debug.h +++ b/include/linux/dynamic_debug.h @@ -124,7 +124,7 @@ struct _ddebug_info { struct ddebug_class_param { union { unsigned long *bits; - unsigned int *lvl; + unsigned long *lvl; }; char flags[8]; const struct ddebug_class_map *map; diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 73ccf947d4aa..152b04c05981 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -799,7 +799,7 @@ int param_get_dyndbg_classes(char *buffer, const struct kernel_param *kp) case DD_CLASS_TYPE_LEVEL_NAMES: case DD_CLASS_TYPE_LEVEL_NUM: - return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl); + return scnprintf(buffer, PAGE_SIZE, "%ld\n", *dcp->lvl); default: return -1; } -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 03/54] dyndbg: reword "class unknown, " to "class:_UNKNOWN_"
When a dyndbg classname is unknown to a kernel module (as before previous patch), the callsite is un-addressable via >control queries. The control-file displays this condition as "class unknown," currently. That spelling is sub-optimal/too-generic, so change it to "class:_UNKNOWN_" to loudly announce the erroneous situation, and to make it exceedingly greppable. NB: pr_debugs are only alterable via >control, and to protect class'd debug's from unintended alteration, "class name" must be given to change them. Classmaps map known classes to reserved .class_ids (the 1..64 val range per module). Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index f2c5e7910bb1..73ccf947d4aa 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -1154,7 +1154,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p) if (class) seq_printf(m, " class:%s", class); else - seq_printf(m, " class unknown, _id:%d", dp->class_id); + seq_printf(m, " class:_UNKNOWN_ _id:%d", dp->class_id); } seq_puts(m, "\n"); -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 02/54] test-dyndbg: fixup CLASSMAP usage error
A more careful reading of logging output from test_dynamic_debug.ko reveals: lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing categories\n" lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" class:MID lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class unknown, _id:13 107 says: HI is unknown, 105,106 have LOW/MID and MID/HI skew. The enum's 1st val (explicitly initialized) was wrong; it must be _base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP param). So the last enumeration exceeded the range of mapped class-id's, which triggered the "class unknown" report. I coded in an error, intending to verify err detection, then forgot, and missed that it was there. So this patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP(), showing that it is too error-prone. As noted in test-mod comments: * Using the CLASSMAP api: * - classmaps must have corresponding enum * - enum symbols must match/correlate with class-name strings in the map. * - base must equal enum's 1st value * - multiple maps must set their base to share the 0-62 class_id space !! Signed-off-by: Jim Cromie --- lib/test_dynamic_debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c index 8dd250ad022b..a01f0193a419 100644 --- a/lib/test_dynamic_debug.c +++ b/lib/test_dynamic_debug.c @@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p); DD_SYS_WRAP(disjoint_bits, T); /* symbolic input, independent bits */ -enum cat_disjoint_names { LOW = 11, MID, HI }; +enum cat_disjoint_names { LOW = 10, MID, HI }; DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10, "LOW", "MID", "HI"); DD_SYS_WRAP(disjoint_names, p); -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH v9-resend 00/54] fix CONFIG_DRM_USE_DYNAMIC_DEBUG=y
ne and export a classmap (in core module), and 2. refer to the exported class-struct from the other modules. They both tell dynamic-debug that the module has some of these class'd pr_debugs, so dyndbg can use the classmap's names to validate >control inputs and change the callsites. This is the opt-in. The distinction allows USErs to act differently than the DEFINEr; they have to follow the ref back to the DEFINEing module, find the kparam connected to the classmap, and lookup and apply its modprobed value. (this is the bug-fix). Dyndbg uses the classnames to validate "class FOO" >control inputs, and apply the changes to each module that has DEFINEd or USEd the classmap. This makes classmaps opt-in: modules must _DEFINE or _USE a classmap for their class'd pr_debug()s to be >control'd. NOTE: __pr_dbg_class(1, "const-int unreachable class 1"); is legal, but not controllable unless the const 1 has been mapped to a _DEFINE'd classname. NB: and __pr_dbg_class(i++, "undeclared class") is illegal. In drm_print.c we have: (theres room for better words...) /* classnames must match value-symbols of enum drm_debug_category */ DRM_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, DRM_UT_CORE, // _base /* this effectively names the bits in drm.debug */ "DRM_UT_CORE", "DRM_UT_DRIVER", "DRM_UT_KMS", "DRM_UT_PRIME", "DRM_UT_ATOMIC", "DRM_UT_VBL", "DRM_UT_STATE", "DRM_UT_LEASE", "DRM_UT_DP", "DRM_UT_DRMRES"); This maps the sequence of "classnames" to ints starting with DRM_UT_CORE. other _bases allow sharing the per-module 0..62 class-id space. (63 is default/unclassed/common prdbg). Only complete, linear maps are recommended. This suits DRM. DYNDBG_CLASSMAP_PARAM_REF() creates the sysfs-kparam classbits knob, binding the extern'd long-int/bitvec to the classmap. The extern insures that old users of __drm_debug can still check its value. DRM's categories are independent of each other. The other possible classmap-type/behavior is "related", ie somehow "ordered": V3>V2. The relatedness of classes in a classmap is enforced at the kparam, where they are all set together, not at the >control interface. THE PATCHSET has 2 halves: 1- dynamic-debug fix - API change The root cause was DECLARE_DYNDBG_CLASSMAP tried to do too much, and its use in both core and drivers, helpers couldnt sort the difference. The fix is to replace it with DYNDBG_CLASSMAP_DEFINE in core, and DYNDBG_CLASSMAP_USE in drivers,helpers. The 1st differs from -v1 by exporting the classmap, allowing 2nd to ref it. They respectively add records to 2 ELF sections in the module. Now, dyndbg's on-modprobe handler follows the _USE/refs to the owning module, finds the controlling kparam: drm.debug, and applies its value thru the classmap, to the module's pr_debugs. A selftest script is included: :#> ./tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh It recapitulates the DRM regression scenario using the 2 test modules. The test verifies that the dependent module is initialized properly from the parent's classmap kparam, and the classed prdbgs get enabled. This latest rev fixes the test for the various CONFIG_DYNAMIC_DEBUG* build combos, by skipping some subtests where the expected counts are wrong. Lukasz Bartosik caught this - thanks. CC: uka...@chromium.org And 2 tweaks to kdoc & howto, to steer api users away from using designated initializers to _DEFINE the classmap. 2- DRM fixes - use new api. a. update core/drivers to invoke DRM_CLASSMAP_DEFINE/_USE b. wrap DYNDBG_CLASSMAP_* with DRM_CLASSMAP_* - hide ifdef c. now with separate +DRM_CLASSMAP_USE patches for each driver/helper: d. and defer dropping DECLARE_DYNDBG_CLASSMAP til later Maybe theres a single place to invoke DRM_CLASSMAP_USE just once, perhaps from a client library c-file. I poked a little, didn't find it. It would be a bit obscured for an opt-in style declaration. Patches are against v6.10 theyre also at: tree/branch: https://github.com/jimc/linux.git dd-fix-9d and lkp-robot told me: [jimc:dd-fix-9d] BUILD SUCCESS 7c38f1d94f9919fec887113b620b83d60061c035 Finally, classmaps are in a meta-stable state right now; some governor might yet walk it over to the gravel pit out back. Tested-bys would help greatly, help get it off the fence it straddles. Please specify your test method: selftest or drm.debug=0x1ff boot. Next Im gonna try to haul this over to the freedesktop DRM-CI river, presuming I can find the way (accts,etc) Also entertaining Reviewed-bys :-} Jim Cromie (54): DYNAMIC-DEBUG parts: cleanup: docs/dyndbg: update exam
[PATCH v9-resend 01/54] docs/dyndbg: update examples \012 to \n
commit 47ea6f99d06e ("dyndbg: use ESCAPE_SPACE for cat control") changed the control-file to display format strings with "\n" rather than "\012". Update the docs to match the new reality. Signed-off-by: Jim Cromie --- Documentation/admin-guide/dynamic-debug-howto.rst | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 0e9b48daf690..6a8ce5a34382 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -52,12 +52,12 @@ query/commands to the control file. Example:: # grease the interface :#> alias ddcmd='echo $* > /proc/dynamic_debug/control' - :#> ddcmd '-p; module main func run* +p' + :#> ddcmd '-p; module main func run* +p' # disable all, then enable main :#> grep =p /proc/dynamic_debug/control - init/main.c:1424 [main]run_init_process =p " with arguments:\012" - init/main.c:1426 [main]run_init_process =p "%s\012" - init/main.c:1427 [main]run_init_process =p " with environment:\012" - init/main.c:1429 [main]run_init_process =p "%s\012" + init/main.c:1424 [main]run_init_process =p " with arguments:\n" + init/main.c:1426 [main]run_init_process =p "%s\n" + init/main.c:1427 [main]run_init_process =p " with environment:\n" + init/main.c:1429 [main]run_init_process =p "%s\n" Error messages go to console/syslog:: -- 2.45.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error
On Thu, May 9, 2024 at 8:39 AM Muni Sekhar wrote: > > Dear Linux Kernel Community, > > I am reaching out to seek assistance regarding the usage of spin locks > in the Linux kernel and to address a recurring issue related to hard > LOCKUP errors that I have encountered during testing. > build your kernel with LOCKDEP everything ? > Recently, I developed a small kernel module that involves ISR handling > and utilizes the spinlock_t primitive. In my module, I have employed > spin locks both in process context using spin_lock() and spin_unlock() > APIs, as well as in ISR context using spin_lock_irqsave() and > spin_unlock_irqrestore() APIs. > > Here is a brief overview of how I have implemented spin locks in my module: > I certainly dont know whether the above and below are legal. Id be comparing my usage to working examples from the source-code. and you didnt say anything about your module or what it does. (fwiw, you'd get more help if it were "our" module, ie gpl'd) > However, during testing, I have encountered a scenario where a hard > LOCKUP (NMI watchdog: Watchdog detected hard LOCKUP on cpu 2) error > occurs, specifically when a process context code execution triggers > the spin_lock() function and is preempted by an interrupt that enters > the ISR context and encounters the spin_lock_irqsave() function. This > situation leads to the CPU being stuck indefinitely. > Id build w/o watchdog, to see what else goes wrong. 2 different errors might help find common cause. > My primary concern is to understand the appropriate usage of spin > locks in both process and ISR contexts to avoid such hard LOCKUP > errors. I am seeking clarification on the following points: > Documentation/locking/hwspinlock.rst > Is it safe to use spin_lock_irqsave() and spin_unlock_irqrestore() > APIs in ISR context and spin_lock() and spin_unlock() APIs in process > context simultaneously? > In scenarios where a process context code execution is preempted > by an interrupt and enters ISR context, how should spin locks be used > to prevent hard LOCKUP errors? > Are there any specific guidelines or best practices for using spin > locks in scenarios involving both process and ISR contexts? > > I would greatly appreciate any insights, guidance, or suggestions from > the experienced members of the Linux kernel community to help address > this issue and ensure the correct and efficient usage of spin locks in > my kernel module. > > Thank you very much for your time and assistance. > > -- > Thanks, > Sekhar > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Handling I2C eeprom devices
On Fri, May 17, 2024 at 7:35 AM Patryk wrote: > > Hi, > I've got a question regarding how to handle I2C eeprom devices. I see > that in the kernel/drivers/misc/eeprom there are not that many drivers > available. Does it mean that they support various chips that do not > necessarily come from one vendor? > Looking at example at24.c, in the compatible properties I see that all > of them refers to atmel, however when I compared the following > devices: AT24C04C and BRCB008GWZ, at the first glance they look kinda > similar: > - they are organized internally in the same way - 1024 x 8 (8K) > - read/write commands looks the same > > I'm not asking you to tell me whether or not it's possible this driver > at24 with the device I need (BRCB008GWZ), rather I would like to get a > suggestion on how to approach this and what factors I should take into > account to make the right decision. > > Best regards > Patryk > $ git ls-files | grep eprom | wc -l 89 [jimc@frodo linux.git]$ git ls-files | grep eprom\.h | wc -l 29 [jimc@frodo linux.git]$ git ls-files | grep eprom | grep include arch/parisc/include/asm/eisa_eeprom.h arch/sparc/include/asm/eeprom.h drivers/staging/rtl8723bs/include/rtw_eeprom.h include/linux/eeprom_93cx6.h include/linux/eeprom_93xx46.h include/linux/spi/eeprom.h include/media/tveeprom.h Id look at those headers for similarity, then the 2 c files in misc for similarity. also the files under devicetree - thats ALL interface defn you didnt say if those parts are I2C or SPI or what. do you have the hardware ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
git send-email and gmail smtp
so I tried to submit a patchset via sendemail, and ran aground on authorization. its been a while since I sent from this computer, laptop power cord is cut :-( but failure wording is ambiguous 5.7.8 Username and Password not accepted. For more information, go to 5.7.8 https://support.google.com/mail/?p=BadCredentials j15-20020a0566022ccf00b007d6905cc017sm3758492iow.4 - gsmtp Essentially, google is changing policy, and 2FA is coming (or just arrived) is there a well-travelled path to work around this issue? something like ssh-key-agent ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Linux 4 block device driver infrastructure
On Thu, Nov 30, 2023 at 9:08 AM Alexandru Goia wrote: > > Greetings ! > > I am a Unix/Linux hobbyist from Romania, interested in kernel stuff. > I need some clarifications, related to block device subsystem in Linux 4, > so I will ask them here, if you can answer me, please... > > 1) Why (in Linux 4) in struct block_device_operations, the (*open)(struct > block_device *, fmode_t) > has a different signature than the (*release)(struct gendisk *, fmode_t) ? > Why open() > uses block_device, while release() uses gendisk ? They are both in a struct > block_device_operations. Why they not refer to the same thing ? > in linux current, its not like that: struct block_device_operations { void (*submit_bio)(struct bio *bio); int (*poll_bio)(struct bio *bio, struct io_comp_batch *iob, unsigned int flags); int (*open)(struct gendisk *disk, blk_mode_t mode); void (*release)(struct gendisk *disk); Old books are still useful, but new code is a much better place to look. > I understand that gendisk refer to a real disk, and block_device (s) to > logical disk (s) > and partitions. But why the kernel developers have chosen to use different > signatures ? > > 2) Release() is also synonim to close() ? > 3) Why is not explicitely present a close() function ? > 4) Why struct gendisk does not have inside it pointers to struct block_device > ? > > Thank you very much, > Alexander, > Computer hobbyist, > Romania > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: from CoLinux to MoreLinux :D
On Mon, Dec 4, 2023 at 1:02 PM Mario Marietto wrote: > > What is this ? > > https://l4re.org/download/snapshots/pre-built-images/arm-v7/ > Thats a micro-kernel, sort of like GNU Hurd. theres also https://doc.redox-os.org/book/ch04-01-microkernels.html ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: What situation will an anonymous writer come?
On Tue, Nov 7, 2023 at 2:01 AM wrote: > > Hi, > > I find this function __up_writer refering to an anonymous a writer? How does > it occur? > ``` > // kernel/locking/rwsem.c > static inline void __up_write(struct rw_semaphore *sem) > { > long tmp; > > DEBUG_RWSEMS_WARN_ON(sem->magic != sem, sem); > /* > * sem->owner may differ from current if the ownership is transferred > * to an anonymous writer by setting the RWSEM_NONSPINNABLE bits. > */ > DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && > !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), > sem);<-- is it necessary? > > preempt_disable(); > rwsem_clear_owner(sem); > tmp = atomic_long_fetch_add_release(-RWSEM_WRITER_LOCKED, > >count); > if (unlikely(tmp & RWSEM_FLAG_WAITERS)) > rwsem_wake(sem); > preempt_enable(); > } > ``` > > I do a search by using `git blame` and find it's added in this commit > 02f1082b003a0cd48f48f12533d969cdbf1c2b63, > and in this commit d7d760efad70c7a030725499bf9f342f04af24dd, it refers to > below situation that can have an anonymous writer: > > > There are use cases where a rwsem can be acquired by one task, but > > released by another task. In thess cases, optimistic spinning may need > > to be disabled. One example will be the filesystem freeze/thaw code > > where the task that freezes the filesystem will acquire a write lock > > on a rwsem and then un-owns it before returning to userspace. Later on, > > another task will come along, acquire the ownership, thaw the filesystem > > and release the rwsem. > > > > Bit 0 of the owner field was used to designate that it is a reader > > owned rwsem. It is now repurposed to mean that the owner of the rwsem > > is not known. If only bit 0 is set, the rwsem is reader owned. If bit > > 0 and other bits are set, it is writer owned with an unknown owner. > > One such value for the latter case is (-1L). So we can set owner to 1 for > > reader-owned, -1 for writer-owned. The owner is unknown in both cases. > > > > To handle transfer of rwsem ownership, the higher level code should > > set the owner field to -1 to indicate a write-locked rwsem with unknown > > owner. Optimistic spinning will be disabled in this case. > > > > Once the higher level code figures who the new owner is, it can then > > set the owner field accordingly. > > As it mentions that at higher level, we set -1 to owner subjectively in order > to do an owner migration, and I only find it's used in only > one place, i.e. percpu-rwsem in this commit > 5a817641f68a6399a5fac8b7d2da67a73698ffed which has been removed in commit > 7f26482a872c36b2ee87ea95b9dcd96e3d5805df. > > So does it mean an anonymous writer don't exist at current kernel? should we > remove the second condition in this assert check? > > DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && > !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem); > > Thanks, > Mu you didnt really say why youre looking at it. I presume youve triggered an error that implied it was your prob, and removing the 2nd condition fixed it ? If so (and you get no further "advice" here) I would try feeding it to lkp-robot, it will at least build-test it on "all" the arches you dont have at hand. FWIW, there are ~12 uses of that macro, and only 1 has the 2nd condition. Were they all added together, or were they spread across several commits ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
how to use perf record effectively
I have a working patchset which de-duplicates the pr_debug per-callsite ( module, filename, function ) data. it loads that column data into 3 maple-trees, and simple accessor fns retrieve the data by lookup with the pr-debug address. So it stores these callsites: [0.721980] dyndbg: 3653 prdebugs in 307 modules, 19 KiB in ddebug tables, 114 kiB .. into these intervals: [ 104.047210] dyndbg: mt-funcs has 2174 entries [ 104.047816] dyndbg: mt-files has 539 entries [ 104.048410] dyndbg: mt-mods has 312 entries once these are loaded, the __dyndbg_sites section, which separates the 3 columns from the __dyndbg section, can be recycled.contains ALL GOOD SO FAR. BUT WHATS THE RUNTIME COST OF THIS ? perf stat -r200 cat /proc/dynamic_debug/control > /dev/null; this should be a good test - it calls all 3 accessors for each pr-debug in the kernel. but comparing master against this branch shows little change, and adding --table to see the variations in the runs suggests that the change is less than the variation within a test. MASTER - v6.6 bash-5.2# perf stat -r 200 cat /proc/dynamic_debug/control > /dev/null Performance counter stats for 'cat /proc/dynamic_debug/control' (200 runs): 10.29 msec task-clock #0.713 CPUs utilized ( +- 0.56% ) 43 context-switches #4.177 K/sec ( +- 0.03% ) 1 cpu-migrations # 97.142 /sec( +- 5.80% ) 73 page-faults #7.091 K/sec ( +- 0.10% ) 8906200 cycles #0.865 GHz ( +- 0.17% ) 147349 stalled-cycles-frontend #1.65% frontend cycles idle( +- 0.18% ) 24971 stalled-cycles-backend #0.28% backend cycles idle ( +- 8.18% ) 20589718 instructions #2.31 insn per cycle #0.01 stalled cycles per insn ( +- 0.02% ) 5470202 branches # 531.388 M/sec ( +- 0.01% ) 0 branch-misses 0.0144421 +- 0.647 seconds time elapsed ( +- 0.45% ) DE_DUPLICATION branch bash-5.2# perf stat -r200 cat /proc/dynamic_debug/control > /dev/null Performance counter stats for 'cat /proc/dynamic_debug/control' (200 runs): 21.89 msec task-clock #0.622 CPUs utilized ( +- 0.69% ) 44 context-switches #2.010 K/sec ( +- 0.12% ) 1 cpu-migrations # 45.693 /sec( +- 3.87% ) 73 page-faults #3.336 K/sec ( +- 0.10% ) 52017542 cycles #2.377 GHz ( +- 0.54% ) 177875 stalled-cycles-frontend #0.34% frontend cycles idle( +- 0.48% ) 134469 stalled-cycles-backend #0.26% backend cycles idle ( +- 4.24% ) 134707837 instructions #2.59 insn per cycle #0.00 stalled cycles per insn ( +- 0.30% ) 39386555 branches #1.800 G/sec ( +- 0.29% ) 0 branch-misses 0.035188 +- 0.000167 seconds time elapsed ( +- 0.47% ) I tried perf stat record, then perf-diff on the results, it showed empty comparisons on a handful of event-types [jimc@frodo boots-dump]$ perf diff -v v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0* v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-8-g067d1f1d8675* v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906* > foo group desc not available pmu capabilities not available group desc not available pmu capabilities not available group desc not available pmu capabilities not available group desc not available pmu capabilities not available group desc not available pmu capabilities not available group desc not available pmu capabilities not available group desc not available pmu capabilities not available [jimc@frodo boots-dump]$ more foo # Event 'task-clock' # # Data files: # [0] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0 (Baseline) # [1] v6.6-36-g73a29cb216c0/perf-rec-6.6.0-f2-00036-g73a29cb216c0-null # [2] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-8-g067d1f1d8675 # [3] v6.6-8-g067d1f1d8675/perf-rec-6.6.0-tf2-8-g067d1f1d8675-null # [4] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906 # [5] v6.6-23-g10f95252e906/perf-rec-6.6.0-tf2-00023-g10f95252e906-null # # Baseline/0 Delta Abs/1
Re: How to switch driver from wireless extension to cfg/mac80211
On Sat, Oct 7, 2023 at 1:14 PM Philipp Hortmann wrote: > > Hi, > > after cutting away a lot of dead code from the rtl8192e I would like to > understand the way forward to migrate the driver from wireless extension > to cfg/mac80211. > I think you need more email recipients for definitive answers. In particular, is anyone else doing this ? if they are, you should find them, make the job easier. > What is the best way forward to migrate the driver rtl8192e towards the > drivers/net/wireless/realtek/rtlwifi/rtl8192* ? > Id start with this search: $ git log --grep=ieee80211_ -p -- drivers/net/wireless/realtek/ | less +/ieee80211_ then narrow with a particular api-call that sounds like it would be central to the switchover. It might be useful to search for many api calls at once, rank them by how many of the calls they add (presuming more to be better, more "comprehensive") > Does it have to be a hard cut? not sure what you mean, but I'd guess no - smaller incremental changes are preferred > > What to start with? > - start to change the used structs towards ieee80211_hw? the old adage: look at the data structs 1st. not sure how well that applies in any given (or your) situation. adapting old code to new structs does sound sane, and incrementally testable. > > Thanks for your support. > > Bye Philipp > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
help - macro arg reuse - fix ?
is there a simple fix for this ? -:451: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_var' - possible side-effects? #451: FILE: include/linux/dynamic_debug.h:121: +#define DYNDBG_CLASSMAP_USE_(_var, _uname) \ + extern struct ddebug_class_map _var;\ + static struct ddebug_class_user __aligned(8) __used \ + __section("__dyndbg_class_users") _uname = {\ + .user_mod_name = KBUILD_MODNAME,\ + .map = &_var, \ } ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
how to fix MACRO_ARG_REUSE
on a recent submit to LKML https://lore.kernel.org/lkml/20230801170255.163237-1-jim.cro...@gmail.com/ I got a Patchwork CI warning in report: https://patchwork.freedesktop.org/series/113363/ 1a864a4fe7ce dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression -:445: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_var' - possible side-effects? #445: FILE: include/linux/dynamic_debug.h:120: +#define DYNDBG_CLASSMAP_USE_(_var, _uname) \ +extern struct ddebug_class_map _var; \ +struct ddebug_class_user __used \ +__section("__dyndbg_class_users") _uname = { \ + .user_mod_name = KBUILD_MODNAME, \ + .map = &_var, \ } _var is expanded 2x, the "extra" time is to declare it as "extern", meaning its exported elsewhere. the usual fix for macro problems like this is __typeof(); something like: #define foo(a,b,...) \ typeof(a) _a = a; \ ... but I dont see how to use it - I need _var to name the struct exported from another module, and I need to take its &-address. Is there a trick / technique I can use ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
back at the naming bikeshed
so I found myself writing this macro, and using it 4 times. +#define for_each_boxed_veclen(_box, _vec, _len, _ct, _curs) \ + for (_ct = 0, _curs = _box->_vec; _ct < _box->_len; _ct++, _curs++) - for (i = 0, cm = di->classes; i < di->num_classes; i++, cm++) { + for_each_boxed_veclen(di, classes, num_classes, i, cm) { Qs: does it exist by another name already ? is it worth having generally ? are there better ways to do it ? fwiw, it does sound semantically connected to __counted_by() attribute struct Ntuple { int len; struct tuple **vector __counted_by(len); } ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CONFLICT (content): Merge conflict in scripts/kconfig/Makefile
On Fri, Jun 23, 2023 at 12:15 PM Mario Marietto wrote: > > Hello. > > I'm trying to enable KVM virtualization on the Arm Chromebook using KVM-tool. > This is the tutorial where I'm reading how to do that : > > > https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/virtualization-on-the-chromebook-using-kvm-tool > > > Below you can see what I did and the error that I've got : > > > /home/marietto/Scrivania/Chromebook# git clone > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > > Cloning into 'linux-stable'... > remote: Enumerating objects: 11487511, done. > remote: Counting objects: 100% (3953/3953), done. > remote: Compressing objects: 100% (2263/2263), done. > remote: Total 11487511 (delta 2912), reused 2100 (delta 1686), pack-reused > 11483558 > Ricezione degli oggetti: 100% (11487511/11487511), 4.47 GiB | 6.32 MiB/s, > done. > Risoluzione dei delta: 100% (9170170/9170170), done. > Checking out files: 100% (80340/80340), done. > > /home/marietto/Scrivania/Chromebook# cd linux-stable > > /home/marietto/Scrivania/Chromebook/linux-stable# git checkout > > Your branch is up to date with 'origin/master'. > > /home/marietto/Scrivania/Chromebook/linux-stable# git checkout > origin/linux-5.4.y -b linux-5.4.y > > Checking out files: 100% (72207/72207), done. > Branch 'linux-5.4.y' set up to track remote branch 'linux-5.4.y' from > 'origin'. > Switched to a new branch 'linux-5.4.y' > > /home/marietto/Scrivania/Chromebook/linux-stable# git remote add kvm-tool > https://github.com/penberg/linux-kvm.git > > > /home/marietto/Scrivania/Chromebook/linux-stable# git remote update > > Fetching origin > Fetching kvm-tool > remote: Enumerating objects: 11257, done. > remote: Counting objects: 100% (676/676), done. > remote: Total 11257 (delta 675), reused 675 (delta 675), pack-reused 10581 > Ricezione degli oggetti: 100% (11257/11257), 2.57 MiB | 8.98 MiB/s, done. > Risoluzione dei delta: 100% (7441/7441), completed with 36 local objects. > Da https://github.com/penberg/linux-kvm > * [nuovo branch] master -> kvm-tool/master > * [nuovo branch] vga/core -> kvm-tool/vga/core > > /home/marietto/Scrivania/Chromebook/linux-stable# git merge kvm-tool/master > > Auto-merging scripts/kconfig/Makefile > CONFLICT (content): Merge conflict in scripts/kconfig/Makefile > Auto-merging arch/x86/Kconfig > Auto-merging MAINTAINERS > CONFLICT (content): Merge conflict in MAINTAINERS > warning: inexact rename detection was skipped due to too many files. > warning: you may want to set your merge.renamelimit variable to at least > 30049 and retry the command. > Automatic Merge failed; fix the conflicts and run the commit of the result. > > # git merge kvm-tool/master > > error: Merging is not possible because you have unmerged files. > hint: Fix them up in the work tree, and then use 'git add/rm ' > hint: as appropriate to mark resolution and make a commit. > fatal: Exiting because of an unresolved conflict. > > > this is the conflict I see inside the Makefile : > > > <<< HEAD > PHONY += xconfig gconfig menuconfig config localmodconfig localyesconfig > build_menuconfig build_nconfig build_gconfig build_xconfig > PHONY += oldconfig xconfig gconfig menuconfig config silentoldconfig > update-po-config localmodconfig localyesconfig kvmconfig > >>> kvm-tool/master > > > Is there a chance to fix it ? thanks > of course there is. you must decide. offhand - Id try to just combine the 2 lists into 1, duplicates are probly ok in PHONY targets. then drop as errs/suggestions guide > > -- > Mario. > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [jimc:dd-fix-2g] BUILD REGRESSION 664531695395972a1684dbc3604731db280b479e
On Tue, Jun 13, 2023 at 11:43 AM wrote: > > Trouble with __UNIQUE_ID > > Im getting an error which "shouldnt be possible", but is happening anyway. > > > On Mon, Jun 12, 2023 at 2:55 PM kernel test robot wrote: > > > > hppa-linux-ld: > > drivers/gpu/drm/nouveau/nouveau_drm.o:(__dyndbg_class_users+0x0): multiple > > definition of `__UNIQUE_ID_ddebug_class_user323'; > > drivers/gpu/drm/radeon/radeon_drv.o:(__dyndbg_class_users+0x0): first > > defined here > > riscv64-linux-ld: drivers/gpu/drm/gud/gud_drv.o:(__dyndbg_class_users+0x0): > > multiple definition of `__UNIQUE_ID_ddebug_class_user305'; > > drivers/gpu/drm/qxl/qxl_drv.o:(__dyndbg_class_users+0x0): first defined here > > riscv64-linux-ld: > > drivers/gpu/drm/nouveau/nouveau_drm.o:(__dyndbg_class_users+0x0): multiple > > definition of `__UNIQUE_ID_ddebug_class_user374'; > > drivers/gpu/drm/radeon/radeon_drv.o:(__dyndbg_class_users+0x0): first > > defined here > > > > Error/Warning ids grouped by kconfigs: > > > > gcc_recent_errors > > |-- parisc-allyesconfig > > | `-- > > multiple-definition-of-__UNIQUE_ID_ddebug_class_user323-drivers-gpu-drm-radeon-radeon_drv.o:(__dyndbg_class_users):first-defined-here > > |-- riscv-allyesconfig > > | |-- > > multiple-definition-of-__UNIQUE_ID_ddebug_class_user305-drivers-gpu-drm-qxl-qxl_drv.o:(__dyndbg_class_users):first-defined-here > > | `-- > > multiple-definition-of-__UNIQUE_ID_ddebug_class_user374-drivers-gpu-drm-radeon-radeon_drv.o:(__dyndbg_class_users):first-defined-here > > the source of the error is this: > > /** > * DYNDBG_CLASSMAP_USE - refer to a classmap, DEFINEd elsewhere. > * @_var: name of the exported classmap var > * > * This registers a module's use of another module's classmap defn, so > * dyndbg can authorize "class DRM_CORE ..." >control commands upon > * this module. > */ > #define DYNDBG_CLASSMAP_USE(_var) \ > DYNDBG_CLASSMAP_USE_(_var, __UNIQUE_ID(ddebug_class_user)) > #define DYNDBG_CLASSMAP_USE_(_var, _uname) \ > extern struct ddebug_class_map _var;\ > struct ddebug_class_user __used \ > __section("__dyndbg_class_users") _uname = {\ > .user_mod_name = KBUILD_MODNAME,\ > .map = &_var, \ > } > > is there something subtle (or obvious) wrong with my macro ? git log --grep __UNIQUE_ID led me to a significant hint, in: commit e9092d0d97961146655ce51f43850907d95f68c3 Author: Linus Torvalds Date: Mon Apr 9 10:34:07 2018 -0700 Fix subtle macro variable shadowing in min_not_zero() [ That said, __UNIQUE_ID() itself has several issues that make it less than wonderful. In particular, the "uniqueness" has a fallback on the line number, which means that it's not actually unique in more complex cases if you don't build with gcc or clang (which have working unique counters that aren't tied to line numbers). That historical broken fallback also means that we have that pointless "prefix" argument that doesn't actually make much sense _except_ for the known-broken case. Oh well. ] [jimc@frodo wk-suren]$ ack 'define __UNIQUE_ID' include/linux/compiler-clang.h 11:#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) include/linux/compiler-gcc.h 42:#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) include/linux/compiler.h 182:# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__) tools/testing/scatterlist/linux/mm.h 65:#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) that 3rd defn, using __LINE__ is what Linus was talking about. for a quick-&-dirty test, I moved the offending DYNDBG_CLASSMAP_USE() decls down a few lines, this made the linker errors go away. It doesnt feel like a robust solution, but Im going with it. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [jimc:dd-fix-2g] BUILD REGRESSION 664531695395972a1684dbc3604731db280b479e
Trouble with __UNIQUE_ID Im getting an error which "shouldnt be possible", but is happening anyway. On Mon, Jun 12, 2023 at 2:55 PM kernel test robot wrote: > > tree/branch: https://github.com/jimc/linux.git dd-fix-2g > branch HEAD: 664531695395972a1684dbc3604731db280b479e drm-drivers: > DRM_CLASSMAP_USE in 2nd batch of drivers, helpers > > Error/Warning: (recently discovered and may have been fixed) > > hppa-linux-ld: > drivers/gpu/drm/nouveau/nouveau_drm.o:(__dyndbg_class_users+0x0): multiple > definition of `__UNIQUE_ID_ddebug_class_user323'; > drivers/gpu/drm/radeon/radeon_drv.o:(__dyndbg_class_users+0x0): first defined > here > include/drm/drm_print.h:421:9: error: implicit declaration of function > '_dynamic_func_call_cls' [-Werror=implicit-function-declaration] > riscv64-linux-ld: drivers/gpu/drm/gud/gud_drv.o:(__dyndbg_class_users+0x0): > multiple definition of `__UNIQUE_ID_ddebug_class_user305'; > drivers/gpu/drm/qxl/qxl_drv.o:(__dyndbg_class_users+0x0): first defined here > riscv64-linux-ld: > drivers/gpu/drm/nouveau/nouveau_drm.o:(__dyndbg_class_users+0x0): multiple > definition of `__UNIQUE_ID_ddebug_class_user374'; > drivers/gpu/drm/radeon/radeon_drv.o:(__dyndbg_class_users+0x0): first defined > here > > Error/Warning ids grouped by kconfigs: > > gcc_recent_errors > |-- parisc-allyesconfig > | `-- > multiple-definition-of-__UNIQUE_ID_ddebug_class_user323-drivers-gpu-drm-radeon-radeon_drv.o:(__dyndbg_class_users):first-defined-here > |-- riscv-allyesconfig > | |-- > multiple-definition-of-__UNIQUE_ID_ddebug_class_user305-drivers-gpu-drm-qxl-qxl_drv.o:(__dyndbg_class_users):first-defined-here > | `-- > multiple-definition-of-__UNIQUE_ID_ddebug_class_user374-drivers-gpu-drm-radeon-radeon_drv.o:(__dyndbg_class_users):first-defined-here > `-- x86_64-randconfig-a015-20230612 > `-- > include-drm-drm_print.h:error:implicit-declaration-of-function-_dynamic_func_call_cls > > elapsed time: 756m > > configs tested: 101 > configs skipped: 6 > > tested configs: > alphaallyesconfig gcc > alpha defconfig gcc > alpharandconfig-r022-20230612 gcc > arc allyesconfig gcc > arc defconfig gcc > arc randconfig-r015-20230612 gcc > arc randconfig-r043-20230612 gcc > arm allmodconfig gcc > arm allyesconfig gcc > arm defconfig gcc > arm randconfig-r046-20230612 clang > arm64allyesconfig gcc > arm64 defconfig gcc > cskydefconfig gcc > hexagon randconfig-r041-20230612 clang > hexagon randconfig-r045-20230612 clang > i386 allyesconfig gcc > i386 buildonly-randconfig-r006-20230612 clang > i386 debian-10.3 gcc > i386defconfig gcc > i386 randconfig-i001-20230612 clang > i386 randconfig-i002-20230612 clang > i386 randconfig-i003-20230612 clang > i386 randconfig-i004-20230612 clang > i386 randconfig-i005-20230612 clang > i386 randconfig-i006-20230612 clang > i386 randconfig-i011-20230612 gcc > i386 randconfig-i012-20230612 gcc > i386 randconfig-i013-20230612 gcc > i386 randconfig-i014-20230612 gcc > i386 randconfig-i015-20230612 gcc > i386 randconfig-i016-20230612 gcc > i386 randconfig-r012-20230612 gcc > i386 randconfig-r014-20230612 gcc > i386 randconfig-r035-20230612 clang > loongarchallmodconfig gcc > loongarch allnoconfig gcc > loongarchbuildonly-randconfig-r001-20230612 gcc > loongarch defconfig gcc > m68k allmodconfig gcc > m68k allyesconfig gcc > m68k buildonly-randconfig-r004-20230612 gcc > m68kdefconfig gcc > mips allmodconfig gcc > mips allyesconfig gcc > mips randconfig-r001-20230612 gcc > mips randconfig-r011-20230612 clang > mips randconfig-r021-20230612 clang > nios2 defconfig gcc > nios2randconfig-r032-20230612 gcc > openrisc randconfig-r013-20230612 gcc > openrisc randconfig-r024-20230612 gcc > parisc allyesconfig gcc > parisc defconfig gcc > parisc
Re: trouble running lkp-tests
On Sat, May 20, 2023 at 11:02 PM Valdis Klētnieks wrote: > > On Fri, 19 May 2023 13:38:37 -0600, jim.cro...@gmail.com said: > > hi all, > > > > anyone familiar enough with running lkp-tests to recognize these errors ? > > > any hints / guesses welcome ! > > Did you already check all the embarrassingly obvious things like a file system > being full and/or out of inodes, dangling symlinks that point to somewhere > in the middle of the Indian Ocean, or a file system mounted R/O? well, theres this in the readme, from 2022. # Note: lkp doesn't support ruby >= 3.0, default ruby version should be 2.x support is now improved/ing (fedora ships 3.2) and ruby 3.2 has been added to their test targets. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
trouble running lkp-tests
hi all, anyone familiar enough with running lkp-tests to recognize these errors ? 1st, from inside a virtme VM - bash-5.2# /usr/local/bin/lkp split-job --compatible /home/jimc/projects/lkp-tests.git/jobs/kmemleak-test.yaml /home/jimc/projects/lkp-tests.git/jobs/kmemleak-test.yaml => ./kmemleak-test-defaults.yaml bash-5.2# /usr/local/bin/lkp run ./kmemleak-test-defaults.yaml 2023-05-19 13:04:31 -0600 WARN -- Jobfile is a dirty file, better to run 'lkp split-job --compatible ./kmemleak-test-defaults.yaml' first sh: -c: line 1: syntax error near unexpected token `(' sh: -c: line 1: `grep -w '^memory:' /home/jimc/projects/lkp-tests.git/hosts/(none)' /home/jimc/projects/lkp-tests.git/bin/run-local:121:in `': undefined method `chomp' for nil:NilClass (NoMethodError) job['memory'] ||= `grep -w '^memory:' #{LKP_SRC}/hosts/#{HOSTNAME}`.split(' ')[1].chomp ^^ bash-5.2# /usr/local/bin/lkp split-job --compatible ./kmemleak-test-defaults.yaml /tmp/20230519-534-276vfc => ./20230519-534-276vfc-defaults.yaml bash-5.2# /usr/local/bin/lkp run ./20230519-534-276vfc-defaults.yaml 2023-05-19 13:05:41 -0600 WARN -- Jobfile is a dirty file, better to run 'lkp split-job --compatible ./20230519-534-276vfc-defaults.yaml' first sh: -c: line 1: syntax error near unexpected token `(' sh: -c: line 1: `grep -w '^memory:' /home/jimc/projects/lkp-tests.git/hosts/(none)' /home/jimc/projects/lkp-tests.git/bin/run-local:121:in `': undefined method `chomp' for nil:NilClass (NoMethodError) job['memory'] ||= `grep -w '^memory:' #{LKP_SRC}/hosts/#{HOSTNAME}`.split(' ')[1].chomp ^^ somehow, ruby is broken / unavailable inside the VM. 2 - on the host itself [jimc@frodo lkp-tests.git]$ sudo lkp run ./20230519-819840-khtr75-defaults.yaml [sudo] password for jimc: 2023-05-19 13:08:54 -0600 WARN -- Jobfile is a dirty file, better to run 'lkp split-job --compatible ./20230519-819840-khtr75-defaults.yaml' first current kernel cannot support kmemleak, please check CONFIG_DEBUG_KMEMLEAK /home/jimc/projects/lkp-tests.git/lib/debug.sh:12: die /home/jimc/projects/lkp-tests.git/tests/kmemleak-test:8: main :0: kill 825577 vmstat --timestamp -n 10 kill 825575 dmesg --follow --decode wait for background processes: 825579 meminfo grep: warning: stray \ before : grep: warning: stray \ before : 2023-05-19 13:08:58 WARN -- job exited due to die /lkp/result/kmemleak-test/defaults/frodo/fedora/defconfig/gcc/6.2.15-300.fc38.x86_64/3 grep: warning: stray \ before : 2023-05-19 13:08:58 WARN -- job exited due to die /lkp/result/kmemleak-test/defaults/frodo/fedora/defconfig/gcc/6.2.15-300.fc38.x86_64/3 grep: warning: stray \ before : 2023-05-19 13:08:58 WARN -- job exited due to die /lkp/result/kmemleak-test/defaults/frodo/fedora/defconfig/gcc/6.2.15-300.fc38.x86_64/3 grep: warning: stray \ before : 2023-05-19 13:08:58 WARN -- job exited due to die /lkp/result/kmemleak-test/defaults/frodo/fedora/defconfig/gcc/6.2.15-300.fc38.x86_64/3 grep: warning: stray \ before : 2023-05-19 13:08:58 WARN -- job exited due to die /lkp/result/kmemleak-test/defaults/frodo/fedora/defconfig/gcc/6.2.15-300.fc38.x86_64/3 grep: warning: stray \ before : 2023-05-19 13:08:58 WARN -- job exited due to die /lkp/result/kmemleak-test/defaults/frodo/fedora/defconfig/gcc/6.2.15-300.fc38.x86_64/3 grep: warning: stray \ before : grep: warning: stray \ before : 2023-05-19 13:08:58 WARN -- job exited due to die /lkp/result/kmemleak-test/defaults/frodo/fedora/defconfig/gcc/6.2.15-300.fc38.x86_64/3 /home/jimc/projects/lkp-tests.git/lib/data_store.rb:62:in `initialize': wrong number of arguments (given 2, expected 1) (ArgumentError) from /home/jimc/projects/lkp-tests.git/lib/common.rb:24:in `new' from /home/jimc/projects/lkp-tests.git/lib/common.rb:24:in `block in add_cached_method' from /home/jimc/projects/lkp-tests.git/lib/data_store.rb:246:in `create_new' from /home/jimc/projects/lkp-tests.git/lib/nresult_root.rb:241:in `create_layout' from /home/jimc/projects/lkp-tests.git/lib/nresult_root.rb:337:in `create_tables_layout' from /home/jimc/projects/lkp-tests.git/bin/run-local:167:in `' any hints / guesses welcome ! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Organizing patches/build artifacts against multiple trees
On Sun, Feb 19, 2023 at 8:21 PM Sarah Langstrom wrote: > > For developers that find themselves with multiple in progress > patchsets against multiple trees, how do you organize them locally? I > add each tree as a remote and use git-worktree for multiple streams of > development. I use worktrees as well. they all use the same repo, so its gotta save space. I tend to reuse them too, and rarely need make clean between swaps. [jimc@frodo f2]$ git worktree list /home/jimc/projects/lx/linux.git 457391b03803 [master] /home/jimc/projects/lx/wk-next75eada68d460 [kmemleak-format-tweaks] /home/jimc/projects/lx/wk-ref 89b88285f7ba [diet-x1b] /home/jimc/projects/lx/wk-rpi b762dfa091f8 [maph] /home/jimc/projects/lx/wk-suren 8660484ed1cf [modules-next] /home/jimc/projects/lx/wk-testb61bb42d2cdc [dd-fix-1d] FWIW, I have ./builds/* folders, each with a .config file and a 2 line makefile: # Automatically generated by /home/jimc/projects/lx/wk-rpi/Makefile: don't edit include /home/jimc/projects/lx/wk-rpi/Makefile > I wish I had a little working area to go along with each > tree/tracking branch where I could store patches and configs related > to that tree without committing them, but still be able to back them > up when I push the trees to my backup NAS. I am starting to lose track > of which patchsets worked against which tree and which commit by > sticking them all in one ~/patches dir. have you seen git stash ? it will do at least some of what you want. > > Another issue I have is that I put files to build a small initramfs > inside of linux/usr and a Makefile of my own to build the initramfs > and start up qemu. Again, I want to use git to store it with my > branches on my NAS, but I don't want to check it in. Does anyone else > have tips for dealing with adding personal scaffolding like this > without having it get accidentally lost? Right now they are just > untracked files that I sometimes delete by mistake. > I use virtme to do my testing. It exposes your host machine inside a qemu vm, so the env & tools in the vm are the same binaries that youre used to using. Ive had to do ZERO messing with the qemu details Id never even used qemu until virtme, and other than some fiddling with its many --options (some are pass thru to qemu) it just works. specifically, it does guest-tools setup, maybe its simple to reuse that.. virtme.guesttools 975097856 485798144 486818176 50% /run/virtme/guesttools virtme.initmount0 975097856 485798144 486818176 50% /root As to personal scaffolding, test scripts etc, I keep them in the parent directory of all the worktrees, and the vm's get it as the HOME dir via --cwd=../../.. [jimc@frodo f2]$ krun vm --show-command --show-boot-console --kdir . --mods=auto --kopt nokaslr --rwdir=/root=/home/jimc/projects/lx/boots-dump/v6.3-7-gb762dfa091f8 --cwd=../../.. --kopt dynamic_debug.verbose=3 --qemu-opts -m 2G --smp 3 then I can just source the shell tools I want [ 21.770154] virtme-init: udev is done virtme-init: console is ttyS0 bash-5.2# . test-funcs.rc :#> > Thanks, > Sarah > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel developer proccess
On Tue, Mar 21, 2023 at 5:21 PM Panagiotis Filippakopoulos wrote: > > Hello. I would like to ask, what your advise would be to a person that wants > to get in the kernel development industry, without having a coputer science > degree. I attended some classes for computer science, but due to some > difficulties i left after the first semester. During that time we learned a > little bit about operating systems and the basics of programming. Is learning > operating systems C and Assembly, for a specific architecture, (e.g. x86) a > good start? What should my steps be after that? Thank you in advance. > > Filippakopoulos Panagiotis You should start smaller. C is hard. kernel programming is harder. You should definitely learn several other languages 1st Python for example. But really, if you havent already, you should start by getting a Linux distro running on a cheap laptop. Then you can scratch any itch. and youll have the tools, like a compiler to complain about your syntax errors > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: 2 modules from 1 source ?
On Mon, Dec 19, 2022 at 11:36 AM Greg KH wrote: > > On Mon, Dec 19, 2022 at 10:02:42AM -0700, jim.cro...@gmail.com wrote: > > On Mon, Dec 19, 2022 at 9:37 AM wrote: > > > > > > Id like to build 2 modules (with different names) > > > from a single source file, with 2nd being dependent > > > on the 1st. > > > > > > Specifically, Ive got: > > > lib/test_dynamic_debug.c > > > > > > I want > > > A: lib/test_dynamic_debug.ko > > > B: lib/test_dynamic_debug_submod.ko > > > > > > I expect that the code just needs an #ifdef #else #endif > > > block to clearly put the dependor & dependee elements > > > next to each other. > > > > > > My question is how to do this in the Makefile ? > > > this does most of it > > > > > > --- a/lib/Makefile > > > +++ b/lib/Makefile > > > @@ -78,7 +78,8 @@ obj-$(CONFIG_TEST_SORT) += test_sort.o > > > obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o > > > obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o > > > obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o > > > -obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o > > > +obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o > > > test_dynamic_debug_submod.o > > > +CFLAGS_test_dynamic_debug_submod.o += -DTEST_DYNAMIC_DEBUG_SUBMOD > > > obj-$(CONFIG_TEST_PRINTF) += test_printf.o > > > > > > but how do I tell it the 2nd target ? > > > > more to the point, this doesnt work (nor do permutations), I miss something: > > > > +($obj)/test_dynamic_debug_submod.o: ($obj)/test_dynamic_debug.c > > Pleaase don't do that :( > > If you _REALLY_ need to do this, then just #include your .c file into > two other .c files. And keep everything in your #included .c file > static to make sure you don't have duplicate global symbols. > that approach works perfectly, thanks. and no CFLAGs or weird rules in the Makefile. dependent module is 2 lines - define, include. > Otherwise it is impossible for the same .o to be linked into two > different modules (or into the kernel image itself) as there will be > duplicate global symbols (as that .c file had to have something global > for you to be able to call into it.) > > But step back, what is the problem that you really want to solve here > that you feel somehow a single .c file built twice would be correct? > Especially with code in lib/ that should not be needed at all as you are > building "library" functions that only get included if they are actually > used in the large kernel image. > Heres my story: CONFIG_DRM_USE_DYNAMIC_DEBUG=y has a regression; i915.ko depends upon drm.ko, which is loaded 1st. drm.debug= is set as last step in the modprobe drm, ie before modprobe i915 is run. So i915's drm_dbg callsites arent enabled at module_init, or later. Once drm.debug is updated again (post modprobe), dyndbg's param-callback applies the drm.debug bits to enable the DRM_UT_* classes, this time seeing i915 and drm-* helpers too. The fix Im working on splits DECLARE_DYNDBG_CLASSMAP into DYNDBG_CLASSMAP_DEFINE & DYNDBG_CLASSMAP_USE. This comports better with K define-once, refer-many model, and distinguishes _USErs (i915, helpers) from DEFINEr (drm). So classmap users get cataloged separately, and get extra behavior, to lookup the state var of the definer of the param, and apply it to the module being loaded. I need to recapitulate this dependent module scenario. In test_dynamic_debug, Ive reworked the DECLARE_*s to ifdef'd _DEFINE and _USE blocks. this makes the parent/child distinction very clear. Using the same code 2x means that logging is same baseline for both. It should mean that ALL the enablements are duplicated, which should be easy to verify. > thanks, > > greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: 2 modules from 1 source ?
On Mon, Dec 19, 2022 at 9:37 AM wrote: > > Id like to build 2 modules (with different names) > from a single source file, with 2nd being dependent > on the 1st. > > Specifically, Ive got: > lib/test_dynamic_debug.c > > I want > A: lib/test_dynamic_debug.ko > B: lib/test_dynamic_debug_submod.ko > > I expect that the code just needs an #ifdef #else #endif > block to clearly put the dependor & dependee elements > next to each other. > > My question is how to do this in the Makefile ? > this does most of it > > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -78,7 +78,8 @@ obj-$(CONFIG_TEST_SORT) += test_sort.o > obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o > obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o > obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o > -obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o > +obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o > test_dynamic_debug_submod.o > +CFLAGS_test_dynamic_debug_submod.o += -DTEST_DYNAMIC_DEBUG_SUBMOD > obj-$(CONFIG_TEST_PRINTF) += test_printf.o > > but how do I tell it the 2nd target ? more to the point, this doesnt work (nor do permutations), I miss something: +($obj)/test_dynamic_debug_submod.o: ($obj)/test_dynamic_debug.c > make[2]: *** No rule to make target 'lib/test_dynamic_debug_submod.o', > needed by 'lib/modules.order'. Stop. > make[1]: *** [/home/jimc/projects/lx/wk-test/scripts/Makefile.build:500: > lib] Error 2 > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
2 modules from 1 source ?
Id like to build 2 modules (with different names) from a single source file, with 2nd being dependent on the 1st. Specifically, Ive got: lib/test_dynamic_debug.c I want A: lib/test_dynamic_debug.ko B: lib/test_dynamic_debug_submod.ko I expect that the code just needs an #ifdef #else #endif block to clearly put the dependor & dependee elements next to each other. My question is how to do this in the Makefile ? this does most of it --- a/lib/Makefile +++ b/lib/Makefile @@ -78,7 +78,8 @@ obj-$(CONFIG_TEST_SORT) += test_sort.o obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o -obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o +obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o test_dynamic_debug_submod.o +CFLAGS_test_dynamic_debug_submod.o += -DTEST_DYNAMIC_DEBUG_SUBMOD obj-$(CONFIG_TEST_PRINTF) += test_printf.o but how do I tell it the 2nd target ? make[2]: *** No rule to make target 'lib/test_dynamic_debug_submod.o', needed by 'lib/modules.order'. Stop. make[1]: *** [/home/jimc/projects/lx/wk-test/scripts/Makefile.build:500: lib] Error 2 CFLAGS_test_dynamic_debug_submod.o += -\ DTEST_DYNAMIC_DEBUG_SUBMOD A.ko: ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: unmap memory mapped with devm_ioremap_resource
On Fri, Dec 9, 2022 at 9:14 AM Adrian Fiergolski wrote: > > Hi, > > Does the community have any other ideas? Or I am wrong, and devm_iounmap is > enough? > I dunno, but it says you asked ~4 hrs ago. I bet you could just try it and get an answer faster. Do feel free to report back. > Regards, > Adrian > > On 6.12.2022 22:23, Adrian Fiergolski wrote: > > Hi Costa, > > Thank you for your reply. > > I saw 'devm_iounmap' , but, correct me if I am wrong, I think is not enough. > > devm_ioremap_resource calls __devm_ioremap_resource (link) which calls > eventually __devm_request_region (link) and __devm_ioremap (link). Those two > will allocate 2 devres: devm_region_release and devm_ioremap_release. > > The proposed devm_iounmap (link) seems to destroy only devm_ioremap_release > devres. > > Regards, > Adrian > > On 2.12.2022 19:01, Constantine Shulyupin wrote: > > Hi, > > I suppose you are looking for `devm_iounmap`. > You can find example of usage in `drivers/fpga/dfl.c`: > > ... > feature->ioaddr = >devm_ioremap_resource(binfo->dev, > >mmio_res); > ... > > static void build_info_complete(struct build_feature_devs_info *binfo) > { >devm_iounmap(binfo->dev, binfo->ioaddr); >devm_release_mem_region(binfo->dev, binfo->start, binfo->len); > } > > Regards, > Costa > > > On Fri, 2 Dec 2022 at 19:25, Adrian Fiergolski > wrote: > > Hello, > > I am extending xilinx-hls driver > (https://github.com/Xilinx/linux-xlnx/blob/master/drivers/media/platform/xilinx/xilinx-hls.c) > to support of_overlay. > > In order to reflect in the driver changes being applied by the overlay > to the device tree, I need to unmap first the memory mapped with > devm_ioremap_resource. How to do it properly? > > I think it's uncommon, as normally kernel (devm_* functions) manages > those resources itself with devres, so I can't find inspiration in other > drivers. > > Regards, > Adrian > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
gdb vmlinux scripting
so Im debugging a kernel, running inside virtme (I cant recommend it enough) using 2 terminals, each in build-dir 1st runs function dkrunk () { echo vm$KRUN_SHOW $KRUN_STDS $KDBG_OPTS $* $QM_OPTS --smp 3 -s -S virtme-run $KRUN_SHOW $KRUN_STDS $KDBG_OPTS $* $QM_OPTS --smp 3 -s -S # -qmp tcp:localhost:,server,nowait } 2nd runs: alias tui='gdb --tui -q -x ../../../gdb-2 vmlinux' that script is # seems I need a hardware breakpoint to get started, # is that the case for anyone else ? hbreak dynamic_debug_init c b strcmp if cs == ct c If you do this, youll find all the places where strcmp is called on identical args. Most of them I dont want to see, but what kind of syntax lets me look up the frame(s) to select only the contexts of interest ? it would be useful enough to test just the caller file, that would get me a long way ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: question about boot_params global variables
On Mon, Nov 14, 2022 at 11:41 AM Saad Masood wrote: > > Hi Jim, > In C, two global variables with the same name are converted to one global > variable (same memory address space). So, the same variable is referenced > with or without the 'extern' keyword. > > Thanks, > > thanks Saad, its nice when a thread reaches a tight conclusion. > > Saad > > On Mon, Nov 14, 2022 at 11:23 AM wrote: >> >> On Tue, Aug 16, 2022 at 4:10 AM shiyu chou wrote: >> > >> > Hello all: >> > In arch x86 directory I found two global variables with the same >> > name(master branch): >> > 1.arch/x86/boot/main.c >> > near line 18: struct boot_params boot_params __attribute__((aligned(16))); >> > 2.arch/x86/kernel/setup.c >> > near line 75: struct boot_params boot_params; >> > Is that wrong to define two global variables with the same name? And when >> > use extern to reference the variable,which one did it reference? >> > >> >> hi, did you figure out a satisfactory answer ? >> >> what happens when you build with W=1 ? >> >> >> > ___ >> > Kernelnewbies mailing list >> > Kernelnewbies@kernelnewbies.org >> > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: question about boot_params global variables
On Tue, Aug 16, 2022 at 4:10 AM shiyu chou wrote: > > Hello all: > In arch x86 directory I found two global variables with the same name(master > branch): > 1.arch/x86/boot/main.c > near line 18: struct boot_params boot_params __attribute__((aligned(16))); > 2.arch/x86/kernel/setup.c > near line 75: struct boot_params boot_params; > Is that wrong to define two global variables with the same name? And when use > extern to reference the variable,which one did it reference? > hi, did you figure out a satisfactory answer ? what happens when you build with W=1 ? > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kernel compile message
On Mon, Oct 31, 2022 at 8:07 AM Anatoly Pugachev wrote: > > got it again... > > mator@ttip:~/linux-2.6$ make V=1 -j olddefconfig; nice make -j20 && > nice make -j20 modules just make might throw less stuff to the screen. > make[1]: /bin/sh: Bad address I pasted that line to google. 1st chunk of results are from stackexchange / serverfault they look promising / ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: work one webcam out of two webcam connect to xhci controller for 2 usb3.0 ports
Let's keep this on the list. I'm sure I don't have Silver Bullet answers. On Tue, Oct 18, 2022, 11:15 AM Malatesh wrote: > Hi. > Thank you for the interest you have shown. > > > - both cameras work one at a time ? > [A]: No. I am using one by one and not at one time both cameras > - does order of plugin affect which one blanks ? > [A]: First plugged camera will give blank and second plugged will work > This certainly suggests two cameras are on or plugged in at the same time. that contradicts your first answer - are they both the same camera model ? > [A]: No one is logitech and another is microsoft > - can you borrow a 3rd camera ? > [A]: Third camera works > I think you need to retest and permute all combinations or at least some of them. I suspect your application doesn't know what to do with two cameras why don't you try another app and see if it works. Cheese is the one on my desktop > Actual Error: > When I click camera preview with two camera connected, one is giving error > some time with "xhci_configure_reset_endpoint:4543 Error to set dequeue > ptr for endpoint 3, 81, err 18, 0". > This is because "ep status is 0 and *Endpoint is disabled".* > > Full Log: > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011861> set halted 1 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011890> real interrupt > (status=0x0008) > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011897> event[77] = 32 > (0x 0x0c00 0x02038000) > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011901> trb 0x0 status c > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011904> slot=2 epno=3 > stream=0 remainder=0 status=12, td_event 0x0 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011907> stream_id=0 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011910> > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011940> trb halted 1, running > 0 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011943> > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011944> Ep(129) No:129 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011946> Ep ID(129to3):3 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011949> dev 2, ep address 81 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011952> xfer > 0xfe003198f148, 0 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011954> ep 81 is not started > yet > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011957> --> epno:3, Oct > 18 16:35:42 WT544810D076E1 kernel: <3645.011861> set halted 1 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011890> real interrupt > (status=0x0008) > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011897> event[77] = 32 > (0x 0x0c00 0x02038000) > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011901> trb 0x0 status c > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011904> slot=2 epno=3 > stream=0 remainder=0 status=12, td_event 0x0 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011907> stream_id=0 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011910> > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011940> trb halted 1, running > 0 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011943> > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011944> Ep(129) No:129 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011946> Ep ID(129to3):3 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011949> dev 2, ep address 81 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011952> xfer > 0xfe003198f148, 0 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011954> ep 81 is not started > yet > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011957> --> epno:3, > *epstatus:0* device:2, ep_address 81 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011960> > *Endpoint is > disabled* > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011962> > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011965> command[5] = 16 > (0x09891001, 0x, 0x02034000) > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.012003> real interrupt > (status=0x0008) > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.012010> event[78] = 33 > (0x000100fffdd0 0x1300 0x02008400) > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.012013> Received command event > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.012042> trb 1300, 2008400 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.012046> src 16, > (0x09891001, 0x, 0x02034000) > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.012051> -> Set dequeue > ptr for EP No:3, EP Addr:81, EP Status:0, EP Error:18 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.012057> [ERROR] - > xhci_configure_reset_endpoint:4543 Error to set dequeue ptr for endpoint > 3, 81, err 18, 0 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.012061> ---> kick_ep 1 called: > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.012064> endpoint is not > running 3, 81, 18 device:2, ep_address 81 > > Oct 18 16:35:42 WT544810D076E1 kernel: <3645.011960> >* Endpoint is > disabled* > > Oct 18 16:35:42
Re: Faster, incremental depmod when adding modules?
On Sun, Aug 21, 2022 at 12:46 PM Ian Pilcher wrote: > > When installing 1 or more out-of-tree modules within > /lib/modules/$UNAME, is it possible to run depmod in an incremental > fashion - adding symbols from the new modules to modules.dep[.bin] > without re-scanning all of the other modules from that kernel version? > > I've tried specifying the new module files, but that seems to create a > completely new modules.dep containing *only* the symbols from the new > modules (which obviously isn't very useful). > OPTIONS -a, --all Probe all modules. This option is enabled by default if no file names are given in the command-line. -A, --quick This option scans to see if any modules are newer than the modules.dep file before any work is done: if not, it silently exits rather than regenerating the files. 2nd looks like what u want ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: work one webcam out of two webcam connect to xhci controller for 2 usb3.0 ports
On Wed, Oct 12, 2022 at 11:21 AM Malatesh wrote: > > Hi Team, > > Good Morning/Afternoon/Evening. > > I connect two usb webcameras and one mouse, one keyboard to xhci controller, > which has 4 usb v3.x ports. > Here, keyboard and mouse works fine without any issue. > But out of two cameras, only one camera works( I mean when I click preview > only one camera show and one camera show blank ) > lemme ask some obvious questions: - both cameras work one at a time ? - does order of plugin affect which one blanks ? - are they both the same camera model ? - can you borrow a 3rd camera ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: mabe a bug in kernel 5.4 since patchlevel 159 - dma error because use ttynull?
On Thu, Oct 13, 2022 at 4:48 AM Simon Lindhorst wrote: > > Hello all, > > > when I updated my Kernel from version 5.4.155 to 5.4.215 I get an strange > xhci error: > > xhci-hcd f10f.usb3: ERROR unknown event type 37 > xhci-hcd f10f.usb3: ERROR Transfer event TRB DMA ptr not part of current > TD ep_index 2 comp_code 13 > > After a lot of this messages, my hardware makes a reboot without any more > outputs. > > The error only occures when i add console=null to my kernel bootargs. When I > add instead console=ttyS0,115200 no error occured. > > Now I go back in kernelversions. The error occured first in version 5.4.159. > Between patchlevel 158 and 159 there is a change: > > --- linux-5.4.158/kernel/printk/printk.c2021-11-06 13:59:45.0 > +0100 > +++ linux-5.4.159/kernel/printk/printk.c2021-11-12 14:43:05.0 > +0100 > @@ -2193,8 +2193,15 @@ > char *s, *options, *brl_options = NULL; > int idx; > > -if (str[0] == 0) > +/* > + * console="" or console=null have been suggested as a way to > + * disable console output. Use ttynull that has been created > + * for exacly this purpose. > + */ > +if (str[0] == 0 || strcmp(str, "null") == 0) { > +__add_preferred_console("ttynull", 0, NULL, NULL); > return 1; > +} > > if (_braille_console_setup(, _options)) > return 1; > > I checked my kernelconfig and found that I have no ttynull device configured > (CONFIG_NULL_TTY=n). Add CONFIG_NULL_TTY=y to my kernelconfig doesn't made a > change. > > When I undo the change above, everything works fine. > > > Does anybody know, what could be the main trigger for the error above? > while there have been lots of change to printk, the code you cite is still there. If that code is a candidate for the root-cause, and you can re-create the error on master, you are 1/2 the way to getting it fixed. Also, note latest: commit 3ef4ea3d84ca568dcd57816b9521e82e3bd94f08 Merge: 30d024b5058e 5eb17c1f458c Author: Linus Torvalds Date: Wed Mar 23 10:54:27 2022 -0700 Merge tag 'printk-for-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux Pull printk updates from Petr Mladek: - Make %pK behave the same as %p for kptr_restrict == 0 also with no_hash_pointers parameter - Ignore the default console in the device tree also when console=null or console="" is used on the command line - Document console=null and console="" behavior that last one is pertinent. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
howto strip trailing newline from a format string at compile-time ?
hi all So Im (always) hacking on dynamic-debug.. Ive added a 'T' flag, which causes dyndbg to send its message to /sys/kernel/tracing/trace instead of syslog (p does that). trouble is, pr_debug() calls almost always have a trailing newline, and ftrace adds its own, so the tracefile has empty lines after each pr_debug's message. I would like to fix this in the format-string, with a macro, and add the newline explicitly, when given originally, for the 'p'/syslog case. While still needing an add-newline? decision, it avoids scanning format or sprint-d bufs for the trailing newline. ie #define strip_trailing_newline(str) . #define has_trailing_newline(str) ... theyd get used in: #define DEFINE_DYNAMIC_DEBUG_METADATA_CLS(name, cls, fmt) \ ... .format = strip_trailing_newline(fmt), \ .add_nl = has_trailing_newline(fmt), \ that new .add_nl bit-field might be difficult - the other flags in _ddebug are not individual bit-fields, but I think this would have to be separate to be initializable in the macro. maybe no big deal. and how to fix the 'fmt expanded 2x' problem ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Where do I put my new driver?
On Mon, Aug 8, 2022 at 12:21 PM Alec Matthews wrote: > > I've created a new device driver that is responsible for controlling a > GPIO expander. This driver contains gpio_chip code, pinmux/pinconf, > code, pwm, and irq handlers. > > I'm not certain what I should name this driver. `pinctrl-*`, `gpio-*`, > or something else? > that suggests that you have several different drivers. each under their own tree to get the same "place" as the ones already there, that build cleanly, use the subsystem support, and work. > I'm also not sure where this driver belongs in the source tree. Should > it exist in drivers/gpio, drivers/pinctrl, or drivers/pwm? > > I have developed this driver out of tree, now I am trying to move it in > tree so I can begin the patch process. I appreciate any insight that > this list may have on where it belongs. > the path of least resistance might be to just put it in staging. Once its there and building, thats a milestone. then when it "works" there, thats clearly another. then maybe break it up into several ko's if feedback says. > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
difference between DECLARE_* and DEFINE_* macro namespaces ?
difference between DECLARE_* and DEFINE_* macro namespaces ? heres some quantitative observations 1st , raw usage counts [jimc@frodo wk-test]$ ack DECLARE_\\w+ | wc 12541 30583 1030008 [jimc@frodo wk-test]$ ack \\bDECLARE_\\w+ | wc 11293 25240 897730 [jimc@frodo wk-test]$ ack \\bDEFINE_\\w+ | wc 14746 42085 1222994 [jimc@frodo wk-test]$ ack DEFINE_\\w+ | wc 16714 48172 1386881 used quite a lot. worth seeing the patterns... this one seems telling it counts indent=0 lines, ie Header lines, file-scope vars, global declarations etc. ]$ ack ^DEFINE_\\w+ | wc 7392 19578 661324 [jimc@frodo wk-test]$ ack 'static DECLARE_\w+' | wc 9203025 80318 so about 1/12 of the DECLAREs have static outside them. #defines determine how many PATTERN uses there are. lets count them. [jimc@frodo wk-test]$ ack '#define DECLARE_\w+' | wc 3141384 27393 [jimc@frodo wk-test]$ ack '#define DEFINE_\w+' | wc 6952734 9 so, 2.3x DEFINE_/DECLARE_ definitions, and 1.15x uses of those defns interesting, not suggestive of anything.. lets look at one case include/linux/spinlock_types_raw.h 71:#define DEFINE_RAW_SPINLOCK(x) raw_spinlock_t x = __RAW_SPIN_LOCK_UNLOCKED(x) its a variable declaration, expecting ';' in caller to close it. [jimc@frodo wk-test]$ ack DEFINE_RAW_SPINLOCK | wc 140 293 10455 [jimc@frodo wk-test]$ ack 'static DEFINE_RAW_SPINLOCK' | wc 116 2588705 [jimc@frodo wk-test]$ ack '^static DEFINE_RAW_SPINLOCK' | wc 107 2318009 140 uses, most with static, most of those at file-scope so, all that said, I havent gleaned any heuristics does anyone want to offer a more qualitative review ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: git magic or usage wisdom.
On Thu, Aug 4, 2022 at 1:58 PM Ismael Luceno wrote: > > On 04/Aug/2022 13:24, jim.cro...@gmail.com wrote: > > so I have this patchset (sent to lkml recently ), > > it adds a new struct: > > struct _ddebug_info > <...> > > is there some git command magic to work this ? > > > > in a pre-git world, I might try > > perl -pi -e 's/_ddebug_info/_ddebug_stateinfo/g' 00*.patch > > > > that "might" work, but could also create a myriad of conflicts > > when the patchset is 'git am' d > > and it might apply clean but still break on compile ? > > > > anyone care to opine on the probability of success ? > > > > If I try this, I'll report back. > > ISTM more likely than my doing it manually. > > The approach is fine :). > thanks for the confirm, and I like the ^+ filter, and the \b's it limits the modifications tightly. > Whatever you do, you can't escape testing that the patches apply and > compile... > indeed. its embarrassing when crap escapes the lab. > What you may simplify is the editing by chaining the commands to > replay changes into a new branch: > > git format-patch -k --stdout base..old-branch | > perl -pe '...' | git am -3 -k > > Further automation seems counterproductive. > that pipeline is helpful, I will play with it. > As for the editing, I would use the following perl code: > > if (/^\+/) { s/\b_ddebug_info\b/_ddebug_stateinfo/g } > > That way you limit edits only to new content, and the struct name is > properly bounded by the regex. > > I guess that's about as robust as you can make it without going out of > your way. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
git magic or usage wisdom.
so I have this patchset (sent to lkml recently ), it adds a new struct: struct _ddebug_info dyndbg: create and use struct _ddebug_info this new struct gathers the linker provided vectors/sections: descs - the vector of descriptors in __dyndbg section. num_descs - length of the data/section If I had an endless supply of free do-overs, Id change the name to something a little less user-facing, since its meant to ref the whole dyndbg-config-state is there some git command magic to work this ? in a pre-git world, I might try perl -pi -e 's/_ddebug_info/_ddebug_stateinfo/g' 00*.patch that "might" work, but could also create a myriad of conflicts when the patchset is 'git am' d and it might apply clean but still break on compile ? anyone care to opine on the probability of success ? If I try this, I'll report back. ISTM more likely than my doing it manually. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Is arch/x86/boot/main.c main obsolete?
On Sat, Jun 25, 2022 at 5:35 PM ebashinskii wrote: > CPU: Intel x86 KabyLake. I'm using 5.17 Kernel built from upstream and > GRUB 2.04 > > When debugging the kernel initialization process I found out that there is > a function *void main(void)* in the source file *arch/x86/boot/main.c* (source > link: > https://elixir.bootlin.com/linux/v5.17/source/arch/x86/boot/main.c#L134) which > seems to be the entry point which the boot loader is supposed to jump into. > > But *objdump*-ing the Kernel image shows that there is no such symbol as > *main*. GDB attached to QEMU does not know about this symbol either. > > The earliest stage of Kernel Initialization I could manage to catch with > GDB is *x86_64_start_kernel* (source link: > https://elixir.bootlin.com/linux/v5.17/source/arch/x86/kernel/head64.c#L467 > ) > > What are you trying to do that start-kernel is insufficiently early ? main.c 's that you dont hit dont really matter do they ? fwiw, I really like virtme virtme-run $KRUN_SHOW $KRUN_STDS $KDBG_OPTS $* $QM_OPTS --smp 3 -s -S the -s -S stops me early enough to anything Ive needed to so far. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH] dogs -
In an attempt to solve frictions in: https://lore.kernel.org/lkml/20220311044756.425777-3-jim.cro...@gmail.com/ And inspired by https://lwn.net/Articles/383362/ defines DOGS macro - an initialization expression, ie list of breeds, each contained by C, an inner macro, undefd when DOGS is defined. C gets 2 defs for 2 tasks: (each with preceding undef to reinforce the pattern) - initialize enum dog_enums = DOGS: C(a) DRM_UT_##a (must form a real token) - stringify each dog in DOGS: C(a) #a Then tries to repeat this macro-pattern in DEFINE_DYNAMIC_DEBUG_CLASSBITS. DOGS --> DRM_DEBUG_CATS C -> C reused for clarity Its close, but not quite right: - want to pass in init-construct once - expand it 2x, with 2 different defs for C() - cant nest #defines, cant redef for 2nd expansion. Is there a way to do this ? theres also some aspirational stuff in there, maybe it communicates / explains things better than this commit msg. Signed-off-by: Jim Cromie --- play/c-code/dogs.c | 149 + 1 file changed, 149 insertions(+) create mode 100644 play/c-code/dogs.c diff --git a/play/c-code/dogs.c b/play/c-code/dogs.c new file mode 100644 index 000..7094982 --- /dev/null +++ b/play/c-code/dogs.c @@ -0,0 +1,149 @@ + +// see https://lwn.net/Articles/383362/ + +#define DOGS { C(JACK_RUSSELL), C(BULL_TERRIER), C(ITALIAN_GREYHOUND) } + +#undef C +#define C(a) ENUM_##a +enum dog_enums DOGS; + +#undef C +#define C(a) #a + +char *dog_strings[] = DOGS; +char *dog_to_string(enum dog_enums dog) +{ + return dog_strings[dog]; +} + + +// self-documenting help composition +#define DOCS { \ + _doc_( CORE, "extra core info"), \ + _doc_( DRIVER, "extra driver info"), \ + _doc_( KMS, "extra kms"),\ +} + +// 2 decomposers +#define _sym_(_sym, _help) DRM_synth_##_sym +#define _help_(_sym, _help)"enables " #_sym " messages - " _help + +// use sym to enumerate the symbols into the enum +#undef _doc_ +#define _doc_ _sym_ +enum cat_enums DOCS; + +// use -help- to initialize the doc-strings +#undef _doc_ +#define _doc_ _help_ +char *doc_helps[] = DOCS; +char *doc_to_string(enum cat_enums cat) +{ + return doc_helps[cat]; +} + +#define FLAGS_LEN 8 +struct dyndbg_classbits_param { + unsigned long *bits;/* ref to shared state */ + const char flags[FLAGS_LEN];/* toggle these flags on bit-changes */ + const int classes[];/* indexed by bitpos */ +}; + +#define _DPRINTK_SITE_UNCLASSED 15 + +#include +#include + +#define OP(s, state, x) BOOST_PP_CAT(state, x) +#define SEQ (b)(o)(o)(s)(t) + +enum foo { + BOOST_PP_SEQ_FOLD_LEFT(OP, BOOST_PP_SEQ_HEAD(SEQ), BOOST_PP_SEQ_TAIL(SEQ)) +}; + +// local copy +enum drm_debug_category { + DRM_UT_CORE, + DRM_UT_DRIVER, + DRM_UT_KMS, + DRM_UT_PRIME, + DRM_UT_ATOMIC, + DRM_UT_VBL, + DRM_UT_STATE, + DRM_UT_LEASE, + DRM_UT_DP, + DRM_UT_DRMRES, + DRM_UT_DEFAULT +}; + +#define DRM_UT_DEFAULT 15 +#define DRM_DEBUG_CATS { \ +C(_CORE), \ +C(_DRIVER), \ +C(_KMS), \ +C(_PRIME), \ +C(_ATOMIC), \ +C(_VBL), \ +C(_STATE), \ +C(_LEASE), \ +C(_DP),\ +C(_DRMRES), \ + C(_DEFAULT) \ + } + +#undef C +#define C(_cat) DRM_UT_##_cat // wo _ after UT get 2x decl on local copy +enum drm_dogs DRM_DEBUG_CATS; + + +/** + * DEFINE_DYNAMIC_DEBUG_CLASSBITS() - bitmap control of classed pr_debugs + * @sysname: sysfs-node name + * @_var:C-identifier of ulong holding bit-vector (Bits 0-14 are usable) + * @_flgs: string with dyndbg flags: 'p' and/or 'T', and maybe "fmlt" also. + * @desc:string summarizing the controls provided + * @classes: vector of callsite.class_id's (uint:4, 15 is reserved) + * + * This macro implements a DRM.debug API style bitmap, mapping bits + * 0-14 to classes of prdbg's, as initialized in their .class_id fields. + * @_flgs chooses the debug recipient; p - syslog, T - tracefs, and + * can include log decorations; m - module, f - function, l - line_num + */ + +#define DEFINE_DYNAMIC_DEBUG_CLASSBITS(fsname, _var, _flgs, desc, ...) \ + static struct dyndbg_classbits_param ddcats_##_var = { \ + .bits = &(_var),
Re: *** Compiler is too old
On Mon, Mar 7, 2022 at 3:30 AM Rogério Valentim Feitoza da Silva wrote: > > On Monday, 7 March 2022, wrote: >> >> I was just perusing this >> https://www.kernel.org/doc/html/latest/process/changes.html >> it speaks to minimum versions of everything >> >> Its good to next thru a bit, youll find things you didnt know. >> I dont need a PGP, but I know where to look for info now. >> > > What distribution are you using, and what version? > > -Rogério Valentim Im on Fedora-35. so I use dnf install when are found missing by make process. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: *** Compiler is too old
On Tue, Feb 22, 2022 at 7:19 PM Aruna Hewapathirane wrote: > > On Tue, Feb 22, 2022 at 8:48 PM Valdis Klētnieks > wrote: > > > > On Sun, 20 Feb 2022 23:52:47 -0500, Aruna Hewapathirane said: > > > > > *** Compiler is too old. > > > > > > What would be the sanest way to do this? Meaning upgrade gcc and friends ? > > > > Well... the answer to the posed question is, of course, "install gcc 5.1 or > > later" > > > I tried to do that believe me I jumped through lots of hoops but uh > uh no cigar.. :( > > > (and even *that* is pretty damned ancient - some of us are chasing problems > > with building the kernel with gcc 12. gcc 5.1 was released on 4-22-2015). > > > Show off, I had no idea there was a gcc 12 ( it is so good to hear > from you after many moons Valdis > how is the Jag and my warmest regards to miss drove a jag did not crash ? :) > > OK. Im picturing Valdis' beard in a top-down E-type I was just perusing this https://www.kernel.org/doc/html/latest/process/changes.html it speaks to minimum versions of everything Its good to next thru a bit, youll find things you didnt know. I dont need a PGP, but I know where to look for info now. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
macro arg reuse warnings, howto fix ?
so, in this patchset : https://patchwork.freedesktop.org/series/100289/ I get a macro warning I cannot solve with the usual local/auto variable declaration (the 2nd line in this macro) #define DEFINE_DYNAMIC_DEBUG_CLASSBITS(_fsname, _var, _flgs, desc, ...) \ __typeof__ (_fsname) fsname = _fsname; \ MODULE_PARM_DESC(fsname, desc); \ static struct dyndbg_classbits_param ddcats_##_var = { \ .bits = &(_var), \ .flags = _flgs, \ .classes = { __VA_ARGS__, _DPRINTK_SITE_UNCLASSED } \ }; \ module_param_cb(fsname, _ops_dyndbg_classbits, \ _##_var, 0644) without that 2nd line, patchwork's checker gives me this: -:164: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fsname' - possible side-effects? #164: FILE: include/linux/dynamic_debug.h:291: +#define DEFINE_DYNAMIC_DEBUG_CLASSBITS(fsname, _var, _flgs, desc, ...) \ + MODULE_PARM_DESC(fsname, desc); \ + static struct dyndbg_classbits_param ddcats_##_var = { \ + .bits = &(_var), \ + .flags = _flgs, \ + .classes = { __VA_ARGS__, _DPRINTK_SITE_UNCLASSED } \ + }; \ + module_param_cb(fsname, _ops_dyndbg_classbits, \ + _##_var, 0644) with it I get compile err - suggesting this was a terrible guess at a fix. from /home/jimc/projects/lx/wk-next/drivers/gpu/drm/drm_print.c:28: /home/jimc/projects/lx/wk-next/drivers/gpu/drm/drm_print.c:57:32: error: ‘debug’ undeclared here (not in a function); did you mean ‘_ddebug’? 57 | DEFINE_DYNAMIC_DEBUG_CLASSBITS(debug, __drm_debug, "p", |^ /home/jimc/projects/lx/wk-next/include/linux/dynamic_debug.h:283:21: note: in definition of macro ‘DEFINE_DYNAMIC_DEBUG_CLASSBITS’ 283 | __typeof__ (_fsname) fsname = _fsname; \ | ^~~ make[3]: *** [/home/jimc/projects/lx/wk-next/scripts/Makefile.build:288: drivers/gpu/drm/drm_print.o] that patchset has another case, similarly confusing: #define __dynamic_func_call_cls(id, cls, fmt, func, ...) do { \ DEFINE_DYNAMIC_DEBUG_METADATA_CLS(id, cls, fmt); \ if (DYNAMIC_DEBUG_BRANCH(id)) \ func(, ##__VA_ARGS__); \ } while (0) that macro is a simple extension of an existing macro, which also would suffer this warning. if I insert this at line 2: __typeof__ (id) __id = (id); \ I get this: | ^~~~ /home/jimc/projects/lx/linux.git/include/linux/dynamic_debug.h:230:25: note: previous definition of ‘__id’ with type ‘int’ 230 | __typeof__ (id) __id = (id);\ | ^~~~ /home/jimc/projects/lx/linux.git/include/linux/dynamic_debug.h:260:9: note: in expansion of macro ‘__dynamic_func_call_cls’ 260 | __dynamic_func_call_cls(__UNIQUE_ID(ddebug), cls, fmt, func, ##__VA_ARGS__) | ^~~ one side thinks its an int, other side sees a struct _ddebug * pointer any hints on how to fix these so patchset it submittable ? thanks jimc ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: adding GCC optimze O0 to early_fixmap_init causes compiler error (BUILD_BUG failed)
On Sun, Jan 23, 2022 at 4:23 AM Chan Kim wrote: > > Hello all, > > In linux 5.4.21, when tell the compiler to use no optimzation for function > early_fixmap_init as below, > > (I need to compile with O0 to follow what’s happening here using gdb.) > > #pragma GCC push_options > > #pragma GCC optimze ("O0") > > void __init early_fixmap_init(void) > > { > > ... > > } > > #pragma GCC pop_options > > > > I get this compiler error below. (make ARCH=arm64 > CROSS_COMPILE=aarch64-none-elf- Image -j24) > > CALLscripts/atomic/check-atomics.sh > > CALLscripts/checksyscalls.sh > > CHK include/generated/compile.h > > CC arch/arm64/mm/mmu.o > > CC drivers/irqchip/irq-gic-v3.o > > In file included from ./include/linux/build_bug.h:5, > > from ./arch/arm64/include/asm/sysreg.h:758, > > from ./arch/arm64/include/asm/cputype.h:126, > > from ./arch/arm64/include/asm/cache.h:8, > > from ./include/linux/cache.h:6, > > from arch/arm64/mm/mmu.c:9: > > ./arch/arm64/include/asm/pgalloc.h: In function '__pgd_populate.constprop': > > ./include/linux/compiler.h:350:38: error: call to '__compiletime_assert_88' > declared with attribute error: BUILD_BUG failed > > 350 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > > | ^ > > ./include/linux/compiler.h:331:4: note: in definition of macro > '__compiletime_assert' > > 331 |prefix ## suffix();\ > > |^~ > > ./include/linux/compiler.h:350:2: note: in expansion of macro > '_compiletime_assert' > > 350 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > > | ^~~ > > ./include/linux/build_bug.h:39:37: note: in expansion of macro > 'compiletime_assert' > >39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > > | ^~ > > ./include/linux/build_bug.h:59:21: note: in expansion of macro > 'BUILD_BUG_ON_MSG' > >59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") > > | ^~~~ > > ./arch/arm64/include/asm/pgalloc.h:88:2: note: in expansion of macro > 'BUILD_BUG' > >88 | BUILD_BUG(); > > | ^ > > make[2]: *** [scripts/Makefile.build:265: arch/arm64/mm/mmu.o] Error 1 > > make[1]: *** [scripts/Makefile.build:509: arch/arm64/mm] Error 2 > > make: *** [Makefile:1652: arch/arm64] Error 2 > > make: *** Waiting for unfinished jobs > > AR drivers/irqchip/built-in.a > > AR drivers/built-in. > > > > What does this mean and what should I do? > it means that some precondition failed, and you reached a known broken setup. Instead of giving you a broken kernel, its told you that you have to fix this 1st. try making an intermediate output, forex: make init/main.i that should provide hints as to how you got to the BUILD_BUG I dont think banging on -O compile options will help, at least not after seeing GregKH opine on it. > Thanks! > > Chan Kim > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: About the kernel configuration(CONFIG_CPU_FREQ and CONFIG_CPU_IDLE.)
On Tue, Jan 18, 2022 at 6:23 PM 孙世龙 sunshilong wrote: > > Hi, list > I am using Linux 5.4.78 with PREEMPT_RT patch. > Hardware name: UNO-2372G-J021AE. > > It's strange that the frequency of the CPU is not constant(i.e. > not fixed at a specific frequency) if I both disable CONFIG_CPU_FREQ > and CONFIG_CPU_IDLE > whereas > the frequency of the CPU is constant if I only disable CONFIG_CPU_FREQ > (leave CONFIG_CPU_IDLE enabled). > > Could somebody please shed some light on this matter? just a WAG, but lower power draw has been hugely important for years, nobody would sacrifice that for "simplicity", such a feature would be unused. I could imagine enterprise SMM bios disallowing such operation. On dozens of processors over time, TSC has been marked unstable by the kernel, Id suppose that signals a certain distrust of some clocks. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Any tracing mechanism can track the executed instructions of a user process in the kernel?
On Sun, Oct 17, 2021 at 8:46 PM Dongliang Mu wrote: > > Hi all, > > I am writing to kindly ask one question: is there any tracing > mechanism in Linux kernel that can trace all the executed instructions > of a user process? If this user process is run on different > processors, traces of this process on different processors should be > also recorded. > > Any comment is welcome. > take a look at rr-project.org what rr does rr aspires to be your primary C/C++ debugging tool for Linux, replacing — well, enhancing — gdb. You record a failure once, then debug the recording, deterministically, as many times as you want. The same execution is replayed every time. rr also provides efficient reverse execution under gdb. Set breakpoints and data watchpoints and quickly reverse-execute to where they were hit. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: error: impossible constraint in 'asm' when compiling kernel code with -O0 option
On Tue, Oct 5, 2021 at 9:00 PM wrote: > > In linux-5.4.21 code, > > To prevent some variables from being ‘optimized out’ during kernel code > analysis using gdb, I added in drivers/iommu/Makefile, > > (replacing -O2 flags to -O0 flags for some files, I found > http://www.joelfernandes.org/linux/2018/06/10/kernel-gdb.html ) > > CFLAGS_REMOVE_arm-smmu.o := -O2 > > CFLAGS_REMOVE_arm-smmu-impl.o := -O2 > > CFLAGS_REMOVE_io-pgtable-arm-v7s.o := -O2 > > CFLAGS_REMOVE_io-pgtable-arm.o := -O2 > > CFLAGS_REMOVE_of_iommu.o := -O2 > > CFLAGS_REMOVE_arm-smmu-v3.o := -O2 > > CFLAGS_arm-smmu.o := -O0 > > CFLAGS_arm-smmu-impl.o := -O0 > > CFLAGS_io-pgtable-arm-v7s.o := -O0 > > CFLAGS_io-pgtable-arm.o := -O0 > > CFLAGS_of_iommu.o := -O0 > > CFLAGS_arm-smmu-v3.o := -O0 > > But when I do make ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- Image, I get > > CALLscripts/checksyscalls.sh > > CALLscripts/atomic/check-atomics.sh > > CHK include/generated/compile.h > > CC drivers/iommu/io-pgtable-arm.o > try make drivers/iommu/io-pgtable-arm.i it will show you intermediate output. I did it on kernel/params.i ( wrong config to run yours) you will find the asm goto code therein [jimc@samwise lm-sept]$ less +/jump_label kernel/params.i # 53 "/home/jimc/projects/lx/wk-next/arch/x86/include/asm/jump_label.h" static inline __attribute__((__gnu_inline__)) __attribute__((__unused__)) __attribute__((no_instrument_function)) __attribute__((__always_inline__)) boo l arch_static_branch_jump(struct static_key * const key, const bool branch) { do { asm goto("1:" "jmp %l[l_yes]\n\t" ".pushsection __jump_table, \"aw\" \n\t" " " ".balign 8" " " "\n\t" ".long 1b - . \n\t" ".long %l[l_yes] - . \n \t" " " ".quad" " " "%c0 + %c1 - .\n\t" ".popsection \n\t" : : "i" (key), "i" (branch) : : l_yes); asm (""); } while (0) ; return false; l_yes: return true; } extern int arch_jump_entry_size(struct jump_entry *entry); # 118 "/home/jimc/projects/lx/wk-next/include/linux/jump_label.h" 2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: advice on checkpatch error
On Tue, Oct 5, 2021 at 1:14 PM wrote: > > so I have this macro, with some helpers, > the helper gets a checkpatch error. > > DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug, > "i915/gvt bitmap desc", > /* map each bit to a category */ > _DD_cat_(0, "gvt:cmd:"), > _DD_cat_(1, "gvt:core:"), > _DD_cat_(2, "gvt:dpy:"), > _DD_cat_(3, "gvt:el:"), > _DD_cat_(4, "gvt:irq:"), > _DD_cat_(5, "gvt:mm:"), > _DD_cat_(6, "gvt:mmio:"), > > > +#if defined(CONFIG_DYNAMIC_DEBUG) || \ > + (defined(CONFIG_DYNAMIC_DEBUG_CORE) && defined(DYNAMIC_DEBUG_MODULE)) > +/** > + * DEFINE_DYNAMIC_DEBUG_CATEGORIES() - bitmap control of categorized prdbgs > + * @fsname: parameter basename under /sys > + * @_var:C-identifier holding bitmap > + * @desc: string summarizing the controls provided > + * @...:list of struct dyndbg_bitdesc initializations > + * > + * Intended for modules with substantial use of "categorized" prdbgs > + * (those with some systematic prefix in the format string), this lets > + * modules using pr_debug to control them in groups according to their > + * format prefixes, and map them to bits 0-N of a sysfs control point. > + * Each @... gives the index and prefix map. > + */ > +#define DEFINE_DYNAMIC_DEBUG_CATEGORIES(fsname, _var, desc, ...) \ > + MODULE_PARM_DESC(fsname, desc); \ > + static struct dyndbg_bitmap_param ddcats_##_var = \ > + { .bits = &(_var), .map = { __VA_ARGS__, { .match = NULL }}}; \ > + module_param_cb(fsname, _ops_dyndbg, _##_var, 0644) > + > +/* helper macros provide combos of '^' anchor and ' ' postfix */ > +#define _DD_cat_(N, str) [N] = { .match = str " " } > +#define _DD_cats_(N, str) [N] = { .match = str } > +#define _DD_pfx_(N, str) [N] = { .match = "^" str " " } > +#define _DD_pfxs_(N, str) [N] = { .match = "^" str } > + > > ERROR: space prohibited before open square bracket '[' > #250: FILE: include/linux/dynamic_debug.h:273: > +#define _DD_cat_(N, str) [N] = { .match = str " " } > > Ive tried various (encapsulations) to no avail. > > what am I missing ? I'll just do it more like this ... static const struct intel_step_info kbl_revids[] = { [1] = { .gt_step = STEP_B0, .display_step = STEP_B0 }, [2] = { .gt_step = STEP_C0, .display_step = STEP_B0 }, [3] = { .gt_step = STEP_D0, .display_step = STEP_B0 }, [4] = { .gt_step = STEP_F0, .display_step = STEP_C0 }, [5] = { .gt_step = STEP_C0, .display_step = STEP_B1 }, [6] = { .gt_step = STEP_D1, .display_step = STEP_B1 }, [7] = { .gt_step = STEP_G0, .display_step = STEP_C0 }, }; ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies