[OS-BUILD PATCH] redhat: Add dummy-module kernel module

[GitLab Bridge on behalf of prarit]

From: Prarit Bhargava <prarit(a)redhat.com&gt;

For years we've had a useful kernel kernel module, dummy-module, in the
tree.

Add dummy-module to the redhat directory.

Signed-off-by: Prarit Bhargava <prarit(a)redhat.com&gt;
---
 redhat/debug/dummy-module/Makefile       | 15 +++++++++
 redhat/debug/dummy-module/dummy-module.c | 39 ++++++++++++++++++++++++
 2 files changed, 54 insertions(+)
 create mode 100644 redhat/debug/dummy-module/Makefile
 create mode 100644 redhat/debug/dummy-module/dummy-module.c

diff --git a/redhat/debug/dummy-module/Makefile b/redhat/debug/dummy-module/Makefile
new file mode 100644
index 000000000000..4c2daaad0b51
--- /dev/null
+++ b/redhat/debug/dummy-module/Makefile
@@ -0,0 +1,15 @@
+ifneq ($(KERNELRELEASE),)
+
+obj-m	:= dummy-module.o
+
+else
+
+KDIR	:= /lib/modules/$(shell uname -r)/build
+PWD	:= $(shell pwd)
+
+default:
+	$(MAKE) -C $(KDIR) M=$(PWD)
+endif
+
+clean:
+	rm -rf *o .*.cmd .tmp* *.mod.c
diff --git a/redhat/debug/dummy-module/dummy-module.c
b/redhat/debug/dummy-module/dummy-module.c
new file mode 100644
index 000000000000..89748e636511
--- /dev/null
+++ b/redhat/debug/dummy-module/dummy-module.c
@@ -0,0 +1,39 @@
+/*
+ * Just an skeleton module.  Useful for debugging.
+ *
+ * Written by: Prarit Bhargava <prarit(a)redhat.com&gt;
+ *
+ * Please don't clutter this file with a bunch of bells-and-whistles.  It
+ * is meant to be a simple module.
+ */
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+
+static int dummy_arg = 0;
+
+void dummy_greetings(void)
+{
+	printk("This module has loaded.\n");
+	if (dummy_arg)
+		printk("And dummy_arg is %d.\n", dummy_arg);
+}
+
+static int init_dummy(void)
+{
+	dummy_greetings();
+	return 0;
+}
+
+static void cleanup_dummy(void)
+{
+	printk("unloading module\n");
+}
+
+module_init(init_dummy);
+module_exit(cleanup_dummy);
+
+MODULE_LICENSE("GPL");
+
+module_param(dummy_arg, int, 0444);
+MODULE_PARM_DESC(dummy_arg, "An argument for this module");
-- 
2.26.2

[Jiri Benc]

On Wed, 20 May 2020 23:28:46 -0000, GitLab Bridge on behalf of prarit wrote:
>  For years we've had a useful kernel kernel module, dummy-module,
> in the
>  tree. 
What is the use case? I've never needed it and I don't know about
anyone who has needed it.

 Jiri

[Prarit Bhargava]

On 5/21/20 8:25 AM, Jiri Benc wrote:
>  On Wed, 20 May 2020 23:28:46 -0000, GitLab Bridge on behalf of prarit
> wrote:
> > For years we've had a useful kernel kernel module, dummy-module, in the
> > tree.
>  
>  What is the use case? I've never needed it and I don't know about
>  anyone who has needed it. 
We've used it (heavily might I add) to debug the kernel.  It's a convenient
place for a quick kernel module.

P.

>  
>   Jiri
>  _______________________________________________
>  kernel mailing list -- kernel(a)lists.fedoraproject.org
>  To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Jiri Benc]

On Thu, 21 May 2020 08:31:56 -0400, Prarit Bhargava wrote:
>  We've used it (heavily might I add) to debug the kernel. 
> It's a convenient
>  place for a quick kernel module. 
Now I'm curious. How does such module help debugging the kernel?

I'm not saying you're wrong. I'm just saying I can't think of anything.
Probably just me not being imaginative enough. More details would be
appreciated. It might come handy one time.

Thanks,

 Jiri

[Prarit Bhargava]

On 5/21/20 9:18 AM, Jiri Benc wrote:
>  On Thu, 21 May 2020 08:31:56 -0400, Prarit Bhargava wrote:
> > We've used it (heavily might I add) to debug the kernel.  It's a convenient
> > place for a quick kernel module.
>  
>  Now I'm curious. How does such module help debugging the kernel?
>  
>  I'm not saying you're wrong. I'm just saying I can't think of anything.
>  Probably just me not being imaginative enough. More details would be
>  appreciated. It might come handy one time.
>   
Well it's literally everything from dumping random values to confirming
alignment of structs to debugging.

