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: <52B82F80.8070902@mojatatu.com>
Date:	Mon, 23 Dec 2013 07:41:36 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Cong Wang <xiyou.wangcong@...il.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 12/22/13 16:11, Cong Wang wrote:

> NOTHING you talked about here is relevant to the policy or
> mechanism you talked previously. Just correctness.
>

It is about _correct policy_
If you have a packets going:
->A-->B-->C-->D-->E

That is the policy (decided by someone/thing in user space).
A to E are mechanisms.
If something goes wrong with mechanism D, you dont go deleting
D because it is affecting other things in the graph. You have
no clue what it would affect - and if you try to build that in
it is not cheap for no good reason.
You let the thing/person who set it know and do the deletion.

You compared it to something going wrong with A(when A is netdev)
and how we delete everything underneath. They are not the same,
in that case, we know precisely that is the begining of the graph
and we can unreference everything underneath.

Does that make more sense?

> If removing an shared action is impossible, what about non-shared
> ones? Actually for my _own_ use case, I even don't use nor care
> about shared one...
>


Refer to above.

cheers,
jamal
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