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=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 8493CC4360D for ; Wed, 25 Sep 2019 15:58:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5CCD521D7A for ; Wed, 25 Sep 2019 15:58:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="wBXX9oCD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725966AbfIYP6J (ORCPT ); Wed, 25 Sep 2019 11:58:09 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:36909 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725851AbfIYP6J (ORCPT ); Wed, 25 Sep 2019 11:58:09 -0400 Received: by mail-wr1-f67.google.com with SMTP id i1so7586652wro.4 for ; Wed, 25 Sep 2019 08:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GAYyX9uJkmy+PaSSr6Il6bqlp+qNEw3PUkHkNhAWLds=; b=wBXX9oCDMbDwDMuaTuCAPEWzYOVn4VrAj2w+YlfPfZbkcei/NtOKUITEBg61VECw6m +4SLsYkLE9/ojQK1bghkqXgOs8p7Zu82WFPYWel+VEkoRKHvfJfoexuy8ND3+L6cm0wI cI77ojQYs6UkzwS6a6U7BnFbrlFLXksxQAETiJcykdFdBQMj6aq38TpM3joNlvkCDqUw SG3D931RoEXrxeKA5qwBDI3wN6/qtQHBckqGT3o71n7g1//2DrDVgerHIasTFwppfeL3 pY8Ikc0dAoMgHpirhfOWqs0Al/RwMADwxs12uoowyIic3FX8dw6QHpX+DvWGYxusn2kZ 8gnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GAYyX9uJkmy+PaSSr6Il6bqlp+qNEw3PUkHkNhAWLds=; b=JZ6JRCV1ydj4b717vimmYb8qD7dI5aBPaUQj6H/2Sz9AQvPL+lLUakNjSZx/aqorB7 +3SxQwd+5WWx3lpo1vwDjatafjkSblMyGszz47/L7xzbkwBxCS3D4UOXja3P5na4orgh ZI2cRXKIbDzIun6d87ZMURktnNG+SB/uAmKfSZo3BimlIlH/BXnkljSm9+weYEmCv25W WjbSuAOmv4qOx+Q5z4hDs4A37JsXkcjaElBJGK7UJUz7bf++EA2zHA79w8iVBTR3pKC6 PWezUgR0CJvfXMvjXcjIxPpmrHsoRLbNdU2QXVsVzh5/InajEPhN64qKvP4il+SDWXON 3DHQ== X-Gm-Message-State: APjAAAXhhclZQjp+Zlvp43wKOZpJNkZcOB5aYivXKd/egoeGpcd4Uiq9 oUJ+wdX8zkdBjpLTcd38c4J8RqWVosw+SM0tAv3wfmgWyug= X-Google-Smtp-Source: APXvYqzjtR7RYasIPX2oWQL73hyxN/m0FS6mtJrgC3T8vNZaFDJOt9HQNeTie1ulXGIfLlofnsfGgbNhWl2T0qhjZvQ= X-Received: by 2002:adf:f406:: with SMTP id g6mr9627266wro.325.1569427087366; Wed, 25 Sep 2019 08:58:07 -0700 (PDT) MIME-Version: 1.0 References: <20190911233239.5916-1-ard.biesheuvel@linaro.org> In-Reply-To: From: Ard Biesheuvel Date: Wed, 25 Sep 2019 17:57:55 +0200 Message-ID: Subject: Re: [PATCH] efi: don't iterate over EFI vars pointlessly if no SSDT override was specified To: Scott Talbert Cc: linux-efi Content-Type: text/plain; charset="UTF-8" Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Thu, 19 Sep 2019 at 20:01, Scott Talbert wrote: > > 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. > >> > > > > I'll send it out as a fix with a cc to -stable. > > Hi - just a quick reminder on this as I don't see it in Linus' tree yet. > Not that I need it urgently, but just want to make sure it isn't > forgotten. > Hi Scott, This should get sent out in the next couple of day. It usually takes another week or so after that for changes to make it into Linus's tree.