Probable module bug in linux-2.6.5-1.358

Probable module bug in linux-2.6.5-1.358

[Richard B. Johnson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 276 bytes --]


The attached script shows that an attempt to open a device
after its module was removed, will seg-fault the kernel.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
             Note 96.31% of all statistics are fiction.

[-- Attachment #2: Type: TEXT/PLAIN, Size: 7720 bytes --]



Kernel 2.6.5-1.358 from Red Hat Fedora has a bug that
causes a kernel oops when attempting to open a device
that had a module removed.

In the following, the first attempt at a user-mode open()
causes the module to be properly loaded by modprobe, the
module alias having been put into /etc/modprobe.conf.

The module can be removed and inserted many times, each
time the resources are deallocated and the module has no
problem obtaining those resources again when it's reloaded.

However, only the FIRST automatic load works. Any attempt
to access the device (open it) after it has been removed,
will not cause it to be reloaded. Instead the kernel will
seg-fault during a call to sys_open().

The virtual address 0x222e7880 is not in the symbol file and
seems to be the address near where the open() in my module
used to be before it was removed.

I can duplicate this and a printk("%p\n", open); shows
0x222e74a0, just after I boot. Subsequent loads show other
addresses.


Oct  6 17:03:30 chaos kernel: Analogic Corp Datalink Driver : Module removed
Oct  6 17:03:38 chaos kernel: Unable to handle kernel paging request at virtual address 222e7880
Oct  6 17:03:38 chaos kernel:  printing eip:
Oct  6 17:03:38 chaos kernel: 021556ad
Oct  6 17:03:38 chaos kernel: *pde = 1f30c067
Oct  6 17:03:38 chaos kernel: *pte = 00000000
Oct  6 17:03:38 chaos kernel: Oops: 0000 [#1]
Oct  6 17:03:38 chaos kernel: SMP 
Oct  6 17:03:38 chaos kernel: CPU:    0
Oct  6 17:03:38 chaos kernel: EIP:    0060:[<021556ad>]    Not tainted
Oct  6 17:03:38 chaos kernel: EFLAGS: 00010206   (2.6.5-1.358-noreg) 
Oct  6 17:03:38 chaos kernel: EIP is at cdev_get+0x14/0x6a
Oct  6 17:03:38 chaos kernel: eax: 20dee000   ebx: 222e7880   ecx: 1f564a80   edx: 13d19910
Oct  6 17:03:38 chaos kernel: esi: 00000000   edi: 1edae208   ebp: 00000000   esp: 20deef20
Oct  6 17:03:38 chaos kernel: ds: 007b   es: 007b   ss: 0068
Oct  6 17:03:38 chaos kernel: Process ftest (pid: 3728, threadinfo=20dee000 task=1f7a0130)
Oct  6 17:03:38 chaos kernel: Stack: 13d19910 00000000 021554bc 13d19910 1f564a80 1f564a80 1edae208 2138bf80 
Oct  6 17:03:38 chaos kernel:        1d49ac8c 0214d443 1edae208 1f564a80 00000002 00000003 1685a000 20dee000 
Oct  6 17:03:38 chaos kernel:        0214d364 20e18180 2138bf80 00000002 20e18180 2138bf80 00000ffc 00000001 
Oct  6 17:03:38 chaos kernel: Call Trace:
Oct  6 17:03:38 chaos kernel:  [<021554bc>] chrdev_open+0xb2/0x18b
Oct  6 17:03:38 chaos kernel:  [<0214d443>] dentry_open+0xd7/0x19b
Oct  6 17:03:38 chaos kernel:  [<0214d364>] filp_open+0x41/0x49
Oct  6 17:03:38 chaos kernel:  [<0214d703>] sys_open+0x31/0x82
Oct  6 17:03:38 chaos kernel: 
Oct  6 17:03:38 chaos kernel: Code: 83 3b 02 8b 40 10 74 0e c1 e0 07 8d 04 18 ff 80 00 01 00 00 
Oct  6 17:08:11 chaos syslogd 1.4.1: restart.


Script started on Wed 06 Oct 2004 05:09:06 PM EDT
# sync
# ./ftest
Make sure a single board exists in a PCI slot and
channel A output is connected to channel B input.
Hit [Enter] to continue... 
Enabling both RX and TX
Waiting for synchronization...
Waiting for synchronization...
Mailbox-A message = 0000000f
Mailbox-B message = 0000000f
Len =   6 Mb, time =  104468.00 us, rate = 64.334954 bytes/usec
[SNIPPED...]
Works...

      PCI slot = 516
Driver version = V2.01
  FPGA version = 61128V00R000
# ps laxw
F   UID   PID  PPID PRI  NI   VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
4     0     1     0  16   0  3124  464 -      S    ?          0:04 init [5]       
[SNIPPED...]
4     0  3128  3127  15   0  6080 1276 wait4  S    pts/0      0:00 bash -i
1  5418  3137     1  15   0     0    0 -      SW   ?          0:00 [DLB daemon]

This shows the kernel daemon that manages the link.

4     0  3140  3128  17   0  3824  584 -      R    pts/0      0:00 ps laxw
# cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cfbff : Video ROM
000d0000-000d0bff : Adapter ROM
000d1000-000d57ff : Adapter ROM
000f0000-000fffff : System ROM
00100000-1f3fffff : System RAM
  00100000-002a8fff : Kernel code
  002a9000-0034fa7f : Kernel data
1f400000-1f4003ff : 0000:00:1f.1
1f401000-22403fff : Analogic Corp Datalink Driver
e4500000-f45fffff : PCI Bus #01
  e8000000-efffffff : 0000:01:00.0
  f4580000-f45fffff : 0000:01:00.0
f8000000-fbffffff : 0000:00:00.0
fc700000-fe7fffff : PCI Bus #01
  fd000000-fdffffff : 0000:01:00.0
fe900000-fe9fffff : 0000:02:04.0
  fe900000-fe9fffff : Analogic Corp Datalink Driver
feafc000-feafcfff : 0000:02:08.0
  feafc000-feafcfff : e100
feafd000-feafdfff : 0000:02:07.0
feafe800-feafe9ff : 0000:02:04.0
  feafe800-feafe9ff : Analogic Corp Datalink Driver
feafec00-feafec7f : 0000:02:01.0
feaff000-feafffff : 0000:02:00.0
  feaff000-feafffff : aic7xxx
febff400-febff4ff : 0000:00:1f.5
febff800-febff9ff : 0000:00:1f.5
febffc00-febfffff : 0000:00:1d.7
# sync

This shows resources used.

# rmmod HeavyLink

I remove the module okay.

# cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cfbff : Video ROM
000d0000-000d0bff : Adapter ROM
000d1000-000d57ff : Adapter ROM
000f0000-000fffff : System ROM
00100000-1f3fffff : System RAM
  00100000-002a8fff : Kernel code
  002a9000-0034fa7f : Kernel data
1f400000-1f4003ff : 0000:00:1f.1
e4500000-f45fffff : PCI Bus #01
  e8000000-efffffff : 0000:01:00.0
  f4580000-f45fffff : 0000:01:00.0
f8000000-fbffffff : 0000:00:00.0
fc700000-fe7fffff : PCI Bus #01
  fd000000-fdffffff : 0000:01:00.0
fe900000-fe9fffff : 0000:02:04.0
feafc000-feafcfff : 0000:02:08.0
  feafc000-feafcfff : e100
feafd000-feafdfff : 0000:02:07.0
feafe800-feafe9ff : 0000:02:04.0
feafec00-feafec7f : 0000:02:01.0
feaff000-feafffff : 0000:02:00.0
  feaff000-feafffff : aic7xxx
febff400-febff4ff : 0000:00:1f.5
febff800-febff9ff : 0000:00:1f.5
febffc00-febfffff : 0000:00:1d.7


The resources are properly freed.

# ps laxw
F   UID   PID  PPID PRI  NI   VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
4     0     1     0  16   0  3124  464 -      S    ?          0:04 init [5]       
[SNIPPED...]
4    42  3088  2989  16   0 20992 9148 -      S    ?          0:00 /usr/bin/gdmgreeter
4     0  3089  2624  15   0  4676 1336 wait4  S    tty1       0:00 -bash
4     0  3126  3089  15   0  4632  464 -      S    tty1       0:00 script
5     0  3127  3126  15   0  4636  496 -      S    tty1       0:00 script
4     0  3128  3127  15   0  6080 1276 wait4  S    pts/0      0:00 bash -i
4     0  3154  3128  17   0  2444  588 -      R    pts/0      0:00 ps laxw

The daemon is gone, properly exited.

# insmod HeavyLink.ko

Insert again. Works.

# ./ftest
Make sure a single board exists in a PCI slot and
channel A output is connected to channel B input.
Hit [Enter] to continue... 
Enabling both RX and TX
Waiting for synchronization...
Waiting for synchronization...
Mailbox-A message = 0000000f
Mailbox-B message = 0000000f
Len =   8 Mb, time =  134457.00 us, rate = 64.362763 bytes/usec
Mailbox-B message = 00000000
[SNIPPED...]
Works fine.....


# 
# lsmod | grep Heavy
HeavyLink              40456  0 
# rmmod HeavyLink\ra

Remove the module as before.  Fine.


# sync
# ./ftest

Now, try to open the device without first manually inserting
the module.

Segmentation fault

DEATH with a console screen display that doesn't get saved anywhere.

The last call was sys_open()

# exit

Script done on Wed 06 Oct 2004 05:12:20 PM EDT

Re: Probable module bug in linux-2.6.5-1.358

[Stephen Hemminger]

On Wed, 2004-10-06 at 18:08 -0400, Richard B. Johnson wrote:
> The attached script shows that an attempt to open a device
> after its module was removed, will seg-fault the kernel.
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
>              Note 96.31% of all statistics are fiction.



Oct  6 17:03:30 chaos kernel: Analogic Corp Datalink Driver : Module
removed

The bug is in that driver. It needs to unregister the character device
in it's module remove routine.  It doesn't appear to be in the main
kernel source tree so bug Redhat or the vendor.

Re: Probable module bug in linux-2.6.5-1.358

[Alan Cox]

On Iau, 2004-10-07 at 00:20, Stephen Hemminger wrote:
> Oct  6 17:03:30 chaos kernel: Analogic Corp Datalink Driver : Module
> removed
> 
> The bug is in that driver. It needs to unregister the character device
> in it's module remove routine.  It doesn't appear to be in the main
> kernel source tree so bug Redhat or the vendor.

Not Red Hat shipped, appears to be his own code.

Re: Probable module bug in linux-2.6.5-1.358

[Stephen Hemminger]

On Wed, 2004-10-06 at 18:08 -0400, Richard B. Johnson wrote:
> The attached script shows that an attempt to open a device
> after its module was removed, will seg-fault the kernel.
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
>              Note 96.31% of all statistics are fiction.



Oct  6 17:03:30 chaos kernel: Analogic Corp Datalink Driver : Module
removed

The bug is in that driver. It needs to unregister the character device
in it's module remove routine.  It doesn't appear to be in the main
kernel source tree so bug Redhat or the vendor.

Re: Probable module bug in linux-2.6.5-1.358

[Richard B. Johnson]

On Wed, 6 Oct 2004, Stephen Hemminger wrote:

> On Wed, 2004-10-06 at 18:08 -0400, Richard B. Johnson wrote:
>> The attached script shows that an attempt to open a device
>> after its module was removed, will seg-fault the kernel.
>>
>> Cheers,
>> Dick Johnson
>> Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
>>              Note 96.31% of all statistics are fiction.
>
>
>
> Oct  6 17:03:30 chaos kernel: Analogic Corp Datalink Driver : Module
> removed
>
> The bug is in that driver. It needs to unregister the character device
> in it's module remove routine.  It doesn't appear to be in the main
> kernel source tree so bug Redhat or the vendor.
>


It certainly does unregister the device.........

     if((ret =  unregister_chrdev(MAJOR_NR, devname)) < 0)
     {
         printk(KERN_ALERT"%s : Can't unregister major number %d (%d)\n",
                                devname, MAJOR_NR, ret);
         return;
     }
     free_resources();
     printk(KERN_INFO"%s : Module removed\n", devname);
}

.... and this works fine in 2.4.x




Cheers,
Dick Johnson
Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
             Note 96.31% of all statistics are fiction.

Re: Probable module bug in linux-2.6.5-1.358

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Thu, 2004-10-07 at 00:08, Richard B. Johnson wrote:
> The attached script shows that an attempt to open a device
> after its module was removed, will seg-fault the kernel.

Oct  6 17:03:30 chaos kernel: Analogic Corp Datalink Driver : Module
removed

Oct  6 17:03:38 chaos kernel: EIP:    0060:[<021556ad>]    Not tainted
Oct  6 17:03:38 chaos kernel: EFLAGS: 00010206   (2.6.5-1.358-noreg) 

since your module apparently is gpl (the kernel isn't tainted), can you
post a URL to the sourcecode so that we can point the bug out to you ?


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Probable module bug in linux-2.6.5-1.358

[Arjan van de Ven]

On Thu, Oct 07, 2004 at 08:01:47AM -0400, Richard B. Johnson wrote:
> Also, when this driver is running, transferring large volumes
> of data, the kernel decides that there have been too many interrupts, and 
> does:
> 
> Message from syslogd@chaos at Wed Oct  6 21:22:57 2004 ...
> chaos kernel: Disabling IRQ #18
> 
> This, in spite of the fact that interrupts occur only when
> DMA completion happens and new data are available, i.e.,
> one interrupt every 16 megabytes of data transferred.
> 
> Who decided that it had a right to disable my interrupt????

the kernel did because you don't return the proper value for "I handled the
IRQ" from your ISR.

Also I don't see where you call cleanup_module(), the function that does the
deregistration of the chardev... where do you call that ????

Re: Probable module bug in linux-2.6.5-1.358

[Richard B. Johnson]

On Thu, 7 Oct 2004, Arjan van de Ven wrote:

> On Thu, Oct 07, 2004 at 08:01:47AM -0400, Richard B. Johnson wrote:
>> Also, when this driver is running, transferring large volumes
>> of data, the kernel decides that there have been too many interrupts, and
>> does:
>>
>> Message from syslogd@chaos at Wed Oct  6 21:22:57 2004 ...
>> chaos kernel: Disabling IRQ #18
>>
>> This, in spite of the fact that interrupts occur only when
>> DMA completion happens and new data are available, i.e.,
>> one interrupt every 16 megabytes of data transferred.
>>
>> Who decided that it had a right to disable my interrupt????
>
> the kernel did because you don't return the proper value for "I handled the
> IRQ" from your ISR.

Do you know what that value is? I can't find it. I just returned 0
and it worked for awhile.

>
> Also I don't see where you call cleanup_module(), the function that does the
> deregistration of the chardev... where do you call that ????
>

The kernel calls cleanup_module() and the printk() shows that it
was truly called.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
             Note 96.31% of all statistics are fiction.

Re: Probable module bug in linux-2.6.5-1.358

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

On Thu, Oct 07, 2004 at 08:26:22AM -0400, Richard B. Johnson wrote:
> On Thu, 7 Oct 2004, Arjan van de Ven wrote:
> 
> >On Thu, Oct 07, 2004 at 08:01:47AM -0400, Richard B. Johnson wrote:
> >>Also, when this driver is running, transferring large volumes
> >>of data, the kernel decides that there have been too many interrupts, and
> >>does:
> >>
> >>Message from syslogd@chaos at Wed Oct  6 21:22:57 2004 ...
> >>chaos kernel: Disabling IRQ #18
> >>
> >>This, in spite of the fact that interrupts occur only when
> >>DMA completion happens and new data are available, i.e.,
> >>one interrupt every 16 megabytes of data transferred.
> >>
> >>Who decided that it had a right to disable my interrupt????
> >
> >the kernel did because you don't return the proper value for "I handled the
> >IRQ" from your ISR.
> 
> Do you know what that value is? I can't find it. I just returned 0
> and it worked for awhile.

IRQ_HANDLED is you handled the irq, IRQ_NONE if you didn't


> The kernel calls cleanup_module() and the printk() shows that it
> was truly called.

I fail to find where you declare module_exit() in your sources

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Probable module bug in linux-2.6.5-1.358

[Richard B. Johnson]

On Thu, 7 Oct 2004, Arjan van de Ven wrote:

> On Thu, Oct 07, 2004 at 08:26:22AM -0400, Richard B. Johnson wrote:
>> On Thu, 7 Oct 2004, Arjan van de Ven wrote:
>>
>>> On Thu, Oct 07, 2004 at 08:01:47AM -0400, Richard B. Johnson wrote:
>>>> Also, when this driver is running, transferring large volumes
>>>> of data, the kernel decides that there have been too many interrupts, and
>>>> does:
>>>>
>>>> Message from syslogd@chaos at Wed Oct  6 21:22:57 2004 ...
>>>> chaos kernel: Disabling IRQ #18
>>>>
>>>> This, in spite of the fact that interrupts occur only when
>>>> DMA completion happens and new data are available, i.e.,
>>>> one interrupt every 16 megabytes of data transferred.
>>>>
>>>> Who decided that it had a right to disable my interrupt????
>>>
>>> the kernel did because you don't return the proper value for "I handled the
>>> IRQ" from your ISR.
>>
>> Do you know what that value is? I can't find it. I just returned 0
>> and it worked for awhile.
>
> IRQ_HANDLED is you handled the irq, IRQ_NONE if you didn't
>
>
>> The kernel calls cleanup_module() and the printk() shows that it
>> was truly called.
>
> I fail to find where you declare module_exit() in your sources
>

Well I don't. Is it now required?  What does it do? If I put
in module_exit() and have it execute cleanup_module(), it
barfs badly. Do I just make a dummy module_exit() that
does nothing? Does this mean that unregister_chrdev() didn't
really happen until module_exit() is called?


Cheers,
Dick Johnson
Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
             Note 96.31% of all statistics are fiction.

Re: Probable module bug in linux-2.6.5-1.358

[Richard B. Johnson]

On Thu, 7 Oct 2004, Richard B. Johnson wrote:

> On Thu, 7 Oct 2004, Arjan van de Ven wrote:
>
>> On Thu, Oct 07, 2004 at 08:26:22AM -0400, Richard B. Johnson wrote:
>>> On Thu, 7 Oct 2004, Arjan van de Ven wrote:
>>> 
>>>> On Thu, Oct 07, 2004 at 08:01:47AM -0400, Richard B. Johnson wrote:
>>>>> Also, when this driver is running, transferring large volumes
>>>>> of data, the kernel decides that there have been too many interrupts, 
>>>>> and
>>>>> does:
>>>>> 
>>>>> Message from syslogd@chaos at Wed Oct  6 21:22:57 2004 ...
>>>>> chaos kernel: Disabling IRQ #18
>>>>> 
>>>>> This, in spite of the fact that interrupts occur only when
>>>>> DMA completion happens and new data are available, i.e.,
>>>>> one interrupt every 16 megabytes of data transferred.
>>>>> 
>>>>> Who decided that it had a right to disable my interrupt????
>>>> 
>>>> the kernel did because you don't return the proper value for "I handled 
>>>> the
>>>> IRQ" from your ISR.
>>> 
>>> Do you know what that value is? I can't find it. I just returned 0
>>> and it worked for awhile.
>> 
>> IRQ_HANDLED is you handled the irq, IRQ_NONE if you didn't
>>


Okay. I'll fix that.


>> 
>>> The kernel calls cleanup_module() and the printk() shows that it
>>> was truly called.
>> 
>> I fail to find where you declare module_exit() in your sources
>> 
>
> Well I don't. Is it now required?  What does it do? If I put
> in module_exit() and have it execute cleanup_module(), it

I found it..........

module_exit() is just a wrapper around cleanup_module().

cleanup_module() gets called. I could rename cleanup_module to
foo() and then  use module_exit(foo);, which seems obtuse
since this has to compile on 2.4.x also, clearly not the
right thing to do.

`dmesg` clearly shown that the exit routine was called....

PCI: Enabling device 0000:02:04.0 (0106 -> 0107)
Analogic Corp Datalink Driver : Installed 12d6:8004 IRQ18 slot:0204 DMA:1f401000
Analogic Corp Datalink Driver : Initialization complete
Analogic Corp Datalink Driver : Module removed


Cheers,
Dick Johnson
Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
             Note 96.31% of all statistics are fiction.

Re: Probable module bug in linux-2.6.5-1.358

[Stephen Hemminger]

Still haven't full source so this is still guess work.
But assuming it is a character device, did you forget to add an owner
field to the file ops structure?

static struct file_operations xxx_fops = {
	.owner	= THIS_MODULE,
	.read	= my_read,
...

The owner field is used by the character device layer to maintain module
ref counts in 2.6.

Re: Probable module bug in linux-2.6.5-1.358

[Richard B. Johnson]

On Thu, 7 Oct 2004, Stephen Hemminger wrote:

> Still haven't full source so this is still guess work.
> But assuming it is a character device, did you forget to add an owner
> field to the file ops structure?
>
> static struct file_operations xxx_fops = {
> 	.owner	= THIS_MODULE,
> 	.read	= my_read,
> ...
>
> The owner field is used by the character device layer to maintain module
> ref counts in 2.6.
>

No. The owner field is properly filled in and I did provide
the complete source code and build files for anybody who didn't
delete the email. Scanner.tar.gz was attached.

Further, unregister_chrdev() is called. Its return value is
checked. Everything is fine. I can manually remove and
reinstall the module multiple times and the resources are
always released and re-acquired.

The problem is that if you install the module and then
remove it, if you attempt to open the device-file, the
kernel will crash because it calls where the properly-
removed module used to be. It isn't there anymore.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
             Note 96.31% of all statistics are fiction.

Re: Probable module bug in linux-2.6.5-1.358

[Stephen Hemminger]

Since you want to play fast and loose with the GPL and modules
licensing, I see no reason to help you debug your problem.

If you can reproduce the same problem with some GPL version of
standalone (even dummy) code, then come back and see us sometime.

--------------
/*
 *   Since some in the Linux-kernel development group want to play
 *   lawyer, and require that a GPL License exist for every kernel
 *   module,  I provide the following:
 *
 *   Everything in this file (only) is released under the so-called
 *   GNU Public License, incorporated herein by reference.
 *
 *   Now, we just link this with any proprietary code and everybody
 *   but the lawyers are happy.
 */
#ifndef __KERNEL__
#define __KERNEL__
#endif
#ifndef MODULE
#define MODULE
#endif
#include <linux/module.h>
#if defined(MODULE_LICENSE)
MODULE_LICENSE("GPL");
#endif

Re: Probable module bug in linux-2.6.5-1.358

[Alan Cox]

On Iau, 2004-10-07 at 20:05, Stephen Hemminger wrote:
> --------------
> /*
>  *   Since some in the Linux-kernel development group want to play
>  *   lawyer, and require that a GPL License exist for every kernel
>  *   module,  I provide the following:
>  *
>  *   Everything in this file (only) is released under the so-called
>  *   GNU Public License, incorporated herein by reference.
>  *
>  *   Now, we just link this with any proprietary code and everybody
>  *   but the lawyers are happy.
>  */

What a fascinating object. I hope thats not reflective of OSDL policy 8)

Is fascinating because my first thought was that if they sign the Induce
act it would be a criminal offence to have it in the USA since its
clearly an incitement and my second thought was that the Bernstein case
appears to argue its protected speech. Interesting times 8)

More seriously the goal of MODULE_LICENSE has never been to -enforce-
GPL licensing. It provides help in understanding what symbols are
definitely off limits and it allows people to identify proprietary stuff
loaded into a system to filter bug reports.

The law on derivative works and copyright in general, murkly alas as it
is, does the enforcing, and unfortunately it is becoming apparent that
the free software world is going to have to go out soon and crack down
hard on abusers, especially those simply shipping Linux binaries with no
source or GPL information.

Alan

Re: Probable module bug in linux-2.6.5-1.358

[Stephen Hemminger]

On Thu, 2004-10-07 at 19:59 +0100, Alan Cox wrote:
> On Iau, 2004-10-07 at 20:05, Stephen Hemminger wrote:
> > --------------
> > /*
> >  *   Since some in the Linux-kernel development group want to play
> >  *   lawyer, and require that a GPL License exist for every kernel
> >  *   module,  I provide the following:
> >  *
> >  *   Everything in this file (only) is released under the so-called
> >  *   GNU Public License, incorporated herein by reference.
> >  *
> >  *   Now, we just link this with any proprietary code and everybody
> >  *   but the lawyers are happy.
> >  */
> 
> What a fascinating object. I hope thats not reflective of OSDL policy 8)

That's from Richard's license.c in the source he attached.
All copies of that code have been deleted from here because the rest of
it is proprietary.

Re: Probable module bug in linux-2.6.5-1.358

[Richard B. Johnson]

On Thu, 7 Oct 2004, Alan Cox wrote:

> On Iau, 2004-10-07 at 20:05, Stephen Hemminger wrote:
>> --------------
>> /*
>>  *   Since some in the Linux-kernel development group want to play
>>  *   lawyer, and require that a GPL License exist for every kernel
>>  *   module,  I provide the following:
>>  *
>>  *   Everything in this file (only) is released under the so-called
>>  *   GNU Public License, incorporated herein by reference.
>>  *
>>  *   Now, we just link this with any proprietary code and everybody
>>  *   but the lawyers are happy.
>>  */
>
> What a fascinating object. I hope thats not reflective of OSDL policy 8)
>
> Is fascinating because my first thought was that if they sign the Induce
> act it would be a criminal offence to have it in the USA since its
> clearly an incitement and my second thought was that the Bernstein case
> appears to argue its protected speech. Interesting times 8)
>
> More seriously the goal of MODULE_LICENSE has never been to -enforce-
> GPL licensing. It provides help in understanding what symbols are
> definitely off limits and it allows people to identify proprietary stuff
> loaded into a system to filter bug reports.
>
> The law on derivative works and copyright in general, murkly alas as it
> is, does the enforcing, and unfortunately it is becoming apparent that
> the free software world is going to have to go out soon and crack down
> hard on abusers, especially those simply shipping Linux binaries with no
> source or GPL information.
>
> Alan
>

