From: Herbert Xu <herbert@gondor.apana.org.au>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: eric.dumazet@gmail.com, cai@lca.pw, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v3] skbuff: fix a data race in skb_queue_len()
Date: Mon, 17 Feb 2020 18:20:13 +0800 [thread overview]
Message-ID: <20200217102012.si4t2x75mo52fnlh@gondor.apana.org.au> (raw)
In-Reply-To: <CAHmME9q+YYia0H3upW7ikwSii_XegNNSBkVxP-1mxaHyEVmBxA@mail.gmail.com>
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 <cai@lca.pw>
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 <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
prev parent reply other threads:[~2020-02-17 10:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-04 18:40 [PATCH v3] skbuff: fix a data race in skb_queue_len() Qian Cai
2020-02-06 12:59 ` David Miller
2020-02-06 16:38 ` Jason A. Donenfeld
2020-02-06 17:10 ` Eric Dumazet
2020-02-06 18:12 ` Jason A. Donenfeld
2020-02-06 18:22 ` Eric Dumazet
2020-02-06 18:43 ` Jason A. Donenfeld
2020-02-06 19:29 ` Marco Elver
2020-02-06 21:55 ` Jason A. Donenfeld
2020-02-07 10:35 ` Marco Elver
2020-02-17 3:24 ` Herbert Xu
2020-02-17 7:39 ` Jason A. Donenfeld
2020-02-17 10:20 ` Herbert Xu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200217102012.si4t2x75mo52fnlh@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=Jason@zx2c4.com \
--cc=cai@lca.pw \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).