[PATCH v9-resend 52/54] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN

2024-07-17 Thread Jim Cromie
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

2024-07-17 Thread Jim Cromie
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

2024-07-17 Thread Jim Cromie
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

2024-07-17 Thread Jim Cromie
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

2024-07-17 Thread Jim Cromie
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

2024-07-17 Thread Jim Cromie
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

2024-07-17 Thread Jim Cromie
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

2024-07-17 Thread Jim Cromie
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

2024-07-17 Thread Jim Cromie
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

2024-07-17 Thread Jim Cromie
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

2024-07-17 Thread Jim Cromie
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

2024-07-17 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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 %

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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/*

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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_"

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-07-16 Thread Jim Cromie
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

2024-05-17 Thread jim . cromie
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

2024-05-17 Thread jim . cromie
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

2024-04-17 Thread jim . cromie
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

2023-12-07 Thread jim . cromie
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

2023-12-07 Thread jim . cromie
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?

2023-11-10 Thread jim . cromie
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

2023-11-10 Thread jim . cromie
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

2023-10-13 Thread jim . cromie
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 ?

2023-10-13 Thread jim . cromie
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

2023-08-23 Thread jim . cromie
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

2023-07-14 Thread jim . cromie
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

2023-07-05 Thread jim . cromie
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

2023-06-14 Thread jim . cromie
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

2023-06-13 Thread jim . cromie
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

2023-05-31 Thread jim . cromie
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

2023-05-19 Thread jim . cromie
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

2023-04-26 Thread jim . cromie
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

2023-04-24 Thread jim . cromie
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 ?

2022-12-20 Thread jim . cromie
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 ?

2022-12-19 Thread jim . cromie
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 ?

2022-12-19 Thread jim . cromie
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

2022-12-09 Thread jim . cromie
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

2022-11-28 Thread jim . cromie
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

2022-11-20 Thread jim . cromie
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

2022-11-14 Thread jim . cromie
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

2022-11-02 Thread jim . cromie
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

2022-10-18 Thread jim . cromie
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?

2022-10-13 Thread jim . cromie
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

2022-10-13 Thread jim . cromie
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?

2022-10-13 Thread jim . cromie
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 ?

2022-10-12 Thread jim . cromie
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?

2022-09-21 Thread jim . cromie
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 ?

2022-09-21 Thread jim . cromie
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.

2022-08-05 Thread jim . cromie
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.

2022-08-04 Thread jim . cromie
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?

2022-07-18 Thread jim . cromie
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 -

2022-03-16 Thread Jim Cromie
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

2022-03-07 Thread jim . cromie
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

2022-03-06 Thread jim . cromie
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 ?

2022-02-28 Thread jim . cromie
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)

2022-01-23 Thread jim . cromie
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.)

2022-01-21 Thread jim . cromie
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?

2021-10-18 Thread jim . cromie
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

2021-10-07 Thread jim . cromie
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

2021-10-05 Thread jim . cromie
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


  1   2   3   >