Hi,
I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
kernel and booted the kernel. Next I compiled e1000 as a module (
e1000.ko ), and tried to insmod it into the kernel( which already had
e1000 a compiled as a part of the kernel). I observed that
/proc/kallsyms contained two copies of all the symbols exported by
e1000, and I also got a Kernel Panic on the way.
Is this behaviour natural and desirable ?
Regards and Thanks
-A
On Wed, 23 Nov 2005, Ashutosh Naik wrote:
> Hi,
>
> I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
> kernel and booted the kernel. Next I compiled e1000 as a module (
> e1000.ko ), and tried to insmod it into the kernel( which already had
> e1000 a compiled as a part of the kernel). I observed that
> /proc/kallsyms contained two copies of all the symbols exported by
> e1000, and I also got a Kernel Panic on the way.
>
> Is this behaviour natural and desirable ?
>
> Regards and Thanks
> -A
When the new module interface was implemented, new bugs were
introduced. You just found another one!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Ashutosh Naik wrote:
> Hi,
>
> I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
> kernel and booted the kernel. Next I compiled e1000 as a module (
> e1000.ko ), and tried to insmod it into the kernel( which already had
> e1000 a compiled as a part of the kernel). I observed that
> /proc/kallsyms contained two copies of all the symbols exported by
> e1000, and I also got a Kernel Panic on the way.
>
> Is this behaviour natural and desirable ?
No, trying to insert a module into a kernel built with the functionality
compiled in is a vile perverted act, and probably illegal in Republican
states! ;-)
The other day I mentioned that reiser4 will find bugs because people
will do bizarre things with it when it is more widely used. I think you
have hit a "no one would ever do that" bug in the module loader, and
demonstrated my point in the process.
The panic isn't desirable, but I'm not sure what "correct behaviour"
would be, I can't imagine that this is intended to work. The issues of
removing such a module gracefully are significant.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On 11/23/05, Bill Davidsen <[email protected]> wrote:
> Ashutosh Naik wrote:
> > Hi,
> >
> > I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
> > kernel and booted the kernel. Next I compiled e1000 as a module (
> > e1000.ko ), and tried to insmod it into the kernel( which already had
> > e1000 a compiled as a part of the kernel). I observed that
> > /proc/kallsyms contained two copies of all the symbols exported by
> > e1000, and I also got a Kernel Panic on the way.
> >
> > Is this behaviour natural and desirable ?
>
> No, trying to insert a module into a kernel built with the functionality
> compiled in is a vile perverted act, and probably illegal in Republican
> states! ;-)
>
> The other day I mentioned that reiser4 will find bugs because people
> will do bizarre things with it when it is more widely used. I think you
> have hit a "no one would ever do that" bug in the module loader, and
> demonstrated my point in the process.
>
> The panic isn't desirable, but I'm not sure what "correct behaviour"
> would be, I can't imagine that this is intended to work. The issues of
> removing such a module gracefully are significant.
Wouldn't the desired behaviour be that when the kernel attempts to
load a module it checks if it is already present build-in and if so
simply refuse to load it at all?
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Wed, 23 Nov 2005 19:04:41 +0100, Jesper Juhl <[email protected]> wrote:
>On 11/23/05, Bill Davidsen <[email protected]> wrote:
>> Ashutosh Naik wrote:
>> > Hi,
>> >
>> > I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
>> > kernel and booted the kernel. Next I compiled e1000 as a module (
>> > e1000.ko ), and tried to insmod it into the kernel( which already had
>> > e1000 a compiled as a part of the kernel). I observed that
>> > /proc/kallsyms contained two copies of all the symbols exported by
>> > e1000, and I also got a Kernel Panic on the way.
>> >
>> > Is this behaviour natural and desirable ?
>>
>> No, trying to insert a module into a kernel built with the functionality
>> compiled in is a vile perverted act, and probably illegal in Republican
>> states! ;-)
>>
>> The other day I mentioned that reiser4 will find bugs because people
>> will do bizarre things with it when it is more widely used. I think you
>> have hit a "no one would ever do that" bug in the module loader, and
>> demonstrated my point in the process.
>>
>> The panic isn't desirable, but I'm not sure what "correct behaviour"
>> would be, I can't imagine that this is intended to work. The issues of
>> removing such a module gracefully are significant.
>
>Wouldn't the desired behaviour be that when the kernel attempts to
>load a module it checks if it is already present build-in and if so
>simply refuse to load it at all?
But that sounds just too easy to implement, what's the catch? :o)
--
Grant.
On 11/23/05, Grant Coady <[email protected]> wrote:
> On Wed, 23 Nov 2005 19:04:41 +0100, Jesper Juhl <[email protected]> wrote:
>
> >On 11/23/05, Bill Davidsen <[email protected]> wrote:
> >> Ashutosh Naik wrote:
> >> > Hi,
> >> >
> >> > I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
> >> > kernel and booted the kernel. Next I compiled e1000 as a module (
> >> > e1000.ko ), and tried to insmod it into the kernel( which already had
> >> > e1000 a compiled as a part of the kernel). I observed that
> >> > /proc/kallsyms contained two copies of all the symbols exported by
> >> > e1000, and I also got a Kernel Panic on the way.
> >> >
> >> > Is this behaviour natural and desirable ?
> >>
> >> No, trying to insert a module into a kernel built with the functionality
> >> compiled in is a vile perverted act, and probably illegal in Republican
> >> states! ;-)
> >>
> >> The other day I mentioned that reiser4 will find bugs because people
> >> will do bizarre things with it when it is more widely used. I think you
> >> have hit a "no one would ever do that" bug in the module loader, and
> >> demonstrated my point in the process.
> >>
> >> The panic isn't desirable, but I'm not sure what "correct behaviour"
> >> would be, I can't imagine that this is intended to work. The issues of
> >> removing such a module gracefully are significant.
> >
> >Wouldn't the desired behaviour be that when the kernel attempts to
> >load a module it checks if it is already present build-in and if so
> >simply refuse to load it at all?
>
> But that sounds just too easy to implement, what's the catch? :o)
I've not looked at what it would take to do that, nor what measures
are currently in place, *at all*, but as I see it, all it would take
would be some "tag" present for each message stating if it was "build
in", or "currently loaded as a module", then on each module load check
the "tag" of the to-be-loaded module against the list of current
in-kernel tags, then reject if already on the list.
I can't see why there would be a catch...
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Jesper Juhl wrote:
> On 11/23/05, Bill Davidsen <[email protected]> wrote:
>
>>Ashutosh Naik wrote:
>>
>>>Hi,
>>>
>>>I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
>>>kernel and booted the kernel. Next I compiled e1000 as a module (
>>>e1000.ko ), and tried to insmod it into the kernel( which already had
>>>e1000 a compiled as a part of the kernel). I observed that
>>>/proc/kallsyms contained two copies of all the symbols exported by
>>>e1000, and I also got a Kernel Panic on the way.
>>>
>>>Is this behaviour natural and desirable ?
>>
>>No, trying to insert a module into a kernel built with the functionality
>>compiled in is a vile perverted act, and probably illegal in Republican
>>states! ;-)
>>
>>The other day I mentioned that reiser4 will find bugs because people
>>will do bizarre things with it when it is more widely used. I think you
>>have hit a "no one would ever do that" bug in the module loader, and
>>demonstrated my point in the process.
>>
>>The panic isn't desirable, but I'm not sure what "correct behaviour"
>>would be, I can't imagine that this is intended to work. The issues of
>>removing such a module gracefully are significant.
>
>
> Wouldn't the desired behaviour be that when the kernel attempts to
> load a module it checks if it is already present build-in and if so
> simply refuse to load it at all?
It doesn't look to be quite as easy to check for built-in as to check
for "already loaded" without some global state tracking, and handling
the case where it just wasn't built at all, and may have other stuff
missing. Add to this not breaking existing out of tree code and the
implementation looks like a non-trivial exercise.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On 11/24/05, Bill Davidsen <[email protected]> wrote:
>>I've not looked at what it would take to do that, nor what measures
>>are currently in place, *at all*, but as I see it, all it would take
>>would be some "tag" present for each message stating if it was "build
>>in", or "currently loaded as a module", then on each module load check
>>the "tag" of the to-be-loaded module against the list of current
>>in-kernel tags, then reject if already on the list.
>>I can't see why there would be a catch...
> It doesn't look to be quite as easy to check for built-in as to check
> for "already loaded" without some global state tracking, and handling
> the case where it just wasn't built at all, and may have other stuff
> missing. Add to this not breaking existing out of tree code and the
> implementation looks like a non-trivial exercise.
I am currently working on a preliminary patch which addresses this
issue. A module wont be able to load any symbol, which already exists
in the kernel symbol table.
Regards
Ashutosh