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