kern/55716: missing bus_dmamap_unload() in siisata error handling path

[thorpej%me.com@localhost]

>Number:         55716
>Category:       kern
>Synopsis:       missing bus_dmamap_unload() in siisata error handling path
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Oct 11 17:00:00 +0000 2020
>Originator:     Jason Thorpe
>Release:        NetBSD 9.99.72
>Organization:
RISCy Business
>Environment:
NetBSD 9.99.72 Alpha, DS25 2 cpu 12G RAM
>Description:
I think there is a missing bus_dmamap_unload() in an error handling path in the siisata driver.  I am seeing the following assertion fire after siisata errors are reported:

[ 14449.8565684] wd2: READ LOG EXT page 10 failed to report error: slot 0 err 0 status 0
Oct 11 04:28:03 helena smartd[809]: Device: /dev/rwd3c, failed to read SMART Attribute Data
[ 14451.0245229] siisata0: fatal error 6 on port 3 (ctx 0x580c0200), resetting
[ 14451.1075247] wd3c: channel reset writing fsbn 5718638848 of 5718638848-5718638911 (wd3 bn 5718638848; cn 5673252 tn 13 sn 13), xfer d8, retry 0
[ 14451.2618195] wd3c: channel reset writing fsbn 5718604992 of 5718604992-5718605039 (wd3 bn 5718604992; cn 5673219 tn 3 sn 51), xfer 218, retry 0
[ 14451.9170887] panic: kernel diagnostic assertion "(map->_dm_flags & (BUS_DMA_READ|BUS_DMA_WRITE)) == 0" failed: file "../../../../arch/alpha/common/bus_dma.c", line 247

The traceback is:

db{0}> bt
cpu_Debugger() at netbsd:cpu_Debugger+0x4
db_panic() at netbsd:db_panic+0xc8
vpanic() at netbsd:vpanic+0x10c
kern_assert() at netbsd:kern_assert+0x70
_bus_dmamap_load_direct() at netbsd:_bus_dmamap_load_direct+0x1ac
siisata_dma_setup() at netbsd:siisata_dma_setup+0x68
siisata_cmd_start() at netbsd:siisata_cmd_start+0x120
ata_xfer_start() at netbsd:ata_xfer_start+0x58
atastart() at netbsd:atastart+0x2bc
siisata_ata_bio() at netbsd:siisata_ata_bio+0x78
wdstart1() at netbsd:wdstart1+0x264
wdbioretry() at netbsd:wdbioretry+0x58
callout_softclock() at netbsd:callout_softclock+0x510
softint_dispatch() at netbsd:softint_dispatch+0x124
alpha_softint_switchto() at netbsd:alpha_softint_switchto+0x60
db{0}>

The assertion indicates that the map is being loaded again after having been previously loaded without an intervening unload.  In order to notice this particular issue on Alpha, you need to have sufficient memory to use the SGMAP DMA windows, which need to track if the map was a used for read or write (>1G is the threshold on the DS25).
>How-To-Repeat:
No specific steps to repeat the problem. I'll keep looking for a pattern.
>Fix:
N/A