I updated the DST and pushed it 'upstream' (into drivers/staging). Besides bio allocation optimization suggested by Jens Axboe, update fixes an interesting bug I started to observe recently between DST and the block layer

kernel BUG at drivers/scsi/scsi_lib.c:1310!
EIP is at scsi_setup_fs_cmnd+0x37/0x6c [scsi_mod]
Call Trace:
  [<f807c5f6>] sd_prep_fn+0x61/0x792 [sd_mod]
  [<c01bc985>] __cfq_slice_expired+0x57/0x62
  [<c01b3202>] elv_next_request+0xa8/0x14c
  [<f80a79d5>] scsi_request_fn+0x6c/0x3f5 [scsi_mod]

This is a BUG_ON() in scsi_setup_fs_cmnd(), which fires when there are no data segments attached to the block IO. This may be empty barrier or recently added data discard request though.

First I thought it is somehow related to the fact, that I recently swiched DST request queue initialization from plain and dumb allocation to the more advanced blk_init_queue(), although I do not use its features. Something like request queue issues a final barrier. Reverting the change did not fix the problem.

So I lazily googled and found 51fd77bd9f512ab6 commit, which disables empty barriers (by completing bio with -EOPNOTSUPP error). This code was changed to only disable bios which have data discard request and no flush prepare function. I used the same logic in DST and still got the same bug. After I enabled the log, I found that XFS issued a final barrier at the umount time without attached data. I used the same logic as in 51fd77bd9f512ab6 commit, i.e. completing bio with -EOPNOTSUPP error, but XFS froze the system. Oops, I really do not know XFS at all, but succesfully completing bio (with 0 error) fixed the issue. Weird.