netdev - Re: [PATCH net-next] net: sched: flower: insert filter to ht before offloading it to hw

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190410084830.378b37fa@cakuba.netronome.com>
Date:   Wed, 10 Apr 2019 08:48:30 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Vlad Buslov <vladbu@...lanox.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "jhs@...atatu.com" <jhs@...atatu.com>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        "jiri@...nulli.us" <jiri@...nulli.us>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "john.hurley@...ronome.com" <john.hurley@...ronome.com>
Subject: Re: [PATCH net-next] net: sched: flower: insert filter to ht before
 offloading it to hw

On Wed, 10 Apr 2019 14:53:53 +0000, Vlad Buslov wrote:
> >> For my next patch set that unlocks the offloads API I implemented the
> >> algorithm to track reoffload count for each tp that works like this:
> >>
> >> 1. struct tcf_proto is extended with reoffload_count counter that
> >>    incremented each time reoffload is called on particular tp instance.
> >>    Counter is protected by tp->lock.
> >>
> >> 2. struct cls_fl_filter is also extended with reoffload_count counter.
> >>    Its value is set to current tp->reoffload_count when offloading the
> >>    filter.
> >>
> >> 3. After offloading the filter, but before inserting it to idr,
> >>    f->reoffload_count is compared with tp->reoffload_count. If values
> >>    don't match, filter is deleted and -EAGAIN is returned. Cls API
> >>    retries filter insertion on -EAGAIN.  
> >
> > Sounds good for add.  Does this solve delete case as well?
> >
> >    CPU 0                       CPU 1
> >
> > __fl_delete
> >   IDR remove
> >                            cb unregister
> >                              hw delete all flows  <- doesn't see the
> >                                                      remove in progress
> >
> >   hw delete  <- doesn't see
> >                 the removed cb  
> 
> Thanks for pointing that out! Looks like I need to move call to hw
> delete in __fl_delete() function to be executed before idr removal.

Ack, plus you need to do the same retry mechanism.  Save CB "count"/seq,
hw delete, remove from IDR, if CB "count"/seq changed hw delete again.
Right?