netdev - Re: [PATCH net-next v3 09/12] net: sched: flower: handle concurrent tcf proto deletion

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: <20190321140629.GM2087@nanopsycho>
Date:   Thu, 21 Mar 2019 15:06:29 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Vlad Buslov <vladbu@...lanox.com>
Cc:     netdev@...r.kernel.org, jhs@...atatu.com, xiyou.wangcong@...il.com,
        davem@...emloft.net, sbrivio@...hat.com
Subject: Re: [PATCH net-next v3 09/12] net: sched: flower: handle concurrent
 tcf proto deletion

Thu, Mar 21, 2019 at 02:17:41PM CET, vladbu@...lanox.com wrote:
>Without rtnl lock protection tcf proto can be deleted concurrently. Check
>tcf proto 'deleting' flag after taking tcf spinlock to verify that no
>concurrent deletion is in progress. Return EAGAIN error if concurrent
>deletion detected, which will cause caller to retry and possibly create new
>instance of tcf proto.
>
>Retry mechanism is a result of fine-grained locking approach used in this
>and previous changes in series and is necessary to allow concurrent updates
>on same chain instance. Alternative approach would be to lock the whole
>chain while updating filters on any of child tp's, adding and removing
>classifier instances from the chain. However, since most CPU-intensive
>parts of filter update code are specifically in classifier code and its
>dependencies (extensions and hw offloads), such approach would negate most
>of the gains introduced by this change and previous changes in the series
>when updating same chain instance.
>
>Signed-off-by: Vlad Buslov <vladbu@...lanox.com>
>Reviewed-by: Stefano Brivio <sbrivio@...hat.com>

Acked-by: Jiri Pirko <jiri@...lanox.com>