Re: NetBSD/vax

[Anders Magnusson <ragge%tethuvudet.se@localhost>]

Den 2020-03-22 kl. 08:38, skrev Martin Husemann:
> On Sat, Mar 21, 2020 at 10:56:27PM +0100, sadness wrote:
> > [   1.0600080] scsibus0: waiting 2 seconds for devices to settle...
> > [   3.0900080] r0=00000000 r1=80f1c800 r2=80f1c800 r3=80f1c974
> > r4=00004000 r5=0000004c r6=80f1a020 r7=80f1ccd8
> > [   3.0900080] r8=00000000 r9=00000000 r10=80f1a020 r11=00000000
> > [   3.0900080] ap=82f33cc4 fp=82f33ca8 sp=00000000 pc=80007780
> > [   3.0900080] panic: SEGV in kernel mode: pc 0x80007780 addr 0x44
> This is a NULL deref in:
>
> (gdb) list *(0x80007780)
> 0x80007780 is in si_dma_alloc (../../../../arch/vax/vsa/ncr.c:278).
> 273     found:
> 274             dh = &sc->ncr_dma[i];
> 275             dh->dh_flags = SIDH_BUSY;
> 276             dh->dh_addr = ncr_sc->sc_dataptr;
> 277             dh->dh_len = xlen;
> 278             dh->dh_proc = xs->bp->b_proc;
> 279
> 280             /* Remember dest buffer parameters */
> 281             if (xs->xs_control & XS_CTL_DATA_OUT)
> 282                     dh->dh_flags |= SIDH_OUT;
A quick look at this says that the scsipi_xfer struct do not have any 
filled in buf struct, so it crashes trying to extract the active process.
The proc struct is needed on vax to extract the address if doing DMA to 
userspace (since it needs to copy to/from a DMA buffer to/from the 
destination).

This struct is not needed if the kernel itself is doing DMA, so without 
deeper investigation I would assume the fix to be something like:

- Check if ncr_sc->sc_dataptr is in user space, if so assign 
dh->dh_proc.   Also add a panic if xs->bp is not set.

This means;  replace line 278 with:
    if (((vaddr_t)ncr_sc->sc_dataptr & KERNBASE) == 0) {
        if (xs->bp == NULL)
            panic("si_dma_alloc");
        dh->dh_proc = xs->bp->b_proc;
    }

-- Ragge