[RFC 5/5] nvme: wire-up support for async-passthru on char-device.

[Christoph Hellwig]

On Mon, Apr 04, 2022 at 07:55:05PM +0530, Kanchan Joshi wrote:
> > Something like this (untested) patch should help to separate
> > the much better:
> 
> It does, thanks. But the only thing is - it would be good to support
> vectored-passthru too (i.e. NVME_IOCTL_IO64_CMD_VEC) for this path.
> For the new opcode "NVME_URING_CMD_IO" , either we can change the
> cmd-structure or flag-based handling so that vectored-io is supported.
> Or we introduce NVME_URING_CMD_IO_VEC also for that.
> Which one do you prefer?

I agree vectored I/O support is useful.

Do we even need to support the non-vectored case?

Also I think we'll want admin command passthrough on /dev/nvmeX as
well, but I'm fine solving the other items first.

> > +static int nvme_ioctl_finish_metadata(struct bio *bio, int ret,
> > +               void __user *meta_ubuf)
> > +{
> > +       struct bio_integrity_payload *bip = bio_integrity(bio);
> > +
> > +       if (bip) {
> > +               void *meta = bvec_virt(bip->bip_vec);
> > +
> > +               if (!ret && bio_op(bio) == REQ_OP_DRV_IN &&
> > +                   copy_to_user(meta_ubuf, meta, bip->bip_vec->bv_len))
> > +                       ret = -EFAULT;
> 
> Maybe it is better to move the check "bio_op(bio) != REQ_OP_DRV_IN" outside.
> Because this can be common, and for that we can avoid entering into
> the function call itself (i.e. nvme_ioctl_finish_metadata).

Function calls are pretty cheap, but I'll see what we can do.  I'll try
to come up with a prep series to refactor the passthrough support for
easier adding of the io_uring in the next days.