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 4B74FECAAA1 for ; Mon, 12 Sep 2022 12:14:36 +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=etOw/k7jIBYCbD6aKKRBHqrtSgkjLZSHBgzfSXzVgK4=; b=AXLG21tBf7qQNl gdg4blUso6AoUEC1EsnLOvCQ0zdpzVlziG7K64WMmxXLYSc0wmfMJb5GU6P47tiZi5LTxY3WZLfLa P/jahd/O+OCQqp6sfcs3cKakkvzGnI0+Qz8/Jaomo2H+CA171XuJdWrpnK+eJ0LAkymfmHcYZa2Dw vhj6987+E7vSCA9lzpp3aAGFnE66bdRLwVAvDZ4pgx3Mj+El7xpMtFNLWWxKV2c7CWNOlU4NbZjaL WgAcEWLMq7zFfNSdh3fGEehLuUoIJBmh0JzbcsaDSWU5vFPpUVpMOzFCr4BBf4z2G6wPXogv+QrKa geTwmNvUr5sLbeFWuU/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oXiJZ-009eA2-7a; Mon, 12 Sep 2022 12:13:25 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oXiJV-009e6o-1q for linux-arm-kernel@lists.infradead.org; Mon, 12 Sep 2022 12:13:23 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A36BF113E; Mon, 12 Sep 2022 05:13:23 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 332433F71A; Mon, 12 Sep 2022 05:13:16 -0700 (PDT) Date: Mon, 12 Sep 2022 13:13:02 +0100 From: Mark Rutland To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, james.morse@arm.com, joey.gouly@arm.com, maz@kernel.org, will@kernel.org Subject: Re: [PATCH 5/9] arm64: alternatives: make alt_region const Message-ID: References: <20220901151403.1735836-1-mark.rutland@arm.com> <20220901151403.1735836-6-mark.rutland@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220912_051322_077912_69082F37 X-CRM114-Status: GOOD ( 26.12 ) 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 Mon, Sep 12, 2022 at 11:13:12AM +0100, Ard Biesheuvel wrote: > On Mon, 12 Sept 2022 at 10:32, Mark Rutland wrote: > > > > On Tue, Sep 06, 2022 at 05:18:54PM +0200, Ard Biesheuvel wrote: > > > Hi Mark, > > > > > > On Thu, 1 Sept 2022 at 17:14, Mark Rutland wrote: > > > > > > > > We never alter a struct alt_region after creation, and we open-code the > > > > bounds of the kernel alternatives region in two functions. > > > > > > > > This patch adds a shared struct alt_region, and marks the alt regions as > > > > const to prevent unintentional modification. > > > > > > > > > > What is the point of struct alt_region? Can we just get rid of it > > > entirely? It seems its only purpose is to carry a tuple > > > that could easily be converted into start and end arguments to > > > __apply_alternatives(). > > > > We could right now, but I'm intending to fix some noinstr issues (and make > > debugging easier) by splitting the alternatives sanity-checking & patching into > > distinct initcalls (alnog with some extra debug), and having the structure for > > the common definition is quite nice to avoid open-coding the start and end > > value in a bunch of places. > > > > So I'd prefer to keep it for now, but I can follow up and delete it if the > > above doesn't turn out to need it, if that's ok? > > > > Yeah, that's fine. The above wasn't really clear to me from the > context you provided. True; I'll add a note to the commit message. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel