linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: joeyli <jlee@suse.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: "Lee, Chun-Yi" <joeyli.kernel@gmail.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matthias Brugger <mbrugger@suse.com>,
	Fabian Vogt <fvogt@suse.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>
Subject: Re: [PATCH v2] efi/efivars: Create efivars mount point via efivars abstraction
Date: Fri, 28 Aug 2020 00:14:41 +0800	[thread overview]
Message-ID: <20200827161441.GH7501@linux-l9pv.suse> (raw)
In-Reply-To: <20200826155633.GC7501@linux-l9pv.suse>

On Wed, Aug 26, 2020 at 11:56:33PM +0800, Joey Lee wrote:
> Hi Ard,
> 
> On Wed, Aug 26, 2020 at 02:08:18PM +0200, Ard Biesheuvel wrote:
> > On Wed, 26 Aug 2020 at 02:46, Lee, Chun-Yi <joeyli.kernel@gmail.com> wrote:
> > >
> > > This patch creates efivars mount point when active efivars abstraction
> > > be set. It is useful for userland to determine the availability of efivars
> > > filesystem.
> > >
> > > Cc: Matthias Brugger <mbrugger@suse.com>
> > > Cc: Fabian Vogt <fvogt@suse.com>
> > > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > Cc: Ard Biesheuvel <ardb@kernel.org>
> > > Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
> > 
> > Apologies for not bringing this up before: while the patch seems fine,
> > I wonder if we really need this if the purpose is to decide whether
> > efivars is available or not. We already have the 'efivars' platform
> > device for this, and so userland can simply check for the existence of
> > 
> > /sys/devices/platform/efivars.0
> > 
> > and so we don't need to make any changes for this.
> > 
> 
> The platform device only be registered on generic EFI runtime services
> platform. If the efivars abstraction is google gsmi, then userland can
> not use efivars.0 to detectmine the availability of efivars filesystem.
> 
> If we only consider generic EFI platform, then efivars.0 is good enough.
> But if the gsmi implementation joins this game, then my patch should not
> blocks the creation of efivars mount point because gsmi_kobj is not
> initialized yet.
> 
> Maybe the creation of efivars mount point can be moved to
> efivars_register(), after the kobject be set. Then gsmi can also create
> mount point. How do you think?
> 

Here is the patch for my concept. I simply tested on qemu-OVMF and
qemu-uboot.

From 7c81d3f058a177bb17c4589fe1863b79940f94c3 Mon Sep 17 00:00:00 2001
From: "Lee, Chun-Yi" <jlee@suse.com>
Date: Fri, 28 Aug 2020 00:05:22 +0800
Subject: [PATCH] efi/efivars: Create efivars mount point in the registration
 of efivars abstraction

This patch moved the logic of creating efivars mount point to the registration
of efivars abstraction. It is useful for userland to determine the availability
of efivars filesystem by checking the existence of mount point.

Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
---
 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) {
+		error = sysfs_create_mount_point(efi_kobj, "efivars");
+		if (error) {
+			if (down_interruptible(&efivars_lock))
+				return -EINTR;
+			__efivars = NULL;
+			up(&efivars_lock);
+			pr_err("efivars: Subsystem registration failed.\n");
+			return error;
+		}
+	}
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(efivars_register);
@@ -1222,6 +1237,8 @@ int efivars_unregister(struct efivars *efivars)
 
 	pr_info("Unregistered efivars operations\n");
 	__efivars = NULL;
+	if (efi_kobj)
+		sysfs_remove_mount_point(efi_kobj, "efivars");
 
 	rv = 0;
 out:
-- 
2.16.4

Thanks a lot!
Joey Lee

> On the other hand, the efisubsys_init() does not unregister efivars.0
> platform device in err_unregister block. It causes that efivars and
> efi-pstore be loaded when no generic_ops.
> 
> Let me know if I miss understood any thing, please.
> 
> 
> > 
> > 
> > > ---
> > >
> > > v2:
> > > Using efivars_kobject() helper instead of checking GetVariable or
> > > GetNextVariable EFI runtime services. Because the efivarfs code could be
> > > instantiated using a different efivars abstraction.
> > >
> > >  drivers/firmware/efi/efi.c | 12 +++++++-----
> > >  1 file changed, 7 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > > index 3aa07c3b5136..db483fc68501 100644
> > > --- a/drivers/firmware/efi/efi.c
> > > +++ b/drivers/firmware/efi/efi.c
> > > @@ -405,11 +405,13 @@ 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 (efivars_kobject()) {
> > > +               /* 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))
> > > --
> > > 2.16.4
> > >


  reply	other threads:[~2020-08-27 16:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-26  0:46 [PATCH v2] efi/efivars: Create efivars mount point via efivars abstraction Lee, Chun-Yi
2020-08-26 12:08 ` Ard Biesheuvel
2020-08-26 15:56   ` joeyli
2020-08-27 16:14     ` joeyli [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-08-25 16:07 Lee, Chun-Yi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200827161441.GH7501@linux-l9pv.suse \
    --to=jlee@suse.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ardb@kernel.org \
    --cc=fvogt@suse.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=joeyli.kernel@gmail.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbrugger@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).