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 520CAC43381 for ; Mon, 18 Feb 2019 18:31:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1E01221773 for ; Mon, 18 Feb 2019 18:31:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BWmdAdOH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729852AbfBRSbm (ORCPT ); Mon, 18 Feb 2019 13:31:42 -0500 Received: from mail-pf1-f194.google.com ([209.85.210.194]:33930 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726695AbfBRSbm (ORCPT ); Mon, 18 Feb 2019 13:31:42 -0500 Received: by mail-pf1-f194.google.com with SMTP id u9so1730899pfn.1 for ; Mon, 18 Feb 2019 10:31:41 -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=nNIC3e9VAeiz4kRqIBeyUfvrVff2QGf0WZhV+o8YddM=; b=BWmdAdOHpgjBF0gSXtIf6Otw3f2qMALwUB+EqZuMzLFKpiebdIHxrxr7P8A850N1eb DaYHoe3xCJtZgYUU4MakarlaPE32jGajxIgAGDN4MXPhWbRratOPEmHy513OCEeDuE7O YjBUwq2XMgAusMnQM7ZyI0UNKjLuBjRJvK/lVgaC5rj9Fel0lxD/Uu4erzlDw/o/zL/y A3jn3AvraMxADf+8VpBKrTey/MdZFMamr7D7aRXdajqb9ka9GW260zX1icAiudpSPJHG vDSj2lM4bV6SkmfkFdxh/iEGoAU0kLAYjxrMCfEXZeI6fH8lLXYQDCMkVVBY9h3elpBD UPZg== 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=nNIC3e9VAeiz4kRqIBeyUfvrVff2QGf0WZhV+o8YddM=; b=rrPH50JKCuE+TWvo08vO6zatBLQxIZbhviQxt244CxnHofL8i6MKP1+hteTvyTImd0 3MJgf+CWonTTKrHkGbkNPKyY2MwASOMX1aO5mbcQyN4BBXJE6kJvfBt59wJImrfU68g1 nUtPhBKuAxVi7SDTbdfpjVSX17ZEh6yv+GEWNVj+BO8hE66LmxZErdZisSY5vQ5/uyEn uYTfOx8O2Zimox/7paiUb9qJvz89g5C/idzoTzC5HaNbwcRAdXLxw2cUHzZcS5kGfZpl 8RdqLKNZI3kgI3mHVirztSB/l/pFLRHb+ugMf/KT/d88miEkL8nVLovb5mu8ZKTORw/q IHdw== X-Gm-Message-State: AHQUAub1+/e+yjH1wCUJ/QKFjvu6lQJjE5VoQbWNC2FmID88Pese8C+G 2pRoUDr7oJDf86Pej2qXcZsQwX3RD+H3DwDt3/0= X-Google-Smtp-Source: AHgI3IbTY8lqbgPiY/lF3IFkdeKHkKL4YEKWc1YZ0cHIrC7CmnD3Je0kpLDT6ZjzQQyz0mudD73EeHd62fJOrWGS0AQ= X-Received: by 2002:a62:e716:: with SMTP id s22mr25192604pfh.35.1550514701110; Mon, 18 Feb 2019 10:31:41 -0800 (PST) MIME-Version: 1.0 References: <20190211085548.7190-1-vladbu@mellanox.com> <20190211085548.7190-8-vladbu@mellanox.com> In-Reply-To: From: Cong Wang Date: Mon, 18 Feb 2019 10:31:29 -0800 Message-ID: Subject: Re: [PATCH net-next v4 07/17] net: sched: protect filter_chain list with filter_chain_lock mutex 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 18, 2019 at 3:06 AM Vlad Buslov wrote: > > On Fri 15 Feb 2019 at 22:35, Cong Wang wrote: > > On Mon, Feb 11, 2019 at 12:56 AM Vlad Buslov wrote: > >> +#ifdef CONFIG_PROVE_LOCKING > >> +static inline bool lockdep_tcf_chain_is_locked(struct tcf_chain *chain) > >> +{ > >> + return lockdep_is_held(&chain->filter_chain_lock); > >> +} > >> +#else > >> +static inline bool lockdep_tcf_chain_is_locked(struct tcf_block *chain) > >> +{ > >> + return true; > >> +} > >> +#endif /* #ifdef CONFIG_PROVE_LOCKING */ > >> + > >> +#define tcf_chain_dereference(p, chain) \ > >> + rcu_dereference_protected(p, lockdep_tcf_chain_is_locked(chain)) > > > > > > Are you sure you need this #ifdef CONFIG_PROVE_LOCKING? > > rcu_dereference_protected() should already test CONFIG_PROVE_RCU. > > > > Ditto for tcf_proto_dereference(). > > I implemented these macro same way as rtnl_dereference() is implemented, > which they are intended to substitute. > > After removing them I get following compilation error with > CONFIG_PROVE_LOCKING disabled: This is pretty odd, because net/core/neighbour.c uses it without any #ifdef CONFIG_PROVE_LOCKING, for instance: 192 neigh = rcu_dereference_protected(n->next, 193 lockdep_is_held(&tbl->lock)); 194 rcu_assign_pointer(*np, neigh); 195 neigh_mark_dead(n); 196 retval = true; So how does this compile when CONFIG_PROVE_LOCKING is disabled? :-/