Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp178917pxk; Thu, 24 Sep 2020 02:53:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwyqK+1tjV6pZGmUAkbdDnv15PXHMlDVpvoo03GKyA70bda2sm6YrUtUQy36oOnVp9Zg0Qh X-Received: by 2002:a17:906:f747:: with SMTP id jp7mr151078ejb.22.1600941190448; Thu, 24 Sep 2020 02:53:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600941190; cv=none; d=google.com; s=arc-20160816; b=WAcPpz9kqnp1vGFg10uris6JiEdBfMfhzMBdFrWbArg4xwW/Iw8j6XFvlQOfCT0JSq mO0l/atvwWptITxEgiKYzLqFCmmQCKiigEX5OpgkIPpZyz6CXQ4e5ZfL7vhO/LFgNYXZ 6Je9IMHpiXOJzI5kMA7GrYv/r6++2mCa6mJVh2cpQVZy4whXfGMs7qIPk+wcSMPZ0NyW KzJfAYAFJoCwpao6pG6sYBXrr8+oQtCUJkDZ3+8kfV3ldbscknCjwA7Z8RmipXOt8zis xt/wXxFcRWbNf90BfrIrJ6vTkyjtS43NeRvqZY9sTX2bYcs3QEc7GSXmekk1IVWeoxa6 aTjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=3H0mk7emc64jBE29oCiBgn/9pmhTgMl4xe4TJfmTh38=; b=Q+oCIDf+mjuyEHPnNC4Z0GoMyq3yhEfoFTYbaScdcuZE6fhJgkFL13XPjxisZjo6sX x2Rk8SqFlgNEJ4+JoElm1VF69npYuAviBaS26RYAPKLSBE7SL/lP6OtG95fOs3xI/byz cNJvJQxt6u9zH4c1eC+EPrwb0m4e7sCS8gcNTVsL/jK5hsDXK3wFModF8dM5V4R8WOZQ 0862EvspIF9YDHuFXCjaSI94N0aE7vldnuOf3t3pFGABqa01vy2S9LUPzg/LLwe4wdqj jnOoKywCCf4xjy3wvUjKJxr/JQUrPB598RfekZU6ZFCga9uRV5wOb88poeiCFsOrbFbb RBeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=RaSEtGHd; 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=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n1si1689559edt.72.2020.09.24.02.52.47; Thu, 24 Sep 2020 02:53:10 -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=@kernel.org header.s=default header.b=RaSEtGHd; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726654AbgIXJvl (ORCPT + 99 others); Thu, 24 Sep 2020 05:51:41 -0400 Received: from mail.kernel.org ([198.145.29.99]:45490 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726380AbgIXJvl (ORCPT ); Thu, 24 Sep 2020 05:51:41 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BB8DE2396E; Thu, 24 Sep 2020 09:51:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600941100; bh=TgimIo4LtMHR70zUjNJMS20tf+W7300XmLWfy8v9sGY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RaSEtGHdwDuOalyNKwB4D+91VvPEZc8LHgmr9sFNvoDdAPXoF3w0tfJMTegCsgM2H z3uJSjoFYs6jjZdCcVArtbadiz6gWj7UnEiZ2En6DgEAiUNfLliPgsN+TkKE+mblIy 3l9o03DLJkf296TIgFeZFDWP64uGgBQJti7GKwZU= Date: Thu, 24 Sep 2020 11:51:57 +0200 From: Greg Kroah-Hartman To: "Lee, Chun-Yi" Cc: Ard Biesheuvel , linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, "Lee, Chun-Yi" , Ard Biesheuvel , Matthias Brugger , Fabian Vogt , Ilias Apalodimas , Arthur Heymans , Patrick Rudolph Subject: Re: [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction Message-ID: <20200924095157.GA304421@kroah.com> References: <20200924082833.12722-1-jlee@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200924082833.12722-1-jlee@suse.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 24, 2020 at 04:28:33PM +0800, Lee, Chun-Yi wrote: > This patch moved the logic of creating efivars mount point to the > registration of efivars abstraction. It's useful for userland to > determine the availability of efivars filesystem by checking the > existence of mount point. Why not do what all other tools do, and look in /proc/filesystems? Why is efivars "special" in this way? What tool isn't properly looking for the filesystem in that way today? > The 'efivars' platform device be created on generic EFI runtime services > platform, so it can be used to determine the availability of efivarfs. > But this approach is not available for google gsmi efivars abstraction. I do not understand this last sentence, can you try to explain it better? > This patch be tested on Here on qemu-OVMF and qemu-uboot. How about real hardware? :) > > Cc: Ard Biesheuvel > Cc: Matthias Brugger > Cc: Fabian Vogt > Cc: Ilias Apalodimas > Cc: Greg Kroah-Hartman > Cc: Arthur Heymans > Cc: Patrick Rudolph > Signed-off-by: "Lee, Chun-Yi" > --- > drivers/firmware/efi/efi.c | 7 ------- > drivers/firmware/efi/vars.c | 17 +++++++++++++++++ > 2 files changed, 17 insertions(+), 7 deletions(-) > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > index 3aa07c3b5136..23c11a2a3f4d 100644 > --- a/drivers/firmware/efi/efi.c > +++ b/drivers/firmware/efi/efi.c > @@ -405,13 +405,6 @@ static int __init efisubsys_init(void) > if (error) > goto err_remove_group; > > - /* and the standard mountpoint for efivarfs */ > - error = sysfs_create_mount_point(efi_kobj, "efivars"); > - if (error) { > - pr_err("efivars: Subsystem registration failed.\n"); > - goto err_remove_group; > - } > - > if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS)) > efi_debugfs_init(); > > diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c > index 973eef234b36..6fa7f288d635 100644 > --- a/drivers/firmware/efi/vars.c > +++ b/drivers/firmware/efi/vars.c > @@ -1179,6 +1179,8 @@ int efivars_register(struct efivars *efivars, > const struct efivar_operations *ops, > struct kobject *kobject) > { > + int error; > + > if (down_interruptible(&efivars_lock)) > return -EINTR; > > @@ -1191,6 +1193,19 @@ int efivars_register(struct efivars *efivars, > > up(&efivars_lock); > > + /* and the standard mountpoint for efivarfs */ > + if (efi_kobj) { Why test for this? Can it race? thanks, greg k-h