netdev - Re: [PATCH RFC] sched: split classification and enqueue

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: <20160622172344.GG10213@breakpoint.cc>
Date:	Wed, 22 Jun 2016 19:23:44 +0200
From:	Florian Westphal <fw@...len.de>
To:	Cong Wang <xiyou.wangcong@...il.com>
Cc:	Florian Westphal <fw@...len.de>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH RFC] sched: split classification and enqueue

Cong Wang <xiyou.wangcong@...il.com> wrote:
> On Wed, Jun 22, 2016 at 3:03 AM, Florian Westphal <fw@...len.de> wrote:
> >
> > This (unfinished!) hack splits classification and enqueue into
> > two steps.
> >
> > Before enqueueing the packet and *before* acquiring the root qdisc lock,
> > the new qdisc ->classify() function is invoked.
> >
> > This function -- much like enqueue in the current scheme -- looks up
> > a child class and/or determines the next qdisc where the packet needs
> > to be handled via the classifier action subsystem.
> > Then it invokes the new ->classify() hook of the child, which can repeat
> > until the leaf qdisc is reached.
> 
> Then how is the atomicity guaranteed? One of the important
> purposes of the qdisc lock is to guarantee the atomicity of any
> change of in the whole hierarchy, i.e., qdisc/class/filter/action.

Not in this PoC, but I think that this could be solved e.g. by adding a
sequence counter that gets sampled pre-classify, we'd then only have to
check post-aquiring the root lock if its unchanged.  If not, some
class/filter, etc changed and we can just drop skb (or re-do the
classification, but I dislike such loops).

Only config changes would increment the counter, so it should not be
a lot of overhead.