rr does not work with ALSA (blocks access to /usr/share/alsa/alsa.conf)

[Hi-Angel]

Stumbled upon it while trying to debug pipewire.

Steps to reproduce

 λ head /usr/share/alsa/alsa.conf
#
#  ALSA library configuration file
#

# pre-load the configuration files

@hooks [
        {
                func load
                files [
 λ rr record head /usr/share/alsa/alsa.conf
rr: Saving execution to trace directory `/tmp/head-1'.
head: cannot open '/usr/share/alsa/alsa.conf' for reading: No such file or directory

Expected

The output of the second run of the head app would be the same as of the first run.

Actual

The second run of the head app, which is under rr record, prints an error that it couldn't open alsa.conf file.

Additional information

Recording ls the same way works fine:

 λ rr record ls /usr/share/alsa/alsa.conf
rr: Saving execution to trace directory `/tmp/ls-0'.
/usr/share/alsa/alsa.conf

The directory in question doesn't have any special mount (mount output attached below), and I have no problem under rr record with reading for example /etc/fstab which is located on the same filesystem.

Version

Tested on older rr 5.4.0.r107.gf7c3d17b-1 as well as yesterday git 5.4.0.r187.ge613d1a9-1

Lunux kernel: 5.12.4-arch1-1 (with v2 of multi-LRU patches, hopefully it doesn't matter).

mount

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=4007088k,nr_inodes=1001772,mode=755,inode64)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755,inode64)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda4 on / type btrfs (rw,noatime,compress=zstd:3,space_cache,autodefrag,subvolid=5,subvol=/)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=15432)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=4021072k,nr_inodes=409600,inode64)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=804212k,nr_inodes=201053,mode=700,uid=1000,gid=1000,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sda4 on /export/bds type btrfs (rw,noatime,compress=zstd:3,space_cache,autodefrag,subvolid=5,subvol=/)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)

[Hi-Angel]

FTR, in case it's something with kernel I tried to reproduce that on another laptop, but stumbled upon a separate issue #2872

[rocallahan]

We're disabling access to alsa.conf intentionally: 0c275bf

You could try removing that, but then rr might not work. I don't know how ALSA communicates with userspace. If it involves kernel writes to memory shared with userspace, that won't work.

[Hi-Angel]

Thanks!

We're disabling access to alsa.conf intentionally: 0c275bf

I'm not quite clear from the commit: why is that?

You could try removing that, but then rr might not work. I don't know how ALSA communicates with userspace. If it involves kernel writes to memory shared with userspace, that won't work.

So, if I was to debug an app using iouring, that would not work?

[rocallahan]

I'm not quite clear from the commit: why is that?

I don't know exactly. Presumably at the time we just wanted to get Firefox working in rr and it wasn't working with ALSA for some reason. It might possibly work now (but I doubt it).

Currently we don't support io_uring either. That's #2613. It can be made to work but we need to make rr mediate between the application and the kernel.

[napaalm]

You could try removing that, but then rr might not work.

@rocallahan I just tried and rr still doesn't work with a binary that uses ALSA. Would it be difficult to solve this limitation?

[rocallahan]

You can try this patch:

diff --git a/src/preload/preload_interface.h b/src/preload/preload_interface.h
index 986fe011..46a9fda9 100644
--- a/src/preload/preload_interface.h
+++ b/src/preload/preload_interface.h
@@ -670,7 +670,6 @@ inline static long stored_record_size(size_t length) {
 inline static int is_blacklisted_filename(const char* filename) {
   const char* f;
   if (strprefix("/dev/dri/", filename) || streq("/dev/nvidiactl", filename) ||
-      streq("/usr/share/alsa/alsa.conf", filename) ||
       streq("/dev/nvidia-uvm", filename)) {
     return 1;
   }

But my understanding is that ALSA uses shared memory mappings shared between the kernel and userspace. Handling that with rr is a lot of work. I'm not that motivated to do it. If someone else is feeling ambitious, I could talk them through it.