Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4605475ybv; Mon, 17 Feb 2020 02:21:16 -0800 (PST) X-Google-Smtp-Source: APXvYqwSwjl14oS1zpExNctDO9/fndFUXtYOQDQoq+QMZnA5vAdoomSpZdWwUaJIQ9sf84JSsMda X-Received: by 2002:a9d:6181:: with SMTP id g1mr12127954otk.104.1581934876589; Mon, 17 Feb 2020 02:21:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581934876; cv=none; d=google.com; s=arc-20160816; b=Jhh449217N34OWfidVstNhaxzrP5icb2zuNf4fWPI2DPCuHu8KnWiHwOKbfhT0aocr U+QEMmSQzUFVThbmC5XbEFzTcUeSI0pnVAaEm9H0VkKr95cOShxRHspA91Av88K9Cl0a pBdRh61LqQ7MhtsMuuoww9jb00BAzfP0f4FJfYQtP6w7enetj/zfizC73eighDcjrN2e gxgJGCU/9bI9W9iQiw7NaZjI91kJkY7gzGZKFfiI1FX2xE/V43qxy1QPsNWSokNv7QLn XJt8MNZN/7ccXDtEpu1kAmPOE3GbdUiL4xYWtzS87fY39wAWfM61Bil8vHvpbOpwfamF RIUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=FVuYcIQO0l3s0vUverAUihkf2802JwJooV1Cz4QoQcA=; b=wtcPoIsuHrCoG/CbqCLQFV4rqCaWJQqmD+fFxqXaiw/X5gJ+TSsFOwwvnzTnIqFZqe ER/byvgLSWKXuq0Yb+TPYXT/5zmOLdHmrj0HJw1czIK7Suvf2D88mWaBBHnyJch3uQ+P QL9ZpP8pzMeMy7Cm9o90bhYHfGotn0V6hsGmOu+n0I3p1diF8eStqtiUPhcxPG6xhGW1 artl8S1YbGZRtXSXM1iopCxeZ5N4zE4akU6HwcBHtd2h9kDZuZmAQTJ25v1/9obv9Zp4 gZVrYJC6jzHRCYsGfw8Bx5PZF4XWF7ljEfoOyuSZ97xCyHYmWU4xqpfCk5Di9hGXNtYD bXjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r3si3750otp.292.2020.02.17.02.21.04; Mon, 17 Feb 2020 02:21:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729192AbgBQKUU (ORCPT + 99 others); Mon, 17 Feb 2020 05:20:20 -0500 Received: from helcar.hmeau.com ([216.24.177.18]:50508 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726397AbgBQKUT (ORCPT ); Mon, 17 Feb 2020 05:20:19 -0500 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1j3dVg-0005di-3a; Mon, 17 Feb 2020 18:20:16 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1j3dVd-0003kW-1p; Mon, 17 Feb 2020 18:20:13 +0800 Date: Mon, 17 Feb 2020 18:20:13 +0800 From: Herbert Xu To: "Jason A. Donenfeld" Cc: eric.dumazet@gmail.com, cai@lca.pw, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH v3] skbuff: fix a data race in skb_queue_len() Message-ID: <20200217102012.si4t2x75mo52fnlh@gondor.apana.org.au> References: <20200206163844.GA432041@zx2c4.com> <20200217032458.kwatitz3pvxeb25w@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 17, 2020 at 08:39:45AM +0100, Jason A. Donenfeld wrote: > > Not necessarily a big fan of this either, but just for the record here > in case it helps, while you might complain about instruction size > blowing up a bit, cycle-wise these wind up being about the same > anyway. On x86, one instruction != one cycle. I don't care about that. My problem is with the mindless patches that started this thread. Look at the patch: commit 86b18aaa2b5b5bb48e609cd591b3d2d0fdbe0442 Author: Qian Cai Date: Tue Feb 4 13:40:29 2020 -0500 skbuff: fix a data race in skb_queue_len() It's utter garbage. Why on earth did it change that one instance of unix_recvq_full? In fact you can see how stupid it is because right after the call that got changed we again call into unix_recvq_full which surely would trigger the same warning. So far the vast majority of the KCSAN patches that have caught my attention have been of this mindless kind that does not add any value to the kernel. If anything they could be hiding real bugs that would now be harder to find. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt