On Wed, 14 Jan 2004 16:44:16 -0800
Stephen Hemminger <shemminger@xxxxxxxx> wrote:
> Possible problems:
> qeth: s390 driver -- bug, code is narcissistic and thinks it only gets
> notified about it's own devices.
>
> atm/mpc: only looks for "lec" devices, don't know if they could exist
> before it starts.
These are both hard errors and potential bogus pointer derefences, they both
assume the type of dev->priv. The atm/mpc case has a netdev->name==NULL
test which is a funny relic :-)
Both these cases ought to be fixed. However, the atm/mpc case poses an issue,
how to identify "my" devices? We've established that the textual name is
basically arbitrary and not a reliable key. Currently I see only two
possible reliable solutions, but I like neither of them:
1) Device driver doing this needs to keep own list of net devices it
has created. Then it's notifiier code does something like:
if (!find_in_mpoa_devlist(dev))
return NOTIFY_DONE;
2) Add a type cookie or similar to the generic netdev, only devices
which need to identify themselves in these generic kind of cases
add identifier values there, so currently that would be MPOA and
QETH, then the code goes:
if (dev->type_cookie == NETDEV_TYPE_MPOA)
return NOTIFY_DONE;
But as stated I think both of these ideas absolutely stink.
... wait...
Ok, I have an idea, consider this. We add a netdev->notifier()
method. We create a new routine to net/core/dev.c:
static void run_netdev_notifiers(int event, struct net_device *dev)
{
notifier_call_chain(&netdev_chain, event, dev);
if (dev->notifier)
dev->notifier(dev, event);
}
Then replace all the notifier_call_chain(&netdev_chain, ...) calls
in net/core/dev.c with invocations of run_netdev_notifiers().
I believe we can (and thus should) add an ASSERT_RTNL() to this new
run_netdev_notifiers() functions, although I'm not %100 sure.
What do you think Stephen?
> Unrelated problems:
> ddp: registers for notifier before it is initialized
Just moving it down to the end of atalk_init() should fix this?
Actually, I don't really see any potential problem here.
> ipmr: no locking for add/delete
Not a problem, RTNL semaphore is held.
> ipfwadm: no module owner on /proc interface
Please elaborate. I don't see the ipfwadm netdev event notifier
messing with procfs stuff, or is this happen at a level or two of
indirection somewhere else?
> The following are okay:
Thanks for the audit.
|