From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6106C282CE for ; Mon, 11 Feb 2019 16:10:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7446621B18 for ; Mon, 11 Feb 2019 16:10:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=resnulli-us.20150623.gappssmtp.com header.i=@resnulli-us.20150623.gappssmtp.com header.b="av3YTbt9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729224AbfBKOYf (ORCPT ); Mon, 11 Feb 2019 09:24:35 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:51122 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729201AbfBKOYd (ORCPT ); Mon, 11 Feb 2019 09:24:33 -0500 Received: by mail-wm1-f68.google.com with SMTP id x7so2003607wmj.0 for ; Mon, 11 Feb 2019 06:24:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=omMew2xS7vh+8NlbeVKz2yK5kXHdmI4Qrp9yitYstLY=; b=av3YTbt9EWoZpYbXsvDJ4Hm+XhyhhaZKCBeOb6yXQAv+dyNhxGUTKKCE52iVSSkoIi a6msiq6QiOEllPe+9b6N9p9WW4nYMOnwFue6mkgEuUyZ0MPwVPy1GbhU7W0B7g5o3o8x fboFMPoHq/yWShgCLXrGl517x6/Fo3foxOko8tAF7OybgptymP0B4a9IFoMaQLk3dC1v dQwjBmjCcLaBA+6TvTPXh+7OULDlNlalNa2TR08xNnjEIZl6K+fHZlRYeXjeUwpOtmrE yFU7tn7qPiXVn6nn6UByEGn1dChMk+79CJIkmxb1DGG8iaa+iarKmXPx6QU8JluOJx9B m9ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=omMew2xS7vh+8NlbeVKz2yK5kXHdmI4Qrp9yitYstLY=; b=rAnEh2UflAW0xUHRBtLRwc3kTOhg8+aA7rn6sfxv6hUWh2Hyptb0SzfW1R9ix/0y9E xORN4hwKL+Lv5QFK6lO7KoBX0KVlBOSHrLhYK7i3qhlErNS5pZETTcVfuYH6y3Lo1uMe YFctcCIF4/q4KoKayRJ05WrVCmFFVNlmb9ZKUl0c5CPpVd0zO20mtyNFN4G3w6rIQNp0 P+EcM46E/LjGIutQTNLo1zx9LyqiYxtmYDN3yPRQiK7lfwRKF7R3bOSKdd0oAWytCogS 3IQljzN6x5CaTGg28hZDWhxzemiklOOUVrwRPF2hDjQ9FfqmeeGFqXD13mhmxjm7xsMb EZXA== X-Gm-Message-State: AHQUAub9ZSy2yTqn75rg15QWiNaRMpNmkb4m3tyLOLvpBWb9/Dp15x7h zkBHHh1NPPpNtgKHzLvtIkT3IA== X-Google-Smtp-Source: AHgI3IaqmluDNImuDX8lhqCE//eUNLxUG3K+ZJrAmiiY1GYuleefyNMsGfCfPsClKYmIlqnV3rGGHw== X-Received: by 2002:a1c:e913:: with SMTP id q19mr9770156wmc.55.1549895071452; Mon, 11 Feb 2019 06:24:31 -0800 (PST) Received: from localhost (jirka.pirko.cz. [84.16.102.26]) by smtp.gmail.com with ESMTPSA id z21sm6275636wmf.19.2019.02.11.06.24.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Feb 2019 06:24:31 -0800 (PST) Date: Mon, 11 Feb 2019 15:15:07 +0100 From: Jiri Pirko To: Vlad Buslov Cc: netdev@vger.kernel.org, jhs@mojatatu.com, xiyou.wangcong@gmail.com, davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net Subject: Re: [PATCH net-next v4 01/17] net: sched: protect block state with mutex Message-ID: <20190211141507.GB2314@nanopsycho.orion> References: <20190211085548.7190-1-vladbu@mellanox.com> <20190211085548.7190-2-vladbu@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190211085548.7190-2-vladbu@mellanox.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Mon, Feb 11, 2019 at 09:55:32AM CET, vladbu@mellanox.com wrote: >Currently, tcf_block doesn't use any synchronization mechanisms to protect >critical sections that manage lifetime of its chains. block->chain_list and >multiple variables in tcf_chain that control its lifetime assume external >synchronization provided by global rtnl lock. Converting chain reference >counting to atomic reference counters is not possible because cls API uses >multiple counters and flags to control chain lifetime, so all of them must >be synchronized in chain get/put code. > >Use single per-block lock to protect block data and manage lifetime of all >chains on the block. Always take block->lock when accessing chain_list. >Chain get and put modify chain lifetime-management data and parent block's >chain_list, so take the lock in these functions. Verify block->lock state >with assertions in functions that expect to be called with the lock taken >and are called from multiple places. Take block->lock when accessing >filter_chain_list. > >In order to allow parallel update of rules on single block, move all calls >to classifiers outside of critical sections protected by new block->lock. >Rearrange chain get and put functions code to only access protected chain >data while holding block lock: >- Rearrange code to only access chain reference counter and chain action > reference counter while holding block lock. >- Extract code that requires block->lock from tcf_chain_destroy() into > standalone tcf_chain_destroy() function that is called by > __tcf_chain_put() in same critical section that changes chain reference > counters. > >Signed-off-by: Vlad Buslov Acked-by: Jiri Pirko