The the added test for exception from exception corner case.
"BUG: spinlock lockup" fails to respect panic_on_warn and panic
after printing report (though, it's a BUG already, so it should
have been paniced even without panic_on_warn).
As the result we got "spinlock lockup" followed by "rcu stall" report.
And we have that special exception for rcu stalls b/c for them
the most of the report is irrelevant up to apic_timer_interrupt frame.
The code did not expect this weird double-report case and skipped
everything up to apic_timer_interrupt, though it's actually
a lockup in netfilter code.
The new manager config argument workdir_template refers to a directory. Optional.
Each VM will get a recursive copy of the files that are present in workdir_template.
VM config can then use these private copies as needed. The copy directory
can be referenced with "{{TEMPLATE}}" string. This is different from using
the files directly in that each instance will get own clean, private,
scratch copy of the files. Currently supported only for qemu_args argument
of qemu VM type. Use example:
Create a template dir with necessary files:
$ mkdir /mytemplatedir
$ truncate -s 64K /mytemplatedir/fd
Then specify the dir in the manager config:
"workdir_template": "/mytemplatedir"
Then use these files in VM config:
"qemu_args": "-fda {{TEMPLATE}}/fd"
Enable /dev/tty{1-6}. These seem to be special.
Few first connected to framebuffers. But the rest
seem to be different from e.g. tty20 anyway.
Also /dev/tty is different from the rest.
/dev/ttyS3 and /dev/ttyprintk are different.
Properly pair BSD pty terminals.
fops_probe utility helps to understand what file_operations callbacks
are attached to a particular file. Requries KCOV and KALLSYMS.
Build with:
g++ tools/fops_probe/fops_probe.cc -Wall -static -o fops_probe
Then copy the binary to target machine and run as:
./fops_probe /dev/fb0
You should see output similar to:
ffffffff81bcccb9 vfs_read
................
ffffffff83af85c3 fb_read
ffffffff83b52af5 cirrusfb_sync
ffffffff81bcd219 vfs_write
................
ffffffff83af7fe2 fb_write
ffffffff83b52af5 cirrusfb_sync
ffffffff81c1b745 do_vfs_ioctl
ffffffff83af7ea9 fb_ioctl
ffffffff81a4ea44 do_mmap
................
ffffffff83af716c fb_mmap
which allows to understand what callbacks are associated with /dev/fb0.
Add a second mode that extracts constant values from
ELF object, instead of running the executable.
This allows to not (1) link binaries, (2) use proper cross-compiler.
It finally fixes 386/arm extracts for my distro.
Hopefully not makes things worse for others,
should generally be safer/more reliable.
The current mode is left b/c I can't test all OSes,
windows binaries are not ELF, so we may need it anyway.
But later we may switch more OSes to this new mode
if they break (fuchsia?).
On my Debian gcc -m32 is hopelessly broken.
Using clang fixes at least arch 386.
Arch arm is still broken b/c clang does not like
some of kernel arm inline assemly constraints.
It's /dev/watch_queue not /dev/fd_watch_queue.
Don't know if it was renamed, or alwys wrong, but does not matter much,
now it's /dev/watch_queue.
Also attach v4l ioctls to /dev/swradio,radio,vbi,cec.
It seems that _some_ of them are applicable to these devices as well.
If we have way too many programs to send (more than 100000),
cap total number to 100000 and give up sending all.
Otherwise new managers will never chew all this on a busy hub.