Naaah. I included it in my module as a joke. Steve didn't take
it as a joke and forwarded it to you. It shows that the whole
MODULE_LICENSE("Whatever") is a joke. Not only that, I can
simply change /proc/sys/kernel/tainted to 0 before submitting
a bug report. This whole GPL thing has taken a real stupid
turn. I guess GNU has really taken over Linux. Stallman will
be real proud of all the work you guys did for him on
GNU/Linux .........

And, yes, we still have free speech in the US, even though
the current administration won't allow us to say anything
bad about it (treason, you know)!


Cheers,
Dick Johnson
Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
             Note 96.31% of all statistics are fiction.

Re: Probable module bug in linux-2.6.5-1.358

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

On Thu, 07 Oct 2004 16:48:42 EDT, "Richard B. Johnson" said:

> Naaah. I included it in my module as a joke. Steve didn't take
> it as a joke and forwarded it to you. It shows that the whole
> MODULE_LICENSE("Whatever") is a joke. Not only that, I can
> simply change /proc/sys/kernel/tainted to 0 before submitting
> a bug report.

Hey. It's your conscience.  Personally, I rank it right up there with
lying to your physician regarding your symptoms, and for the same reasons.

As for shipping code like that - that's just downright dishonest.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Probable module bug in linux-2.6.5-1.358

