On 2025-05-06 18:51:04 +0100, Al Viro wrote:
> On Tue, May 06, 2025 at 07:47:29PM +0200, Klara Modin wrote:
> > On 2025-05-06 18:25:39 +0100, Al Viro wrote:
> > > On Tue, May 06, 2025 at 03:36:03PM +0200, Klara Modin wrote:
> > >
> > > > 25: 49 8b 44 24 60 mov 0x60(%r12),%rax
> > > rax = fc->root
> > > > 2a:* 48 8b 78 68 mov 0x68(%rax),%rdi <-- trapping instruction
> > > rdi = rax->d_sb, hitting rax == 0
> > >
> > > > > - mnt = fc_mount(dup_fc);
> > > > > - if (IS_ERR(mnt)) {
> > > > > - put_fs_context(dup_fc);
> > > > > - return PTR_ERR(mnt);
> > > > > + ret = vfs_get_tree(dup_fc);
> > > > > + if (!ret) {
> > > > > + ret = btrfs_reconfigure_for_mount(dup_fc);
> > > > > + up_write(&fc->root->d_sb->s_umount);
> > >
> > > ... here. D'oh... Should be dup_fc, obviously - fc->root hadn't been
> > > set yet. Make that line
> > > up_write(&dup_fc->root->d_sb->s_umount);
> > > and see if it helps. Sorry about the braino...
> >
> > Thanks, that fixes the oops for me.
> >
> > Though now I hit another issue which I don't know if it's related or
> > not. I'm using an overlay mount with squashfs as lower and btrfs as
> > upper. The mount fails with invalid argument and I see this in the log:
> >
> > overlayfs: failed to clone upperpath
>
> Seeing that you already have a kernel with that thing reverted, could
> you check if the problem exists there?
Yeah, it works fine with the revert instead.
