netdev - Re: mirred, redirect action vs. dev refcount issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20100721.165802.111593910.davem@davemloft.net>
Date:	Wed, 21 Jul 2010 16:58:02 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	shemminger@...tta.com
Cc:	hadi@...erus.ca, netdev@...r.kernel.org
Subject: Re: mirred, redirect action vs. dev refcount issue

From: Stephen Hemminger <shemminger@...tta.com>
Date: Wed, 21 Jul 2010 16:52:47 -0700

> On Wed, 21 Jul 2010 16:39:55 -0700 (PDT)
> David Miller <davem@...emloft.net> wrote:
> 
>> If it is the action rule holding onto the device, it should have
>> an appropriate netdevice notifier handler.
> 
> There is no notifier there, and the module doesn't keep track of
> list of filters. So that is why it has to be done at act api level.

Any rule, or route, or whatever that makes references to devices must
transparently accomodate the requested removal or downing of a device.

There is no way around this.

So either the action code needs to keep track of it's table entries on
some global list that can be traversed at notifier time, or we go with
the ifindex thing.

Whether the ifindex or the global list + delete scheme is better is a
topic for discussion.  Since from the user's perspective it is unclear
which semantic is less surprising, entries disappearing or suddenly
stop working (or start applying to a different device which has taken
a previous one's ifindex!).
--
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