Re: Modules with list

[Adam J. Richter]

On 2002-11-27 22:42:46 GMT, Keith Owens wrote:
>On Wed, 27 Nov 2002 10:19:02 -0800, 
>"Adam J. Richter" <[e-mail]> wrote:
>>       Hmm.  We could certainly have a binary editing tool to remove
>>what was the .exit{,func} sections after the link...
>>       In this scenario, the .exit{,func} section would be linked
>>in and then discarded by the module loader, by the process of the
>>kernel releasing its .init{,data} areas, or, if you wanted to build
>>a bzImage without CONFIG_HOTPLUG, by using a binary editing tool or
>>perhaps an ld script as I mentioned earlier in this response.
>>
>>       The point of the .devexit_p_refs section would just be to
>>set those references to NULL if that was useful.  The kernel module
>>load code would do something like:
>
>You have it back to front.  The real problem is open code that calls
>functions in sections that have been discarded, that code is an oops
>just waiting to happen.  When binutils was changed to detect such
>dangling references, it found a lot of bad code on rarely tested error
>paths.  Your method would stop binutils finding the dangling references
>and open the kernel up to bad code again.

	Currently, for __devexit{,func}, this is only detected on
CONFIG_HOTPLUG=n systems.  Under my scheme we would always build
.devexit.{text,data} sections, so we could actually test this more
widely, although it would require making a binary tool to delete the
relocations at addresses pointed to by the .devexit_p_ptrs entries.
We could have a regession test that would run that tool on every
module, then run an ld script to delete .devexit.{data,text} and see
if there are any dangling references.

Adam J. Richter     __     ______________   575 Oroville Road
[e-mail]     \ /                  Milpitas, California 95035
[phone]         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."