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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 D71E6C43381 for ; Tue, 19 Feb 2019 09:46:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9C8602146F for ; Tue, 19 Feb 2019 09:46:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=Mellanox.com header.i=@Mellanox.com header.b="mDcklFpU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727303AbfBSJqH (ORCPT ); Tue, 19 Feb 2019 04:46:07 -0500 Received: from mail-eopbgr150048.outbound.protection.outlook.com ([40.107.15.48]:26694 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725797AbfBSJqG (ORCPT ); Tue, 19 Feb 2019 04:46:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1fyOXLt0Z0EL8r8pNdupACEtwAXs4mmn9TvpesH0ZUg=; b=mDcklFpUOaU/QOgkSSYhQZkTgZcdEcu6TUniWaF6dSJ0v8e92W7fkPZrVqOnObjk1T2lBa3EmX5kjPQaIjQPNztwtxtfRj39pvSzGZQNhuc35ghhg+Tr7hD4F85dG42I8IIff0Z1dsl5Qbp4CCE4wgVNhDsbmnVbXRbYyCE++uc= Received: from VI1PR0502MB3647.eurprd05.prod.outlook.com (52.134.7.141) by VI1PR0502MB2894.eurprd05.prod.outlook.com (10.175.24.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Tue, 19 Feb 2019 09:45:59 +0000 Received: from VI1PR0502MB3647.eurprd05.prod.outlook.com ([fe80::d058:d17:78fc:969a]) by VI1PR0502MB3647.eurprd05.prod.outlook.com ([fe80::d058:d17:78fc:969a%6]) with mapi id 15.20.1622.018; Tue, 19 Feb 2019 09:45:59 +0000 From: Vlad Buslov To: Cong Wang CC: Linux Kernel Network Developers , Jamal Hadi Salim , Jiri Pirko , David Miller Subject: Re: [PATCH net-next 01/12] net: sched: flower: don't check for rtnl on head dereference Thread-Topic: [PATCH net-next 01/12] net: sched: flower: don't check for rtnl on head dereference Thread-Index: AQHUxDmfnNJQQFjgm0S2EuLlSiVKMKXl8iaAgADz/YA= Date: Tue, 19 Feb 2019 09:45:59 +0000 Message-ID: References: <20190214074712.17846-1-vladbu@mellanox.com> <20190214074712.17846-2-vladbu@mellanox.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0467.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a2::23) To VI1PR0502MB3647.eurprd05.prod.outlook.com (2603:10a6:803:f::13) authentication-results: spf=none (sender IP is ) smtp.mailfrom=vladbu@mellanox.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [37.142.13.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e821588-a2a8-46a4-5861-08d6964f0d54 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020);SRVR:VI1PR0502MB2894; x-ms-traffictypediagnostic: VI1PR0502MB2894: x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1;VI1PR0502MB2894;23:GniH9n+Zc+CdiQ6y4982eYfQn99HDYZ79V7Fu?= =?iso-8859-1?Q?F8VPAonTl/w7KPR2E17Nyufv+0M3VNY4Q2BUVUexpu3Y8eWoTc88CMwT/v?= =?iso-8859-1?Q?HQ/tOjaKHybWWVij/Cc0G3rhEsgq5vGm8EnPbINPLbQhA7rfffuI3o35q1?= =?iso-8859-1?Q?Tc81uVojZv6LNUrbKvdrERTAISSz11UbC8rwk/7dp4NMUSUyfGI+0w6N7I?= =?iso-8859-1?Q?PjTyPCy+N8S7BbJ0tjqQSWJC3ZawwpvhNJKLYceSAaHw8zP8l8hI3EuN66?= =?iso-8859-1?Q?59vpZ/FDWGqFbUbnw1e6YzgRYcQNvjKYkekOnb9B1VqYexJORMvvoSiki2?= =?iso-8859-1?Q?YEdLAV35iD7tEjut1COwlnX4QDzaARYMURCsytgUaELHKTIo9cddYY5Ffr?= =?iso-8859-1?Q?Ow4v1Tijf8MzF20lJ8tK6qlv0gQ8gKRttAX6cMLwehaS4Emx+h+k0tmrEx?= =?iso-8859-1?Q?6SMw/sGasdm9nl1ufAJrMNXJG9VWm4qldz7yCSB3xzBxXuFZcj5WeWjl8Z?= =?iso-8859-1?Q?Gdzz87pQh91ilJilQjMuu3Btnj3uBRXmzgUR06q4H5a1T859ZkElAORTvS?= =?iso-8859-1?Q?cwjkljRz9vND5ucm73BgV6qW3UIfIfeZhxc+CQw93UCCsuyOdCX/+cZhBM?= =?iso-8859-1?Q?UKD8Jb/OrrOxjRiW1OijTWXro5ACCe7x5kRd3MncubSrsc8C53iRv42BCb?= =?iso-8859-1?Q?wrdegoKHbl05QXUqhBicEwiESCGPnhck8kVDMaUH2c4pq6rX5iTucWBasM?= =?iso-8859-1?Q?Cj0rFdYItzebY4mjayIK6IBuSfGDirkdXoKEzfP1orXN1HKG1umVMirC6q?= =?iso-8859-1?Q?/cBZb1BUeKE3YBbNCh97H61Avoc+Bsax8pzhxko96SUpdYJCu4bVa6wF3t?= =?iso-8859-1?Q?3g7z3b7lvK1EOGYeaaGeKNSnldSLj2gPNaFvbvvKFUwMNG1oGZU8oStDa7?= =?iso-8859-1?Q?FC8Hk0duMAF0fMnDwR91gMXr1/oztKt/YapCpBjFKHqJD1bXbfF4rIg2Ct?= =?iso-8859-1?Q?WdAtmEMtI02ZdVKNsF/DiawoR/MJ3G/iItjMeB8XNhzqk2VB5wYLZfn9Io?= =?iso-8859-1?Q?UfZ9Bc1eLE9cMK95DCR3zWJ3ALZpRQjPqjBXG83SWbng+H9v3t0UH/gvyL?= =?iso-8859-1?Q?tGeYDHG91VukDraFSZVa9qgqvAx8kviMUjFB7yf+0tWJ7exECn7VLwMbaH?= =?iso-8859-1?Q?dMiBEj57fGVx/Tq45iNFu6LP0MXklzRJcnnnaLlIPYNN22QbZltICK3zWv?= =?iso-8859-1?Q?RrCxTiCq3zNjFPl8go/JETBGFPXnapx7daPOwBnsaxngJDVNYjMt8XMsIg?= =?iso-8859-1?Q?/d1BT7Z+ReyvO8+twA+zfNe3n?= x-microsoft-antispam-prvs: x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(376002)(136003)(346002)(366004)(396003)(39860400002)(54534003)(199004)(189003)(102836004)(53546011)(305945005)(2906002)(7736002)(36756003)(8676002)(86362001)(6246003)(66066001)(6506007)(52116002)(386003)(256004)(5660300002)(26005)(14444005)(6512007)(97736004)(3846002)(6116002)(71200400001)(316002)(53936002)(68736007)(71190400001)(81156014)(6916009)(14454004)(4326008)(99286004)(54906003)(76176011)(81166006)(11346002)(6436002)(106356001)(478600001)(186003)(25786009)(8936002)(6486002)(446003)(2616005)(476003)(486006)(229853002)(105586002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0502MB2894;H:VI1PR0502MB3647.eurprd05.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: P27emL59UHTLgzX8Fm28cJ+nFbfI8PyMFfuRUAYGxQcegu38/JgVkVt7juO3fJSbo3yiuXOwsu6kCeyiA6CIp+hClcQ+RLQ7x6Lf5w+YRWnxEyum2szowvAE/f7LJ7iOUqb9E6MuKI/OSEXe1bquhx+xW8K9/zW/3ZxgqA9nvzLMlR+vS5CO1SDflqfXQ2Cvl8VwXyu1d98j1Ns3PCxfRijZEd+wyQSUPZHmDkFX/VurDCkHQWijTW+YxKUxS307TTAaakf1cK33EjJxS73nQtlR7HnkRQjjfTLRnkvFdxtmhcBDefq7w8G0Z9CP/7bv4bJJ+LGyfdt90b+fMln5TrkKoosAYQ5Xv1CTu3KD71LQ+vbDj7RMrvjwRjWrqPCzL6/uqBHs3nxB9djsh/ifUm9qf4+JnMN9EYio5bO5GqM= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e821588-a2a8-46a4-5861-08d6964f0d54 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 09:45:58.2793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0502MB2894 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon 18 Feb 2019 at 19:08, Cong Wang wrote: > On Wed, Feb 13, 2019 at 11:47 PM Vlad Buslov wrote: >> >> Flower classifier only changes root pointer during init and destroy. Cls >> API implements reference counting for tcf_proto, so there is no danger o= f >> concurrent access to tp when it is being destroyed, even without protect= ion >> provided by rtnl lock. > > How about atomicity? Refcnt doesn't guarantee atomicity, how do > you make sure two concurrent modifications are atomic? In order to guarantee atomicity I lock shared flower classifier data structures with tp->lock in following patches. > > >> >> Implement new function fl_head_dereference() to dereference tp->root >> without checking for rtnl lock. Use it in all flower function that obtai= n >> head pointer instead of rtnl_dereference(). >> > > So what lock protects RCU writers after this patch? I explained it in comment for fl_head_dereference(), but should have copied this information to changelog as well: Flower classifier only changes root pointer during init and destroy. Cls API implements reference counting for tcf_proto, so there is no danger of concurrent access to tp when it is being destroyed, even without protection provided by rtnl lock. In initial version of this change I used tp->lock to protect tp->root access and verified it with lockdep, but during internal review Jiri noted that this is not needed in current flower implementation.