Today I looked at the history... In 2017 you started using range in bufbackoff:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/vfs_bio.c.diff?r1=1.180&r2=1.181 In 2014 tedu passed NULL for range but that wouldn't cause this panic then because bufbackoff didn't yet use range: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/uvm/uvm_pdaemon.c.diff?r1=1.65&r2=1.66 https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/uvm/uvm_pmemrange.c.diff?r1=1.36&r2=1.37 I had the panic a second time since I reported it, but since that time I've been running with the patch below to avoid it. I didn't know what to make those two calls tell bufbackoff about what range of memory they would like or how to do that correctly. Index: vfs_bio.c =================================================================== RCS file: /cvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.200 diff -u -p -r1.200 vfs_bio.c --- vfs_bio.c 29 Apr 2020 02:25:48 -0000 1.200 +++ vfs_bio.c 20 Jul 2020 21:10:45 -0000 @@ -309,7 +309,7 @@ bufbackoff(struct uvm_constraint_range * * If we will accept high memory for this backoff * try to steal it from the high memory buffer cache. */ - if (range->ucr_high > dma_constraint.ucr_high) { + if (range && range->ucr_high > dma_constraint.ucr_high) { struct buf *bp; int64_t start = bcstats.numbufpages, recovered = 0; int s = splbio(); > thanks. probably enough. ill go find it :) > > > On Jul 1, 2020, at 18:33, [email protected] wrote: > >> > >> Synopsis: uvm_wait_pla calls bufbackoff(NULL,4). It *(NULL)s. > >> Category: kernel > >> Environment: > > System : OpenBSD 6.7 > > Details : OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020 > > > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > >> Description: > > I got a uvmfault that showed bufbackoff called as > > bufbackoff(0,4) at bufbackoff+0x23 with the next function > > down being uvm_wait_pla. Out of curiosity I looked at > > these two functions, and it looks to me like a null pointer > > is passed and dereferenced by bufbackoff's first line: > > > > kern/vfs_bio.c: > > bufbackoff(struct uvm_constraint_range *range, long size) > > { > > ... > > if (range->ucr_high > dma_constraint.ucr_high) { > > > > uvm/uvm_pmemrange.c:2049 (uvm_wait_pla): > > > > if (bufbackoff(NULL, atop(size)) == 0) { > > > > Apologies if it is not actually this simple. I do have a bunch > > of pictures of ddb output including stack trace, registers, > > and ps output. Unfortunately, I fumbled around thinking more > > info would help, so the dmesg I got on reboot didn't have > > the good stuff. I'm hoping you don't really need all that once > > you read the two functions. > > > > It looks like uvm_wait() in uvm/uvm_pdaemon.c also calls bufbackoff > > with a NULL range argument. > > > > Things still look like this in current based on cvsweb. > > > >> How-To-Repeat: > > It has only happened once since upgrading to 6.7 in May. > >> Fix: > > I have no clue. > > > >
