Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2659635imm; Mon, 24 Sep 2018 07:59:44 -0700 (PDT) X-Google-Smtp-Source: ACcGV61yoODOSybuCUaXECaoG0n2MDGnNVPNXUhbSPKb7FEsRKcPLcRiuQ5DRiDpGke5eWtzoWej X-Received: by 2002:a63:1064:: with SMTP id 36-v6mr9878730pgq.254.1537801184881; Mon, 24 Sep 2018 07:59:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537801184; cv=none; d=google.com; s=arc-20160816; b=DaL+OOkwobfKFzcur9wsoWYpzMidyT0AetIyJaTVTiX4XdpuG5IdrEPeUib8Wzqw3j YIMmI5EukGHL3b8Sbq2wN0T4KY6fSG4KMYxv4/vMV9nkHAOouvmWl8aSN5lcFsrVO9ag BbymUbhSeXFPbwo8dB1sjrdKFndEwDEecEGemOFqwRiBI+6IMA3A47XMM3tAVG1Y3o+t SjQT+FnxBUxTN/bzDgGTgMtRyXWF4WebtpePEYZBZ2rEvVTTYZ0DmzHNqs3SDrCejK4p BjR5Dbdy3O8xHBQkVY4xU8KyBXTwCDGZXyKigb20ls8wlreeich3Bwzh8t8Be5w3tkKP nT1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=yjgSJBurcO1wWIZDaLDodCSzKYV5YrLyVtCSPTQ8ClI=; b=lDFTB0AadjzJbdWRv51YP4cDbGh2qkAtgFVUaCIL8R2jfCSHpdDFhRqa3L5iCdfXCm jE+tOchq7H62+KF/Lw60we4pQl6EbcT0QhYr/WqjubiAMxC1we6Z6Q66Xulz/q5zu2cF CgKlvW5/G2bkMWEwTabwjPULEr22/l9N4GVfw/sNPdPFuVw8vM3epSubAyEreFwo25IC payjXIU+7HZBvR16SqppMlDsezMjigicmhkq7w4BzGl1sNufRxN0PHEJDNhkYbnBk3J5 3P1DC1iQAQaTInUrG+7t0wyvB3SLF614jBRRXRsrh9W9LAXNC7A+52DnOaOWiC5F4AVX QYHg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r7-v6si12182709pgf.620.2018.09.24.07.59.29; Mon, 24 Sep 2018 07:59:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729150AbeIXU0f (ORCPT + 99 others); Mon, 24 Sep 2018 16:26:35 -0400 Received: from mx2.suse.de ([195.135.220.15]:40046 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727050AbeIXU0e (ORCPT ); Mon, 24 Sep 2018 16:26:34 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 0A7A1ACCC; Mon, 24 Sep 2018 14:24:10 +0000 (UTC) Date: Mon, 24 Sep 2018 16:24:08 +0200 From: Michal Hocko To: zhe.he@windriver.com Cc: akpm@linux-foundation.org, vbabka@suse.cz, pasha.tatashin@oracle.com, mgorman@techsingularity.net, aaron.lu@intel.com, osalvador@suse.de, iamjoonsoo.kim@lge.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] mm/page_alloc: Fix panic caused by passing debug_guardpage_minorder or kernelcore to command line Message-ID: <20180924142408.GC18685@dhcp22.suse.cz> References: <1537628013-243902-1-git-send-email-zhe.he@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1537628013-243902-1-git-send-email-zhe.he@windriver.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat 22-09-18 22:53:32, zhe.he@windriver.com wrote: > From: He Zhe > > debug_guardpage_minorder_setup and cmdline_parse_kernelcore do not check > input argument before using it. The argument would be a NULL pointer if > "debug_guardpage_minorder" or "kernelcore", without its value, is set in > command line and thus causes the following panic. > > PANIC: early exception 0xe3 IP 10:ffffffffa08146f1 error 0 cr2 0x0 > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc4-yocto-standard+ #11 > [ 0.000000] RIP: 0010:parse_option_str+0x11/0x90 > ... > [ 0.000000] Call Trace: > [ 0.000000] cmdline_parse_kernelcore+0x19/0x41 > [ 0.000000] do_early_param+0x57/0x8e > [ 0.000000] parse_args+0x208/0x320 > [ 0.000000] ? rdinit_setup+0x30/0x30 > [ 0.000000] parse_early_options+0x29/0x2d > [ 0.000000] ? rdinit_setup+0x30/0x30 > [ 0.000000] parse_early_param+0x36/0x4d > [ 0.000000] setup_arch+0x336/0x99e > [ 0.000000] start_kernel+0x6f/0x4ee > [ 0.000000] x86_64_start_reservations+0x24/0x26 > [ 0.000000] x86_64_start_kernel+0x6f/0x72 > [ 0.000000] secondary_startup_64+0xa4/0xb0 > > This patch adds a check to prevent the panic Is this something we deeply care about? The kernel command line interface is to be used by admins who know what they are doing. Using random or wrong values for these parameters can have detrimental effects on the system. This particular case would blow up early, good. At least it is visible immediately. This and many other parameters could have a seemingly valid input (e.g. not a missing value) and subtle runtime effect. You won't blow up immediately but the system is hardly usable and the early checking cannot possible catch all those cases. Take a mem=$N copied from one machine to another with a different memory layout. While 2G can be perfectly fine on one a different machine might result on a completely unusable system because the available RAM is place higher. So I am really wondering. Do we really want a lot of code to catch kernel command line incorrect inputs? Does it really lead to better quality overall? IMHO, we do have a proper documentation and we should trust those starting the kernel. > and adds KBUILD_MODNAME to prints. This doesn't seem to be done in this patch. Probably a left over from the previous version. > Signed-off-by: He Zhe > Cc: stable@vger.kernel.org > Cc: akpm@linux-foundation.org > Cc: mhocko@suse.com > Cc: vbabka@suse.cz > Cc: pasha.tatashin@oracle.com > Cc: mgorman@techsingularity.net > Cc: aaron.lu@intel.com > Cc: osalvador@suse.de > Cc: iamjoonsoo.kim@lge.com > --- > v2: > Use more clear error info > Split the addition of KBUILD_MODNAME out > > mm/page_alloc.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 89d2a2a..f34cae1 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -630,6 +630,12 @@ static int __init debug_guardpage_minorder_setup(char *buf) > { > unsigned long res; > > + if (!buf) { > + pr_err("kernel option debug_guardpage_minorder requires an \ > + argument\n"); > + return -EINVAL; > + } > + > if (kstrtoul(buf, 10, &res) < 0 || res > MAX_ORDER / 2) { > pr_err("Bad debug_guardpage_minorder value\n"); > return 0; > @@ -6952,6 +6958,11 @@ static int __init cmdline_parse_core(char *p, unsigned long *core, > */ > static int __init cmdline_parse_kernelcore(char *p) > { > + if (!p) { > + pr_err("kernel option kernelcore requires an argument\n"); > + return -EINVAL; > + } > + > /* parse kernelcore=mirror */ > if (parse_option_str(p, "mirror")) { > mirrored_kernelcore = true; > -- > 2.7.4 > -- Michal Hocko SUSE Labs