netdev - Re: [PATCH 2/2] net/sched: CAN Filter/Classifier

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] [day] [month] [year] [list]

Message-ID: <1339062806.4816.3.camel@lolumad>
Date:	Thu, 07 Jun 2012 11:53:26 +0200
From:	Rostislav Lisovy <lisovy@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org, linux-can@...r.kernel.org,
	lartc@...r.kernel.org, pisa@....felk.cvut.cz, sojkam1@....cvut.cz
Subject: Re: [PATCH 2/2] net/sched: CAN Filter/Classifier

On Tue, 2012-06-05 at 10:09 +0200, Eric Dumazet wrote: 
> On Mon, 2012-06-04 at 18:09 +0200, Rostislav Lisovy wrote:
> > This classifier classifies CAN frames (AF_CAN) according to their
> > identifiers. This functionality can not be easily achieved with
> > existing classifiers, such as u32. This classifier can be used
> > with any available qdisc and it is able to classify both SFF
> > or EFF frames.
> > 
> > The filtering rules for EFF frames are stored in an array, which
> > is traversed during classification. A bitmap is used to store SFF
> > rules -- one bit for each ID.
> > 
> > More info about the project:
> > http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf
> > 
> > Signed-off-by: Rostislav Lisovy <lisovy@...il.com>
> > ---
> >  net/sched/Kconfig   |   10 +
> >  net/sched/Makefile  |    1 +
> >  net/sched/cls_can.c |  572 +++++++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 583 insertions(+)
> >  create mode 100644 net/sched/cls_can.c
> 
> It seems a huge amount of code, and before reviewing it I would like to
> ask :
> 
> 1) Did you try to extend cls_flow somehow ?
I did not. If I understand it right, cls_flow is intended to be mainly
used with SFQ qdisc (which tries to ensure fairness among different
flows).
My intention was to make a simple and deterministic filter (which may be
used with any available qdisc).

However, after thoroughly going through cls_flow I realized that
implementing an ematch function (to be used with cls_basic or others)
will preserve the functionality and save some code at the same time.
Therefore I tend to implement a new ematch function and resubmit the
patch later if it turns to be a good approach. What do you think?

Command syntax proposed in this patch was
tc filter add ... can sffid 0x123 sffid 0x500:0x700 effid 0x00:0xff ...
An ematch could look like
tc filter add ... basic match 'canid(sff 0x123 sff 0x124:0x7f0 \
  eff 0x1234)' ...


> 2) Adding a cls_filter (or extend cls_flow to be able to use a bpf),
> could be more generic, and thanks to bpf jit could be way faster.
What do you mean with 'adding a cls_filter'?
BPF is useful only for filtering incoming data, isn't it?


> 
> 3) sfq/fq_codel could be CAN aware if you adapt skb_flow_dissect() ?
I will try to implement "deterministic ematch" filter in the first
place.
I may extend skb_flow_dissect() later.

Regards;
Rostislav Lisovy


--
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