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 05DC7C433FE for ; Mon, 16 May 2022 22:07:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 431066B0072; Mon, 16 May 2022 18:07:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DF9E6B0073; Mon, 16 May 2022 18:07:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A6646B0074; Mon, 16 May 2022 18:07:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1AB976B0072 for ; Mon, 16 May 2022 18:07:21 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E1E6934271 for ; Mon, 16 May 2022 22:07:20 +0000 (UTC) X-FDA: 79472993040.06.AA00792 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id 44CEF1C00B8 for ; Mon, 16 May 2022 22:07:07 +0000 (UTC) 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 54E7F61592; Mon, 16 May 2022 22:07:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28715C385AA; Mon, 16 May 2022 22:07:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1652738836; 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: in-reply-to:in-reply-to:references:references; bh=2Ij941pgPSObJ5yDgX33gwExzpgdb5NtjJSN0FhK17c=; b=cA35lvvlF3dISnP3mUllrkBDgKy5JwiEdHbog5pwo+PVtnyBS/fXelK4hUcGelK0UT3Ctb 5KrusRDCZNg+HYaNfJK/RabxRq8TnAxZXfp9gyDygP1RroRX/gajzHDMsHLFsDPpZTG4mA MVUZ1ZJdMWZLb1Y+vSUvBWU1xVo5OLY= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id d65a96fc (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Mon, 16 May 2022 22:07:15 +0000 (UTC) Date: Tue, 17 May 2022 00:07:12 +0200 From: "Jason A. Donenfeld" To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Theodore Ts'o Subject: Re: [PATCH] random: move randomize_page() into mm where it belongs Message-ID: References: <20220514120556.363559-1-Jason@zx2c4.com> <20220516142800.4730a41ec1498d5e3d7863c0@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220516142800.4730a41ec1498d5e3d7863c0@linux-foundation.org> X-Stat-Signature: hkzeo37kxerym7uarhz6fw59ty77dozk Authentication-Results: imf18.hostedemail.com; dkim=fail ("body hash did not verify") header.d=zx2c4.com header.s=20210105 header.b=cA35lvvl; spf=pass (imf18.hostedemail.com: domain of "SRS0=FKqB=VY=zx2c4.com=Jason@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=FKqB=VY=zx2c4.com=Jason@kernel.org"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=zx2c4.com (policy=none) X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 44CEF1C00B8 X-HE-Tag: 1652738827-203250 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: Hi Andrew, On Mon, May 16, 2022 at 02:28:00PM -0700, Andrew Morton wrote: > On Sat, 14 May 2022 14:05:56 +0200 "Jason A. Donenfeld" wrote: > > > randomize_page is an mm function. It is documented like one. It contains > > the history of one. It has the naming convention of one. It looks > > just like another very similar function in mm, randomize_stack_top(). > > And it has always been maintained and updated by mm people. There is no > > need for it to be in random.c. In the "which shape does not look like > > the other ones" test, pointing to randomize_page() is correct. > > > > So move randomize_page() into mm/util.c, right next to the similar > > randomize_stack_top() function. > > > > This commit contains no actual code changes. > > hm, does it make sense? > > Probably randomize_page() (which used to be called randomize_range()) > should have been called randomize_address(). Is it an MM function > then? Not really - it's simply an application of the random number > generator. So I think it's more a random thing than an MM thing. There are many uses of randomness in the Linux kernel. Your use in mm is not a special snowflake usage. You want good random integers with various crypto properties? No problem, you got it. But what you do with those is your own business. (I'm just a random number dealer.) The particulars of addresses or page aligned addresses or whatever weird properties you need out of this thing is your own mm puzzle. It has no business hanging out here. And as evidence of this, randomize_stack_ top() is also in mm/util.c where it belongs and where the various things it does can be maintained by people who know a thing or two about mm. Just imagine all the different types of domain-specific objects that we could randomize according to certain rules, and how insane it would be if those all wound up in random.c. So with all due respect, I must disagree with you. > > --- a/mm/util.c > > +++ b/mm/util.c > > @@ -343,6 +343,38 @@ unsigned long randomize_stack_top(unsigned long stack_top) > > #endif > > } > > > > +/** > > + * randomize_page - Generate a random, page aligned address > > The patch assumes that drivers/char/random.o is always built into > vmlinux, which appears to be the case. If some space-conscious person > goes and makes random.o build-time optional then they'll need to make > the appropriate adjustments in util.c. I see no problems with this. random.o has random_init() that is called by main.o, so just for that reason alone, it's un-=m-able. Plus the zillion call sites everywhere in the kernel. It'll always be a builtin (and rightly so too, I think). Jason >