> 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: > >