From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCEDD26D4E5 for ; Thu, 16 Apr 2026 16:40:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776357643; cv=none; b=GsGERqCe1Z1ADOmEwqz6D+yVZct2QhVBnDK090cpgPfA2c3XaT8qtlfkBhPHIFfm61Q8ZyQWyh+rbtoBI8SnMDhDJPd4FWblNnDA/ngDNJf0rIYA5WXCTFYrg69K8uQDAHEUGrsfxh0VN7KXt00dKe8MhbtUSJ357rfJkJBLwpk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776357643; c=relaxed/simple; bh=lCGmJ3F+1zjEehNS6SOPtlYDsWuMjRcxlWpNpztwY20=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=lnGP7slh9w/VYjmp0/YZ82oeIk5HQaTPv9ZxRgedm1gSICXh+7/i2HJq5wKBjRHj3EppQlAml5fmszz2Ext+e7aXvdi3sglTwIN+sB0IYdTAgUbTfJTuWtLv92gj9hlirwxX3mt0NZuwo6IBcypxQc5CXRV9yY5qoRxmw5Wd73s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bX6Niq2f; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bX6Niq2f" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4E96C2BCAF; Thu, 16 Apr 2026 16:40:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776357643; bh=lCGmJ3F+1zjEehNS6SOPtlYDsWuMjRcxlWpNpztwY20=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bX6Niq2fCvU2FntF15yZDWJ/6kd2Cd766Rcq3gRZajZ7zH3dwUYzJXmr3v8Ej0VpI Y+ZtIqhAupEVlrXQmQ8VS3DghuyFB5ZRtY0zXOhvSgnMw97KPaucJzr4KinUEczUZt vbwJSi8fzOpDoIxZJa5Skk/0FyALPGDeCO96pXFXimupZpphGc0JKQEtmSQ/bi3c3V 7kEbSX0DJbwviS1cRP2J1VRrqS2AdpcLykzDmygRjkuduwfIPwBPhsAnu2Jf+JO97C QPFjR8EZgaVOY4z2jDxxSJMLj/PyyrwZLTSwAQS55NRu/jGwNQ+TDD1mCHqRNGdOFf Rh+gML+PhNJ0Q== From: Pratyush Yadav To: Evangelos Petrongonas Cc: Pratyush Yadav , "Mike Rapoport (Microsoft)" , Alexander Graf , Pasha Tatashin , Rob Herring , Saravana Kannan , Changyuan Lyu , Andrew Morton , , , , Subject: Re: [PATCH v2] kho: skip KHO for crash kernel In-Reply-To: <20260416161744.GA65710@dev-dsk-epetron-1c-1d4d9719.eu-west-1.amazon.com> (Evangelos Petrongonas's message of "Thu, 16 Apr 2026 16:17:44 +0000") References: <20260410011609.1103-1-epetron@amazon.de> <2vxztstf7ys7.fsf@kernel.org> <20260416161744.GA65710@dev-dsk-epetron-1c-1d4d9719.eu-west-1.amazon.com> Date: Thu, 16 Apr 2026 16:40:39 +0000 Message-ID: <2vxz8qam7ta0.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Thu, Apr 16 2026, Evangelos Petrongonas wrote: > On Mon, Apr 13, 2026 at 01:52:40PM +0000 Pratyush Yadav wrote: >> Hi Evangelos, >> >> On Fri, Apr 10 2026, Evangelos Petrongonas wrote: [...] >> > Note regarding backporting >> > The offending commit was deployed with 6.19. The only other supported >> > kernel version with 6.18, unless I miss someting uses >> > ``` >> > if (!kho_out.finalized) >> > ``` >> > which in the case of crash kernel it shouldn't be finalised. >> >> While normally you should load the crash kernel early in boot and at >> that point KHO should not be finalized, I don't see anything that >> prevents crash kernel from being loaded after finalize. In which case, >> you can trigger this bug before d7255959b69a ("kho: allow kexec load >> before KHO finalization") as well. Also, before f322a97aeb2a ("kho: only >> fill kimage if KHO is finalized") (landed in v6.18) kho_fill_kimage() >> was also guarded by if (!kho_enable). So you'd hit this bug in all >> kernels before that point in the very same way as today. >> >> So should we update Fixes to 3bdecc3c93f9 ("kexec: add KHO support to >> kexec file loads") and Cc stable? >> > But in this case it seems a userspace misuse if it finalizes kho for > crash kernel. Whereas with the current state we hit the bug with a sane > userspace. Yeap we would hit that in earlier kernel than 6.18, but none > with KHO is supported is it? > > I don't have strong objection for backporting it to 6.18, but it feels > unnecessary. Fair enough. Let's leave it as it is then. [...] -- Regards, Pratyush Yadav