On 2019-01-29 3:35 a.m., Christoph Hellwig wrote:
I disagree with investing further effort into BIDI support. It is
dead for all practical purposes in standards and implementation,
and the fact that we found all these bugs in it just further confirms
that. The only answer to that is to bite the bullet and remove it.
The patchset was introduced by Bart as an expansion of my 1 line patch
to get around an oops when a bidi command failed and returned a sense
buffer. Boaz was able to replicate the oops in osd/exofs by injecting
a SCSI error. So Bart's patchset is an expanded fix, or fix and improve.
I'm guessing that bug was introduced by the blk-mq/scsi-mq work and was
made more serious when the SCSI stack was forced to use blk-mq/scsi-mq
exclusively.
So are you arguing that an oops that you had a hand in generating ***
should not fixed, and should be used as a further reason to remove bidi
completely from the kernel? Bebugging?
The T10 members that I have spoken to, have expressed surprise that
Linux kernel developers are contemplating removing SCSI bidi support.
True, XDWRITEREAD and bidi friends have been removed from draft SBC-4
but they are still used by RAID vendors and there is no move to deprecate
them from SBC-3, the current standard. XCOPY(LID1) is an example of another
command removed from draft SPC-5 but still much used as defined in SPC-4,
the current standard. RESERVE and RELEASE are other examples. There also
seems to be a consensus forming to add READ GATHERED (the bidi variant)
to draft SBC-4. One member told me that their development lab maintains
Linux kernels internally due to features they are experimenting with,
being removed from the mainline. Perhaps they should be looking at using
another open source OS.
If the NVMe stack does bidi (and quad-di) using a different technique,
couldn't the SCSI stack's bidi implementation (which is pretty ugly but is
less ugly after this patchset) be changed to do bidi the same way as NVMe?
Doug Gilbert
*** 'git blame' credits you 20140117 with the memset() that causes the oops.
BTW The pr_warn_once() warning people that bidi may be removed and to contact
this list only seems to be in bsg code. exofs uses osd which is a SCSI ULD and
osd does not use bsg to inject OSD commands. So users of exofs and the osd
driver directly will not be warned and thus will be less likely to report
to this list.
