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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88497C433F5 for ; Thu, 6 Oct 2022 02:51:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230044AbiJFCvG (ORCPT ); Wed, 5 Oct 2022 22:51:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229468AbiJFCvB (ORCPT ); Wed, 5 Oct 2022 22:51:01 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E6557E83D; Wed, 5 Oct 2022 19:50:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 199736181A; Thu, 6 Oct 2022 02:50:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5A5AC433D6; Thu, 6 Oct 2022 02:50:55 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="J8ZlHze6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1665024654; h=from:from: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; bh=kCoSuUs9/UuRmM69QeDy2i9LHinxGmdLR45ZcTaEirk=; b=J8ZlHze6sqai3o7SvOSz7LCNjiTd0iy1m0Y4XI+eT5AImUvZr7raWMM6G4rEI94cHJCpxn XjlegKcoSMS8i1dxSH+vfMysjIZ2bhfg2hvS66iR5sZJK2Dmj1F+eRKIiZG4Kn68b6cX6p zxxQ1acjouQWyuYV2XHGTzovx3YOSQs= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 873c7cbc (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 6 Oct 2022 02:50:53 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org Cc: "Jason A. Donenfeld" , brcm80211-dev-list.pdl@broadcom.com, cake@lists.bufferbloat.net, ceph-devel@vger.kernel.org, coreteam@netfilter.org, dccp@vger.kernel.org, dev@openvswitch.org, dmaengine@vger.kernel.org, drbd-dev@lists.linbit.com, dri-devel@lists.freedesktop.org, kasan-dev@googlegroups.com, linux-actions@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-block@vger.kernel.org, linux-crypto@vger.kernel.org, linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fbdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-hams@vger.kernel.org, linux-media@vger.kernel.org, linux-mm@kvack.org, linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org, linux-nvme@lists.infradead.org, linux-raid@vger.kernel.org, linux-rdma@vger.kernel.org, linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org, linux-xfs@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, lvs-devel@vger.kernel.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, rds-devel@oss.oracle.com, SHA-cyfmac-dev-list@infineon.com, target-devel@vger.kernel.org, tipc-discussion@lists.sourceforge.net Subject: [PATCH v1 0/5] treewide cleanup of random integer usage Date: Wed, 5 Oct 2022 23:48:39 +0200 Message-Id: <20221005214844.2699-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Hi folks, This is a five part treewide cleanup of random integer handling. The rules for random integers are: - If you want a secure or an insecure random u64, use get_random_u64(). - If you want a secure or an insecure random u32, use get_random_u32(). * The old function prandom_u32() has been deprecated for a while now and is just a wrapper around get_random_u32(). - If you want a secure or an insecure random u16, use get_random_u16(). - If you want a secure or an insecure random u8, use get_random_u8(). - If you want secure or insecure random bytes, use get_random_bytes(). * The old function prandom_bytes() has been deprecated for a while now and has long been a wrapper around get_random_bytes(). - If you want a non-uniform random u32, u16, or u8 bounded by a certain open interval maximum, use prandom_u32_max(). * I say "non-uniform", because it doesn't do any rejection sampling or divisions. Hence, it stays within the prandom_* namespace. These rules ought to be applied uniformly, so that we can clean up the deprecated functions, and earn the benefits of using the modern functions. In particular, in addition to the boring substitutions, this patchset accomplishes a few nice effects: - By using prandom_u32_max() with an upper-bound that the compiler can prove at compile-time is ≤65536 or ≤256, internally get_random_u16() or get_random_u8() is used, which wastes fewer batched random bytes, and hence has higher throughput. - By using prandom_u32_max() instead of %, when the upper-bound is not a constant, division is still avoided, because prandom_u32_max() uses a faster multiplication-based trick instead. - By using get_random_u16() or get_random_u8() in cases where the return value is intended to indeed be a u16 or a u8, we waste fewer batched random bytes, and hence have higher throughput. So, based on those rules and benefits from following them, this patchset breaks down into the following five steps: 1) Replace `prandom_u32() % max` and variants thereof with prandom_u32_max(max). 2) Replace `(type)get_random_u32()` and variants thereof with get_random_u16() or get_random_u8(). I took the pains to actually look and see what every lvalue type was across the entire tree. 3) Replace remaining deprecated uses of prandom_u32() with get_random_u32(). 4) Replace remaining deprecated uses of prandom_bytes() with get_random_bytes(). 5) Remove the deprecated and now-unused prandom_u32() and prandom_bytes() inline wrapper functions. I was thinking of taking this through my random.git tree (on which this series is currently based) and submitting it near the end of the merge window, or waiting for the very end of the 6.1 cycle when there will be the fewest new patches brewing. If somebody with some treewide-cleanup experience might share some wisdom about what the best timing usually winds up being, I'm all ears. I've CC'd get_maintainers.pl, which is a pretty big list. Probably some portion of those are going to bounce, too, and everytime you reply to this thread, you'll have to deal with a bunch of bounces coming immediately after. And a recipient list this big will probably dock my email domain's spam reputation, at least temporarily. Sigh. I think that's just how it goes with treewide cleanups though. Again, let me know if I'm doing it wrong. Please take a look! Thanks, Jason Cc: Ajay Singh Cc: Akinobu Mita Cc: Alexandre Torgue Cc: Amitkumar Karwar Cc: Andreas Dilger Cc: Andreas Färber Cc: Andreas Noever Cc: Andrew Lunn Cc: Andrew Morton Cc: Andrii Nakryiko Cc: Andy Gospodarek Cc: Andy Lutomirski Cc: Andy Shevchenko Cc: Anil S Keshavamurthy Cc: Anna Schumaker Cc: Arend van Spriel Cc: Ayush Sawal Cc: Borislav Petkov Cc: Chao Yu Cc: Christoph Böhmwalder Cc: Christoph Hellwig Cc: Christophe Leroy Cc: Chuck Lever Cc: Claudiu Beznea Cc: Cong Wang Cc: Dan Williams Cc: Daniel Borkmann Cc: Darrick J. Wong Cc: Dave Hansen Cc: David Ahern Cc: David S. Miller Cc: Dennis Dalessandro Cc: Dick Kennedy Cc: Dmitry Vyukov Cc: Eric Dumazet Cc: Florian Westphal Cc: Franky Lin Cc: Ganapathi Bhat Cc: Greg Kroah-Hartman Cc: Gregory Greenman Cc: H. Peter Anvin Cc: Hannes Reinecke Cc: Hans Verkuil Cc: Hante Meuleman Cc: Hao Luo Cc: Haoyue Xu Cc: Heiner Kallweit Cc: Helge Deller Cc: Herbert Xu Cc: Hideaki YOSHIFUJI Cc: Hugh Dickins Cc: Igor Mitsyanko Cc: Ilya Dryomov Cc: Ingo Molnar Cc: Jack Wang Cc: Jaegeuk Kim Cc: Jaehoon Chung Cc: Jakub Kicinski Cc: Jamal Hadi Salim Cc: James E.J. Bottomley Cc: James Smart Cc: Jan Kara Cc: Jason Gunthorpe Cc: Jay Vosburgh Cc: Jean-Paul Roubelat Cc: Jeff Layton Cc: Jens Axboe Cc: Jiri Olsa Cc: Jiri Pirko Cc: Johannes Berg Cc: John Fastabend Cc: John Stultz Cc: Jon Maloy Cc: Jonathan Corbet Cc: Jozsef Kadlecsik Cc: Julian Anastasov Cc: KP Singh Cc: Kalle Valo Cc: Kees Cook Cc: Keith Busch Cc: Lars Ellenberg Cc: Leon Romanovsky Cc: Manish Rangankar Cc: Manivannan Sadhasivam Cc: Marcelo Ricardo Leitner Cc: Marco Elver Cc: Martin K. Petersen Cc: Martin KaFai Lau Cc: Masami Hiramatsu Cc: Mauro Carvalho Chehab Cc: Maxime Coquelin Cc: Md. Haris Iqbal Cc: Michael Chan Cc: Michael Ellerman Cc: Michael Jamet Cc: Michal Januszewski Cc: Mika Westerberg Cc: Miquel Raynal Cc: Namjae Jeon Cc: Naveen N. Rao Cc: Neil Horman Cc: Nicholas Piggin Cc: Nilesh Javali Cc: OGAWA Hirofumi Cc: Pablo Neira Ayuso Cc: Paolo Abeni Cc: Peter Zijlstra Cc: Philipp Reisner Cc: Potnuri Bharat Teja Cc: Pravin B Shelar Cc: Rasmus Villemoes Cc: Richard Weinberger Cc: Rohit Maheshwari Cc: Russell King Cc: Sagi Grimberg Cc: Santosh Shilimkar Cc: Sergey Matyukevich Cc: Sharvari Harisangam Cc: Simon Horman Cc: Song Liu Cc: Stanislav Fomichev Cc: Steffen Klassert Cc: Stephen Boyd Cc: Stephen Hemminger Cc: Sungjong Seo Cc: Theodore Ts'o Cc: Thomas Gleixner Cc: Thomas Graf Cc: Thomas Sailer Cc: Toke Høiland-Jørgensen Cc: Trond Myklebust Cc: Ulf Hansson Cc: Varun Prakash Cc: Veaceslav Falico Cc: Vignesh Raghavendra Cc: Vinay Kumar Yadav Cc: Vinod Koul Cc: Vlad Yasevich Cc: Wenpeng Liang Cc: Xinming Hu Cc: Xiubo Li Cc: Yehezkel Bernat Cc: Ying Xue Cc: Yishai Hadas Cc: Yonghong Song Cc: Yury Norov Cc: brcm80211-dev-list.pdl@broadcom.com Cc: cake@lists.bufferbloat.net Cc: ceph-devel@vger.kernel.org Cc: coreteam@netfilter.org Cc: dccp@vger.kernel.org Cc: dev@openvswitch.org Cc: dmaengine@vger.kernel.org Cc: drbd-dev@lists.linbit.com Cc: dri-devel@lists.freedesktop.org Cc: kasan-dev@googlegroups.com Cc: linux-actions@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-block@vger.kernel.org Cc: linux-crypto@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-ext4@vger.kernel.org Cc: linux-f2fs-devel@lists.sourceforge.net Cc: linux-fbdev@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-hams@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: linux-mm@kvack.org Cc: linux-mmc@vger.kernel.org Cc: linux-mtd@lists.infradead.org Cc: linux-nfs@vger.kernel.org Cc: linux-nvme@lists.infradead.org Cc: linux-raid@vger.kernel.org Cc: linux-rdma@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: linux-sctp@vger.kernel.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-usb@vger.kernel.org Cc: linux-wireless@vger.kernel.org Cc: linux-xfs@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: lvs-devel@vger.kernel.org Cc: netdev@vger.kernel.org Cc: netfilter-devel@vger.kernel.org Cc: rds-devel@oss.oracle.com Cc: SHA-cyfmac-dev-list@infineon.com Cc: target-devel@vger.kernel.org Cc: tipc-discussion@lists.sourceforge.net Jason A. Donenfeld (5): treewide: use prandom_u32_max() when possible treewide: use get_random_{u8,u16}() when possible treewide: use get_random_u32() when possible treewide: use get_random_bytes when possible prandom: remove unused functions Documentation/networking/filter.rst | 2 +- arch/powerpc/crypto/crc-vpmsum_test.c | 2 +- arch/x86/mm/pat/cpa-test.c | 4 +- block/blk-crypto-fallback.c | 2 +- crypto/async_tx/raid6test.c | 2 +- crypto/testmgr.c | 94 +++++++++---------- drivers/block/drbd/drbd_receiver.c | 4 +- drivers/dma/dmatest.c | 2 +- drivers/infiniband/core/cma.c | 2 +- drivers/infiniband/hw/cxgb4/cm.c | 4 +- drivers/infiniband/hw/cxgb4/id_table.c | 4 +- drivers/infiniband/hw/hfi1/tid_rdma.c | 2 +- drivers/infiniband/hw/hns/hns_roce_ah.c | 5 +- drivers/infiniband/hw/mlx4/mad.c | 2 +- drivers/infiniband/ulp/ipoib/ipoib_cm.c | 2 +- drivers/infiniband/ulp/rtrs/rtrs-clt.c | 3 +- drivers/md/raid5-cache.c | 2 +- drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 2 +- .../media/test-drivers/vivid/vivid-radio-rx.c | 4 +- drivers/mmc/core/core.c | 4 +- drivers/mmc/host/dw_mmc.c | 2 +- drivers/mtd/nand/raw/nandsim.c | 8 +- drivers/mtd/tests/mtd_nandecctest.c | 12 +-- drivers/mtd/tests/speedtest.c | 2 +- drivers/mtd/tests/stresstest.c | 19 +--- drivers/mtd/ubi/debug.c | 2 +- drivers/mtd/ubi/debug.h | 6 +- drivers/net/bonding/bond_main.c | 2 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- drivers/net/ethernet/broadcom/cnic.c | 5 +- .../chelsio/inline_crypto/chtls/chtls_cm.c | 4 +- .../chelsio/inline_crypto/chtls/chtls_io.c | 4 +- drivers/net/ethernet/rocker/rocker_main.c | 8 +- drivers/net/hamradio/baycom_epp.c | 2 +- drivers/net/hamradio/hdlcdrv.c | 2 +- drivers/net/hamradio/yam.c | 2 +- drivers/net/phy/at803x.c | 2 +- drivers/net/wireguard/selftest/allowedips.c | 16 ++-- .../broadcom/brcm80211/brcmfmac/p2p.c | 2 +- .../net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 2 +- .../net/wireless/marvell/mwifiex/cfg80211.c | 4 +- .../wireless/microchip/wilc1000/cfg80211.c | 2 +- .../net/wireless/quantenna/qtnfmac/cfg80211.c | 2 +- drivers/nvme/common/auth.c | 2 +- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 4 +- drivers/scsi/fcoe/fcoe_ctlr.c | 4 +- drivers/scsi/lpfc/lpfc_hbadisc.c | 6 +- drivers/scsi/qedi/qedi_main.c | 2 +- drivers/target/iscsi/cxgbit/cxgbit_cm.c | 2 +- drivers/thunderbolt/xdomain.c | 2 +- drivers/video/fbdev/uvesafb.c | 2 +- fs/ceph/inode.c | 2 +- fs/ceph/mdsmap.c | 2 +- fs/exfat/inode.c | 2 +- fs/ext2/ialloc.c | 2 +- fs/ext4/ialloc.c | 4 +- fs/ext4/ioctl.c | 4 +- fs/ext4/mmp.c | 2 +- fs/ext4/super.c | 7 +- fs/f2fs/gc.c | 2 +- fs/f2fs/namei.c | 2 +- fs/f2fs/segment.c | 8 +- fs/fat/inode.c | 2 +- fs/nfsd/nfs4state.c | 4 +- fs/ubifs/debug.c | 10 +- fs/ubifs/journal.c | 2 +- fs/ubifs/lpt_commit.c | 14 +-- fs/ubifs/tnc_commit.c | 2 +- fs/xfs/libxfs/xfs_alloc.c | 2 +- fs/xfs/libxfs/xfs_ialloc.c | 4 +- fs/xfs/xfs_error.c | 2 +- fs/xfs/xfs_icache.c | 2 +- fs/xfs/xfs_log.c | 2 +- include/linux/prandom.h | 12 --- include/net/netfilter/nf_queue.h | 2 +- include/net/red.h | 2 +- include/net/sock.h | 2 +- kernel/kcsan/selftest.c | 4 +- kernel/time/clocksource.c | 2 +- lib/fault-inject.c | 2 +- lib/find_bit_benchmark.c | 4 +- lib/random32.c | 4 +- lib/reed_solomon/test_rslib.c | 12 +-- lib/sbitmap.c | 4 +- lib/test_fprobe.c | 2 +- lib/test_kprobes.c | 2 +- lib/test_list_sort.c | 2 +- lib/test_objagg.c | 2 +- lib/test_rhashtable.c | 6 +- lib/test_vmalloc.c | 19 +--- lib/uuid.c | 2 +- mm/shmem.c | 2 +- net/802/garp.c | 2 +- net/802/mrp.c | 2 +- net/ceph/mon_client.c | 2 +- net/ceph/osd_client.c | 2 +- net/core/neighbour.c | 2 +- net/core/pktgen.c | 47 +++++----- net/core/stream.c | 2 +- net/dccp/ipv4.c | 4 +- net/ipv4/datagram.c | 2 +- net/ipv4/igmp.c | 6 +- net/ipv4/inet_connection_sock.c | 2 +- net/ipv4/inet_hashtables.c | 2 +- net/ipv4/ip_output.c | 2 +- net/ipv4/route.c | 2 +- net/ipv4/tcp_cdg.c | 2 +- net/ipv4/tcp_ipv4.c | 4 +- net/ipv4/udp.c | 2 +- net/ipv6/addrconf.c | 8 +- net/ipv6/ip6_flowlabel.c | 2 +- net/ipv6/mcast.c | 10 +- net/ipv6/output_core.c | 2 +- net/mac80211/rc80211_minstrel_ht.c | 2 +- net/mac80211/scan.c | 2 +- net/netfilter/ipvs/ip_vs_conn.c | 2 +- net/netfilter/ipvs/ip_vs_twos.c | 4 +- net/netfilter/nf_nat_core.c | 4 +- net/netfilter/xt_statistic.c | 2 +- net/openvswitch/actions.c | 2 +- net/packet/af_packet.c | 2 +- net/rds/bind.c | 2 +- net/sched/act_gact.c | 2 +- net/sched/act_sample.c | 2 +- net/sched/sch_cake.c | 8 +- net/sched/sch_netem.c | 22 ++--- net/sched/sch_pie.c | 2 +- net/sched/sch_sfb.c | 2 +- net/sctp/socket.c | 4 +- net/sunrpc/auth_gss/gss_krb5_wrap.c | 4 +- net/sunrpc/cache.c | 2 +- net/sunrpc/xprt.c | 2 +- net/sunrpc/xprtsock.c | 2 +- net/tipc/socket.c | 2 +- net/unix/af_unix.c | 2 +- net/xfrm/xfrm_state.c | 2 +- 136 files changed, 304 insertions(+), 339 deletions(-) -- 2.37.3