On Thu, Oct 17, 2024 at 04:31:26PM -0600, Uday Shankar wrote:
> 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?
Yeah, it should, thanks for the test & report.
Thanks,
Ming
