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 49DB2ECDFA1 for ; Sun, 23 Oct 2022 21:09:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229619AbiJWVJF (ORCPT ); Sun, 23 Oct 2022 17:09:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229497AbiJWVJE (ORCPT ); Sun, 23 Oct 2022 17:09:04 -0400 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83D396686E; Sun, 23 Oct 2022 14:09:03 -0700 (PDT) Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 29NL7D2p025712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 23 Oct 2022 17:07:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1666559243; bh=zbENVyGNAon7zNh9ohkJFECSMTzXRXbcNrepMHxrEAM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=FXNrxCWraFmMAOW+vqR38ZOexAnGjiiR9A8LdOwTHYuoNMBlL77R2zP0ktOpr83lt VqRJZ2eM6bTmotP3IJ0ZjbLCm4EYxGWCpxZWFf6OGNB4ci103uHdfxC4WF6VQ2zTX/ sdIQ8AMmuFf2tnrWyiobYzmlMOkVIMT/l7Xfqoj9INuJk54r2BALT8VjDgqDT3Zhdd VJdERnwc5/7VlgvkT7OeoHx0mHgokAaWpeUY/UYmdBjcPk3IReiiQVTczMP0A0m8lc roc5e18VhoTm14PI9JdmJ03W1yO7BPKEnbbIuJ9deFvxdyuN3p81VawGcIo+Cv1H4t KETGAaOyQuEfg== Received: by cwcc.thunk.org (Postfix, from userid 15806) id BE8CB15C33A3; Sun, 23 Oct 2022 17:07:13 -0400 (EDT) Date: Sun, 23 Oct 2022 17:07:13 -0400 From: "Theodore Ts'o" To: Jakub Kicinski Cc: "Jason A. Donenfeld" , linux-kernel@vger.kernel.org, Kees Cook , Greg Kroah-Hartman , Russell King , Catalin Marinas , Thomas Bogendoerfer , Heiko Carstens , Herbert Xu , Christoph =?iso-8859-1?Q?B=F6hmwalder?= , Jani Nikula , Jason Gunthorpe , Sakari Ailus , "Martin K . Petersen" , Andreas Dilger , Jaegeuk Kim , Richard Weinberger , "Darrick J . Wong" , SeongJae Park , Thomas Gleixner , Andrew Morton , Michael Ellerman , Helge Deller , netdev@vger.kernel.org, linux-crypto@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mmc@vger.kernel.org, linux-parisc@vger.kernel.org Subject: Re: [PATCH v1 0/5] convert tree to get_random_u32_{below,above,between}() Message-ID: References: <20221022014403.3881893-1-Jason@zx2c4.com> <20221021205522.6b56fd24@kernel.org> <20221021223242.05df0a5b@kernel.org> <20221021230322.00dd045c@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221021230322.00dd045c@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Fri, Oct 21, 2022 at 11:03:22PM -0700, Jakub Kicinski wrote: > On Sat, 22 Oct 2022 07:47:06 +0200 Jason A. Donenfeld wrote: > > On Fri, Oct 21, 2022 at 10:32:42PM -0700, Jakub Kicinski wrote: > > > But whatever. I mean - hopefully there aren't any conflicts in the ~50 > > > networking files you touch. I just wish that people didn't pipe up with > > > the tree wide changes right after the merge window. Feels like the > > > worst possible timing. > > > > Oh, if the timing is what makes this especially worrisome, I have > > no qualms about rebasing much later, and reposting this series then. > > I'll do that. > > Cool, thanks! I promise to not be grumpy if you repost around rc6 :) One way of making things less painful for the stable branch and for the upstream branch is to *add* new helpers instead of playing replacement games like s/prandom_u32_max/get_random_u32_below/. This is what causes the patch conflict problems. One advantage of at least adding the new functions to the stable branches, even if we don't do the wholesale replacement, is that it makes it much less likely that a backported patch, which uses the new API, won't fail to compile --- and of course, the major headache case is one where it's not noticed at first because it didn't get picked up in people's test compiles until after the Linux x.y.z release has been pushed out. Whether it's worth doing the wholesale replacement is a different question, but separating "add the new functions with one or two use cases so the functions are actulaly _used_" from the "convert the world to use the new functions" from the "remove the old functions", might life easier. - Ted 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 68A78C433FE for ; Sun, 23 Oct 2022 21:12:46 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4MwWBN4lBTz3cB4 for ; Mon, 24 Oct 2022 08:12:44 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=FXNrxCWr; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=mit.edu (client-ip=18.9.28.11; helo=outgoing.mit.edu; envelope-from=tytso@mit.edu; receiver=) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=FXNrxCWr; dkim-atps=neutral X-Greylist: delayed 179 seconds by postgrey-1.36 at boromir; Mon, 24 Oct 2022 08:11:46 AEDT Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4MwW9G6cfCz2xGJ for ; Mon, 24 Oct 2022 08:11:45 +1100 (AEDT) Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 29NL7D2p025712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 23 Oct 2022 17:07:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1666559243; bh=zbENVyGNAon7zNh9ohkJFECSMTzXRXbcNrepMHxrEAM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=FXNrxCWraFmMAOW+vqR38ZOexAnGjiiR9A8LdOwTHYuoNMBlL77R2zP0ktOpr83lt VqRJZ2eM6bTmotP3IJ0ZjbLCm4EYxGWCpxZWFf6OGNB4ci103uHdfxC4WF6VQ2zTX/ sdIQ8AMmuFf2tnrWyiobYzmlMOkVIMT/l7Xfqoj9INuJk54r2BALT8VjDgqDT3Zhdd VJdERnwc5/7VlgvkT7OeoHx0mHgokAaWpeUY/UYmdBjcPk3IReiiQVTczMP0A0m8lc roc5e18VhoTm14PI9JdmJ03W1yO7BPKEnbbIuJ9deFvxdyuN3p81VawGcIo+Cv1H4t KETGAaOyQuEfg== Received: by cwcc.thunk.org (Postfix, from userid 15806) id BE8CB15C33A3; Sun, 23 Oct 2022 17:07:13 -0400 (EDT) Date: Sun, 23 Oct 2022 17:07:13 -0400 From: "Theodore Ts'o" To: Jakub Kicinski Subject: Re: [PATCH v1 0/5] convert tree to get_random_u32_{below,above,between}() Message-ID: References: <20221022014403.3881893-1-Jason@zx2c4.com> <20221021205522.6b56fd24@kernel.org> <20221021223242.05df0a5b@kernel.org> <20221021230322.00dd045c@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221021230322.00dd045c@kernel.org> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Jason A. Donenfeld" , "Darrick J . Wong" , linux-mips@vger.kernel.org, netdev@vger.kernel.org, Andreas Dilger , Herbert Xu , Richard Weinberger , Helge Deller , Russell King , Jason Gunthorpe , Catalin Marinas , linux-media@vger.kernel.org, Kees Cook , Heiko Carstens , Jani Nikula , linux-block@vger.kernel.org, SeongJae Park , loongarch@lists.linux.dev, Jaegeuk Kim , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Thomas Bogendoerfer , linux-parisc@vger.kernel.org, "Martin K . Petersen" , Greg Kroah-Hartman , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph =?iso-88 59-1?Q?B=F6hmwalder?= , linux-crypto@vger.kernel.org, Sakari Ailus , linux-fsdevel@vger.kernel.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Oct 21, 2022 at 11:03:22PM -0700, Jakub Kicinski wrote: > On Sat, 22 Oct 2022 07:47:06 +0200 Jason A. Donenfeld wrote: > > On Fri, Oct 21, 2022 at 10:32:42PM -0700, Jakub Kicinski wrote: > > > But whatever. I mean - hopefully there aren't any conflicts in the ~50 > > > networking files you touch. I just wish that people didn't pipe up with > > > the tree wide changes right after the merge window. Feels like the > > > worst possible timing. > > > > Oh, if the timing is what makes this especially worrisome, I have > > no qualms about rebasing much later, and reposting this series then. > > I'll do that. > > Cool, thanks! I promise to not be grumpy if you repost around rc6 :) One way of making things less painful for the stable branch and for the upstream branch is to *add* new helpers instead of playing replacement games like s/prandom_u32_max/get_random_u32_below/. This is what causes the patch conflict problems. One advantage of at least adding the new functions to the stable branches, even if we don't do the wholesale replacement, is that it makes it much less likely that a backported patch, which uses the new API, won't fail to compile --- and of course, the major headache case is one where it's not noticed at first because it didn't get picked up in people's test compiles until after the Linux x.y.z release has been pushed out. Whether it's worth doing the wholesale replacement is a different question, but separating "add the new functions with one or two use cases so the functions are actulaly _used_" from the "convert the world to use the new functions" from the "remove the old functions", might life easier. - Ted 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5ABAEC433FE for ; Sun, 23 Oct 2022 21:09:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Bn2e06H6NmAkaY/tAW8MfD5mXZbxUPVgr6LYdn55slo=; b=VLwN/u/Ztx3aex XG5bzj2TVgzpYD4tb6V3qm1Eo+QVfq+5BtggXVaLx1RE/0zrmDh4RqEQa2YWnaADBfu3BF5GtovKU 4/hHyqwZGsoSwRudIfhjfdI6UrlcxdLIVuobjVDghRik89n9hSPi1mNVSwqrRVqP67Z8G1ARlfjC6 4th6Z9F8fHMSkh5WBFkiSyQOTaD254U0ge5KbhYVjVMojZW+XuV9k/LVEZakzG6IkVJfNYxiO5z/t DNEZpPRtr42Glr4dtx8NhweiRz6bQ+m4FpTYzFffttuv6l7zuZf3TDZ+azFSQn0TwsWl2XrzZthFd 54EsKhfngPpLaAwYn3wQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1omiCu-00GHD4-Qv; Sun, 23 Oct 2022 21:08:32 +0000 Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1omiCr-00GHCc-C2 for linux-arm-kernel@lists.infradead.org; Sun, 23 Oct 2022 21:08:31 +0000 Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 29NL7D2p025712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 23 Oct 2022 17:07:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1666559243; bh=zbENVyGNAon7zNh9ohkJFECSMTzXRXbcNrepMHxrEAM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=FXNrxCWraFmMAOW+vqR38ZOexAnGjiiR9A8LdOwTHYuoNMBlL77R2zP0ktOpr83lt VqRJZ2eM6bTmotP3IJ0ZjbLCm4EYxGWCpxZWFf6OGNB4ci103uHdfxC4WF6VQ2zTX/ sdIQ8AMmuFf2tnrWyiobYzmlMOkVIMT/l7Xfqoj9INuJk54r2BALT8VjDgqDT3Zhdd VJdERnwc5/7VlgvkT7OeoHx0mHgokAaWpeUY/UYmdBjcPk3IReiiQVTczMP0A0m8lc roc5e18VhoTm14PI9JdmJ03W1yO7BPKEnbbIuJ9deFvxdyuN3p81VawGcIo+Cv1H4t KETGAaOyQuEfg== Received: by cwcc.thunk.org (Postfix, from userid 15806) id BE8CB15C33A3; Sun, 23 Oct 2022 17:07:13 -0400 (EDT) Date: Sun, 23 Oct 2022 17:07:13 -0400 From: "Theodore Ts'o" To: Jakub Kicinski Cc: "Jason A. Donenfeld" , linux-kernel@vger.kernel.org, Kees Cook , Greg Kroah-Hartman , Russell King , Catalin Marinas , Thomas Bogendoerfer , Heiko Carstens , Herbert Xu , Christoph =?iso-8859-1?Q?B=F6hmwalder?= , Jani Nikula , Jason Gunthorpe , Sakari Ailus , "Martin K . Petersen" , Andreas Dilger , Jaegeuk Kim , Richard Weinberger , "Darrick J . Wong" , SeongJae Park , Thomas Gleixner , Andrew Morton , Michael Ellerman , Helge Deller , netdev@vger.kernel.org, linux-crypto@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mmc@vger.kernel.org, linux-parisc@vger.kernel.org Subject: Re: [PATCH v1 0/5] convert tree to get_random_u32_{below,above,between}() Message-ID: References: <20221022014403.3881893-1-Jason@zx2c4.com> <20221021205522.6b56fd24@kernel.org> <20221021223242.05df0a5b@kernel.org> <20221021230322.00dd045c@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221021230322.00dd045c@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221023_140829_725605_A669BB34 X-CRM114-Status: GOOD ( 21.65 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 21, 2022 at 11:03:22PM -0700, Jakub Kicinski wrote: > On Sat, 22 Oct 2022 07:47:06 +0200 Jason A. Donenfeld wrote: > > On Fri, Oct 21, 2022 at 10:32:42PM -0700, Jakub Kicinski wrote: > > > But whatever. I mean - hopefully there aren't any conflicts in the ~50 > > > networking files you touch. I just wish that people didn't pipe up with > > > the tree wide changes right after the merge window. Feels like the > > > worst possible timing. > > > > Oh, if the timing is what makes this especially worrisome, I have > > no qualms about rebasing much later, and reposting this series then. > > I'll do that. > > Cool, thanks! I promise to not be grumpy if you repost around rc6 :) One way of making things less painful for the stable branch and for the upstream branch is to *add* new helpers instead of playing replacement games like s/prandom_u32_max/get_random_u32_below/. This is what causes the patch conflict problems. One advantage of at least adding the new functions to the stable branches, even if we don't do the wholesale replacement, is that it makes it much less likely that a backported patch, which uses the new API, won't fail to compile --- and of course, the major headache case is one where it's not noticed at first because it didn't get picked up in people's test compiles until after the Linux x.y.z release has been pushed out. Whether it's worth doing the wholesale replacement is a different question, but separating "add the new functions with one or two use cases so the functions are actulaly _used_" from the "convert the world to use the new functions" from the "remove the old functions", might life easier. - Ted _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel