Re: Slab corruption after unloading a module

Re: Slab corruption after unloading a module

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> There was no problem if I just load and unload the module. But if I
> write to the device using "ls > /dev/temp" and then unload the
> module, I would get slab corruption.

you return different value as what has really been consumed:

>         if (*f_pos + count > MAX_DSIZE)
>                 count1 = MAX_DSIZE - *f_pos;
>
>         if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
>                 rv = -EFAULT;
>                 goto wrap_up;
>         }
>         up (&temp_dev->sem);
>         *f_pos += count1;
>         return count;

may be it confuses the rest of kernel a bit?

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEQh/JR6LMutpd94wRAgn/AKCapb6QcSSeHn1X7qD1TxLBs2OCSACgnGg7
o7fTn3l6DTnLEr5EwqL7hjk=
=bHLf
-----END PGP SIGNATURE-----

Re: Slab corruption after unloading a module

[zhiyi huang]

>
>> There was no problem if I just load and unload the module. But if I
>> write to the device using "ls > /dev/temp" and then unload the
>> module, I would get slab corruption.
>
> you return different value as what has really been consumed:
>
>>         if (*f_pos + count > MAX_DSIZE)
>>                 count1 = MAX_DSIZE - *f_pos;
>>
>>         if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
>>                 rv = -EFAULT;
>>                 goto wrap_up;
>>         }
>>         up (&temp_dev->sem);
>>         *f_pos += count1;
>>         return count;
>
> may be it confuses the rest of kernel a bit?

I did this intentionally. Since my baby device buffer is fixed size,  
I can't overflow the buffer. What I do is to cheat the application  
(by pretending the bytes requested are copied to the device) so that  
the application will be happy and do not hang on to send to the  
device again and again. After all it is a test module for char device.
Nevertheless, I don't think this cheating has something to do with  
the slab corruption.

Re: Slab corruption after unloading a module

[Arjan van de Ven]

