From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F36F32F0661 for ; Thu, 16 Jul 2026 15:04:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784214276; cv=none; b=kS9eQWCvlUUTbhDNtx+MMrgpXV+i4z6QKwbxZpqSWs7lbiNAxDkZhAMqtDjLgQlYL5KrISYEYfdMxpS4mrzs+Zbw1mraO8/lac6CrMdW5FodbeU5O76hP5TtGR852MMyFMUYIG6o1pYxjOtVrZ8At2/s/dznYaUxLGplvFdut5g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784214276; c=relaxed/simple; bh=zsvG/ZYVz07QC00s2kxY7FoYlwh29MstrP+Y9pGuqsg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tntSKZ6g+HBwQp+clhOLGaC0I5i+jE36FsbRpOJ93b/IeXWXttISqN7o8Us9zZt+ocnQMHnAxGSxhFN70961L6OA/P2l2cllXthsgT69aBWS/Tne/pqHh0y6qQnRRz3VXLIYl+NXCxKowSPnp0h7JwzE4gpwhTFJnZeGFZ4Ukgs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com; spf=pass smtp.mailfrom=soleen.com; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b=VNhSUY+o; arc=none smtp.client-ip=209.85.128.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=soleen.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b="VNhSUY+o" Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-81e6f0b4610so71564007b3.2 for ; Thu, 16 Jul 2026 08:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1784214274; x=1784819074; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=ESEHmQjCMBnGaENVOX4xB1tescWaluk9TL1CPIBeov4=; b=VNhSUY+oNT1VZXVA678t6hCgCcBsF9PHWOzrdGxP3PRoF3Igmty1Jujleq4SOQnKsf WXYinHisGvb6GfOKU3b8QPNap8TdVocdBvsb7LPdggI39ojY3yX+tQQdxRIVtgPqRrep it9fxtZvewhzXQ1NqtPqKBdrdIzCVytKbFls8TzXtK/XKu9LH1blfTW7OCyeezFXs72A HoYzkpKASZjjzS/h3g4ttrclQiNKsJZ7bZ8DY3pLfPblzAZ5R5Llm7rILZej4dtqPICp hMkKDNbIjsJKUc0cgfsxRVoLP89Psk/C98AXjFd1TJXoCd1GbzXXlO4RFudohlfg7cuT oF0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784214274; x=1784819074; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ESEHmQjCMBnGaENVOX4xB1tescWaluk9TL1CPIBeov4=; b=qP+K4TfyT+5VscwPSn9Kn/ykp9k5XZHf8GxE1Dkbk+xslJs+c8rToKl8Qeq/9De7Jr EQFve2M4dKT8tZTmXKTMY09DhVLZpPHLzrE1Uz/k3Q10y/wqL917z7Wc3NMyFYuE2ETI gOAKA/9WYuxHT+f3TXHXEUH3afi57mZsIR0Hjs3uoYeq6y/GEc4Js4OR2Y2F1lMGoDkR wj7vAMjApRNruxK3HnrCgb7Js56sx3MP4NBUrSJJb3pZ+mjPGeL3Z3CCIYM6CCzIN06o nw1fZzhszKw/ylaGZsrF4BFd3lAxF9qS4Svrbmupd7DL0S0V8L5zqDfv2+KtiU0o9vQo QwvA== X-Forwarded-Encrypted: i=1; AHgh+Roxs6SzwxAtLKmIA0SA41av3ahS0dHr9qaxeVeBb6FqCoW1RM6mpQS6uAe9XuUAgkwNs6BKqxNX8xkwkF8=@vger.kernel.org X-Gm-Message-State: AOJu0YzANfH98Hodp1/bJh0HLtLu6baQewmRK9R9i5SLAddMNbF3kbtD qASobBL5Vg/avz4/hjQTx6rN+Oe7C47QF9rbWKPMAMxYJedkIhnne5DjP0gPGO7LmUg= X-Gm-Gg: AfdE7cn6ricVFXPD1GnfgAsafXUTHE4vkSfzfuv2kojcV6sNd4Zgw9OAQ2Veq55xfdX ssGz9gWVqGhqgFisRX36qxKFeggzCMra2G46XLn1pKlj7PAMdLKrHCpQnK/YlqIVbEvCNCC8wtB P47RSb1gvMy56CyM34tufcnrCB4tppARB/hFb29H2HxpMwltrMCAlemhQsdXakokXlrULelkjzy PpoXIrUH6CBZrQ+RfVXL7Ger7MxG5s4KGE95GhmK7J70mXIFmQVN0wJQpbEMNNVRO+zdlSuOsVD XhnPqa1Gd37d1Jt9au4Prj8z5RNwBswibPqsO7xS62uxLTjkGAgjZkbyqh6Obdexay2b37zTKMy qdfZOAzmjnuwN8KRcBqcoqY9H8Lg0pNb7EBz7XDU7aJOn3XJ3TbWSFAQpfdjgfoFG7cGraeDlaC PurXfjt1cRamvx1IOauN0iZ/gUVYIKev3nDmFL68Dz0qBEWZjEGOVv2+q8bxIsvJ4YNPS/mdpq4 N0I8YRyIylB X-Received: by 2002:a05:690c:22c9:b0:7f8:7e50:6390 with SMTP id 00721157ae682-81ebb28d493mr96938907b3.50.1784214273078; Thu, 16 Jul 2026 08:04:33 -0700 (PDT) Received: from google.com (138.200.150.34.bc.googleusercontent.com. [34.150.200.138]) by smtp.gmail.com with ESMTPSA id 00721157ae682-81e6c23d1afsm198963407b3.47.2026.07.16.08.04.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jul 2026 08:04:32 -0700 (PDT) Date: Thu, 16 Jul 2026 11:04:31 -0400 From: Pasha Tatashin To: Mike Rapoport Cc: Michal Clapinski , Pasha Tatashin , Pratyush Yadav , Alexander Graf , Evangelos Petrongonas , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] kho: align kho_scratch to MAX_ORDER_NR_PAGES pages Message-ID: References: <20260714205111.2497151-1-mclapinski@google.com> <178409777790.255896.16691338963510282908.b4-review@b4> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <178409777790.255896.16691338963510282908.b4-review@b4> On 07-15 09:42, Mike Rapoport wrote: > Hi Michal, > > > I caught this crash: > > BUG: unable to handle page fault for address: ff19164fffff8328 > > RIP: 0010:__free_one_page+0x1a1/0x6b0 > > Call Trace: > > > > [] free_one_page+0xaf/0x240 > > [] deferred_free_pages+0xa8/0xd0 > > [] deferred_init_memmap_chunk+0x10f/0x1b0 > > [] padata_mt_helper+0x65/0xa0 > > [] process_scheduled_works+0x202/0x410 > > [] worker_thread+0x1f9/0x2d0 > > [] kthread+0x27d/0x2f0 > > [] ? __pfx_worker_thread+0x10/0x10 > > [] ? __pfx_kthread+0x10/0x10 > > [] ret_from_fork+0x145/0x280 > > [] ? __pfx_kthread+0x10/0x10 > > [] ret_from_fork_asm+0x1a/0x30 > > > > > > deferred_init_memmap_chunk() works fine without KHO because free > > regions will never be neighbors. However, with KHO, free memory > > will be split into (free && scratch) and (free && !scratch). > > KHO scratch is aligned to CMA_MIN_ALIGNMENT_BYTES (which on my setup > > is equal to 1 << 9 pages) but buddy can look at the neighborhood of > > MAX_ORDER_NR_PAGES pages (which is equal to 1 << 10 pages). > > This sometimes crashes when one half of the neighborhood is being > > initialized but the other part is yet to be initialized. > > > > To fix this, let's just align KHO scratch to MAX_ORDER_NR_PAGES pages. > > > > Fixes: c6073743d0c7 ("kho: make preserved pages compatible with deferred struct page init") > > Signed-off-by: Michal Clapinski > > > > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c > > index 4834a809985ab..50928aaa33710 100644 > > --- a/kernel/liveupdate/kexec_handover.c > > +++ b/kernel/liveupdate/kexec_handover.c > > @@ -38,6 +38,16 @@ > > #include "../kexec_internal.h" > > #include "kexec_handover_internal.h" > > > > +/* > > + * This is the minimal alignment required by deferred struct page init. > > + * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks > > + * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them. > > + * If KHO scratch is not aligned to that value, buddy can access uninitialized > > + * struct pages, which can cause a crash. > > + */ > > +#define SCRATCH_ALIGNMENT_BYTES (1 << (PAGE_SHIFT + MAX_PAGE_ORDER)) > > +static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES); > > Maybe make it a variable and set it at runtime? > We won't need to worry about different confugurations that override > MAX_ORDER and potentail divergence of pageblock size from MAX_ORDER in Do those architectures reduce MAX_ORDER when they override it? I would hope we could set the alignment once and make it large enough to work everywhere, rather than depending on dynamic changes even during boot... > the future. > > -- > Sincerely yours, > Mike. >