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

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

[Keith Owens]

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.

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

[Gergely Madarasz]

On Mon, 6 Aug 2001, Keith Owens wrote:

> 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          gorgo@sztaki.hu          gorgo@linux.rulez.org
    It's practically impossible to look at a penguin and feel angry.
        Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                  HuLUG: http://mlf.linux.rulez.org/

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

[Alexander Viro]

On Mon, 6 Aug 2001, Keith Owens wrote:

> 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.

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.

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

[Alexander Viro]

On Mon, 6 Aug 2001, Gergely Madarasz wrote:

> On Mon, 6 Aug 2001, Keith Owens wrote:
> 
> > 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.

The driver needs a major rewrite to work.

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

[Gergely Madarasz]

On Mon, 6 Aug 2001, Alexander Viro wrote:

>
>
> On Mon, 6 Aug 2001, Gergely Madarasz wrote:
>
> > On Mon, 6 Aug 2001, Keith Owens wrote:
> >
> > > 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.
>
> 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          gorgo@sztaki.hu          gorgo@linux.rulez.org
    It's practically impossible to look at a penguin and feel angry.
        Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                  HuLUG: http://mlf.linux.rulez.org/

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

[Alexander Viro]

On Mon, 6 Aug 2001, Gergely Madarasz wrote:

> 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...

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...