On Tue, 2006-04-18 at 10:08 +1200, zhiyi huang wrote:
> >
> >> There was no problem if I just load and unload the module. But if I
> >> write to the device using "ls > /dev/temp" and then unload the
> >> module, I would get slab corruption.
> >
> > you return different value as what has really been consumed:
> >
> >>         if (*f_pos + count > MAX_DSIZE)
> >>                 count1 = MAX_DSIZE - *f_pos;
> >>
> >>         if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {

this is still buggy.. what if f_pos is huge???

Re: Slab corruption after unloading a module

[zhiyi huang]

> On Tue, 2006-04-18 at 10:08 +1200, zhiyi huang wrote:
>>>
>>>> There was no problem if I just load and unload the module. But if I
>>>> write to the device using "ls > /dev/temp" and then unload the
>>>> module, I would get slab corruption.
>>>
>>> you return different value as what has really been consumed:
>>>
>>>>         if (*f_pos + count > MAX_DSIZE)
>>>>                 count1 = MAX_DSIZE - *f_pos;
>>>>
>>>>         if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
>
> this is still buggy.. what if f_pos is huge???

Well, if you look at my program, the complete code is like this:

         if (*f_pos > MAX_DSIZE)
                 goto wrap_up;
         if (*f_pos + count > MAX_DSIZE)
                 count1 = MAX_DSIZE - *f_pos;

         if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {

Re: Slab corruption after unloading a module

[Randy.Dunlap]

On Tue, 18 Apr 2006 09:49:13 +1200 zhiyi huang wrote:

> 
> > On Sun, 16 Apr 2006 19:17:41 -0700 Randy.Dunlap wrote:
> >
> >> On Sun, 16 Apr 2006 21:38:44 +1200 zhiyi huang wrote:
> >>
> >>>
> >>> On 16/04/2006, at 4:21 PM, Randy.Dunlap wrote:
> >>>
> >>>> On Thu, 13 Apr 2006 11:04:39 +1200 Zhiyi Huang wrote:
> >>>>
> >>>>>> 2.6.8 is an old kernel, you could very well be hitting a  
> >>>>>> kernel bug
> >>>>>> that has been fixed already. Can you reproduce this with 2.6.16?
> >>>>>
> >>>>> I will try that soon.
> >>>>>
> >>>>>> Also,
> >>>>>> you're not including sources to your module so it's impossible to
> >>>>>> tell
> >>>>>> whether you're doing something wrong.
> >>>>>>
> >>>>>>                                                          Pekka
> >>>>>
> >>>>> Below is my baby module which only uses kmalloc and kfree for my
> >>>>> device
> >>>>> structure. I found the slab corruption address is the address of
> >>>>> the structure.
> >>>>> It seems to be a bug for kmalloc and kfree.
> >>>>
> >>>>> /* The parameter for testing */
> >>>>> int major=0;
> >>>>> MODULE_PARM(major, "i");
> >>>>> MODULE_PARM_DESC(major, "device major number");
> >>>>
> >>>> Hi,
> >>>> I had no problem loading and unloading your module on
> >>>> 2.6.17-rc1 [after changing MODULE_PARM() to
> >>>> module_param(major, int, 0644);
> >>>> ].
> >>>>
> >>>> ---
> >>>> ~Randy
> >>>
> >>> There was no problem if I just load and unload the module. But if I
> >>> write to the device using "ls > /dev/temp" and then unload the
> >>> module, I would get slab corruption.  I tried to install 2.6.16.5 at
> >>> the moment but got stuck when I was making an initrd image file (no
> >>> output file produced! and no errors displayed). Once I get around
> >>> this problem, I should be able to test it on the new kernel.
> >>> Zhiyi
> >>
> >> Hm, OK, somehow I missed that crucial part.  Yes, my kernel now dies
> >> a horrible death after I unload the tem module, but not with slab
> >> corruption, just with invalid memory pointers.  Anyway, the most
> >> obvious hint in your earlier email was the data values that were
> >> printed:
> >>
> >> Slab corruption: start=c7933c38, len=192
> >> Redzone: 0x5a2cf071/0x5a2cf071.
> >> Last user: [<c01ac52d>](load_elf_interp+0xdd/0x2d0)
> >> 070: 6b 6b 6b 6b ac 3c 93 c7 ac 3c 93 c7 6b 6b 6b 6b
> >> Prev obj: start=c7933b6c, len=192
> >> Redzone: 0x5a2cf071/0x5a2cf071.
> >> Last user: [<00000000>](0x0)
> >> 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >> 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >> Next obj: start=c7933d04, len=192
> >> Redzone: 0x5a2cf071/0x5a2cf071.
> >> Last user: [<c01e58fa>](__journal_remove_checkpoint+0x4a/0xa0)
> >> 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >> 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >>
> >> Aside from the obvious slab corruption and redzone error,
> >> the 0x6b value is what mm/slab.c uses for use-after-free
> >> poisoning, so it seems that there are some pointers out in
> >> never-never land somewhere.
> >>
> >>
> >> from mm/slab.c:
> >> #define	POISON_INUSE	0x5a	/* for use-uninitialised poisoning */
> >> #define POISON_FREE	0x6b	/* for use-after-free poisoning */
> >> #define	POISON_END	0xa5	/* end-byte of poisoning */
> >
> >
> > I don't see problems after I move the kfree() to after the call
> > to unregister_chrdev_region().  Sounds like a good plan to make
> > that change.
> >
> > ---
> > ~Randy
> 
> I just did the same for my 2.6.8 kernel, but I still have similar  
> problem. Below is the dmesg. Sometimes the problem didn't appear the  
> first time you load the module. You may need to repeat what you did  
> (i.e. load the module, write to the device, and then unload the  
> module) before the problem appear.
> 
> Hello world from Template Module
> temp device MAJOR is 253, dev addr: c51d0000
> Good bye from Template Module
> Slab corruption: start=c51d0000, len=4096
> c60: 6b 6b 6b 6b 6b 6b 6b 6b 68 0c 1d c5 68 0c 1d c5

OK, on the third run of the test, my kernel dies (not slab
corruption).  I don't have time to dig into it tonight...

---
~Randy

Re: Slab corruption after unloading a module

[zhiyi huang]

> On Sun, 16 Apr 2006 19:17:41 -0700 Randy.Dunlap wrote:
>
>> On Sun, 16 Apr 2006 21:38:44 +1200 zhiyi huang wrote:
>>
>>>
>>> On 16/04/2006, at 4:21 PM, Randy.Dunlap wrote:
>>>
>>>> On Thu, 13 Apr 2006 11:04:39 +1200 Zhiyi Huang wrote:
>>>>
>>>>>> 2.6.8 is an old kernel, you could very well be hitting a  
>>>>>> kernel bug
>>>>>> that has been fixed already. Can you reproduce this with 2.6.16?
>>>>>
>>>>> I will try that soon.
>>>>>
>>>>>> Also,
>>>>>> you're not including sources to your module so it's impossible to
>>>>>> tell
>>>>>> whether you're doing something wrong.
>>>>>>
>>>>>>                                                          Pekka
>>>>>
>>>>> Below is my baby module which only uses kmalloc and kfree for my
>>>>> device
>>>>> structure. I found the slab corruption address is the address of
>>>>> the structure.
>>>>> It seems to be a bug for kmalloc and kfree.
>>>>
>>>>> /* The parameter for testing */
>>>>> int major=0;
>>>>> MODULE_PARM(major, "i");
>>>>> MODULE_PARM_DESC(major, "device major number");
>>>>
>>>> Hi,
>>>> I had no problem loading and unloading your module on
>>>> 2.6.17-rc1 [after changing MODULE_PARM() to
>>>> module_param(major, int, 0644);
>>>> ].
>>>>
>>>> ---
>>>> ~Randy
>>>
>>> There was no problem if I just load and unload the module. But if I
>>> write to the device using "ls > /dev/temp" and then unload the
>>> module, I would get slab corruption.  I tried to install 2.6.16.5 at
>>> the moment but got stuck when I was making an initrd image file (no
>>> output file produced! and no errors displayed). Once I get around
>>> this problem, I should be able to test it on the new kernel.
>>> Zhiyi
>>
>> Hm, OK, somehow I missed that crucial part.  Yes, my kernel now dies
>> a horrible death after I unload the tem module, but not with slab
>> corruption, just with invalid memory pointers.  Anyway, the most
>> obvious hint in your earlier email was the data values that were
>> printed:
>>
>> Slab corruption: start=c7933c38, len=192
>> Redzone: 0x5a2cf071/0x5a2cf071.
>> Last user: [<c01ac52d>](load_elf_interp+0xdd/0x2d0)
>> 070: 6b 6b 6b 6b ac 3c 93 c7 ac 3c 93 c7 6b 6b 6b 6b
>> Prev obj: start=c7933b6c, len=192
>> Redzone: 0x5a2cf071/0x5a2cf071.
>> Last user: [<00000000>](0x0)
>> 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
>> 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
>> Next obj: start=c7933d04, len=192
>> Redzone: 0x5a2cf071/0x5a2cf071.
>> Last user: [<c01e58fa>](__journal_remove_checkpoint+0x4a/0xa0)
>> 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
>> 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
>>
>> Aside from the obvious slab corruption and redzone error,
>> the 0x6b value is what mm/slab.c uses for use-after-free
>> poisoning, so it seems that there are some pointers out in
>> never-never land somewhere.
>>
>>
>> from mm/slab.c:
>> #define	POISON_INUSE	0x5a	/* for use-uninitialised poisoning */
>> #define POISON_FREE	0x6b	/* for use-after-free poisoning */
>> #define	POISON_END	0xa5	/* end-byte of poisoning */
>
>
> I don't see problems after I move the kfree() to after the call
> to unregister_chrdev_region().  Sounds like a good plan to make
> that change.
>
> ---
> ~Randy

I just did the same for my 2.6.8 kernel, but I still have similar  
problem. Below is the dmesg. Sometimes the problem didn't appear the  
first time you load the module. You may need to repeat what you did  
(i.e. load the module, write to the device, and then unload the  
module) before the problem appear.

Hello world from Template Module
temp device MAJOR is 253, dev addr: c51d0000
Good bye from Template Module
Slab corruption: start=c51d0000, len=4096
c60: 6b 6b 6b 6b 6b 6b 6b 6b 68 0c 1d c5 68 0c 1d c5

Re: Slab corruption after unloading a module

[Randy.Dunlap]

On Sun, 16 Apr 2006 19:17:41 -0700 Randy.Dunlap wrote:

> On Sun, 16 Apr 2006 21:38:44 +1200 zhiyi huang wrote:
> 
> > 
> > On 16/04/2006, at 4:21 PM, Randy.Dunlap wrote:
> > 
> > > On Thu, 13 Apr 2006 11:04:39 +1200 Zhiyi Huang wrote:
> > >
> > >>> 2.6.8 is an old kernel, you could very well be hitting a kernel bug
> > >>> that has been fixed already. Can you reproduce this with 2.6.16?
> > >>
> > >> I will try that soon.
> > >>
> > >>> Also,
> > >>> you're not including sources to your module so it's impossible to  
> > >>> tell
> > >>> whether you're doing something wrong.
> > >>>
> > >>>                                                          Pekka
> > >>
> > >> Below is my baby module which only uses kmalloc and kfree for my  
> > >> device
> > >> structure. I found the slab corruption address is the address of  
> > >> the structure.
> > >> It seems to be a bug for kmalloc and kfree.
> > >
> > >> /* The parameter for testing */
> > >> int major=0;
> > >> MODULE_PARM(major, "i");
> > >> MODULE_PARM_DESC(major, "device major number");
> > >
> > > Hi,
> > > I had no problem loading and unloading your module on
> > > 2.6.17-rc1 [after changing MODULE_PARM() to
> > > module_param(major, int, 0644);
> > > ].
> > >
> > > ---
> > > ~Randy
> > 
> > There was no problem if I just load and unload the module. But if I  
> > write to the device using "ls > /dev/temp" and then unload the  
> > module, I would get slab corruption.  I tried to install 2.6.16.5 at  
> > the moment but got stuck when I was making an initrd image file (no  
> > output file produced! and no errors displayed). Once I get around  
> > this problem, I should be able to test it on the new kernel.
> > Zhiyi
> 
> Hm, OK, somehow I missed that crucial part.  Yes, my kernel now dies
> a horrible death after I unload the tem module, but not with slab
> corruption, just with invalid memory pointers.  Anyway, the most
> obvious hint in your earlier email was the data values that were
> printed:
> 
> Slab corruption: start=c7933c38, len=192
> Redzone: 0x5a2cf071/0x5a2cf071.
> Last user: [<c01ac52d>](load_elf_interp+0xdd/0x2d0)
> 070: 6b 6b 6b 6b ac 3c 93 c7 ac 3c 93 c7 6b 6b 6b 6b
> Prev obj: start=c7933b6c, len=192
> Redzone: 0x5a2cf071/0x5a2cf071.
> Last user: [<00000000>](0x0)
> 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> Next obj: start=c7933d04, len=192
> Redzone: 0x5a2cf071/0x5a2cf071.
> Last user: [<c01e58fa>](__journal_remove_checkpoint+0x4a/0xa0)
> 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> 
> Aside from the obvious slab corruption and redzone error,
> the 0x6b value is what mm/slab.c uses for use-after-free
> poisoning, so it seems that there are some pointers out in
> never-never land somewhere.
> 
> 
> from mm/slab.c:
> #define	POISON_INUSE	0x5a	/* for use-uninitialised poisoning */
> #define POISON_FREE	0x6b	/* for use-after-free poisoning */
> #define	POISON_END	0xa5	/* end-byte of poisoning */


I don't see problems after I move the kfree() to after the call
to unregister_chrdev_region().  Sounds like a good plan to make
that change.

---
~Randy

Re: Slab corruption after unloading a module

[Randy.Dunlap]

On Sun, 16 Apr 2006 21:38:44 +1200 zhiyi huang wrote:

> 
> On 16/04/2006, at 4:21 PM, Randy.Dunlap wrote:
> 
> > On Thu, 13 Apr 2006 11:04:39 +1200 Zhiyi Huang wrote:
> >
> >>> 2.6.8 is an old kernel, you could very well be hitting a kernel bug
> >>> that has been fixed already. Can you reproduce this with 2.6.16?
> >>
> >> I will try that soon.
> >>
> >>> Also,
> >>> you're not including sources to your module so it's impossible to  
> >>> tell
> >>> whether you're doing something wrong.
> >>>
> >>>                                                          Pekka
> >>
> >> Below is my baby module which only uses kmalloc and kfree for my  
> >> device
> >> structure. I found the slab corruption address is the address of  
> >> the structure.
> >> It seems to be a bug for kmalloc and kfree.
> >
> >> /* The parameter for testing */
> >> int major=0;
> >> MODULE_PARM(major, "i");
> >> MODULE_PARM_DESC(major, "device major number");
> >
> > Hi,
> > I had no problem loading and unloading your module on
> > 2.6.17-rc1 [after changing MODULE_PARM() to
> > module_param(major, int, 0644);
> > ].
> >
> > ---
> > ~Randy
> 
> There was no problem if I just load and unload the module. But if I  
> write to the device using "ls > /dev/temp" and then unload the  
> module, I would get slab corruption.  I tried to install 2.6.16.5 at  
> the moment but got stuck when I was making an initrd image file (no  
> output file produced! and no errors displayed). Once I get around  
> this problem, I should be able to test it on the new kernel.
> Zhiyi

Hm, OK, somehow I missed that crucial part.  Yes, my kernel now dies
a horrible death after I unload the tem module, but not with slab
corruption, just with invalid memory pointers.  Anyway, the most
obvious hint in your earlier email was the data values that were
printed:

Slab corruption: start=c7933c38, len=192
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<c01ac52d>](load_elf_interp+0xdd/0x2d0)
070: 6b 6b 6b 6b ac 3c 93 c7 ac 3c 93 c7 6b 6b 6b 6b
Prev obj: start=c7933b6c, len=192
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<00000000>](0x0)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=c7933d04, len=192
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<c01e58fa>](__journal_remove_checkpoint+0x4a/0xa0)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b

