2.6.0-test6: more __init bugs

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?

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

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