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 X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3AFE7C4CEC6 for ; Thu, 12 Sep 2019 19:35:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F30FA2084D for ; Thu, 12 Sep 2019 19:35:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=techie.net header.i=@techie.net header.b="QSZkndUv" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726164AbfILTfI (ORCPT ); Thu, 12 Sep 2019 15:35:08 -0400 Received: from bear.techie.net ([205.134.185.202]:48550 "EHLO bear.techie.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726148AbfILTfI (ORCPT ); Thu, 12 Sep 2019 15:35:08 -0400 Received: by bear.techie.net (Postfix, from userid 545) id E7E1722A0945; Thu, 12 Sep 2019 15:35:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=techie.net; s=default; t=1568316907; bh=PR3Oys8g9aZruQAbK2JjcS9X6DoNsIxCIqWRipF6gP0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QSZkndUvpcsZtmSFOMS6NED1BwZ4CEQ6kHoTeBlW/7c5mP31k/7xeAY2H6nh3rJxB DVq1UIQ8TuU9XRKTMBgXV3EWspOBUhwCX9Igq63imkpkeBQm4fsiCxvMpb90ncSysJ DSBKFMjQtEi8WCkoEecBcQjhp56EzQPVbCm0HKg0= Received: from localhost (localhost [127.0.0.1]) by bear.techie.net (Postfix) with ESMTP id C60E522A0943; Thu, 12 Sep 2019 15:35:07 -0400 (EDT) Date: Thu, 12 Sep 2019 15:35:07 -0400 (EDT) From: Scott Talbert X-X-Sender: talbert@bear.techie.net To: Ard Biesheuvel cc: linux-efi@vger.kernel.org Subject: Re: [PATCH] efi: don't iterate over EFI vars pointlessly if no SSDT override was specified In-Reply-To: <20190911233239.5916-1-ard.biesheuvel@linaro.org> Message-ID: References: <20190911233239.5916-1-ard.biesheuvel@linaro.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Thu, 12 Sep 2019, Ard Biesheuvel wrote: > The kernel command line option efivar_ssdt= allows a EFI variable name > to be specified which contains an ACPI SSDT table that will be loaded > into memory by the OS. > > Currently, that code will always iterate over the EFI variables and > compare each name with the provided name, even if the command line > option wasn't set to begin with. > > So bail early when no variable name was provided. > > Cc: Scott Talbert > Signed-off-by: Ard Biesheuvel > --- > drivers/firmware/efi/efi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > index ad3b1f4866b3..8f020827cdd3 100644 > --- a/drivers/firmware/efi/efi.c > +++ b/drivers/firmware/efi/efi.c > @@ -282,6 +282,9 @@ static __init int efivar_ssdt_load(void) > void *data; > int ret; > > + if (!efivar_ssdt[0]) > + return 0; > + > ret = efivar_init(efivar_ssdt_iter, &entries, true, &entries); > > list_for_each_entry_safe(entry, aux, &entries, list) { Thanks for the quick fix! I can confirm this fixes booting on my Mac Pro 2012 system when applied to 5.3-rc7. Whenever this makes it in, if it could be targeted for the stable kernels as well, that would be appreciated. Thanks, Scott