What I'm doing today is attempting to break the Intel Split Lock detector by running

        for (cpu = 0; cpu < nr_cpu_ids; cpu++) {
                c = &cpu_data(cpu);
                printk("data for cpu %d\n", cpu);
                for (i = 0; i < (NCAPINTS + NBUGINTS * 32); i++) {
                        cpu_has(c, i);
                }
        }

in a tight loop.  Unfortunately that doesn't seem to kick it.  I suspect that
the cpuinfo_x86 struct is magically aligned atm :(.

I guess I could keep the dummy-module in it's own tree but that's just a PITA
when I have to quickly debug something.  Let's keep it in the tree where it's
always been ;)

P.

>  Thanks,
>  
>   Jiri
>

[Neil Horman]

On Thu, May 21, 2020 at 09:27:35AM -0400, Prarit Bhargava wrote:
>  On 5/21/20 9:18 AM, Jiri Benc wrote:
>  > On Thu, 21 May 2020 08:31:56 -0400, Prarit Bhargava wrote:
>  >> We've used it (heavily might I add) to debug the kernel.  It's a
> convenient
>  >> place for a quick kernel module.
>  > 
>  > Now I'm curious. How does such module help debugging the kernel?
>  > 
>  > I'm not saying you're wrong. I'm just saying I can't think of
> anything.
>  > Probably just me not being imaginative enough. More details would be
>  > appreciated. It might come handy one time.
>  > 
>  
>  Well it's literally everything from dumping random values to confirming
>  alignment of structs to debugging.
>  
>  What I'm doing today is attempting to break the Intel Split Lock detector by running
>  
>          for (cpu = 0; cpu < nr_cpu_ids; cpu++) {
>                  c = &cpu_data(cpu);
>                  printk("data for cpu %d\n", cpu);
>                  for (i = 0; i < (NCAPINTS + NBUGINTS * 32); i++) {
>                          cpu_has(c, i);
>                  }
>          }
>  
>  in a tight loop.  Unfortunately that doesn't seem to kick it.  I suspect that
>  the cpuinfo_x86 struct is magically aligned atm :(.
>  
>  I guess I could keep the dummy-module in it's own tree but that's just a PITA
>  when I have to quickly debug something.  Let's keep it in the tree where it's
>  always been ;)
>   
I remember using this module quite alot, and it was very helpful.  I have to ask
though, does systemtap offer the same level of functionality at this point for
most of the debugging we need to do?

Neil

>  P.
>  
>  > Thanks,
>  > 
>  >  Jiri
>  > 
>  _______________________________________________
>  kernel mailing list -- kernel(a)lists.fedoraproject.org
>  To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Prarit Bhargava]

On 5/21/20 9:37 AM, Neil Horman wrote:
>  On Thu, May 21, 2020 at 09:27:35AM -0400, Prarit Bhargava wrote:
> > On 5/21/20 9:18 AM, Jiri Benc wrote:
> >> On Thu, 21 May 2020 08:31:56 -0400, Prarit Bhargava wrote:
> >>> We've used it (heavily might I add) to debug the kernel.  It's a
> convenient
> >>> place for a quick kernel module.
> >>
> >> Now I'm curious. How does such module help debugging the kernel?
> >>
> >> I'm not saying you're wrong. I'm just saying I can't think of
> anything.
> >> Probably just me not being imaginative enough. More details would be
> >> appreciated. It might come handy one time.
> >>
> >
> > Well it's literally everything from dumping random values to confirming
> > alignment of structs to debugging.
> >
> > What I'm doing today is attempting to break the Intel Split Lock detector by
> running
> >
> >         for (cpu = 0; cpu < nr_cpu_ids; cpu++) {
> >                 c = &cpu_data(cpu);
> >                 printk("data for cpu %d\n", cpu);
> >                 for (i = 0; i < (NCAPINTS + NBUGINTS * 32); i++) {
> >                         cpu_has(c, i);
> >                 }
> >         }
> >
> > in a tight loop.  Unfortunately that doesn't seem to kick it.  I suspect that
> > the cpuinfo_x86 struct is magically aligned atm :(.
> >
> > I guess I could keep the dummy-module in it's own tree but that's just a
> PITA
> > when I have to quickly debug something.  Let's keep it in the tree where
> it's
> > always been ;)
> >
>  I remember using this module quite alot, and it was very helpful.  I have to ask
>  though, does systemtap offer the same level of functionality at this point for
>  most of the debugging we need to do?
>   
Yup!  But I have had many cases when I'm digging for HW register values, etc.,
that a module has been _invaluable_.

P.

>  Neil
>  
> > P.
> >
> >> Thanks,
> >>
> >>  Jiri
> >>
> > _______________________________________________
> > kernel mailing list -- kernel(a)lists.fedoraproject.org
> > To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Jiri Benc]

On Thu, 21 May 2020 09:38:58 -0400, Prarit Bhargava wrote:
>  Yup!  But I have had many cases when I'm digging for HW register
> values, etc.,
>  that a module has been _invaluable_. 
Thanks, Prarit. I personally use different means to achieve such things
but now I understand why you want this.

 Jiri

[Neil Horman]

On Thu, May 21, 2020 at 09:38:58AM -0400, Prarit Bhargava wrote:
>  On 5/21/20 9:37 AM, Neil Horman wrote:
>  > On Thu, May 21, 2020 at 09:27:35AM -0400, Prarit Bhargava wrote:
>  >> On 5/21/20 9:18 AM, Jiri Benc wrote:
>  >>> On Thu, 21 May 2020 08:31:56 -0400, Prarit Bhargava wrote:
>  >>>> We've used it (heavily might I add) to debug the kernel.  It's a
> convenient
>  >>>> place for a quick kernel module.
>  >>>
>  >>> Now I'm curious. How does such module help debugging the kernel?
>  >>>
>  >>> I'm not saying you're wrong. I'm just saying I can't think
> of anything.
>  >>> Probably just me not being imaginative enough. More details would be
>  >>> appreciated. It might come handy one time.
>  >>>
>  >>
>  >> Well it's literally everything from dumping random values to confirming
>  >> alignment of structs to debugging.
>  >>
>  >> What I'm doing today is attempting to break the Intel Split Lock detector by
> running
>  >>
>  >>         for (cpu = 0; cpu < nr_cpu_ids; cpu++) {
>  >>                 c = &cpu_data(cpu);
>  >>                 printk("data for cpu %d\n", cpu);
>  >>                 for (i = 0; i < (NCAPINTS + NBUGINTS * 32); i++) {
>  >>                         cpu_has(c, i);
>  >>                 }
>  >>         }
>  >>
>  >> in a tight loop.  Unfortunately that doesn't seem to kick it.  I suspect
> that
>  >> the cpuinfo_x86 struct is magically aligned atm :(.
>  >>
>  >> I guess I could keep the dummy-module in it's own tree but that's just a
> PITA
>  >> when I have to quickly debug something.  Let's keep it in the tree where
> it's
>  >> always been ;)
>  >>
>  > I remember using this module quite alot, and it was very helpful.  I have to ask
>  > though, does systemtap offer the same level of functionality at this point for
>  > most of the debugging we need to do?
>  > 
>  
>  Yup!  But I have had many cases when I'm digging for HW register values, etc.,
>  that a module has been _invaluable_.
>   
Good enough then, Ive got no problem with it.

Neil

>  P.
>  
>  > Neil
>  > 
>  >> P.
>  >>
>  >>> Thanks,
>  >>>
>  >>>  Jiri
>  >>>
>  >> _______________________________________________
>  >> kernel mailing list -- kernel(a)lists.fedoraproject.org
>  >> To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>  >> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  >> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  > 
>

[Prarit Bhargava]

On 5/21/20 9:53 AM, Neil Horman wrote:

> >
>  Good enough then, Ive got no problem with it.
>  
>  Neil
>   
nhorman & jbenc I need _acks_ :)

P.

[Jiri Benc]

On Tue, 26 May 2020 14:10:20 -0400, Prarit Bhargava wrote:
>  nhorman & jbenc I need _acks_ :) 
Acks are rare commodity nowadays ;-)

Acked-by: Jiri Benc <jbenc(a)redhat.com&gt;

[Neil Horman]

On Tue, May 26, 2020 at 08:51:43PM +0200, Jiri Benc wrote:
>  On Tue, 26 May 2020 14:10:20 -0400, Prarit Bhargava wrote:
>  > nhorman & jbenc I need _acks_ :)
>  
>  Acks are rare commodity nowadays ;-)
>   
Acked-by: Neil Horman <nhorman(a)redhat.com&gt;