----- Original Message ----- > On Mon, Nov 04, 2019 at 10:25:21AM -0500, Jan Stancek wrote: > > > > ----- 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? > > You are NOT reading /proc/ here. No. That was a general question to usefulness of privileged read, using /proc as example where it commonly happens. > You are reading debugfs which you > really have NOT idea what is in there. As you saw, you are reading from > hardware that is slow and doing odd things when you read from it. Agreed, I already sent a patch to LTP to blacklist it. > And yes, there are some /proc/ files that you should not read from as > root and expect things to always work. PCI devices are notorious for > this, and if you are reading those files as root, you "know" you know > what you are doing and can accept the risk for when things go wrong. > > It is fine to write tests to read specific /proc/ files that you know > what is happening in them. To pick random ones is never a good idea. Thanks for example.