Aside from the obvious slab corruption and redzone error,
the 0x6b value is what mm/slab.c uses for use-after-free
poisoning, so it seems that there are some pointers out in
never-never land somewhere.


from mm/slab.c:
#define	POISON_INUSE	0x5a	/* for use-uninitialised poisoning */
#define POISON_FREE	0x6b	/* for use-after-free poisoning */
#define	POISON_END	0xa5	/* end-byte of poisoning */

---
~Randy

Re: Slab corruption after unloading a module

[zhiyi huang]

On 16/04/2006, at 4:21 PM, Randy.Dunlap wrote:

> On Thu, 13 Apr 2006 11:04:39 +1200 Zhiyi Huang wrote:
>
>>> 2.6.8 is an old kernel, you could very well be hitting a kernel bug
>>> that has been fixed already. Can you reproduce this with 2.6.16?
>>
>> I will try that soon.
>>
>>> Also,
>>> you're not including sources to your module so it's impossible to  
>>> tell
>>> whether you're doing something wrong.
>>>
>>>                                                          Pekka
>>
>> Below is my baby module which only uses kmalloc and kfree for my  
>> device
>> structure. I found the slab corruption address is the address of  
>> the structure.
>> It seems to be a bug for kmalloc and kfree.
>
>> /* The parameter for testing */
>> int major=0;
>> MODULE_PARM(major, "i");
>> MODULE_PARM_DESC(major, "device major number");
>
> Hi,
> I had no problem loading and unloading your module on
> 2.6.17-rc1 [after changing MODULE_PARM() to
> module_param(major, int, 0644);
> ].
>
> ---
> ~Randy

