----- Original Message ----- > On Mon, Nov 04, 2019 at 09:28:10AM -0500, Jan Stancek wrote: > > > > > > ----- Original Message ----- > > > On Mon, Nov 04, 2019 at 08:35:51AM -0500, Jan Stancek wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > Hello, > > > > > > > > > > We ran automated tests on a recent commit from this kernel tree: > > > > > > > > > > Kernel repo: > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > > > Commit: dfe283e9fdac - Linux 5.3.9-rc1 > > > > > > > > > > The results of these automated tests are provided below. > > > > > > > > > > Overall result: FAILED (see details below) > > > > > Merge: OK > > > > > Compile: OK > > > > > Tests: FAILED > > > > > > > > > > All kernel binaries, config files, and logs are available for > > > > > download > > > > > here: > > > > > > > > > > https://artifacts.cki-project.org/pipelines/262380 > > > > > > > > > > One or more kernel tests failed: > > > > > > > > > > x86_64: > > > > > ❌ LTP lite > > > > > > > > > > > > > Not a 5.3 -stable regression. > > > > > > > > Failure comes from test that sanity checks all /proc files by doing > > > > 1k read from each. There are couple issues it hits wrt. snd_hda_*. > > > > > > > > Example reproducer: > > > > dd if=/sys/kernel/debug/regmap/hdaudioC0D3-hdaudio/access of=out.txt > > > > count=1 bs=1024 iflag=nonblock > > > > > > That's not a proc file :) > > > > Right. It's same test that's used for /proc too. > > > > > > > > > It's slow and triggers soft lockups [1]. And it also requires lot > > > > of memory, triggering OOMs on smaller VMs: > > > > 0x0000000024f0437b-0x000000001a32b1c8 1073745920 seq_read+0x131/0x400 > > > > pages=262144 vmalloc vpages N0=262144 > > > > > > > > I'm leaning towards skipping all regmap entries in this test. > > > > Comments are welcomed. > > > > > > Randomly poking around in debugfs is a sure way to cause crashes and > > > major problems. Also, debugfs files are NOT stable and only for > > > debugging and should never be enabled on "real" systems. > > > > > > So what exactly is the test trying to do here? > > > > It's (unprivileged) user trying to open/read anything it can (/proc, /sys) > > to see if that triggers anything bad. > > > > It can run as privileged user too, which was the case above. > > Sure, you can do tons of bad things as root poking around in sysfs, > debugfs, and procfs. What exactly are you trying to do, break the > system? We are talking about read-only here. Is it unreasonable to expect that root can read all /proc entries without crashing the system? Some entries are readable only by root. So an unprivileged user will skip considerable number of entries: -r--------. 1 root root 0 Nov 4 16:13 /proc/slabinfo > That sounds like a horrible test that is just setting itself up to lock > the system up, you should revisit it...
