port-vax/59287: vnd(4) causes ill-formed access to underlying device

[rokuyama.rk%gmail.com@localhost]

>Number:         59287
>Category:       port-vax
>Synopsis:       vnd(4) causes ill-formed access to underlying device
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-vax-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Apr 13 11:40:00 +0000 2025
>Originator:     Rin Okuyama
>Release:        10.99.12 (not recent regression)
>Organization:
Internet Initiative Japan Inc.
>Environment:
NetBSD  10.99.12 NetBSD 10.99.12 (GENERIC) #1: Sun Apr 13 19:38:40 JST 2025  rin@sakaizumii.local:/home/rin/src/sys/arch/vax/compile/obj.vax-vax/GENERIC vax
>Description:
As recently reported by riastradh@:
https://mail-index.netbsd.org/source-changes/2025/04/05/msg156250.html

ATF cases with vnd(4) can results in the system crash. This one

> kernel/t_umountstress (126/983): 2 test cases
>     fileop: [ 5516.6200030] vnd0: no disk label
> [ 5517.1500030] ra0: drive 0 hard error datagram: memory addr 0x5000: host buffer access error (non-exist. memory) (code 9, subcode 3)
> [ 5517.1500030] ra0: host buffer access error (non-exist. memory) (code 9, subcode 3)
> [7.680000s] Failed: atf-check failed; see the output of the test for details
>     mountlist: [ 5524.4600030] vnd0: no disk label
> Traceback (most recent call last):
> 
> pexpect.exceptions.TIMEOUT: Timeout exceeded.
> 
> https://releng.netbsd.org/b5reports/vax/2025/2025.04.01.03.16.41/test.log

probably suggests that vnd(4) can cause ill-formed access to
underlying device!

Actually, if you are good (bad?) luck enough, you can observe
similar messages by carrying out typical vnd(4) operations manually:

```
dd if=/dev/zero of=/root/foo
vnconfig vnd0 /root/foo
newfs /dev/rvnd0a
```

newfs(8) fails even if the system does not crash.

Also note that similar failure also happens for tmpfs, i.e.,
tests/fs/tmpfs/t_vnd.
>How-To-Repeat:
Described above.
>Fix:
notyet