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,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 9DBD7C43381 for ; Sat, 2 Mar 2019 00:51:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6244D20823 for ; Sat, 2 Mar 2019 00:51:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="UiKuIwpc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726644AbfCBAvr (ORCPT ); Fri, 1 Mar 2019 19:51:47 -0500 Received: from mail-pg1-f194.google.com ([209.85.215.194]:33314 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726007AbfCBAvr (ORCPT ); Fri, 1 Mar 2019 19:51:47 -0500 Received: by mail-pg1-f194.google.com with SMTP id h11so12237218pgl.0 for ; Fri, 01 Mar 2019 16:51:46 -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=JbM1j9+P3q+frecAO+7IMGgcOZJBB7zgPnC9ag+PGGc=; b=UiKuIwpciMlMJo6hNUeqq4LEZhwrRY5l5LI/GFdTf/xPVd7YJbaQrPw1B7cUhMRWhj cPDLi4733GsPFgBFBmYxApWRaZw+YdI5CtXllyjzfVhLIsim2l7aW4eC0hGFRjwfNbCU Li78WPq8siF8+EfjQr3DKicTpOKxK+jupw6WAdZumNApIk3h3KvKJf2hjfPs3hxcf+nq pPOs+8IjUhS+oGDg3/PaU4UuhnsQpnL9jHGPyJ9W6vyKFKGnmhmILEWEWskIgVAQo8Cp Vs3HWe5ZWjSn5MVDYNkK4TKkbiTOVaHf2rGoZqiQ8pgaXx2XrcwBaXt7nd6ozTC+gOGr f99Q== 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=JbM1j9+P3q+frecAO+7IMGgcOZJBB7zgPnC9ag+PGGc=; b=prfo/netNHf21CvsnF2kH8Tajp/iieSiC3UUZhF8pmBUSfnzMdW8R74sJ2ME++aFqO oHoaBnbh8XoWeWLNFdd95OisxiakVVN25xzHIcIg9nARt+B27M07aF+Yj6JO3QIYeLbu UNncaF5oK0qBWzU8rxSaibEhKrdBD9lAze3c3lWr2YD4s+EV/ArST8wKjOiNj2W/o3xL sX6WebGZxw+l/YVZ9HBpISmz/VuUyOnMk7+cxSnJMIXhe29SUUNzJ36bhmip7NQXU9e3 OeQCPNR6X6BmcnfLZW23MWJ21cvskf488Pcm9sdE5OHZj2fZt4QgDRDgjC0/XZzexqwH Zk0g== X-Gm-Message-State: AHQUAubTpC8H3FhB/bKLhs09lBHv3D4YHpB8ZumdDEjq2K111lAh60/e qpYYknznlequ35aRw8TNCDHkohqrkLT459tcrmu7wg== X-Google-Smtp-Source: APXvYqzUn2M+HrJCC5VjJMNsVxeMX15Z/TAXxNhCLeuRY6D6vcvB+R1F8XU+2i7nXtwYTSBudvRRJMKR8CwvwyRaePc= X-Received: by 2002:a62:62c5:: with SMTP id w188mr8599161pfb.160.1551487905682; Fri, 01 Mar 2019 16:51:45 -0800 (PST) MIME-Version: 1.0 References: <20190214074712.17846-1-vladbu@mellanox.com> <20190214074712.17846-2-vladbu@mellanox.com> In-Reply-To: From: Cong Wang Date: Fri, 1 Mar 2019 16:51:33 -0800 Message-ID: Subject: Re: [PATCH net-next 01/12] net: sched: flower: don't check for rtnl on head dereference To: Vlad Buslov Cc: Jiri Pirko , Linux Kernel Network Developers , Jamal Hadi Salim , David Miller 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 Thu, Feb 28, 2019 at 10:35 AM Vlad Buslov wrote: > > > On Thu 28 Feb 2019 at 00:49, Cong Wang wrote: > > On Tue, Feb 26, 2019 at 6:57 AM Vlad Buslov wrote: > >> > >> > >> On Mon 25 Feb 2019 at 22:39, Cong Wang wrote: > >> > On Mon, Feb 25, 2019 at 8:11 AM Vlad Buslov wrote: > >> >> > >> >> > >> >> On Fri 22 Feb 2019 at 19:32, Cong Wang wrote: > >> >> > > >> >> > So if it is no longer RCU any more, why do you still use > >> >> > rcu_dereference_protected()? That is, why not just deref it as a raw > >> >> > pointer? > >> > > >> > > >> > Any answer for this question? > >> > >> I decided that since there is neither possibility of concurrent pointer > >> assignment nor deallocation of object that it points to, most performant > >> solution would be using rcu_dereference_protected() which is the only > >> RCU dereference helper that doesn't use READ_ONCE. I now understand that > >> this is confusing (and most likely doesn't provide any noticeable > >> performance improvement anyway!) and will change this patch to use > >> rcu_dereference_raw() as you suggest. > > > > Yeah, please make sure sparse is happy with that. :) > > I checked my flower change with sparse. It produced a lot of warnings, > some of which are several years old. None in the code I changed though: If so, we can address this later, it is not urgent.