[Stephen Hemminger]

I can't reproduce your problem with a simple dummy character device.

-------------
/*
 * Minimum driver to test character device stuff.
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public
 * License version 2 as published by the Free Software Foundation.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public
 * License along with this program; if not, write to the
 * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 * Boston, MA 021110-1307, USA.
 */

#include <linux/module.h>
#include <linux/init.h>
#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/major.h>
#include <linux/fs.h>
#include <linux/device.h>

#define MYMAJOR	204

static int dummy_open(struct inode *inode, struct file *file)
{
	pr_info("dummy_open (%d)\n", iminor(inode));
	return 0;
}

static int dummy_release(struct inode *inode, struct file *file)
{
	pr_info("dummy_release (%d)\n", iminor(inode));
	return 0;
}

static struct file_operations dummy_ops = {
	.owner		= THIS_MODULE,
	.open		= dummy_open,
	.release	= dummy_release,
};

static int __init dummy_init(void)
{
	pr_info("dummy module init\n");
	return register_chrdev(MYMAJOR, "dummy", &dummy_ops);
}

static void __exit dummy_exit(void)
{
	pr_info("dummy module unloaded\n");
	unregister_chrdev(MYMAJOR, "dummy");
}

module_init(dummy_init);
module_exit(dummy_exit);

