netdev - Re: [PATCH net-next 1/1] net: sched: ensure tc flower reoffload takes filter ref

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, 3 Apr 2019 15:53:16 +0000
From:   Vlad Buslov <vladbu@...lanox.com>
To:     John Hurley <john.hurley@...ronome.com>
CC:     Jiri Pirko <jiri@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Vlad Buslov <vladbu@...lanox.com>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>
Subject: Re: [PATCH net-next 1/1] net: sched: ensure tc flower reoffload takes
 filter ref

On Wed 03 Apr 2019 at 01:53, John Hurley <john.hurley@...ronome.com> wrote:
> Recent changes to TC flower remove the requirement for rtnl lock when
> accessing and modifying filters. Refcounts now ensure access and deletion
> do not happen concurrently. However, the reoffload function which cycles
> through all filters and replays them to registered hw drivers is not
> protected.
>
> Use the fl_get_next_filter() function to cycle the filters for reoffload
> and ensure the ref taken by this function is put when done with each
> filter.
>
> Signed-off-by: John Hurley <john.hurley@...ronome.com>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@...ronome.com>

Hi John,

I have a very similar implementation in my next patch set that
implements unlocked hw offloads API, though I implemented helpers
fl_get_next_mask() and fl_get_next_hw_filter_on_mask() to traverse
filters with their linked list instead of performing idr lookup on each
iteration. However, I'm not sure this optimization is necessary because
offloading to hardware is supposedly much more costly than idr lookup
anyway.

Thanks for doing this and FWIW:

Reviewed-by: Vlad Buslov <vladbu@...lanox.com>