There was no problem if I just load and unload the module. But if I  
write to the device using "ls > /dev/temp" and then unload the  
module, I would get slab corruption.  I tried to install 2.6.16.5 at  
the moment but got stuck when I was making an initrd image file (no  
output file produced! and no errors displayed). Once I get around  
this problem, I should be able to test it on the new kernel.
Zhiyi

Re: Slab corruption after unloading a module

[Randy.Dunlap]

On Thu, 13 Apr 2006 11:04:39 +1200 Zhiyi Huang wrote:

> > 2.6.8 is an old kernel, you could very well be hitting a kernel bug
> > that has been fixed already. Can you reproduce this with 2.6.16? 
> 
> I will try that soon.
> 
> > Also,
> > you're not including sources to your module so it's impossible to tell
> > whether you're doing something wrong.
> > 
> >                                                          Pekka
> 
> Below is my baby module which only uses kmalloc and kfree for my device 
> structure. I found the slab corruption address is the address of the structure. 
> It seems to be a bug for kmalloc and kfree.

> /* The parameter for testing */
> int major=0;
> MODULE_PARM(major, "i");
> MODULE_PARM_DESC(major, "device major number");

Hi,
I had no problem loading and unloading your module on
2.6.17-rc1 [after changing MODULE_PARM() to
module_param(major, int, 0644);
].

