netdev - Re: [PATCH net-next v4 3/8] net_sched: mirred: remove action when the target device is gone

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: <CAM_iQpWarY7kHNCtVdYqMVdADFbCUmDsAVQz1+iEx9JKsdZN5w@mail.gmail.com>
Date:	Mon, 23 Dec 2013 14:14:04 -0800
From:	Cong Wang <xiyou.wangcong@...il.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next v4 3/8] net_sched: mirred: remove action when the
 target device is gone

On Mon, Dec 23, 2013 at 12:41 PM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
>
> Now if you have such a graph:

Making such an abstraction only helps misunderstanding, really...

> What you cannot do is, on your own as kernel, decide you want to delete
> one action that is _bound_ to a filter because one of its attributes is
> gone berserk. It doesnt matter whether such an action is mirred or foo
> or whether D and E dont exist. You can put a big hole where the town
> used to be and leave roads leading to the town.

Again, since (non-shared) actions attached to a filter are chained by
a doubly linked list, why not?

> It will still be referenced by things preeceding it (primarily the
> classifier which keeps an action chain intact), which is bad when the
> next packet arrives.

You know, there is a head for such linked list for the filter to refer,
so what's the problem with deleting a node from a linked list if
we lock it properly? In non-shared case, no filter can refer to any
action without the head of the chain, right? So what is the problem
of "referenced by things preeceding it" when they are linked and locked
properly?

> You let the user/control program which is monitoring things do that
> and "reroute" around the problem. If you insist on putting a little part
> of the medula oblangata in the stomach, then:
> the only correct way to do it is delete the filter.

Apparent not, different actions can attached to the same filter
and only mirred action has a target dev.

> And you start doing that you are making some serious policy decisions
> in the kernel and adding lots of complexity.
>

Why removing a filter when the netdev is removed is not policy?
Actually it is, ONLY that it is not be able to shared with current
implementation.

Since you love mechanism _so much_, why not make filters shared
by other qdisc's and stop removing them when netdev is gone in kernel?

Be realistic, Jamal, user-space is hard, you can't simply let user-space
decide everything, especially when you don't provide a simple way to do it.
Netlink is already hard to use, even with libnl, since it enforces a cache
layer. Sit down and spend some time to write some libnl code, compare it
with this patch.
--
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