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>

Powered by blists - more mailing lists