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 867A5C021A4 for ; Wed, 12 Feb 2025 15:39:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E87476B0085; Wed, 12 Feb 2025 10:39:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E37E76B0088; Wed, 12 Feb 2025 10:39:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFF126B0089; Wed, 12 Feb 2025 10:39:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B22486B0085 for ; Wed, 12 Feb 2025 10:39:42 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 408B381F9B for ; Wed, 12 Feb 2025 15:39:42 +0000 (UTC) X-FDA: 83111702604.26.B34DCD4 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf24.hostedemail.com (Postfix) with ESMTP id 3A353180016 for ; Wed, 12 Feb 2025 15:39:39 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hvWtgxBl; spf=pass (imf24.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739374780; a=rsa-sha256; cv=none; b=IWySexpwAsqZKKsZaw8Nm9xm4WE4mOZ4vL7EGipYlGi08sBuHFMH+NYZKkra0Q1NeaPK8R VMFStPI7bvWaYfnxCh+Q0QR3yXIxVtgX5sf3+Xmn6cmaKT6pjVVDrariz1G/9eZGAQhfnx 49xGIqh2hoEnmf+Y+t9CKNLA81MOACk= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hvWtgxBl; spf=pass (imf24.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739374780; 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=c+FbtZAlFDnWNkZYt7dUHBqnCrrT1pQsY7dvJuBAfwg=; b=GUWP6uKfDNgWyraR/sXvxwRVwpBnsHdN2uKSo6n6uHkkt1oBkD1w/88rBR1kGoq8ILAreO 7i4qQpI4Y4WvAIeNxlLu9RMP4euxiW6OlAEXvwHo4SfN5vuX6nAcI/rzHDRxpaqRk1dvWe sUV6gSZT/XyeZ3EyjRxM7Z3XOh+IE+s= Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-30615661f98so73925551fa.2 for ; Wed, 12 Feb 2025 07:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739374778; x=1739979578; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=c+FbtZAlFDnWNkZYt7dUHBqnCrrT1pQsY7dvJuBAfwg=; b=hvWtgxBlPAbbDRszrq15kFTG19hmHVJMyHpPbTDr2/2gE8O4asEX7HmItWW4AyVavh 5e6lMLsemS1SFITR+IoOySrvptnJY4WWRmm1BYua5JL5KYo+UVvZ4YNLUA8+M4ykQEBq tRRFuQbgrz3WXXn8AdKV4k7499QF1cBQqZw2LL8Z1AHoEm4TvZDpmzcfWfiF4IoGfCuc VX3lHtZh4EPYvyVrAPHNL/mQ1RRtak4FJvPKKRk1+je70iMLGlKiytUmiTJtWJEZK8YC dn8B1daHVUzaf0vIEwbR/DkZqM527eJpWpKXituoXVzcM02q69AqCSfxYi6Hin5XyBlE /LCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739374778; x=1739979578; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=c+FbtZAlFDnWNkZYt7dUHBqnCrrT1pQsY7dvJuBAfwg=; b=CoriNVkGAfH+fU1VodXtjmlE++8x0cm8ELrTNXsT8rVfvEwTq4LPx84+bH5idFvNb3 EJBl41LvQkoYbc8eVMytgEdbBE/rIoXlj2Iaf5R9AS7bHaC6Nd2fqBP256U+anVly3j1 ykozgP5kzjUz+szgKLO41Mq98WiT2bpVBGC0BKUvwYD9LlWKarnWrG7D858t2u4gt389 h/4+u34xajD2ZZ7yu+xi14jpEmqeyJawG4BQqzkLAa6b5Fg7Yj6PNO5QcrcJdJgzimLQ JMDnQlfSobPr6bzPs+kSHta6TNkwAbkaKq/K+CaY/zfiV46EYh5Uolq+zJmUgngqrPSg YO1Q== X-Forwarded-Encrypted: i=1; AJvYcCU8+KU5uZ9GwlKB4sJ+RiOOJ9itLGKQ3wLe9Onto8RIedLD60PVNOb39fQASRLxh/3TpTmsaIBAVQ==@kvack.org X-Gm-Message-State: AOJu0Ywpcm8TBb3M4P8qgwFU2spq+a3a4YejYKhGA75of2xz+w+zwBSJ wpclG6A3T2/u4IHDQrwzfiDopAPb2aWryijyigzxLIb2k79hh1xljm8L3da1JyrzQ0oe7V9Zjmc b+V4oCV4bizd2qV4mnlr46e7D39A= X-Gm-Gg: ASbGncuRSK4WxUFwJdfSD1FFtsDxFWPgcompWV2mZ3bLKcojwwEujdKzeiM3LH/shAJ 7YQugz1gjLUaQfKKJXhz+FQcnE7NAL6m8P0qbkwgIPU+u3J54xUsMwq7B+65IU6k12DiIPc4= X-Google-Smtp-Source: AGHT+IHIVXNab1BOwmWz6a/Olt6hbaMVNiKD6PsmxeEahtZ5dItZPFOQlTmfbwCK/vN41pOD1RoY6IyKFqV1etX4FZw= X-Received: by 2002:a05:6512:3dac:b0:544:138d:4b7b with SMTP id 2adb3069b0e04-545181aa0cdmr1114594e87.52.1739374777501; Wed, 12 Feb 2025 07:39:37 -0800 (PST) MIME-Version: 1.0 References: <20250212141648.599661-1-chenhuacai@loongson.cn> In-Reply-To: <20250212141648.599661-1-chenhuacai@loongson.cn> From: "Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com> Date: Thu, 13 Feb 2025 00:39:25 +0900 X-Gm-Features: AWEUYZk9xCLyQMauhOuQl-xiWShJj9iRS9rA-5uWRxBydRrisTXIpngPN_Q6b6A Message-ID: Subject: Re: [PATCH] mm/slab: Initialise random_kmalloc_seed after initcalls To: Huacai Chen 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-Rspamd-Queue-Id: 3A353180016 X-Stat-Signature: tfkwoxdkggcrfaxii6pm1dfwp5p8af7f X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1739374779-180567 X-HE-Meta: U2FsdGVkX1+yXP0d3ZmWeheW5qTiMK7WjWqZJGJISI+Ytljuqi9jDNpp6qYDppn7WuDkTyJfrUez+iZaDGUGS03VA7XEKohs66EaHjDGnVSxFfKkKiXv5zxQwQYZSURihbVaOAKo+dmXBO5i8QEK0DtNneBLZ5ueftA7cqZTVFQoBlkyjs0LzvGYIoX5DUEbTTlBeCeMXLYJ7x9RPxg5o7hvgaVyZSnpGpaVRBQd9wwmD9gyEsgOxNqfHjlLibcENpmAp8WHQvNwE9ZxyOMLrFgAAsEfERYwc1Yde8dR7tEyJgl3WXowKPKVmPPElkTmcMhA5n/rDwED9ur1OIsU7S/9xMxLDfrfG5W+DqjVUOX5DJF9CCuwptxUonfUYJ+LGG/DtKDhAfGjokiYioduKjrmZZQnV+XkMsUN1lj9kkzqLA6Ktsb4jkudOXhVDOFUB/0ZxwG2eAMaVwgjTfrmKflpwZbNhElziQuxy0h5qMvcNgUU//5jXrtZBQhIJ4krSZfCu5aPZ7XlqVypwrhKs7IrxJOeEANjIxY91Z2QnA4BqYs0TGNLtD4SX2xnyK5QhDjIS9wdlP1fN0637ZMu8sde7qk4CCR9bxeUq2ROjBTY8cFsdfK95s6r4CfjvKWmvgZvh4MXE2StspuVcigS0pVt3DSewusyCKcsQHBgoPXgojMNJiSbghZWgGLg+N1dwE38+udS/V+GBcScraqb+7hk8fILcrJkKyWM6z+kynNsP5DG1JpztEsYubwmcN6AlJphjeQPIgulpj00c/V/ym5anfLi57iyqM7hL38EYj3wZr8gp/hZFAGTTs2t0pUHCIGQ8Y0U/0y4WnsWUiKMdVh11mPuTval/AJktbwkW0ZGpn3JMm4srGfd15iMYCgXvkCnR50kb5JBXC2xOHQjY2E+m4dd3GA2AYn33G0cL196m4s0OZdy7vHJxeg2LZDDfJyK1NQqiEF5+oBQPuq 0n9YOeNP 8T+ZapqzwCma3UOtHbQNmjqYtiQ6UB9jWJOsHBn8wfiDpIbtv2LSpXRKF2y9KyLRUs2PgOHfiqrYmaziL0cMUaelfj6MQhxM/qAtvVy4Orkk20acvVAyJ7w1m1d46OLoCWbBa0RjRAker0Hd11kcyUCMG+2o4ghsWabuAvzFPSrh3qlR13WBqR9E79KgxIbKfIHP9dEsX09miefQ3Z5bnY/qZW99inJleRd+bOEq6WaNQc8LZ4wyLJiukm2uZfgwtvH8zWEeywQPPwya/6cb15hasYwS/tuqXx0hljJVpxihgvCRa/UfSX7BD21aNxVC9SsM9y3prhpFYgWCUe9l0RDF5RPX5FoWl3sNHsxURsz3gIZ4kHDkjVOB1pQKrCAOOQdMCd7tYGuM+Qjd2P+YzBBKTOoqJEJYph8+kOnUVDW/Wgnt2wR8zSNaFcgb5vOSjqKsHRznzYSsdPTwFM0IX9a9wUA+S+UF/en37 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: 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 that= are already allocated (before hibernation). > 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? > 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 memory= */ > 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. > 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?) > /* Kmalloc array is now usable */ > slab_state =3D UP; -- Harry