Received-SPF: pass (google.com: domain of linux-kernel+bounces-51308-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Sat, 3 Feb 2024 23:03:46 +0100
From: David Sterba <dsterba@suse.cz>
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: Anand Jain <anand.jain@oracle.com>, Alex Romosan <aromosan@gmail.com>,
	CHECK_1234543212345@protonmail.com, brauner@kernel.org,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	linux-kernel@vger.kernel.org, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>, David Sterba <dsterba@suse.com>,
	dsterba@suse.cz
Subject: Re: [btrfs] commit bc27d6f0aa0e4de184b617aceeaf25818cc646de breaks
 update-grub
Message-ID: <20240203220346.GA355@twin.jikos.cz>
Reply-To: dsterba@suse.cz
References: <CAKLYgeJ1tUuqLcsquwuFqjDXPSJpEiokrWK2gisPKDZLs8Y2TQ@mail.gmail.com>
 <39e3a4fe-d456-4de4-b481-51aabfa02b8d@leemhuis.info>
 <20240111155056.GG31555@twin.jikos.cz>
 <20240111170644.GK31555@twin.jikos.cz>
 <f45e5b7c-4354-87d3-c7f1-d8dd5f4d2abd@oracle.com>
 <7d3cee75-ee74-4348-947a-7e4bce5484b2@leemhuis.info>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7d3cee75-ee74-4348-947a-7e4bce5484b2@leemhuis.info>
User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12)

On Thu, Feb 01, 2024 at 11:25:28AM +0100, Linux regression tracking (Thorsten Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
> 
> Anand, what's the status wrt to below issue (which afaics seems to
> affect quite a few people)? Things look stalled, but I might be missing
> something, that's why I ask for a quick update.

Yeah it's affecting people and not stalled but we ran out of ideas.

I'll present the latest fix that works for me (similar setup as the
reporter), though not everybody may like it:

--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -2360,6 +2360,7 @@ static int btrfs_unfreeze(struct super_block *sb)
 static int btrfs_show_devname(struct seq_file *m, struct dentry *root)
 {
        struct btrfs_fs_info *fs_info = btrfs_sb(root->d_sb);
+       char real[4096] = { "/dev/" };
 
        /*
         * There should be always a valid pointer in latest_dev, it may be stale
@@ -2367,7 +2368,8 @@ static int btrfs_show_devname(struct seq_file *m, struct dentry *root)
         * the end of RCU grace period.
         */
        rcu_read_lock();
-       seq_escape(m, btrfs_dev_name(fs_info->fs_devices->latest_dev), " \t\n\\");
+       scnprintf(real + 5, sizeof(real) - 5, "%pg", fs_info->fs_devices->latest_dev->bdev);
+       seq_puts(m, real);
        rcu_read_unlock();
 
        return 0;
---

The problem that was reported was a discrepancy in what show_devname
returned (/proc/self/mountinfo) and what eg. mount showed. Both resolve
the device name in a different way. The problem is that mountinfo relies
on what btrfs remembers as the device path that was passed during
scanning && at the mount time. Since then it's not updated due to
changes done in 6.7 for temp_fsid (single devices don't have any cached
representation of the device, so the new path is basically forgotten).

What the fix does: print the path of the same block device but not the
cached (possibly stale) value.