Here are some cases where __init code or data is referenced by
non-__init code.
Questions:
- Is init_module allowed, required or forbidden to be __init?
- Ditto for Scsi_Host_Template.detect()?
- Ditto for net_device->set_config()?
Thanks for looking at these potential bugs, and sorry if I've made
any mistakes.
Best,
Rob
P.S. All these bugs were found with Cqual, the bug-finding tool
developed by Jeff Foster, John Kodumal, and many others, and available
at http://www.cs.umd.edu/~jfoster/cqual/, although the currently
released version of cqual only has primitive support for
__init bug-finding.
Linux 2.6.0-test6:
** Probably a bug:
** drivers/net/tokenring/ibmtr.c:channel_def (__init)
referenced by drivers/net/tokenring/ibmtr.c:ibmtr_probe1() (__devinit)
called by drivers/net/tokenring/ibmtr.c:ibmtr_probe() (__devinit)
is stored in a dev_link_t->irq.Instance->init()
returned by drivers/net/pcmcia/ibmtr_cs.c:ibmtr_attach() (not __init)
Note: So it looks like ibmtr_probe() can be called any time
a token ring pcmcia card is inserted, which may be after
init-time
Fix: Make all this stuff non-__init when it's used for the pcmcia
version of the driver?
** Probably a bug?
** drivers/net/wan/sdla.c:valid_port (__init)
referenced by sdla_set_config() (not __init)
Note: sdla_set_config() is stored as a net_device->set_config().
Is such a function allowed to touch __init data?
Fix: declare valid_port as not __init.
** Possible bug:
** drivers/net/tokenring/3c359.c:xl_init() (__init)
called by xl_probe() (__devinit)
Fix: declare xl_init __devinit or declare xl_probe __init.
Note: xl_probe is used as a pci_driver->probe() field.
** Possible bug:
** drivers/char/ipmi/ipmi_msghandler.c:ipmi_init_msghandler() (__init)
called by numerous non-__init functions
Note: ipmi_init_msghandler() is an alias for init_module
Fix: declare ipmi_init_msghandler non-__init.
** Code can be declared __init
** drivers/net/acenic.c:probed (__init)
referenced by: acenic_probe() (__devinit)
only caller: ace_module_init() (__init)
Fix: Make acenic_probe() __init?
** Probably not a bug?
** drivers/message/fusion/mptscsih.c:mptscsih_setup() (__init)
called from drivers/message/fusion/mptscsih.c:mptscsih_detect() (not __init)
Note: mptscsih_detect() is a Scsi_Host_Template.detect() function.
Can detect() functions be __init?
Fix: either declare mptscsih_setup() non-__init OR
declare mptscsih_detect() as __init
** Probably not a bug?
** drivers/scsi/qla1280.c:driver_setup (__init)
referenced by qla1280_read_nvram() (not __init)
called by qla1280_initialize_adapter() (not __init)
called by qla1280_do_device_init() (not __init)
called by qla1280_detect() (not __init)
Note: qla1280_detect is a Scsi_Host_Template->detect() routine.
Fix: make all this stuff __init?
On Tue, 2003-09-30 at 02:42, Corey Minyard wrote:
> This is not actually a bug, but it may be bad style (and thus could lead
> to a bug). It is possible that something that uses IPMI can do some
> IPMI things before IPMI is initialized. This can only happen during
> initialization, though. Thus the check; once IPMI is initialized the
> function will never be called.
>
> What's the opinion on this? Should I just force IPMI users to
> initialize after IPMI?
Thanks for looking at it. Would it be reasonable to fail if a client
tries to use the ipmi interface before it is initialized? That would be
a simple change, e.g.:
if (!initialized)
return -ENODEV;
Best,
Rob
Robert T. Johnson wrote:
>Here are some cases where __init code or data is referenced by
>non-__init code.
>
>Questions:
>- Is init_module allowed, required or forbidden to be __init?
>- Ditto for Scsi_Host_Template.detect()?
>- Ditto for net_device->set_config()?
>
>Thanks for looking at these potential bugs, and sorry if I've made
>any mistakes.
>
>Best,
>Rob
>
>P.S. All these bugs were found with Cqual, the bug-finding tool
>developed by Jeff Foster, John Kodumal, and many others, and available
>at http://www.cs.umd.edu/~jfoster/cqual/, although the currently
>released version of cqual only has primitive support for
>__init bug-finding.
>
>
>** Possible bug:
>** drivers/char/ipmi/ipmi_msghandler.c:ipmi_init_msghandler() (__init)
> called by numerous non-__init functions
>Note: ipmi_init_msghandler() is an alias for init_module
>Fix: declare ipmi_init_msghandler non-__init.
>
>
>
This is not actually a bug, but it may be bad style (and thus could lead
to a bug). It is possible that something that uses IPMI can do some
IPMI things before IPMI is initialized. This can only happen during
initialization, though. Thus the check; once IPMI is initialized the
function will never be called.
What's the opinion on this? Should I just force IPMI users to
initialize after IPMI?
Thanks,
-Corey