physio concurrency bug?

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

It seems to me that physio() in 4.0 has a bug in its concurrency code.
See PR kern/38643 for the full scoop, including the investigation
history.

The first problem is that it tries to fire off concurrent transfers
even for DV_TAPE devices.  But, for my purposes, I hid that by having
the relevant tape driver pass its own buf to physio(); arguably, it
would be righter to suppress concurrency for DV_TAPE - possibly for
non-DV_DISK, since that's the closest available approximation to
"random access", and concurrency really makes sense only for
random-access devices.

The second problem is somewhat more subtle.  If physio() gets a request
larger than MAXPHYS, it will send off a MAXPHYS-sized request to the
relevant strategy routine.  If this request errors, it will
nevertheless issue a second request to the strategy routine, at least
sometimes.  This is because the main-line physio code blocks in
physio_wait() before the first request errors, and the B_ERROR setting
on mbp is not noticed until after the second request is issued.  This
breaks at least one tape program.

Here's a patch to physio (extracted from the PR, relative to the 4.0
source) which seems to fix the second problem:

--- /dev/fd/4   Tue Dec  9 16:18:08 2003
+++ /dev/fd/5   Tue Dec  9 16:18:08 2003
@@ -336,6 +336,9 @@
                        if (error) {
                                goto done_locked;
                        }
+                       if ((mbp->b_flags & B_ERROR) != 0) {
+                               goto done_locked;
+                       }
                        simple_unlock(&mbp->b_interlock);
                        if (obp != NULL) {
                                /*

Comments?

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B