[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3bqjb6wsw.fsf@maximus.localdomain>
Date: Sat, 03 Mar 2007 00:38:23 +0100
From: Krzysztof Halasa <khc@...waw.pl>
To: David Miller <davem@...emloft.net>
Cc: akpm@...ux-foundation.org, netdev@...r.kernel.org,
bugme-daemon@...zilla.kernel.org, loveminix@...oo.com.cn
Subject: Re: [Bugme-new] [Bug 8107] New: dev->header_cache_update has a random value
David Miller <davem@...emloft.net> writes:
> I disagree, you can't leave dangling references to functions
> which are potentially inside of unloaded modules, as this code
> does.
All such pointers were thought to be initialized by all HDLC protocol
handlers before device activation, but they were actually used by the
hdlc* code, and this one doesn't seem to...
> Rather, HDLC Cisco should implement a proper protocol destructor
> method to clean up these function pointers.
No, it wouldn't work - hdlc_cisco doesn't use it at all, it's just
a victim. But now I think there may be other victims.
It seems the only way to become non-NULL is through ether_setup()
from hdlc_raw_eth.c (Ethernet framing over HDLC).
I think it's best to NULLify it and the like in hdlc.c
unconditionally, it's slow path and we don't need another useless
EXPORT_SYMBOL(s). It would fix all such problems forever.
Compile-tested only but it seems pretty obvious and of course I check
if the packets still flow after regular kernel upgrades (and I run
automatic tests checking all protos except X.25 from time to time as
well).
(the patch is in the next message).
Not sure if 2.6.21 material.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists