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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 45290C43381 for ; Mon, 18 Feb 2019 18:56:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1474C217F5 for ; Mon, 18 Feb 2019 18:56:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="O3NaJvDZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728009AbfBRS4X (ORCPT ); Mon, 18 Feb 2019 13:56:23 -0500 Received: from mail-pg1-f193.google.com ([209.85.215.193]:34845 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727414AbfBRS4W (ORCPT ); Mon, 18 Feb 2019 13:56:22 -0500 Received: by mail-pg1-f193.google.com with SMTP id s198so8907600pgs.2 for ; Mon, 18 Feb 2019 10:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=21l7QlTdv7VGdN7UP7dqNgLQIliz34vJZ3ObB0QtVi8=; b=O3NaJvDZGqco6e7VZjU1RBZ1SHKC3VckhM7/gE0j9hOnnDWO2Dy0BAcgu36Fz3O7Gh GXlUxpXVJpusarsZ28uX9KG7xJUt7KJg3PEiy7lCiVl2CvGMwpW+SrkmN82Pr54FEDFO bLrYgPIUJQ73jkuacNaBgRHED6+EV1UiwI60dgc4vOM57cdqdtQgwHlFfZ0BWJ5WQ1G1 Uj1v62VDzVvFXb/cBbjKPdSFh/lNlqLQMAoGXs9M5PBaThE7YMPKdDMWSGQqwG59iShK yCUGsp5HIu5J6bwOkFbnV4RmO4Q98NuCMzzMP6kj+FkeLlv6fvBnE8VblwETJAgAKwMJ U8XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=21l7QlTdv7VGdN7UP7dqNgLQIliz34vJZ3ObB0QtVi8=; b=QV9SgGGn7+c4aToakfc7YxoHXCUMc32xWs3w1LDd4j8o0uXpllaocVSLAu0wOC/bYT b4VZW9ccL1ivdmQ591DUX5YNLQO5kXLtzJZjaQk4QVxgQN9O1ivtJvFVDdjaSfl4VDhd nBwgBPxuS374KqsQe5yNo3XaTtW/Ur4mh3SA/ZZbb7EMEzRmfL5A3yMZB2oiWOnuHoNA 0Q33wfaFMY1eJT+iWUEJAuB6rRgOLs7v7txwOcSnCgjNWQnpN5jqizBzU4wRtZJ54Dp4 4QZhnN3wBwo05p4v0bwbudmhtQriQJQwkIVXRrdlAxVpLrSixH5StFADerlqvElaOQ3D qjeA== X-Gm-Message-State: AHQUAubNwOTZNdBLsx2hayZdIk/xEZvG4Vn8njHTqFVVHhJ4QQnNgHjQ 5WE1pjNQtNrY5RUV1KF+f4jBciZPHZRHlz1nmQs= X-Google-Smtp-Source: AHgI3IYl4v2dvLKlJ4X5g6/LmaI6s6WtdTO/r1XE2B/gRekI2FWB/yO+qGUOr2VNu7zeU2dRvrYyLiw9FnjbeIhMnjs= X-Received: by 2002:a62:e04b:: with SMTP id f72mr26033352pfh.41.1550516181902; Mon, 18 Feb 2019 10:56:21 -0800 (PST) MIME-Version: 1.0 References: <20190211085548.7190-1-vladbu@mellanox.com> <20190211085548.7190-18-vladbu@mellanox.com> In-Reply-To: <20190211085548.7190-18-vladbu@mellanox.com> From: Cong Wang Date: Mon, 18 Feb 2019 10:56:08 -0800 Message-ID: Subject: Re: [PATCH net-next v4 17/17] net: sched: unlock rules update API To: Vlad Buslov Cc: Linux Kernel Network Developers , Jamal Hadi Salim , Jiri Pirko , David Miller , Alexei Starovoitov , Daniel Borkmann Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Feb 11, 2019 at 12:56 AM Vlad Buslov wrote: > > Register netlink protocol handlers for message types RTM_NEWTFILTER, > RTM_DELTFILTER, RTM_GETTFILTER as unlocked. Set rtnl_held variable that > tracks rtnl mutex state to be false by default. > > Introduce tcf_proto_is_unlocked() helper that is used to check > tcf_proto_ops->flag to determine if ops can be called without taking rtnl > lock. Manually lookup Qdisc, class and block in rule update handlers. > Verify that both Qdisc ops and proto ops are unlocked before using any of > their callbacks, and obtain rtnl lock otherwise. So if you end goal is to completely get rid of RTNL from tc filter and action control path, why this change is needed? I was expecting you to break down the RTNL lock down to each block/filter chain, which should be done in this patchset. So again, why do we still need RTNL for some cases? Please state the reasoning in your changelog, rather than just describing what your code does. Thanks.