lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 17 Feb 2020 18:20:13 +0800 From: Herbert Xu <herbert@...dor.apana.org.au> To: "Jason A. Donenfeld" <Jason@...c4.com> Cc: eric.dumazet@...il.com, cai@....pw, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [PATCH v3] skbuff: fix a data race in skb_queue_len() 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@....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@...dor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists