>Number:         33110
>Category:       port-xen
>Synopsis:       map_align() in xbd.c can block in interrupt context, on 3.0
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    port-xen-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar 20 21:50:00 +0000 2006
>Originator:     Jed Davis
>Release:        NetBSD 3.0
>Organization:
PANIX Public Access Internet and UNIX, NYC
>Environment:
System: NetBSD polyhedra.nyc.access.net 3.0.0_STABLE NetBSD 3.0.0_STABLE (PANIX-XENU-NETSERVER) #8: Tue Mar  7 23:51:10 EST 2006  root@juggler.panix.com:/devel/netbsd/netbsd-3-0_20060125/src/sys/arch/i386/compile/PANIX-XENU-NETSERVER i386
Architecture: i386
Machine: i386
>Description:
On the 3.0 branch, the map_align() function in xbd.c calls
uvm_km_kmemalloc1 without UVM_KMF_NOWAIT; it's possible to cause the
allocation to fail in interrupt context, which causes a panic.

This looks to have been fixed in -CURRENT, but amidst a number of
significant infrastructure changes (merging the yamt-km branch, for
instance); so it's not obvious to me if this specific fix can be
extracted and pulled up, nor how else to work around this specific
problem for the -3 branch.

>How-To-Repeat:
I have a test program that does a large number of scattered raw device
reads concurrently, which can reliably panic at least one test system.
(It could probably use synced regular file writes and be run without
privilege to the same effect; I haven't tried.)

(This test program, as it happens, was meant to exercise a certain
condition in the disk *backend*, not crash the frontend.)

>Fix:
Maybe let map_align fail and have xbdstart do something reasonable in
that case?  I'm not sure what to do about the disk_busy() call higher up.