netdev - Re: [patch net-next 1/6] net: sched: introduce a TRAP control action

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: <20170605195905.GD1986@nanopsycho>
Date:   Mon, 5 Jun 2017 21:59:05 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, jhs@...atatu.com,
        xiyou.wangcong@...il.com, edumazet@...gle.com,
        alexander.h.duyck@...el.com, stephen@...workplumber.org,
        daniel@...earbox.net, mlxsw@...lanox.com
Subject: Re: [patch net-next 1/6] net: sched: introduce a TRAP control action

Mon, Jun 05, 2017 at 09:56:32PM CEST, andrew@...n.ch wrote:
>> On Mon, Jun 05, 2017 at 04:38:27PM +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@...lanox.com>
>> 
>> There is need to instruct the HW offloaded path to push certain matched
>> packets to cpu/kernel for further analysis. So this patch introduces a
>> new TRAP control action to TC.
>> 
>> For kernel datapath, this action does not make much sense. So with the
>> same logic as in HW, new TRAP behaves similar to STOLEN. The skb is just
>> dropped in the datapath (and virtually ejected to an upper level, which
>> does not exist in case of kernel).
>> 
>> Signed-off-by: Jiri Pirko <jiri@...lanox.com>
>> Reviewed-by: Yotam Gigi <yotamg@...lanox.com>
>> ---
>>  include/uapi/linux/pkt_cls.h | 5 +++++
>>  net/core/dev.c               | 2 ++
>>  net/sched/cls_bpf.c          | 1 +
>>  net/sched/sch_atm.c          | 1 +
>>  net/sched/sch_cbq.c          | 1 +
>>  net/sched/sch_drr.c          | 1 +
>>  net/sched/sch_dsmark.c       | 1 +
>>  net/sched/sch_fq_codel.c     | 1 +
>>  net/sched/sch_hfsc.c         | 1 +
>>  net/sched/sch_htb.c          | 1 +
>>  net/sched/sch_multiq.c       | 1 +
>>  net/sched/sch_prio.c         | 1 +
>>  net/sched/sch_qfq.c          | 1 +
>>  net/sched/sch_sfb.c          | 1 +
>>  net/sched/sch_sfq.c          | 1 +
>>  15 files changed, 20 insertions(+)
>> 
>> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
>> index edf43dd..5d6f711 100644
>> --- a/include/uapi/linux/pkt_cls.h
>> +++ b/include/uapi/linux/pkt_cls.h
>> @@ -37,6 +37,11 @@ enum {
>>  #define TC_ACT_QUEUED		5
>>  #define TC_ACT_REPEAT		6
>>  #define TC_ACT_REDIRECT		7
>> +#define TC_ACT_TRAP		8 /* For hw path, this means "trap to cpu",
>> +				   * for sw path, this is equivalent of
>> +				   * TC_ACT_STOLEN - drop the skb and act
>> +				   * like everything is allright.
>> +				   */
>
>Hi Jiri
>
>Given my question and your answer, can we please extend this
>description.
>
>"For hw path, this means "trap to cpu" and don't further process the
>frame in hardware."

Okay :)


>
>Oh, and s/allright/alright.

English is an odd language :) Thanks!