public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Masahisa Kojima <masahisa.kojima@linaro.org>
Subject: Re: linux-next: manual merge of the efi tree with the efi-fixes tree
Date: Mon, 11 Dec 2023 15:39:05 +1100	[thread overview]
Message-ID: <20231211153905.6cbf7dcb@canb.auug.org.au> (raw)
In-Reply-To: <20231211151303.1286eda5@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 3581 bytes --]

Hi all,

On Mon, 11 Dec 2023 15:13:03 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the efi tree got a conflict in:
> 
>   fs/efivarfs/super.c
> 
> between commits:
> 
>   0b6d38bdd6f8 ("efivarfs: Free s_fs_info on unmount")
>   ab5c4251a009 ("efivarfs: Move efivarfs list into superblock s_fs_info")
> 
> from the efi-fixes tree and commit:
> 
>   b501d5b36f58 ("efivarfs: automatically update super block flag")
> 
> from the efi tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Actually the below is needed. ("info" is not a great name for, even a
static, global variable.  And maybe what I have called "einfo" could be
"sfi" like in efivarfs_kill_sb() ...)
-- 
Cheers,
Stephen Rothwell

diff --cc fs/efivarfs/super.c
index d7d9a3e189a0,42eff5ac7ab4..d209475a8a49
--- a/fs/efivarfs/super.c
+++ b/fs/efivarfs/super.c
@@@ -18,6 -20,32 +20,30 @@@
  
  #include "internal.h"
  
 -LIST_HEAD(efivarfs_list);
 -
+ struct efivarfs_info {
+ 	struct super_block *sb;
+ 	struct notifier_block nb;
+ };
+ 
+ static struct efivarfs_info info;
+ 
+ static int efivarfs_ops_notifier(struct notifier_block *nb, unsigned long event,
+ 				 void *data)
+ {
+ 	switch (event) {
+ 	case EFIVAR_OPS_RDONLY:
+ 		info.sb->s_flags |= SB_RDONLY;
+ 		break;
+ 	case EFIVAR_OPS_RDWR:
+ 		info.sb->s_flags &= ~SB_RDONLY;
+ 		break;
+ 	default:
+ 		return NOTIFY_DONE;
+ 	}
+ 
+ 	return NOTIFY_OK;
+ }
+ 
  static void efivarfs_evict_inode(struct inode *inode)
  {
  	clear_inode(inode);
@@@ -290,7 -317,6 +316,7 @@@ static int efivarfs_parse_param(struct 
  
  static int efivarfs_fill_super(struct super_block *sb, struct fs_context *fc)
  {
- 	struct efivarfs_fs_info *info = sb->s_fs_info;
++	struct efivarfs_fs_info *einfo = sb->s_fs_info;
  	struct inode *inode = NULL;
  	struct dentry *root;
  	int err;
@@@ -316,10 -345,17 +342,16 @@@
  	if (!root)
  		return -ENOMEM;
  
+ 	info.sb = sb;
+ 	info.nb.notifier_call = efivarfs_ops_notifier;
+ 	err = blocking_notifier_chain_register(&efivar_ops_nh, &info.nb);
+ 	if (err)
+ 		return err;
+ 
 -	INIT_LIST_HEAD(&efivarfs_list);
 -
 -	err = efivar_init(efivarfs_callback, (void *)sb, true, &efivarfs_list);
 +	err = efivar_init(efivarfs_callback, (void *)sb, true,
- 			  &info->efivarfs_list);
++			  &einfo->efivarfs_list);
  	if (err)
- 		efivar_entry_iter(efivarfs_destroy, &info->efivarfs_list, NULL);
 -		efivar_entry_iter(efivarfs_destroy, &efivarfs_list, NULL);
++		efivar_entry_iter(efivarfs_destroy, &einfo->efivarfs_list, NULL);
  
  	return err;
  }
@@@ -357,13 -399,15 +400,15 @@@ static int efivarfs_init_fs_context(str
  
  static void efivarfs_kill_sb(struct super_block *sb)
  {
 +	struct efivarfs_fs_info *sfi = sb->s_fs_info;
 +
+ 	blocking_notifier_chain_unregister(&efivar_ops_nh, &info.nb);
+ 	info.sb = NULL;
  	kill_litter_super(sb);
  
 -	if (!efivar_is_available())
 -		return;
 -
  	/* Remove all entries and destroy */
 -	efivar_entry_iter(efivarfs_destroy, &efivarfs_list, NULL);
 +	efivar_entry_iter(efivarfs_destroy, &sfi->efivarfs_list, NULL);
 +	kfree(sfi);
  }
  
  static struct file_system_type efivarfs_type = {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2023-12-11  4:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-11  4:13 linux-next: manual merge of the efi tree with the efi-fixes tree Stephen Rothwell
2023-12-11  4:39 ` Stephen Rothwell [this message]
2023-12-11  9:22   ` Ard Biesheuvel
  -- strict thread matches above, loose matches on Subject: below --
2023-05-30  4:32 Stephen Rothwell

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=20231211153905.6cbf7dcb@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=ardb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=masahisa.kojima@linaro.org \
    /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