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 A76EAC83F1D for ; Sat, 12 Jul 2025 15:19:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 373AD6B00D0; Sat, 12 Jul 2025 11:19:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 34A316B00D1; Sat, 12 Jul 2025 11:19:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 238C56B00D2; Sat, 12 Jul 2025 11:19:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 123CD6B00D0 for ; Sat, 12 Jul 2025 11:19:02 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C478C10D06C for ; Sat, 12 Jul 2025 15:19:01 +0000 (UTC) X-FDA: 83655970482.05.4A84C52 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf11.hostedemail.com (Postfix) with ESMTP id AB12C40003 for ; Sat, 12 Jul 2025 15:18:59 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tkJJ39Gl; spf=pass (imf11.hostedemail.com: domain of chenhuacai@kernel.org designates 172.234.252.31 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=1752333539; 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=RQAveTme+MANlCYFi2iws3oJwTFUGaQMBRvlU1pXUTY=; b=PVnGCILOEvB3I1pYOh/uCHUHDuRNYMgT11y4PfGwV0dodeuii0p6nCIx6wpfC4+CK1zrXd TfdqKa6xZtxJGipD8+6cIeHjy8mDOdSyP9qz6pEc2zEFACA5rSPoiD11nZ3E4yititqmRF JKdbgcdk2ptALV7vDraLnpyfSJTgoog= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752333539; a=rsa-sha256; cv=none; b=BSkF0S/MRLvYgnyrV8m0AwJzexniu1bCxoRFziZS8SEE22x2WYX+YJ6wdjgsJT5Bfnun5I kra7KaDt+FiLpzgAEghfp7DVJB+jKxfOW9IA+H4Poxf2B4qOXO1hEacydhF9W5TG3z892C F9Jq/2L42pzxXi5Naul1768dfY3tIjM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tkJJ39Gl; spf=pass (imf11.hostedemail.com: domain of chenhuacai@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 4CCD344B49 for ; Sat, 12 Jul 2025 15:18:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2B60CC4CEEF for ; Sat, 12 Jul 2025 15:18:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752333538; bh=oBuInK/Er1FzxA1L8e6FwS1J0+Ud/HnGx2Yd/U2ONAI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tkJJ39GlvkgSbwm68I7ha4Vn08nRXL4aMAdBQOuPNMVRAA90HpjfAO6q6a3WAcbir BQh7BN28+rV38rwU89D6AOZYUU7rVe8aj9KFjPK3jSpsWcTLSoCAZe8H38srsxgZDg 8/o3IBbLw9nCDu76HmBvxy7Xv45vpHeHRR/qGTat8YgOI15Zi+fdsa9KGSjpNwbszM ghQbpKD9JzbKZqhESYr/MRSzZ088/nuCSazUuSPIde1jSKauMI2Tsof1c/GB3AJXmu qThTq51OQvSA2Ue3o8JUzySPvfO/Zq8siYZieoLQYgioqrGcsS/i65pXPy4StllEuR GTTbZW1YEhF7A== Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-60c93c23b08so5813477a12.3 for ; Sat, 12 Jul 2025 08:18:58 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXK+wFOMn+SWAGzzXIpPo1meInAh5Y9YFqu2JelKo0c0x5vvKa0DY+ztNW0YkcJehLs5RWFVCeing==@kvack.org X-Gm-Message-State: AOJu0YxxkdVmLJkNWJjeHMcQDVLqsJVzYtzimpN7DmxNECPfb0gKdFJc y9oR2xRYLGYwwmmEv7j+PCJ1rYh3g7cG4bG/fWckXSHNJRTMz5f6o9JAw8UZTJEOC7Sh/CrbXyP Yrx8kTq0l0KRJ9f5nWA/kOq0BteRIvNk= X-Google-Smtp-Source: AGHT+IFrzSZLNInWS+8kFPoqYt/MMfdTYQoSCkNyar2BMbLSJNWC8sQxzSzjG5tUH1/1HNQ6F/ZaEFU5n43ZNhmmJwI= X-Received: by 2002:a05:6402:34c7:b0:5fe:7b09:9e27 with SMTP id 4fb4d7f45d1cf-611e7c21fb6mr6228271a12.12.1752333536713; Sat, 12 Jul 2025 08:18:56 -0700 (PDT) MIME-Version: 1.0 References: <20250711102455.3673865-1-chenhuacai@loongson.cn> <2025071130-mangle-ramrod-38ff@gregkh> <2025071116-pushchair-happening-a4cf@gregkh> <2025071150-oasis-chewy-4137@gregkh> In-Reply-To: <2025071150-oasis-chewy-4137@gregkh> From: Huacai Chen Date: Sat, 12 Jul 2025 23:18:44 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXwsrOLHm2zwCsbZIeklHFbvZsw2Idkz2eK6IwezSFPRuRdFcX288N4584o Message-ID: Subject: Re: [PATCH] init: Handle bootloader head in kernel parameters To: Greg KH Cc: Huacai Chen , Andrew Morton , linux-mm@kvack.org, Alexander Viro , Christian Brauner , Jan Kara , linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: AB12C40003 X-Stat-Signature: s4g38t1t9whib8t1gx6s36ktay4ogbs7 X-Rspam-User: X-HE-Tag: 1752333539-672476 X-HE-Meta: U2FsdGVkX1/9+cZudKaxQIIonFLUc0Qf8JGpPgcd+9yZPO9hT6SCSuh/TuMtZYT6dCVniA7NDd0I4y7hl1G9tc9v0RSThiKGk7p2kAn9pKYC7/p4QCRdmwcAO5G9jVR1ZACNV6NB7+fbbwPYK19ZtDKf5rwslE7x6fGqz1n6nVxF93qcV9k4eUp50YzwKYOlFArAW78pM8vPJTtxhjyCOkFT363ZuBm6uJwX0ygFnBQGJaDpc2UlTf847kBlqb7Z77cbo7pnthCLnpWZHQ/XkkBgZy/NSSLHBJSMxGdGvf9yJUfFz9eBiVCUlaZ2tTJBgVOM1ag7plHdEtQTsNNwhLqrbdv+CndNzFsgNLQgkGosxJZmOKhMk6RJmr4bwdZedxZAO03y276xMfpXJuDAzqI32CVdsR8oN5zSUQbFSEZHkONIiED8xSfbM1UTGJrcDA5hzWV0Ly0qPSsTbAAoVK14L1BhBqPmF9NZesW1CwzC64ShIFJDwHTfr9t4sNA3NwgLJHNmL4W+SEQDK3c2JBWKZVSg5lJqYxb1f7C16aIAGLLeIYTLj7Ku5WLIU/hK72B/FIsYLrheB3Ee7IU25rADSQdtelECz0X9SsKqxApBRdIyt8Ce8dLRuI2cr/HcvOawZZnON3bHtYCry1JG9eH12MUUEnPey0fjOopQRSI5qtAMd70ZZ4ElHUkhlVlc2QdiJVDpwW3JxXhamUw9Rj80COzVhqoMBx97CusKGOjyq8zolFWHTa7d/c9RNNHRJ1zxvhUhEslhhDdvGMVNuuw/tKYw8x1902jvd1PjOxbmIHxb1w0d+m8zyxQjdCsBRxEdiPOE/WjSU82cRdPLUc9BjqMZef/G5Yck91FBwdBYriLJ5hkF6X1CaBdvVaqBjDtb5mlq6tEUw1BadvT3SEAzn95G9Yfc4OJnJ4E68BzenGAuOtPQIXPwXHA32tcWDl+TNh7pNjHeUqVhitA TpirBCxn 8UC5x1CtttAZaMmkxYj6LFNvU7KZ7ZrYMbcP0qfpLFcpIy4z1GPTx9jVVNX/7yjGHEMePSLTxePWC8navVRn65v6L7equE6EVnLycD5zRU51tLb1VWvM7jPZLB7kr83AtsutprFvxzf9xifJqK8mawlka2xhAKsuSjQeI2NEfwd8dCJ2DT+4JIW3Kr9owHWQDQpyd1c+oA8LcAYyrnrVVSe8Oa+a6nJoPgBibq6kgNGm29q+hNH6M0vKbdDYfeLfSW5CK/Cr781mJRRwVjjrgut8ySLVxrlUIXJ2QYpJCatf217sXG9f1gCx3btBNITtIz/qzo1g1kZ9OS1eDqYNeKdxfXkpalYOhMp8F/Mfvya3WXg9JEUCHWpsBWNQTCfn4X2vsJeAMN959fz4djdaTI7yYCek2wEFw0rie 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 Fri, Jul 11, 2025 at 9:04=E2=80=AFPM Greg KH wrote: > > On Fri, Jul 11, 2025 at 08:51:28PM +0800, Huacai Chen wrote: > > On Fri, Jul 11, 2025 at 8:41=E2=80=AFPM Greg KH wrote: > > > > > > On Fri, Jul 11, 2025 at 08:34:25PM +0800, Huacai Chen wrote: > > > > Hi, Greg, > > > > > > > > On Fri, Jul 11, 2025 at 7:06=E2=80=AFPM Greg KH wrote: > > > > > > > > > > On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote: > > > > > > BootLoader may pass a head such as "BOOT_IMAGE=3D/boot/vmlinuz-= x.y.z" to > > > > > > kernel parameters. But this head is not recognized by the kerne= l so will > > > > > > be passed to user space. However, user space init program also = doesn't > > > > > > recognized it. > > > > > > > > > > Then why is it on the kernel command line if it is not recognized= ? > > > > UEFI put it at the beginning of the command line, you can see it fr= om > > > > /proc/cmdline, both on x86 and LoongArch. > > > > > > Then fix UEFI :) > > > > > > My boot command line doesn't have that on x86, perhaps you need to fi= x > > > your bootloader? > > Not only UEFI, Grub also do this, for many years, not now. I don't > > know why they do this, but I think at least it is not a bug. For > > example, maybe it just tells user the path of kernel image via > > /proc/cmdline. > > > > [chenhuacai@kernelserver linux-official.git]$ uname -a > > Linux kernelserver 6.12.0-84.el10.x86_64 #1 SMP PREEMPT_DYNAMIC Tue > > May 13 13:39:02 UTC 2025 x86_64 GNU/Linux > > [chenhuacai@kernelserver linux-official.git]$ cat /proc/cmdline > > BOOT_IMAGE=3D(hd0,gpt2)/vmlinuz-6.12.0-84.el10.x86_64 > > root=3DUUID=3Dc8fcb11a-0f2f-48e5-a067-4cec1d18a721 ro > > crashkernel=3D2G-64G:256M,64G-:512M > > resume=3DUUID=3D1c320fec-3274-4b5b-9adf-a06 > > 42e7943c0 rhgb quiet > > Sounds like a bootloader bug: > > $ cat /proc/cmdline > root=3D/dev/sda2 rw > > I suggest fixing the issue there, at the root please. Grub pass BOOT_IMAGE for all EFI-based implementations, related commits of = Grub: https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=3D16ccb8b138218d= 56875051d547af84410d18f9aa https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=3D25953e10553dad= 2e378541a68686fc094603ec54 Linux kernel treats BOOT_IMAGE as an "offender" of unknown command line parameters, related commits of kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3D86d1919a4fb0d9c115dd1d3b969f5d1650e45408 There are user space projects that search BOOT_IMAGE from /proc/cmdline: https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/util.go (search getBootOptions) https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/main.go (search getKernelReleaseWithBootOption) So, we can say Grub pass BOOT_IMAGE is reasonable and there are user space programs that hope it be in /proc/cmdline. But BOOT_IMAGE should not be passed to the init program. Strings in cmdline contain 4 types: BootLoader head (BOOT_IMAGE, kexec, etc.), kernel parameters, init parameters, wrong parameters. The first type is handled (ignored) by this patch, the second type is handled (consumed) by the kernel, and the last two types are passed to user space. If the first type is also passed to user space, there are meaningless warnings, and (maybe) cause problems with the init program. Huacai > > > > > > > KEXEC may also pass a head such as "kexec" on some architecture= s. > > > > > > > > > > That's fine, kexec needs this. > > > > > > > > > > > So the the best way is handle it by the kernel itself, which ca= n avoid > > > > > > such boot warnings: > > > > > > > > > > > > Kernel command line: BOOT_IMAGE=3D(hd0,1)/vmlinuz-6.x root=3D/d= ev/sda3 ro console=3Dtty > > > > > > Unknown kernel command line parameters "BOOT_IMAGE=3D(hd0,1)/vm= linuz-6.x", will be passed to user space. > > > > > > > > > > Why is this a problem? Don't put stuff that is not needed on the= kernel > > > > > command line :) > > > > Both kernel and user space don't need it, and if it is passed to us= er > > > > space then may cause some problems. For example, if there is > > > > init=3D/bin/bash, then bash will crash with this parameter. > > > > > > Again, fix the bootloader to not do this, why is the kernel responsib= le > > > for this? > > > > > > What has suddenly changed to now require this when we never have need= ed > > > it before? > > Because init=3D/bin/bash is not a usual use case, so in most cases it i= s > > just a warning in dmesg. But once we see it, we need to fix it. > > Why is this the kernel's fault? > > Again, what changed in the kernel to cause this to happen? I think you > are seeing bugs in bootloaders, NOT in the kernel. Fix the issue at the > root, don't paper over the problem in the kernel for something that is > NOT the kernel's fault. > > > > > > > Cc: stable@vger.kernel.org > > > > > > Signed-off-by: Huacai Chen > > > > > > --- > > > > > > init/main.c | 7 +++++++ > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > > > diff --git a/init/main.c b/init/main.c > > > > > > index 225a58279acd..9e0a7e8913c0 100644 > > > > > > --- a/init/main.c > > > > > > +++ b/init/main.c > > > > > > @@ -545,6 +545,7 @@ static int __init unknown_bootoption(char *= param, char *val, > > > > > > const char *unused, void *ar= g) > > > > > > { > > > > > > size_t len =3D strlen(param); > > > > > > + const char *bootloader[] =3D { "BOOT_IMAGE", "kexec", NUL= L }; > > > > > > > > > > You need to document why these are ok to "swallow" and not warn f= or. > > > > Because they are bootloader heads, not really a wrong parameter. We > > > > only need a warning if there is a wrong parameter. > > > > > > Again, fix the bootloader. > > But I don't think this is a bootloader bug. > > Seems like it is if nothing changed in the kernel and this just started > showing up now :) > > Unless you can find a kernel commit that caused this issue? > > thanks, > > greg k-h