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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D0B6C4167B for ; Thu, 13 Oct 2022 01:37:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77A916B0071; Wed, 12 Oct 2022 21:37:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 72A4F6B0073; Wed, 12 Oct 2022 21:37:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CAB66B0074; Wed, 12 Oct 2022 21:37:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 47AFC6B0071 for ; Wed, 12 Oct 2022 21:37:33 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1261C40615 for ; Thu, 13 Oct 2022 01:37:33 +0000 (UTC) X-FDA: 80014213986.11.629A86F Received: from relay.hostedemail.com (unirelay02 [10.200.18.65]) by imf26.hostedemail.com (Postfix) with ESMTP id BD10014002A for ; Thu, 13 Oct 2022 01:37:32 +0000 (UTC) Received: from omf20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 640C9120237; Thu, 13 Oct 2022 01:37:28 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: joe@perches.com) by omf20.hostedemail.com (Postfix) with ESMTPA id 56EDD20026; Thu, 13 Oct 2022 01:37:01 +0000 (UTC) Message-ID: <3f527ec95a12135eb40f5f2d156a2954feb7fbfe.camel@perches.com> Subject: Re: [PATCH v1 3/5] treewide: use get_random_u32() when possible From: Joe Perches To: David Laight , "Jason A. Donenfeld" , "linux-kernel@vger.kernel.org" Cc: "linux-fbdev@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-wireless@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linux-mm@kvack.org" , "linux-sctp@vger.kernel.org" , "target-devel@vger.kernel.org" , "linux-mtd@lists.infradead.org" , "linux-stm32@st-md-mailman.stormreply.com" , "drbd-dev@lists.linbit.com" , "dev@openvswitch.org" , "rds-devel@oss.oracle.com" , "linux-scsi@vger.kernel.org" , "dccp@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "kasan-dev@googlegroups.com" , "lvs-devel@vger.kernel.org" , "SHA-cyfmac-dev-list@infineon.com" , "coreteam@netfilter.org" , "tipc-discussion@lists.sourceforge.net" , "linux-ext4@vger.kernel.org" , "linux-media@vger.kernel.org" , "linux-actions@lists.infradead.org" , "linux-nfs@vger.kernel.org" , "linux-block@vger.kernel.org" , "dmaengine@vger.kernel.org" , "linux-nvme@lists.infradead.org" , "linux-hams@vger.kernel.org" , "ceph-devel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "cake@lists.bufferbloat.net" , "brcm80211-dev-list.pdl@broadcom.com" , "linux-raid@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-usb@vger.kernel.org" , "linux-mmc@vger.kernel.org" , "linux-f2fs-devel@lists.sourceforge.net" , "linux-xfs@vger.kernel.org" , "netfilter-devel@vger.kernel.org" , "linux-crypto@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" Date: Wed, 12 Oct 2022 18:37:11 -0700 In-Reply-To: References: <20221005214844.2699-1-Jason@zx2c4.com> <20221005214844.2699-4-Jason@zx2c4.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX18KEIRmyyr9pSEavQqF5X0dTzAEITyiJq4= ARC-Authentication-Results: i=1; imf26.hostedemail.com; none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665625052; a=rsa-sha256; cv=none; b=MQUaFe8BSlmFgqormjoeX7pO29sgCTo5jbStkqs3CUDTBwfNaopPTn8twLfmpzwgP/0frN nTA+HFnRZa3Hs4bi1olB10Od+RBah03zP67UhdF2CMpvQQnjQExjpSQY12UHd3YQxQqelc 6mF+udWswvej3Yihprj29IMSKgus8aM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665625052; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=c2YwssGIaPysLPcR20mrskERCj5dzMDhD63/1J4p7RU=; b=6oVO2Ib/BQQXqtaQQ03uvEkGrqb+pgtJi7JFmm4NWvmS86zHkFQG72zjyryrWCT0dTLTa0 4eV5c/nOpk3lAyL43I2LlaR9K2MAAlg1bMQ1RP9UG2Xrmnyjw5chCSwcN+mHOF8yw+fwbN JOSbiMAWhpHF1YA2Xci/orWXuXCuRdk= X-Rspam-User: X-HE-Tag-Orig: 1665625021-540494 Authentication-Results: imf26.hostedemail.com; none X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: BD10014002A X-Stat-Signature: a7iahb8y9h873wooartjpdsap84ttadg X-HE-Tag: 1665625052-479821 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 2022-10-12 at 21:29 +0000, David Laight wrote: > From: Joe Perches > > Sent: 12 October 2022 20:17 > >=20 > > On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote: > > > The prandom_u32() function has been a deprecated inline wrapper aroun= d > > > get_random_u32() for several releases now, and compiles down to the > > > exact same code. Replace the deprecated wrapper with a direct call to > > > the real function. > > [] > > > diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw= /cxgb4/cm.c > > [] > > > @@ -734,7 +734,7 @@ static int send_connect(struct c4iw_ep *ep) > > > &ep->com.remote_addr; > > > int ret; > > > enum chip_type adapter_type =3D ep->com.dev->rdev.lldi.adapter_type= ; > > > - u32 isn =3D (prandom_u32() & ~7UL) - 1; > > > + u32 isn =3D (get_random_u32() & ~7UL) - 1; > >=20 > > trivia: > >=20 > > There are somewhat odd size mismatches here. > >=20 > > I had to think a tiny bit if random() returned a value from 0 to 7 > > and was promoted to a 64 bit value then truncated to 32 bit. > >=20 > > Perhaps these would be clearer as ~7U and not ~7UL >=20 > That makes no difference - the compiler will generate the same code. True, more or less. It's more a question for the reader. > The real question is WTF is the code doing? True. > The '& ~7u' clears the bottom 3 bits. > The '- 1' then sets the bottom 3 bits and decrements the > (random) high bits. Right. > So is the same as get_random_u32() | 7. True, it's effectively the same as the upper 29 bits are random anyway and the bottom 3 bits are always set. > But I bet the coder had something else in mind. Likely. And it was also likely copy/pasted a few times.