2.4.8-pre4 drivers/net/wan/comx.c unresolved symbol

This is probably already known but 2.4.8-pre4 drivers/net/wan/comx.c has an unresolved symbol proc_get_inode when compiled as a module.

I was pleasently suprised when doing a full kernel compile as modules. 840 modules created, only one unresolved symbol.

It is using a symbol which was exported in 2.2, but is not exported in 2.4. Either the driver needs a major rewrite to work as a module (it works compiled into the kernel) or proc_get_inode needs to be exported again.

Madarasz Gergely          [email protected]          [email protected]
    It's practically impossible to look at a penguin and feel angry.
        Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                  HuLUG: http://mlf.linux.rulez.org/

The driver needs a major rewrite to work.

Ok. I was just maintaining that code, I didn't write it, and it was accepted into 2.2 with no mention of these problems. And btw it at least seemed to be working...

Madarasz Gergely          [email protected]          [email protected]
    It's practically impossible to look at a penguin and feel angry.
        Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                  HuLUG: http://mlf.linux.rulez.org/

Ask Alan - he had accepted that code in 2.2...

Seriously, it's badly broken. I'm quite interested in getting the filesystem side fixed (and ready to help with that), but amount of other bugs is _very_ large. Several I can remember right now:
* kmalloc(..., GFP_KERNEL) may block and lead to IO. What do you
expect to happen if it gets called when interrupts are disabled?
* ->hw_init() can block before it bumps module reference count
(e.g. mixcom calls kmalloc()). rmmod while we are sleeping and you've got a nice oops.
* return value of ->stop() is ignored. Returning -EBUSY
will not prevent shutting the interface down.
* remove_proc_entry() won't terminate ->read() in progress (obviously)
and it doesn't wait for completion of said ->read() (nothing to wait on). open a file and do rmdir(). See what happens if somebody's reading from the file right now...

Yes. The fix is also know - rm(1). comx.c is oopsable in so many ways that it's not worth fixing. I've played with it for quite a while trying to fix the sucker, but there were more and more bugs. About the only function they hadn't fscked up was their reimplementation of strcasecmp(3).
Diagnosis: FUBAR. Literally.

If the authors (who, AFAICS, happen to be manufacturers of the hardware in question) are interested in having that driver in a tree I would _really_ recommend them to rewrite the damn thing from scratch and submit it for review before it goes into the kernel.

I can dig up the list of bugs (incomplete - at some point I simply gave up on that) and post it, if anyone is interested.

And no, exporting proc_get_inode() will not help anything - their procfs code is completely b0rken (as in, if you ever rmmod the thing _or_ unregister an interface - any user can crash the box). And that's aside of GFP_KERNEL kmalloc() with interrupts disabled, extremely odd ideas about the semantics of netdev ->stop(), lousy use of timers, kmalloc() before MOD_INC_USE_COUNT, various and sundry races, yodda, yodda.