linux-kernel - Re: [btrfs] commit bc27d6f0aa0e4de184b617aceeaf25818cc646de breaks update-grub

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Sat, 3 Feb 2024 23:03:46 +0100
From: David Sterba <dsterba@...e.cz>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Anand Jain <anand.jain@...cle.com>, Alex Romosan <aromosan@...il.com>,
	CHECK_1234543212345@...tonmail.com, brauner@...nel.org,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	linux-kernel@...r.kernel.org, Chris Mason <clm@...com>,
	Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com>,
	dsterba@...e.cz
Subject: Re: [btrfs] commit bc27d6f0aa0e4de184b617aceeaf25818cc646de breaks
 update-grub

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.