Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1916814pxb; Thu, 4 Nov 2021 10:40:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0/hgBijALYWJiBK0hhDh9CDRKjPU35WabVPjTbEDjWGAiSBKNOc5TAMBJ83wsyB7ftce4 X-Received: by 2002:a17:907:d08:: with SMTP id gn8mr63717892ejc.395.1636047658107; Thu, 04 Nov 2021 10:40:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1636047658; cv=none; d=google.com; s=arc-20160816; b=HrRHNoSJM+zaAOrgks+7cmCHiprJvztro36V/KrWZ994wqkSEMcLDjNDUPUtdhGR5X zUsho9wq3vyMcmzpJ57KJGjbLyqCskNIknYRHvgAmz0iN2lBpStNiW3BrID69ZN0l+r2 o78bFe6zNCZsnDj4mbsh9Fv0SRqhcq5Ao1+/Nhes4QQ/0mXyJCJLK7qYXlX5ziVu+Pam Zf5r5Zi8EGFkkFyej9OBDb/RBZMxzmomHS8aAWSaxuKU/b63TtZQdQCw/GuFRjwS/0K0 hru5CD2iEvwp3BhsXdpACywkqYOZhaC4GZHAvYW6QO9nYkZOw6SQmOtjxi4uzvkKxv10 T7SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=JE7BWh7EPof2q1qNnDyfyKa+RjN00TLgKWFmUR6xPto=; b=zydxLdTyI8T0SgAn2ZYisyVrqbxAp6EHPKutfpvHXQ6VVx54NwrTUk785Bzlg/qAFn qAQc+ETmNC8qU65dnroRME4H84wtlttGwvQsyNdhscff3RcZUkFjPsOjWnR/bQrqjBec WdawhGt22u5ughF5/c26iHSK2uksGBinmRjKYjPjrxAI0LOs1eH/C+o2IYfeEz8jdFYT vt0yHCqaeP+y5rCXz7bnVO/9D6UnmOfFUfUOrOTbQMxSn8NakDohrLNZGuZRkfQKtBz7 RLYRDzjp4soBbroorMjhfW0QT4rwqXxa1kegFYKEReZqReDokDva5cCcm3Em0yF2rKIV ieSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=s4ImMsgG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y6si10218263edp.593.2021.11.04.10.40.04; Thu, 04 Nov 2021 10:40:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=s4ImMsgG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233940AbhKDRjX (ORCPT + 99 others); Thu, 4 Nov 2021 13:39:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233937AbhKDRjV (ORCPT ); Thu, 4 Nov 2021 13:39:21 -0400 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25B32C061203 for ; Thu, 4 Nov 2021 10:36:43 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id b13so8451024plg.2 for ; Thu, 04 Nov 2021 10:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JE7BWh7EPof2q1qNnDyfyKa+RjN00TLgKWFmUR6xPto=; b=s4ImMsgGQUm6mPzKM3B7NN46K9mZpThq5Ex5NXxELwvAQv//gJkb4OoJtyk5iSzmpJ I3mUqa9VU+FgsWW4eNq0E4V7DBBnLF25zbym4s98B02IKYUoSPfPj1BB4YzC1qo7K7e1 F8jpINNbsAP8yMlNfJafwBgadBd8zcPhur4Z2vkwy2W9QNtrtM7+gkb903YGkJCxe8iN 6KMSxmUCQVTgc+DflfDvjhll8s9mck6+NRGbQaeVC2SOY+zcKv3+9PjY4HIgqGSGD/BX lQWt6XNSDiGQnx8Jy4M+Y4En33jGcYPby6DS7HsWd/4tD4V2VUNhWEuYojKIx0iN9S+0 XgGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JE7BWh7EPof2q1qNnDyfyKa+RjN00TLgKWFmUR6xPto=; b=umHrYLekzvGB/m0FAA4P6Rz/WSURduJS/NkUkgsVkosL2E7j8nh8sbwAql8Cq0JZZa /gvErg2xyHsg+NfQrA/bnA7cwd5roM/RttHRmAI1ZJke8hPzzcGInNEp4KWaJCtUiaY9 k82zyQtxsDinNR6S0bM2hpb/zSGXkNKulfptVhEaKMfpIXVUwTawdrgwo0G7X0i9WDDP 8lHHFN0UTV+KU2DIGAAtNQrIkZyTysblravw1uOxrPdVw0127nUdSysyXYIfdnd/rJC3 ODfkn5yoQkM5lT3kO25kNwIf0l1eag7DxbtObj+KYHtpuD+J3SAEqWr1P6/iJeKqe2P+ 1RwA== X-Gm-Message-State: AOAM533zgDW6VFRCKmM7Z8AdyVzJLT2gEb5cFMaQGXJzHg9rTEncwfvL hLPcy/8jIL1dKo7Rxf7KKxOwTUyNlm9LGnlo0mgDPA== X-Received: by 2002:a17:902:aa84:b0:142:36cb:2a47 with SMTP id d4-20020a170902aa8400b0014236cb2a47mr4251518plr.89.1636047402658; Thu, 04 Nov 2021 10:36:42 -0700 (PDT) MIME-Version: 1.0 References: <20210920120421.29276-1-jgross@suse.com> <163233113662.25758.10031107028271701591.tip-bot2@tip-bot2> In-Reply-To: From: Dan Williams Date: Thu, 4 Nov 2021 10:36:32 -0700 Message-ID: Subject: Re: [tip: x86/urgent] x86/setup: Call early_reserve_memory() earlier To: Borislav Petkov Cc: "linux-kernel@vger.kernel.org" , "linux-tip-commits@vger.kernel.org" , "nathan@kernel.org" , "Gross, Jurgen" , "stable@vger.kernel.org" , "marmarek@invisiblethingslab.com" , "Chagam, Anjaneya" , "bp@suse.de" , "x86@kernel.org" , Mike Rapoport Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 4, 2021 at 4:40 AM Borislav Petkov wrote: > > + Mike. > > On Thu, Nov 04, 2021 at 05:38:54AM +0000, Williams, Dan J wrote: > > By inspection, this commit looks like the source of the problem because > > early_reserve_memory() now runs before parse_early_param(). > > Yah, I see it too: > > early_reserve_memory > |-> efi_memblock_x86_reserve_range > |-> efi_fake_memmap_early > > which does > > if (!efi_soft_reserve_enabled()) > return; > > and that would have set EFI_MEM_NO_SOFT_RESERVE after having parsed > "nosoftreserve". > > And parse_early_param() happens later. > > Uuuf, that early memory reservation dance is not going to be over, > ever... > > Well, I guess we can do something like this below. The intent being to > carve out the command line preparation into a separate function which > does the early param parsing too. So that it all goes together. > > And then call that function before early_reserve_memory() so that the > params have been parsed by then. > > Looking at the changed flow, I think we should be ok but I've said that > a bunch of times already regarding this memory reservation early and > something in our house of cards called early boot order always broke. > > Damn. Thanks Boris! You can add: Tested-by: Anjaneya Chagam Reviewed-by: Dan Williams > > --- > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 40ed44ead063..05f69e7d84dc 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -742,6 +742,28 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p) > return 0; > } > > +static char *prepare_command_line(void) > +{ > +#ifdef CONFIG_CMDLINE_BOOL > +#ifdef CONFIG_CMDLINE_OVERRIDE > + strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE); > +#else > + if (builtin_cmdline[0]) { > + /* append boot loader cmdline to builtin */ > + strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE); > + strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE); > + strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE); > + } > +#endif > +#endif > + > + strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE); > + > + parse_early_param(); > + > + return command_line; > +} > + > /* > * Determine if we were loaded by an EFI loader. If so, then we have also been > * passed the efi memmap, systab, etc., so we should use these data structures > @@ -830,6 +852,23 @@ void __init setup_arch(char **cmdline_p) > > x86_init.oem.arch_setup(); > > + /* > + * x86_configure_nx() is called before parse_early_param() (called by > + * prepare_command_line()) to detect whether hardware doesn't support > + * NX (so that the early EHCI debug console setup can safely call > + * set_fixmap()). It may then be called again from within noexec_setup() > + * during parsing early parameters to honor the respective command line > + * option. > + */ > + x86_configure_nx(); > + > + /* > + * This parses early params and it needs to run before > + * early_reserve_memory() because latter relies on such settings > + * supplies as early params. > + */ > + *cmdline_p = prepare_command_line(); > + > /* > * Do some memory reservations *before* memory is added to memblock, so > * memblock allocations won't overwrite it. > @@ -863,33 +902,6 @@ void __init setup_arch(char **cmdline_p) > bss_resource.start = __pa_symbol(__bss_start); > bss_resource.end = __pa_symbol(__bss_stop)-1; > > -#ifdef CONFIG_CMDLINE_BOOL > -#ifdef CONFIG_CMDLINE_OVERRIDE > - strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE); > -#else > - if (builtin_cmdline[0]) { > - /* append boot loader cmdline to builtin */ > - strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE); > - strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE); > - strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE); > - } > -#endif > -#endif > - > - strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE); > - *cmdline_p = command_line; > - > - /* > - * x86_configure_nx() is called before parse_early_param() to detect > - * whether hardware doesn't support NX (so that the early EHCI debug > - * console setup can safely call set_fixmap()). It may then be called > - * again from within noexec_setup() during parsing early parameters > - * to honor the respective command line option. > - */ > - x86_configure_nx(); > - > - parse_early_param(); > - > #ifdef CONFIG_MEMORY_HOTPLUG > /* > * Memory used by the kernel cannot be hot-removed because Linux > > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette