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 8266AC433EF for ; Wed, 26 Jan 2022 21:36:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B08E36B0071; Wed, 26 Jan 2022 16:36:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AB8546B0072; Wed, 26 Jan 2022 16:36:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A66C6B0073; Wed, 26 Jan 2022 16:36:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 8B93A6B0071 for ; Wed, 26 Jan 2022 16:36:26 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 376ED8249980 for ; Wed, 26 Jan 2022 21:36:26 +0000 (UTC) X-FDA: 79073747172.25.BF7F821 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id C012840004 for ; Wed, 26 Jan 2022 21:36:25 +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 9659561926; Wed, 26 Jan 2022 21:36:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1F23C340E8; Wed, 26 Jan 2022 21:36:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643232984; bh=qiDwOHAZZYgzMESTLY09sncGjaRqe3P7WUyD63U80QA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=F5N5X4tFYnAPtsQXZdHMR/zZCc9G6WRuaXBfK+Ty5IM/QMwMOdyliX4LBQzikYCRA EbxPUMzlBLq5kxn2Lp0cw6skBSXxq8XEgVuf6+lujnGG1XDj3L51N6//5M6Y3QrjOh Qjjsvo6HAyuhIFv50e2OCI+NPAASzuQaMml82XCScDEM2tNfWJ8JjwQ0gEcih7/MNY JNESyI5BmHohYobkVSEHNReqMQ9KBlDKprBjI8o+gcDWHjkFEduTZaWXpcnWDLvcXp mXoALrN0E1bm7oyRxjSzeBe/lgpnyZM+LvvX9slVLLDeANjKEhkqhZJe9x6IunDd7F UbXGnOxc8kq6g== Date: Wed, 26 Jan 2022 23:36:13 +0200 From: Mike Rapoport To: Christophe Leroy Cc: Luis Chamberlain , Jessica Yu , "linux-kernel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "kgdb-bugreport@lists.sourceforge.net" , "linux-mm@kvack.org" , "linux-arch@vger.kernel.org" Subject: Re: [PATCH 1/7] modules: Refactor within_module_core() and within_module_init() Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: nil X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C012840004 X-Stat-Signature: x6zbzf7rtk3czaqn3do5x5f13e1ykctm Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=F5N5X4tF; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org X-HE-Tag: 1643232985-154053 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 Mon, Jan 24, 2022 at 09:22:15AM +0000, Christophe Leroy wrote: > within_module_core() and within_module_init() are doing the exact same > test, one on core_layout, the second on init_layout. > > In preparation of increasing the complexity of that verification, > refactor it into a single function called within_module_layout(). > > Signed-off-by: Christophe Leroy > --- > include/linux/module.h | 17 +++++++++++++---- > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/include/linux/module.h b/include/linux/module.h > index c9f1200b2312..33b4db8f5ca5 100644 > --- a/include/linux/module.h > +++ b/include/linux/module.h > @@ -565,18 +565,27 @@ bool __is_module_percpu_address(unsigned long addr, unsigned long *can_addr); > bool is_module_percpu_address(unsigned long addr); > bool is_module_text_address(unsigned long addr); > > +static inline bool within_range(unsigned long addr, void *base, unsigned int size) > +{ > + return addr >= (unsigned long)base && addr < (unsigned long)base + size; > +} There's also 'within' at least in arch/x86/mm/pat/set_memory.c and surely tons of open-coded "address within" code. Should it live in, say, include/linux/range.h? > + > +static inline bool within_module_layout(unsigned long addr, > + const struct module_layout *layout) > +{ > + return within_range(addr, layout->base, layout->size); > +} > + > static inline bool within_module_core(unsigned long addr, > const struct module *mod) > { > - return (unsigned long)mod->core_layout.base <= addr && > - addr < (unsigned long)mod->core_layout.base + mod->core_layout.size; > + return within_module_layout(addr, &mod->core_layout); > } > > static inline bool within_module_init(unsigned long addr, > const struct module *mod) > { > - return (unsigned long)mod->init_layout.base <= addr && > - addr < (unsigned long)mod->init_layout.base + mod->init_layout.size; > + return within_module_layout(addr, &mod->init_layout); > } > > static inline bool within_module(unsigned long addr, const struct module *mod) > -- > 2.33.1 > -- Sincerely yours, Mike.