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 BA499C02198 for ; Thu, 13 Feb 2025 03:20:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4050C6B008C; Wed, 12 Feb 2025 22:20:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B4646B0092; Wed, 12 Feb 2025 22:20:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25485280001; Wed, 12 Feb 2025 22:20:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 01A716B008C for ; Wed, 12 Feb 2025 22:20:37 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7754E160279 for ; Thu, 13 Feb 2025 03:20:37 +0000 (UTC) X-FDA: 83113468914.18.E6FDD9B Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf14.hostedemail.com (Postfix) with ESMTP id 8535810000A for ; Thu, 13 Feb 2025 03:20:35 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=de0A3Qf4; spf=pass (imf14.hostedemail.com: domain of chenhuacai@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739416835; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hdi41BXFPFn/TpmPu5pxQKELjJLXsW/evrJcz1Dfn1M=; b=m380jB4fs4gU7YMn7tQqzHMxhyi/J6hXWAB+jWBMiTqqMdvgA50FWeoDKHHy8I6QSi/ZVQ OiUQue0xl0wusbCGqHMNnUi/7ft2YbHf8p0+9fzhW4wYlpSKJSjF91xR5rnf3hYnyQ90Ly xvUVhsndxnxgW84M+W30X8kSUYZIVzE= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=de0A3Qf4; spf=pass (imf14.hostedemail.com: domain of chenhuacai@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739416835; a=rsa-sha256; cv=none; b=PipkBi7qdiV7EHUHw7ETSiOLTWHUFCItixU+YKrqEPaEPhiaYPfMmdu8X9opf1Ana77AE9 XlF0Pznusj1vUnktRgbyScw0Vj8P8dPlwKNZTqm5pXebeDL6062sQP+gIaNf+6zOU0C/RS ohUx04KdJVc4b4s/HN7tLnouq5MP/Ik= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 6E057A41D7E for ; Thu, 13 Feb 2025 03:18:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76238C4CEE7 for ; Thu, 13 Feb 2025 03:20:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739416834; bh=ZZtTGc97rYuezRwymIH2Hj30+2Ig+dElar5rFqwGxTY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=de0A3Qf4Xj1Q3wrFa/BONbIsxubNb1elroOVkQnysNxvvngC1gwLSAwNduq3fxEsO WJO3khkyOZmAG6oS6S6iBGQziE4y9RxfWaK7cKg0B0Rtno6Lbyvg2Zv1Y8zefVLoKV Rb+k4i+vdfKUA9nFFDp8yGJfMQMz6Ynjmj8tBUY+aIn0qRDAXAMsPi+7HsLkVP9GQf wtEiKMqv5JvNoy4wtx6KKXs4pHXagoHrUVLEbz7gth3Tr72Wa+2MfvRJS6rbBCSIY6 0yT7r7RpM8ZpgnR5tXWZzcmuE9ZwFgblME5vUs4v+fdsZCEDppkdVNpjsB8L6O+lIG Z1Sn7COePJGVg== Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-5de594e2555so591176a12.2 for ; Wed, 12 Feb 2025 19:20:34 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUNKyrNh14spBRqmhYMKcBeVbJojKaaIfEehZhJKZaPGD9MQkQkSstBGsl0oGfKyrHOYoY2HvyaOw==@kvack.org X-Gm-Message-State: AOJu0YzhYn8hxQRQCPykHSkziXHYZKMoUFlZWD8gNZDp+UwiMhNjkqee 3lrwQUNQFAX64RjZbrWtN/oHkszJdsZS5PMvrSyKOaUcwkx7YPvyltMWpI6HGfw/rISIgwkLkjL 4h7LtYUnlGTRSWS1DBWVOSPuBTdg= X-Google-Smtp-Source: AGHT+IFmDko2YyfGXLm5N7dpgFRel/cJF8hEyY4/JBVR8gKi9tylitcgLg0rIQPxEOtT+fAIMByFWZ5LtW5BhSRGpSI= X-Received: by 2002:a05:6402:4024:b0:5d0:efaf:fb73 with SMTP id 4fb4d7f45d1cf-5deaddc10acmr5634218a12.15.1739416832930; Wed, 12 Feb 2025 19:20:32 -0800 (PST) MIME-Version: 1.0 References: <20250212141648.599661-1-chenhuacai@loongson.cn> In-Reply-To: From: Huacai Chen Date: Thu, 13 Feb 2025 11:20:22 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AWEUYZkPCPR1x9EMHB3sgDzhdPaQ_MLs8QhmK6dDB4tI1CFXaY4nt5-W7kb1leg Message-ID: Subject: Re: [PATCH] mm/slab: Initialise random_kmalloc_seed after initcalls To: "Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com> Cc: Huacai Chen , Andrew Morton , linux-mm@kvack.org, "Rafael J . Wysocki" , Pavel Machek , linux-pm@vger.kernel.org, GONG Ruiqi , Xiu Jianfeng , stable@vger.kernel.org, Yuli Wang , Vlastimil Babka , Christoph Lameter , David Rientjes , Roman Gushchin , Pekka Enberg , Joonsoo Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 8535810000A X-Stat-Signature: i7utpkmxmdor6dpp8isruxm5sy8d7snw X-HE-Tag: 1739416835-340469 X-HE-Meta: U2FsdGVkX1+tvzT+eSYxDXub+YzaRrj9aV4Z4BejL8E+95+fXBzYhhMclegbgaksHXMYmRmhVoMIhh0tWXJlI21+mB44c2MC6TDzMfkzxtsCvJ0t4LhBAC9RdM35Q2d9X5dlG71OAywAI7rwmSuuwbp9TRNPHe8PiLq1Vpr0afQAPysnhnyQog7Opqcxw0DXCDZt9kYaz3YWomYnt7SILebM7dNHROI+NKnS98gGx4kFY6P2MtSo9Tydehk8VW2XEmJ5Nl2DpZdmfqEYmHPd0nGHytILjEnv85bAQLfp0lpNVpqHGa2azFwLudx35HDhQUmM/f8NBBzkliAaKoOmvX8XzCjioU9u4tJofihvWmRRbiaYT/2PUkqaCsWnt+holmeGuuUQyNaFjGNn/dnADXllehAPRdZAghCF3eeGA2kMNR97LMm1WnFOl5iPxRe8EW9rs3beB5I8BZeUAyyz5nYZTL5m8+IUgmIJl11IZTJju/1XQftV9FNLfFTJBhJmIJhefO//Xp458Ha2BSYRxpNCPCKMQ/wHkuYwUhMYlw0i2P7BMdyoM0nE3RlJJSFSm/Cd3+3bbTetiAcHHmCl+O4yeg6105y+2t+TNVg1IPhWD5naB22+/hZXlVD9ZjeDtvtdkHOXZmywpEReWSq/K+9lrFr32wj1U0a46Mi69Dh9T8yJ8fE/VdHJCw2E/VicbD8v4HqsZO8fd4G2/87hgvsl3feixSG7zYOtKxc+b61LHpEl22ettW0KRmCfB+3Y52Fk8yhDDEzrI5RleyhTSgmgW4F0Ev5IjyGG4FUaIWVFpwqNBHcs7vMMWgEGQg9gw9Ojp8lOnNnS40ALKSh7upPQI6hXH5wVDbOzHR+Ef+7UL5r4V6Tyj8h2BVRKMLLG0ZECCG3s6IGJKCGzbQObyNXpl/Sd8nQF+H83CpDtOPJBP5HwnErL5rApXRZA8u21IqPJcgO6nt7qSMdEeOG a6AbhJar bGKVgl3z/F6oopFBW+21aYpZclkM+UJ+DwYMVe54M9DEBfUtNxa0BlS0NyA9vOVJc0DcWR8GSK6z4CQ2Pbad0A9JbGwSnjH+VfNzVaBhpOJ32agIE+Mn2EQG3qkM9w+P0zR7haUPji9OEeA98m3cqxm0z1+cWgP4j24IiVO1ORZT5uo+KtV0prdGNd2+9aVspBh/4np7+YJch0vV6dABU7HYp0n4KglYJ8MCovOaTDwaKjCcBvSpy4mubae5LAYNn7PbmGX1LOph8E22reSn5KSe2uErREhSEKnPXClOQbnJqHOzPdAB4FaofuszgpEaUuR1oFbDQeFWXjrOVrzWwSJEHPJ2KQxOK3BRjZCkFH6bv6BLLFnfOZTfUA51sUTXRujJyazldYuG/OW3gap8cKpgxCCJyqQvrQxTnKvdQOoBPMOJ2jX9oRoX81TIHx0FQbGCU2kMoMVQOsxfT2kG+SwvYaQfGnxSdx4RssEimduLkRYoHq304yQz8a9CGJTKwV5IK 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: List-Subscribe: List-Unsubscribe: Hi, Harry, On Wed, Feb 12, 2025 at 11:39=E2=80=AFPM Harry (Hyeonggon) Yoo <42.hyeyoo@gmail.com> wrote: > > On Wed, Feb 12, 2025 at 11:17=E2=80=AFPM Huacai Chen wrote: > > > > Hibernation assumes the memory layout after resume be the same as that > > before sleep, but CONFIG_RANDOM_KMALLOC_CACHES breaks this assumption. > > [Let's also Cc SLAB ALLOCATOR folks in MAINTAINERS file] > > Could you please elaborate what do you mean by > hibernation assumes 'the memory layout' after resume be the same as that > before sleep? > > I don't understand how updating random_kmalloc_seed breaks resuming from > hibernation. Changing random_kmalloc_seed affects which kmalloc caches > newly allocated objects are from, but it should not affect the objects th= at are > already allocated (before hibernation). When resuming, the booting kernel should switch to the target kernel, if the address of switch code (from the booting kernel) is the effective data of the target kernel, then the switch code may be overwritten. For LoongArch there is an additional problem: the regular kernel function uses absolute address to call exception handlers, this means the code calls to exception handlers should at the same address for booting kernel and target kernel. > > > At least on LoongArch and ARM64 we observed failures of resuming from > > hibernation (on LoongArch non-boot CPUs fail to bringup, on ARM64 some > > devices are unusable). > > Did you have any chance to reproduce it on x86_64? I haven't reproduce on x86_64, but I have heard that x86_32 has problems. > > > software_resume_initcall(), the function which resume the target kernel > > is a initcall function. So, move the random_kmalloc_seed initialisation > > after all initcalls. > > > > Cc: stable@vger.kernel.org > > Fixes: 3c6152940584290668 ("Randomized slab caches for kmalloc()") > > Reported-by: Yuli Wang > > Signed-off-by: Huacai Chen > > --- > > > > init/main.c | 3 +++ > > mm/slab_common.c | 3 --- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/init/main.c b/init/main.c > > index 2a1757826397..1362957bdbe4 100644 > > --- a/init/main.c > > +++ b/init/main.c > > @@ -1458,6 +1458,9 @@ static int __ref kernel_init(void *unused) > > /* need to finish all async __init code before freeing the memo= ry */ > > async_synchronize_full(); > > > > +#ifdef CONFIG_RANDOM_KMALLOC_CACHES > > + random_kmalloc_seed =3D get_random_u64(); > > +#endif > > It doesn=E2=80=99t seem appropriate to put slab code in kernel_init. > > Additionally, it introduces a dependency that the code must be executed > after all late_initcalls, which sounds like introducing yet another > type of initcall. What about introducing a function to initialize kmalloc seed in slab_common.c, and then call it at kernel_init()? I don't have a better solution than this. > > > system_state =3D SYSTEM_FREEING_INITMEM; > > kprobe_free_init_mem(); > > ftrace_free_init_mem(); > > diff --git a/mm/slab_common.c b/mm/slab_common.c > > index 4030907b6b7d..23e324aee218 100644 > > --- a/mm/slab_common.c > > +++ b/mm/slab_common.c > > @@ -971,9 +971,6 @@ void __init create_kmalloc_caches(void) > > for (i =3D KMALLOC_SHIFT_LOW; i <=3D KMALLOC_SHIFT_HIGH= ; i++) > > new_kmalloc_cache(i, type); > > } > > -#ifdef CONFIG_RANDOM_KMALLOC_CACHES > > - random_kmalloc_seed =3D get_random_u64(); > > -#endif > > I have no idea how hibernation and resume work, but let me ask here: > Can we simply skip or defer updating random_kmalloc_seed when the system = is > resuming from hibernation? (probably system_state represents this?) Do you mean something like below? It does work (it is my original solution), but this patch is simpler. diff --git a/include/linux/slab.h b/include/linux/slab.h index b35e2db7eb0e..42fb91650b13 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -614,14 +614,20 @@ static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags, unsigne * The most common case is KMALLOC_NORMAL, so test for it * with a single branch for all the relevant flags. */ - if (likely((flags & KMALLOC_NOT_NORMAL_BITS) =3D=3D 0)) + if (likely((flags & KMALLOC_NOT_NORMAL_BITS) =3D=3D 0)) { #ifdef CONFIG_RANDOM_KMALLOC_CACHES + unsigned long random_seed =3D 0; + + if (system_state > SYSTEM_SCHEDULING) + random_seed =3D random_kmalloc_seed; + /* RANDOM_KMALLOC_CACHES_NR (=3D15) copies + the KMALLOC_NO= RMAL */ - return KMALLOC_RANDOM_START + hash_64(caller ^ random_kmalloc_seed, + return KMALLOC_RANDOM_START + hash_64(caller ^ random_seed, ilog2(RANDOM_KMALLOC_CACHES_NR + 1)); #else return KMALLOC_NORMAL; #endif + } Huacai > > > /* Kmalloc array is now usable */ > > slab_state =3D UP; > > -- > Harry