On Thu, Oct 26, 2023 at 08:00:20PM +0300, a...@me.com wrote:
> Package: btrfs-progs
The bug in question is in the kernel, not in btrfs-progs (but see below).
> sudo find "/dev/snd" -exec btrfs prop set {} compression zstd \;
> Causing stuck on /dev/snd/pcmC1D0p file and insta reboots in 5 mins.
> ls -al /dev/snd/pcmC1D0p
> crw-rw----+ 1 root audio 116, 5 окт 26 19:37 /dev/snd/pcmC1D0p
This is very clearly not a btrfs filesystem. The driver associated with
the device in question (ie, your sound card) should either accept the
request or cleanly reject it, not crash the whole machine.
If you could say what driver is responsible for the sound card in your
machine, it'd be possible to fix the crash. This information can be found
eg. in /proc/asound/cards or other files there.
What btrfs-progs are doing here is setting an xattr named btrfs.compression
(with a value that you provide); unlike ioctls which are at risk of having
a different meaning for an unrelated device, that xattr is cleanly
namespaced. Thus, my guess is that your sound card's driver will crash
for any xattr whose name it doesn't understand.
You don't need btrfs-progs to reproduce that, you could set the xattr
directly (via the setfattr command), copy it via some backup tool (rsync
in particular teaches people to use -X or lose the ability to use /bin/ping
etc), etc. And this is (kind of) an unprivileged operation...
The real bug aside, there's a question whether btrfs-progs should protect
the user and fstatfs() every file it processes. That could be reasonable
but could break remote filesystems from transporting this setting (I don't
know if they do).
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up. This
⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project.
⠈⠳⣄⠀⠀⠀⠀