---
~Randy

Re: Slab corruption after unloading a module

[Randy.Dunlap]

On Thu, 13 Apr 2006 11:04:39 +1200 Zhiyi Huang wrote:

> > 2.6.8 is an old kernel, you could very well be hitting a kernel bug
> > that has been fixed already. Can you reproduce this with 2.6.16? 
> 
> I will try that soon.
> 
> > Also,
> > you're not including sources to your module so it's impossible to tell
> > whether you're doing something wrong.
> > 
> >                                                          Pekka
> 
> Below is my baby module which only uses kmalloc and kfree for my device 
> structure. I found the slab corruption address is the address of the structure. 
> It seems to be a bug for kmalloc and kfree.

I haven't looked at your source code yet, but in addition to testing with a
recent kernel version, it may help to enable lots of kernel debug options.
Could you try that too, or do you already do that?

---
~Randy

Slab corruption after unloading a module

[Zhiyi Huang]

Hi there, I am a bit timid to post a message to the list after reading the FAQ,
but I did get a problem. When reply, please cc to my email address.
My kernel info: Linux version 2.6.8 (root@zhiyi) (gcc version 3.3.5 (Debian
1:3.3.5-8)) #1
Everytime (except the first time) I unload my module (a ram device), I got the
following message. Please just indicate if it is a kernel bug or if there is any
fix patch. At the moment I have no clue. I used kmalloc and alloc_page to
allocate memory dynamically when the ram device grows. And I freed them
when the module is unloaded of course.

Hello world from Template Module
temp device MAJOR is 253
Good bye from Template Module: 618 pages
Hello world from Template Module
temp device MAJOR is 253
Good bye from Template Module: 618 pages
Slab corruption: start=c7c12d24, len=192
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<c01ac52d>](load_elf_interp+0xdd/0x2d0)
070: 6b 6b 6b 6b 98 2d c1 c7 98 2d c1 c7 6b 6b 6b 6b
Prev obj: start=c7c12c58, len=192
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<c01ac52d>](load_elf_interp+0xdd/0x2d0)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=c7c12df0, len=192
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<00000000>](0x0)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b