> Date: Sun, 6 Aug 2023 14:36:30 +0200
> From: Tobias Heider <tobias.hei...@stusta.de>
>
> On Sun, Aug 06, 2023 at 07:55:40AM +0200, Anton Lindqvist wrote:
> > On Sat, Aug 05, 2023 at 10:08:53PM +0200, xavie...@mailoo.org wrote:
> > > Hi,
> > >
> > > I run a 2G/100G virtual machine at openbsd.amsterdam freshly upgraded
> > > from stable to the latest snapshot and I've figured out the panic
> > > by the two steps detailed there:
> > >
> > > 1. The system has a root @reboot crontab entry that start a tmux
> > > session in the background (so always detached from a TTY during the
> > > whole procedure) + a /root/.tmux.conf which is some copy of my usual
> > > tmux confi, which appears to call a script that does `apm -b` (we have
> > > our quick workaround by removing it).
> > >
> > > The tmux session and the programs ran inside started just fine at the
> > > exception of the tmux session itself. By attaching that special
> > > session created @reboot, I noticed that tmux somehow fallback'd on the
> > > builtin's default config. (Green bottom status-bar and defaults
> > > keybinds). Which indeed indicated me that something went wrong.
> > >
> > > 2. It's only when I started tmux manually that the .tmux.conf calling
> > > `apm -b` triggerred the crash:
> > >
> > > # tmux ^M
> > > campfire.01:ksh* <-- my "on-top" status-bar was loaded this time
> > > uvm_fault(0xfffffd8078416cf0, 0x39c, 0, 2) -> e
> > > kernel: page fault trap, code=2
> > > Stopped at acpiopen+0x85: orb $0x1,0x39c(%r13)
> > > TID PID UID PRFLAGS PFLAGS CPU COMMAND
> > > *173406 19781 0 0x2 0 0 apm
> > > acpiopen(5300,1,2000,ffff8000ffff0b08) at acpiopen+0x85
> > > spec_open(ffff800021648598) at spec_open+0xe0
> > > VOP_OPEN(fffffd803bb6bcb0,1,fffffd80691bf550,ffff8000ffff0b08) at
> > > VOP_OPEN+0x4e
> > >
> > > vn_open(ffff8000216487b0,1,0) at vn_open+0x275
> > > doopenat(ffff8000ffff0b08,ffffff9c,f9805daef3b,0,0,ffff800021648980)
> > > at doopena
> > > t+0x1d1
> > > syscall(ffff8000216489f0) at syscall+0x364
> > > Xsyscall() at Xsyscall+0x128
> > > end of kernel
> > > end trace frame: 0x775e645c8040, count: 8
> >
> > This looks like a regression introduced in the recent acpi_apm.c
> > extraction in which the ENXIO short circuit got lost in
> > acpi{open,close,ioctl}.
> >
> >
> > https://github.com/openbsd/src/commit/c75690924c3df592a3a5078fe57c951f808a8350
> >
>
> Urgh yes, thanks for tracking this down. We are clearly missing at
> least a few checks here. I am working on getting this reproduced
> meanwhile here is a first diff to hopefully fix the crash.
ok kettenis@
> Index: dev/acpi/acpi_apm.c
> ===================================================================
> RCS file: /mount/openbsd/cvs/src/sys/dev/acpi/acpi_apm.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 acpi_apm.c
> --- dev/acpi/acpi_apm.c 8 Jul 2023 14:44:43 -0000 1.2
> +++ dev/acpi/acpi_apm.c 6 Aug 2023 12:29:56 -0000
> @@ -47,6 +47,9 @@ acpiopen(dev_t dev, int flag, int mode,
> struct acpi_softc *sc = acpi_softc;
> int s;
>
> + if (sc == NULL)
> + return (ENXIO);
> +
> s = splbio();
> switch (APMDEV(dev)) {
> case APMDEV_CTL:
> @@ -82,6 +85,9 @@ acpiclose(dev_t dev, int flag, int mode,
> struct acpi_softc *sc = acpi_softc;
> int s;
>
> + if (sc == NULL)
> + return (ENXIO);
> +
> s = splbio();
> switch (APMDEV(dev)) {
> case APMDEV_CTL:
> @@ -106,6 +112,9 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
> struct apm_power_info *pi = (struct apm_power_info *)data;
> int s;
>
> + if (sc == NULL)
> + return (ENXIO);
> +
> s = splbio();
> /* fake APM */
> switch (cmd) {
> @@ -167,6 +176,9 @@ acpikqfilter(dev_t dev, struct knote *kn
> {
> struct acpi_softc *sc = acpi_softc;
> int s;
> +
> + if (sc == NULL)
> + return (ENXIO);
>
> switch (kn->kn_filter) {
> case EVFILT_READ:
>
>
