what extension provides /sys/fs/cgroup/net_cls?

[GNUser]

I'm trying to make Mullvad VPN's app work on my TCL13 x86_64 machine. I can't quite get it to work yet. I did an strace and one of the things I discovered is that the app fails to find /sys/fs/cgroup/net_cls.

How do I make this available on my machine? I already tried this but no luck:

Code: [Select]

$ tce-load -wi net-sched-5.15.10-tinycore64
$ sudo modprobe cls_cgroup
$ sudo modprobe cls_route
$ sudo modprobe cls_basic

[GNUser]

According to our kernel's config file (at http://repo.tinycorelinux.net/13.x/x86_64/release/src/kernel/config-5.15.10-tinycore64), it seems the kernel is configured to support this.

Code: [Select]

...
CONFIG_NET_CLS=y
...

Currently, my system has a /sys/fs/cgroup directory but it is empty.

[GNUser]

Oh, sorry. I need to pay more attention. The problem is not the absence of this directory. Per strace, the problem is that this directory fails to be created. From the strace:

Code: [Select]

mkdir("/sys/fs/cgroup/net_cls", 0777)   = -1 ENOENT (No such file or directory)

Indeed, the /sys/fs/cgroup/ directory exists on my system, but creating the needed subdirectory is not allowed even if I try manually:

Code: [Select]

$ sudo mkdir /sys/fs/cgroup/net_cls
mkdir: can't create directory '/sys/fs/cgroup/net_cls': No such file or directoryThe Mullvad VPN daemon is running as root and assumes it should be able to create this directory. What gives?

[Rich]

Hi GNUser
Trying to create the directory as root I got this:

Code: [Select]

root@E310:/home/tc# mkdir /sys/fs/cgroup/net_cls
mkdir: cannot create directory '/sys/fs/cgroup/net_cls': No such file or directory
The cgroup directory is read only, so I tried this:

Code: [Select]

root@E310:/home/tc# chmod 755 /sys/fs/cgroup
chmod: changing permissions of '/sys/fs/cgroup': Operation not permitted
Some searching online turned up this:

Code: [Select]

root@E310:/home/tc# mount -t cgroup -o all cgroup /sys/fs/cgroupfound here:
https://man7.org/linux/man-pages/man7/cgroups.7.html

Now I could do this this without errors:

Code: [Select]

root@E310:/home/tc# mkdir /sys/fs/cgroup/net_cls
root@E310:/home/tc# rmdir /sys/fs/cgroup/net_cls
root@E310:/home/tc# umount /sys/fs/cgroup
root@E310:/home/tc#

[GNUser]

Some searching online turned up this:

Code: [Select]

root@E310:/home/tc# mount -t cgroup -o all cgroup /sys/fs/cgroupfound here:
https://man7.org/linux/man-pages/man7/cgroups.7.html

I can confirm that after entering that command, the mullvad daemon works as expected. Thank you very much. It seems that on other distros that directory must be writable by default.

You're the best, Rich!

[Rich]

Hi GNUser
It seems  /sys/fs/cgroup  is not really usable until it gets mounted, even though it is visible.
The mkdir error states the directory doesn't even exist.

Even after mounting, the directory is listed as executable and read only:

Code: [Select]

root@E310:~# ls -l /sys/fs/ | grep cgroup
dr-xr-xr-x 2 root root 0 Nov 12 10:07 cgroup
root@E310:~# Yet you can now write to it.

[gadget42]

that's some manpage!
re:
https://man7.org/linux/man-pages/man7/cgroups.7.html

also the rabbithole led to:
https://www.kernel.org/doc/man-pages/
https://man7.org/tlpi/
https://man7.org/tlpi/purchase.html
https://nostarch.com/tlpi/

as well as this particular book review(2013):
https://www.amazon.com/gp/customer-reviews/R1IVGSAJQC0S02/

...
For example, on page 246, where Michael discusses Direct I/O, he says:

"If a file is opened with O_DIRECT by one process, and opened normally (i.e. so that the buffer cache is used) by another process, then there is no coherency between the contents of the buffer cache and the data read or written via direct I/O. Such scenarios should be avoided."

Wow. In just one sentence, Michael tells us one of the fundamental issues with concurrent I/O, and that by simultaneously using different I/O mechanisms, you can corrupt your files.
...