Hi all,
Today's linux-next merge of the vfs-brauner tree got a conflict in:
fs/btrfs/super.c
between commit:
2f2cfead5107 ("btrfs: remove old mount API code")
from the btrfs tree and commit:
ead622674df5 ("btrfs: Do not restrict writes to btrfs devices")
from the vfs-brauner tree.
I fixed it up (the former removed the funtion updated by the latter, but
a further fix may be required to implement the intent of the latter?) 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.
--
Cheers,
Stephen Rothwell
Hi Stephen (and other maintainers),
On Mon, Nov 27, 2023 at 09:20:01AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
>
> fs/btrfs/super.c
>
> between commit:
>
> 2f2cfead5107 ("btrfs: remove old mount API code")
>
> from the btrfs tree and commit:
>
> ead622674df5 ("btrfs: Do not restrict writes to btrfs devices")
>
> from the vfs-brauner tree.
>
> I fixed it up (the former removed the funtion updated by the latter, but
> a further fix may be required to implement the intent of the latter?)
Yes, the lack of ead622674df5 appears to cause issues with mounting
btrfs volumes on at least next-20231128 due to the presence of commit
6f861765464f ("fs: Block writes to mounted block devices"). In QEMU, I
can see:
:: running early hook [udev]
Warning: /lib/modules/6.7.0-rc3-next-20231128/modules.devname not found - ignoring
Starting systemd-udevd version 252.5-1-arch
:: running hook [udev]
:: Triggering uevents...
:: running hook [keymap]
:: Loading keymap...kbd_mode: KDSKBMODE: Inappropriate ioctl for device
done.
:: performing fsck on '/dev/vda2'
:: mounting '/dev/vda2' on real root
mount: /new_root: wrong fs type, bad option, bad superblock on /dev/vda2, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
[rootfs ]#
The following diff allows my VM to boot properly but I am not sure if
there is a better or more proper fix (I am already out of my element
heh). If a proper merge solution cannot be found quickly, can
6f861765464f be reverted in the meantime so that all my machines with
btrfs can boot properly? :)
Cheers,
Nathan
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 99d10a25a579..23db0306b8ef 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -299,6 +299,7 @@ static int btrfs_parse_param(struct fs_context *fc,
case Opt_device: {
struct btrfs_device *device;
blk_mode_t mode = sb_open_mode(fc->sb_flags);
+ mode &= ~BLK_OPEN_RESTRICT_WRITES;
mutex_lock(&uuid_mutex);
device = btrfs_scan_one_device(param->string, mode, false);
@@ -1801,6 +1802,8 @@ static int btrfs_get_tree_super(struct fs_context *fc)
blk_mode_t mode = sb_open_mode(fc->sb_flags);
int ret;
+ mode &= ~BLK_OPEN_RESTRICT_WRITES;
+
btrfs_ctx_to_info(fs_info, ctx);
mutex_lock(&uuid_mutex);
On Tue 28-11-23 14:33:44, Nathan Chancellor wrote:
> Hi Stephen (and other maintainers),
>
> On Mon, Nov 27, 2023 at 09:20:01AM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the vfs-brauner tree got a conflict in:
> >
> > fs/btrfs/super.c
> >
> > between commit:
> >
> > 2f2cfead5107 ("btrfs: remove old mount API code")
> >
> > from the btrfs tree and commit:
> >
> > ead622674df5 ("btrfs: Do not restrict writes to btrfs devices")
> >
> > from the vfs-brauner tree.
> >
> > I fixed it up (the former removed the funtion updated by the latter, but
> > a further fix may be required to implement the intent of the latter?)
>
> Yes, the lack of ead622674df5 appears to cause issues with mounting
> btrfs volumes on at least next-20231128 due to the presence of commit
> 6f861765464f ("fs: Block writes to mounted block devices"). In QEMU, I
> can see:
>
> :: running early hook [udev]
> Warning: /lib/modules/6.7.0-rc3-next-20231128/modules.devname not found - ignoring
> Starting systemd-udevd version 252.5-1-arch
> :: running hook [udev]
> :: Triggering uevents...
> :: running hook [keymap]
> :: Loading keymap...kbd_mode: KDSKBMODE: Inappropriate ioctl for device
> done.
> :: performing fsck on '/dev/vda2'
> :: mounting '/dev/vda2' on real root
> mount: /new_root: wrong fs type, bad option, bad superblock on /dev/vda2, missing codepage or helper program, or other error.
> dmesg(1) may have more information after failed mount system call.
> You are now being dropped into an emergency shell.
> sh: can't access tty; job control turned off
> [rootfs ]#
>
> The following diff allows my VM to boot properly but I am not sure if
> there is a better or more proper fix (I am already out of my element
> heh). If a proper merge solution cannot be found quickly, can
> 6f861765464f be reverted in the meantime so that all my machines with
> btrfs can boot properly? :)
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 99d10a25a579..23db0306b8ef 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -299,6 +299,7 @@ static int btrfs_parse_param(struct fs_context *fc,
> case Opt_device: {
> struct btrfs_device *device;
> blk_mode_t mode = sb_open_mode(fc->sb_flags);
> + mode &= ~BLK_OPEN_RESTRICT_WRITES;
>
> mutex_lock(&uuid_mutex);
> device = btrfs_scan_one_device(param->string, mode, false);
> @@ -1801,6 +1802,8 @@ static int btrfs_get_tree_super(struct fs_context *fc)
> blk_mode_t mode = sb_open_mode(fc->sb_flags);
> int ret;
>
> + mode &= ~BLK_OPEN_RESTRICT_WRITES;
> +
> btrfs_ctx_to_info(fs_info, ctx);
> mutex_lock(&uuid_mutex);
This looks like the proper resolution. Basically btrfs needs to strip
BLK_OPEN_RESTRICT_WRITES from the mode provided by sb_open_mode(). Thanks
for writing it!
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Hi all,
On Wed, 29 Nov 2023 12:09:30 +0100 Jan Kara <[email protected]> wrote:
>
> On Tue 28-11-23 14:33:44, Nathan Chancellor wrote:
> > Hi Stephen (and other maintainers),
> >
> > On Mon, Nov 27, 2023 at 09:20:01AM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the vfs-brauner tree got a conflict in:
> > >
> > > fs/btrfs/super.c
> > >
> > > between commit:
> > >
> > > 2f2cfead5107 ("btrfs: remove old mount API code")
> > >
> > > from the btrfs tree and commit:
> > >
> > > ead622674df5 ("btrfs: Do not restrict writes to btrfs devices")
> > >
> > > from the vfs-brauner tree.
> > >
> > > I fixed it up (the former removed the funtion updated by the latter, but
> > > a further fix may be required to implement the intent of the latter?)
> >
> > Yes, the lack of ead622674df5 appears to cause issues with mounting
> > btrfs volumes on at least next-20231128 due to the presence of commit
> > 6f861765464f ("fs: Block writes to mounted block devices"). In QEMU, I
> > can see:
> >
> > :: running early hook [udev]
> > Warning: /lib/modules/6.7.0-rc3-next-20231128/modules.devname not found - ignoring
> > Starting systemd-udevd version 252.5-1-arch
> > :: running hook [udev]
> > :: Triggering uevents...
> > :: running hook [keymap]
> > :: Loading keymap...kbd_mode: KDSKBMODE: Inappropriate ioctl for device
> > done.
> > :: performing fsck on '/dev/vda2'
> > :: mounting '/dev/vda2' on real root
> > mount: /new_root: wrong fs type, bad option, bad superblock on /dev/vda2, missing codepage or helper program, or other error.
> > dmesg(1) may have more information after failed mount system call.
> > You are now being dropped into an emergency shell.
> > sh: can't access tty; job control turned off
> > [rootfs ]#
> >
> > The following diff allows my VM to boot properly but I am not sure if
> > there is a better or more proper fix (I am already out of my element
> > heh). If a proper merge solution cannot be found quickly, can
> > 6f861765464f be reverted in the meantime so that all my machines with
> > btrfs can boot properly? :)
> >
> > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> > index 99d10a25a579..23db0306b8ef 100644
> > --- a/fs/btrfs/super.c
> > +++ b/fs/btrfs/super.c
> > @@ -299,6 +299,7 @@ static int btrfs_parse_param(struct fs_context *fc,
> > case Opt_device: {
> > struct btrfs_device *device;
> > blk_mode_t mode = sb_open_mode(fc->sb_flags);
> > + mode &= ~BLK_OPEN_RESTRICT_WRITES;
> >
> > mutex_lock(&uuid_mutex);
> > device = btrfs_scan_one_device(param->string, mode, false);
> > @@ -1801,6 +1802,8 @@ static int btrfs_get_tree_super(struct fs_context *fc)
> > blk_mode_t mode = sb_open_mode(fc->sb_flags);
> > int ret;
> >
> > + mode &= ~BLK_OPEN_RESTRICT_WRITES;
> > +
> > btrfs_ctx_to_info(fs_info, ctx);
> > mutex_lock(&uuid_mutex);
>
> This looks like the proper resolution. Basically btrfs needs to strip
> BLK_OPEN_RESTRICT_WRITES from the mode provided by sb_open_mode(). Thanks
> for writing it!
I have added this patch as a merge fix from today.
--
Cheers,
Stephen Rothwell
Hi all,
On Thu, 30 Nov 2023 07:50:21 +1100 Stephen Rothwell <[email protected]> wrote:
>
> On Wed, 29 Nov 2023 12:09:30 +0100 Jan Kara <[email protected]> wrote:
> >
> > On Tue 28-11-23 14:33:44, Nathan Chancellor wrote:
> > > Hi Stephen (and other maintainers),
> > >
> > > On Mon, Nov 27, 2023 at 09:20:01AM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > Today's linux-next merge of the vfs-brauner tree got a conflict in:
> > > >
> > > > fs/btrfs/super.c
> > > >
> > > > between commit:
> > > >
> > > > 2f2cfead5107 ("btrfs: remove old mount API code")
> > > >
> > > > from the btrfs tree and commit:
> > > >
> > > > ead622674df5 ("btrfs: Do not restrict writes to btrfs devices")
> > > >
> > > > from the vfs-brauner tree.
> > > >
> > > > I fixed it up (the former removed the funtion updated by the latter, but
> > > > a further fix may be required to implement the intent of the latter?)
> > >
> > > Yes, the lack of ead622674df5 appears to cause issues with mounting
> > > btrfs volumes on at least next-20231128 due to the presence of commit
> > > 6f861765464f ("fs: Block writes to mounted block devices"). In QEMU, I
> > > can see:
> > >
> > > :: running early hook [udev]
> > > Warning: /lib/modules/6.7.0-rc3-next-20231128/modules.devname not found - ignoring
> > > Starting systemd-udevd version 252.5-1-arch
> > > :: running hook [udev]
> > > :: Triggering uevents...
> > > :: running hook [keymap]
> > > :: Loading keymap...kbd_mode: KDSKBMODE: Inappropriate ioctl for device
> > > done.
> > > :: performing fsck on '/dev/vda2'
> > > :: mounting '/dev/vda2' on real root
> > > mount: /new_root: wrong fs type, bad option, bad superblock on /dev/vda2, missing codepage or helper program, or other error.
> > > dmesg(1) may have more information after failed mount system call.
> > > You are now being dropped into an emergency shell.
> > > sh: can't access tty; job control turned off
> > > [rootfs ]#
> > >
> > > The following diff allows my VM to boot properly but I am not sure if
> > > there is a better or more proper fix (I am already out of my element
> > > heh). If a proper merge solution cannot be found quickly, can
> > > 6f861765464f be reverted in the meantime so that all my machines with
> > > btrfs can boot properly? :)
> > >
> > > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> > > index 99d10a25a579..23db0306b8ef 100644
> > > --- a/fs/btrfs/super.c
> > > +++ b/fs/btrfs/super.c
> > > @@ -299,6 +299,7 @@ static int btrfs_parse_param(struct fs_context *fc,
> > > case Opt_device: {
> > > struct btrfs_device *device;
> > > blk_mode_t mode = sb_open_mode(fc->sb_flags);
> > > + mode &= ~BLK_OPEN_RESTRICT_WRITES;
> > >
> > > mutex_lock(&uuid_mutex);
> > > device = btrfs_scan_one_device(param->string, mode, false);
> > > @@ -1801,6 +1802,8 @@ static int btrfs_get_tree_super(struct fs_context *fc)
> > > blk_mode_t mode = sb_open_mode(fc->sb_flags);
> > > int ret;
> > >
> > > + mode &= ~BLK_OPEN_RESTRICT_WRITES;
> > > +
> > > btrfs_ctx_to_info(fs_info, ctx);
> > > mutex_lock(&uuid_mutex);
> >
> > This looks like the proper resolution. Basically btrfs needs to strip
> > BLK_OPEN_RESTRICT_WRITES from the mode provided by sb_open_mode(). Thanks
> > for writing it!
>
> I have added this patch as a merge fix from today.
This is now a conflict between the btrfs tree and Linus' tree.
--
Cheers,
Stephen Rothwell