There's a lot of disk drivers in the tree, many don't like random
commands. So, like BIO_DELETE, make it opt-in only. The drivers that
are part of the CAM IOSCHEDULER are the only ones that can use
this. For everybody else, return success, but don't adjust the
residual to indicate that nothing was done in response.
Details
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 29213 Build 27139: arc lint + arc unit
Event Timeline
I would honestly prefer drivers to report reasonable errors on unknown commands. That would fix the issue once and for all.
I won't object too much, but first addition of quite specialized command and then workaround for it does not make me particularly happy.
I understand. Had I realized the issue before the commit, I'd have done this from the start. I have an AI to make it so we can add additional commands in the future w/o panics.
Yep, gotta bite the bullet sometime
--- scsi_da.c (revision 355435) +++ scsi_da.c (working copy) @@ -3381,6 +3381,10 @@ } break; } + default: + biofinish(bp, NULL, EOPNOTSUPP); + xpt_release_ccb(start_ccb); + return; } start_ccb->ccb_h.ccb_state = DA_CCB_BUFFER_IO; start_ccb->ccb_h.flags |= CAM_UNLOCKED;
In that case what about the console spam? I presume messages of this sort:
g_vfs_done():md10a[UNKNOWN()]error = 45
stem precisely from this. This happens to really spam the console for me when e.g., running stress2 when at least for this case it should never print anything. iow it looks like a design error that that devices which don't support something can get a request AND fail resulting in an error message.
Here is an example from pho's log: https://people.freebsd.org/~pho/stress/log/mark125.txt