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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 10 Apr 2019 16:02:17 +0000
From:   Vlad Buslov <vladbu@...lanox.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
CC:     Vlad Buslov <vladbu@...lanox.com>,
        "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 at 18:48, Jakub Kicinski <jakub.kicinski@...ronome.com> wrote:
> 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?

Actually, I intended to modify fl_reoffload() to ignore filters with
'deleted' flag set when adding, but I guess reusing 'reoffload_count' to
retry fl_hw_destroy_filter() would also work.