MODULE_LICENSE("GPL");

Re: Probable module bug in linux-2.6.5-1.358

[Richard B. Johnson]

On Thu, 7 Oct 2004, Stephen Hemminger wrote:

> Since you want to play fast and loose with the GPL and modules
> licensing, I see no reason to help you debug your problem.
>
> If you can reproduce the same problem with some GPL version of
> standalone (even dummy) code, then come back and see us sometime.
>

Well it isn't my problem. It's a kernel problem that only exists
in 2.6.n kernels. Versions 2.4.x work fine. And what are you
bitching for? You have the entire source-code.

Further, it exists in a dummy driver that impliments a dummy
open(), close(), and ioctl().

Once a character-device module is installed, then removed. If
you attempt to open() the module again, instead of the kernel
reloading it, it crashes. The last thing executed is
sys_open(). It should have stopped at chrdev_open(), but
the code is broken.


> --------------
> /*
> *   Since some in the Linux-kernel development group want to play
> *   lawyer, and require that a GPL License exist for every kernel
> *   module,  I provide the following:
> *
> *   Everything in this file (only) is released under the so-called
> *   GNU Public License, incorporated herein by reference.
> *
> *   Now, we just link this with any proprietary code and everybody
> *   but the lawyers are happy.
> */
> #ifndef __KERNEL__
> #define __KERNEL__
> #endif
> #ifndef MODULE
> #define MODULE
> #endif
> #include <linux/module.h>
> #if defined(MODULE_LICENSE)
> MODULE_LICENSE("GPL");
> #endif
>
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
             Note 96.31% of all statistics are fiction.

Re: Probable module bug in linux-2.6.5-1.358

[Richard B. Johnson]

On Thu, 7 Oct 2004, Stephen Hemminger wrote:

[SNIPPED...]


> If you can reproduce the same problem with some GPL version of
> standalone (even dummy) code, then come back and see us sometime.
>

Best I can see in the sources, the only place cd_forget() (for
removing a character device) is called is from clear_inode()
in inode.c. This is never called by unregister_chrdev().



Cheers,
Dick Johnson
Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
             Note 96.31% of all statistics are fiction.