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=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, 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 AC345C282D7 for ; Wed, 30 Jan 2019 19:53:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6CEFB20989 for ; Wed, 30 Jan 2019 19:53:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="iAAaXGxo" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731671AbfA3TxZ (ORCPT ); Wed, 30 Jan 2019 14:53:25 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:56810 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728446AbfA3TxZ (ORCPT ); Wed, 30 Jan 2019 14:53:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RcEvOrP6AWM9et43vwO4FbPEce6HOIQsHm9X6RYAfRE=; b=iAAaXGxocFN/FLhKsq7DMSHmY P0j/FWggJPLmbyI7j/IX6tF1q8b/lICbkMGlu33USZfS4+MsDQ/Nu7UnVs6QSd9BgukmP5mXJ6boM KKSJ9ZJdfJT5OzXEnDb8N4UUprhGVgujWBxzvDUXFKxrTZOoa7usPjleYcO5fdtVyOUDAMK7PDL8P vj7CEwVbLspNVk5wedSxxVGcMZN6MDEs6AZUyR2eeE0w/1FLKpUwWG4YZ4RvHz3cm3bVYDqAP6d7b 6U3giYehrlCUQRq99OlfUlKC3pVT/+CheisPsSptriXvrfCgIilHjRZetYVb/wFdnF/vLv0bFEBMr wmm+TQy5g==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1govv9-00086D-Nx; Wed, 30 Jan 2019 19:53:18 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id E140B20423036; Wed, 30 Jan 2019 20:53:13 +0100 (CET) Date: Wed, 30 Jan 2019 20:53:13 +0100 From: Peter Zijlstra To: Alexei Starovoitov Cc: Alexei Starovoitov , davem@davemloft.net, daniel@iogearbox.net, edumazet@google.com, jannh@google.com, netdev@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH bpf-next 1/4] bpf: fix lockdep false positive in percpu_freelist Message-ID: <20190130195313.GC3085@hirez.programming.kicks-ass.net> References: <20190130040458.2544340-1-ast@kernel.org> <20190130040458.2544340-2-ast@kernel.org> <20190130102126.GF2278@hirez.programming.kicks-ass.net> <20190130192752.rvpi2ul26543oax7@ast-mbp.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190130192752.rvpi2ul26543oax7@ast-mbp.dhcp.thefacebook.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 On Wed, Jan 30, 2019 at 11:27:54AM -0800, Alexei Starovoitov wrote: > On Wed, Jan 30, 2019 at 11:21:26AM +0100, Peter Zijlstra wrote: > > On Tue, Jan 29, 2019 at 08:04:55PM -0800, Alexei Starovoitov wrote: > > > > > > It has been explained that is a false positive here: > > > https://lkml.org/lkml/2018/7/25/756 > > > > Please, no external references like that. The best option is to fully > > I strongly disagree. > We allowed all kinds of external links in bpf tree in the past and > going to continue doing so in the future. > I'm perfectly aware that some of them will go stale in a day or > in a year. What's the point of adding URLs if you know they'll not be useful later? Anyway, your tree, so you get to make the rules, but personally I've cursed about this exact issue a fair few times. See for example the x86 tree policy of creating BZ entries to store Intel documents to refer to them from commits because the Intel website is notoriously flaky wrt persistence. There's nothing worse than references to a document you can no longer find while trying to make sense of this 3 year old code that suddenly comes apart.