netdev - RE: [EXT] Re: [RFC,net-next 2/9] net: qos: introduce a gate control flow 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: <VE1PR04MB6496FB9C6C6DC9794826B37092FA0@VE1PR04MB6496.eurprd04.prod.outlook.com>
Date:   Fri, 13 Mar 2020 03:47:25 +0000
From:   Po Liu <po.liu@....com>
To:     Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     Claudiu Manoil <claudiu.manoil@....com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Roy Zang <roy.zang@....com>, Mingkai Hu <mingkai.hu@....com>,
        Jerry Huang <jerry.huang@....com>, Leo Li <leoyang.li@....com>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        "vishal@...lsio.com" <vishal@...lsio.com>,
        "saeedm@...lanox.com" <saeedm@...lanox.com>,
        "leon@...nel.org" <leon@...nel.org>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "jhs@...atatu.com" <jhs@...atatu.com>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        "john.hurley@...ronome.com" <john.hurley@...ronome.com>,
        "simon.horman@...ronome.com" <simon.horman@...ronome.com>,
        "moshe@...lanox.com" <moshe@...lanox.com>,
        "ivan.khoronzhuk@...aro.org" <ivan.khoronzhuk@...aro.org>,
        "m-karicheri2@...com" <m-karicheri2@...com>,
        "andre.guedes@...ux.intel.com" <andre.guedes@...ux.intel.com>
Subject: RE: [EXT] Re: [RFC,net-next  2/9] net: qos: introduce a gate control
 flow action

Hi Vinicius,


> -----Original Message-----
> From: Vinicius Costa Gomes <vinicius.gomes@...el.com>
> Sent: 2020年3月13日 6:14
> >> tc qdisc add dev eth0 ingress
> >
> >> tc filter add dev eth0 parent ffff: protocol ip \
> >          flower src_ip 192.168.0.20 \
> >          action gate index 2 \
> >          sched-entry OPEN 200000000 -1 -1 \
> >          sched-entry CLOSE 100000000 -1 -1
> >
> >> tc chain del dev eth0 ingress chain 0
> 
> A more complex example, showing how it would work for more filters
> would be nice.
> 
> For example, filters matching 3 different source IPs (even better, using
> MAC addresses so it would work when you add the 'skip_sw' flag),
> assigning different priorities to them, also showing how the "base-time"
> could be used.

Ok, I would update with a more clear example.

> >
> > +static int tcf_gate_act(struct sk_buff *skb, const struct tc_action *a,
> > +                     struct tcf_result *res) {
> > +     struct tcf_gate *g = to_gate(a);
> > +     struct tcf_gate_params *p;
> > +     struct gate_action *gact;
> > +     int action;
> > +
> > +     tcf_lastuse_update(&g->tcf_tm);
> > +     tcf_action_update_bstats(&g->common, skb);
> > +
> 
> Please test this with lockdep enabled, I got the feeling that there's a
> missing rcu_read_lock() somewhere around here.

I will add lock here.

> 
> > +     gact->tk_offset = tk_offset;
> > +     spin_lock_init(&gact->entry_lock);
> > +     hrtimer_init(&gact->hitimer, clockid, HRTIMER_MODE_ABS);
> > +     gact->hitimer.function = gate_timer_func;
> 
> Hm, having an hrtimer per filter seems kind dangerous, in the sense that it
> seems very hard to configure right.

Per gate action exactly. 

> 
> But I don't have any alternative ideas for now.

Yes, hrtimer should only start when software gate simulator binding. But seems there is no way to link the skip_hw state with the gate action in current state. So hrtimer has to start at initial time when it is create.

> 
> --
> Vinicius

Br,
Po Liu