On Thu, Sep 12, 2024 at 06:49:28PM +0800, Ming Lei wrote:
> +static int ublk_provide_io_buf(struct io_uring_cmd *cmd,
> + struct ublk_queue *ubq, int tag)
> +{
> + struct ublk_device *ub = cmd->file->private_data;
> + struct ublk_rq_data *data;
> + struct request *req;
> +
> + if (!ub)
> + return -EPERM;
> +
> + req = __ublk_check_and_get_req(ub, ubq, tag, 0);
> + if (!req)
> + return -EINVAL;
> +
> + pr_devel("%s: qid %d tag %u request bytes %u\n",
> + __func__, tag, ubq->q_id, blk_rq_bytes(req));
> +
> + data = blk_mq_rq_to_pdu(req);
> +
> + /*
> + * io_uring guarantees that the callback will be called after
> + * the provided buffer is consumed, and it is automatic removal
> + * before this uring command is freed.
> + *
> + * This request won't be completed unless the callback is called,
> + * so ublk module won't be unloaded too.
> + */
> + return io_uring_cmd_provide_kbuf(cmd, data->buf);
> +}
We did some testing with this patchset and saw some panics due to
grp_kbuf_ack being a garbage value. Turns out that's because we forgot
to set the UBLK_F_SUPPORT_ZERO_COPY flag on the device. But it looks
like the UBLK_IO_PROVIDE_IO_BUF command is still allowed for such
devices. Should this function test that the device has zero copy
configured and fail if it doesn't?
