Message ID | 20200317165106.29282-1-andrzej.p@collabora.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [RESEND,1/2] loop: Report EOPNOTSUPP properly | expand |
On Tue, Mar 17, 2020 at 05:51:06PM +0100, Andrzej Pietrasiewicz wrote: > From: Evan Green <evgreen@chromium.org> > > Properly plumb out EOPNOTSUPP from loop driver operations, which may > get returned when for instance a discard operation is attempted but not > supported by the underlying block device. Before this change, everything > was reported in the log as an I/O error, which is scary and not > helpful in debugging. This really should be using errno_to_blk_status.
On Thu, Mar 26, 2020 at 7:53 AM Christoph Hellwig <hch@infradead.org> wrote: > > On Tue, Mar 17, 2020 at 05:51:06PM +0100, Andrzej Pietrasiewicz wrote: > > From: Evan Green <evgreen@chromium.org> > > > > Properly plumb out EOPNOTSUPP from loop driver operations, which may > > get returned when for instance a discard operation is attempted but not > > supported by the underlying block device. Before this change, everything > > was reported in the log as an I/O error, which is scary and not > > helpful in debugging. > > This really should be using errno_to_blk_status. I had that here in v7: https://lore.kernel.org/lkml/20191114235008.185111-1-evgreen@chromium.org/
On Thu, Mar 26, 2020 at 08:51:21AM -0700, Evan Green wrote: > On Thu, Mar 26, 2020 at 7:53 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > On Tue, Mar 17, 2020 at 05:51:06PM +0100, Andrzej Pietrasiewicz wrote: > > > From: Evan Green <evgreen@chromium.org> > > > > > > Properly plumb out EOPNOTSUPP from loop driver operations, which may > > > get returned when for instance a discard operation is attempted but not > > > supported by the underlying block device. Before this change, everything > > > was reported in the log as an I/O error, which is scary and not > > > helpful in debugging. > > > > This really should be using errno_to_blk_status. > > I had that here in v7: > https://lore.kernel.org/lkml/20191114235008.185111-1-evgreen@chromium.org/ Well, it wasn't in the version you sent the ping for..
Hi, W dniu 26.03.2020 o 16:55, Christoph Hellwig pisze: > On Thu, Mar 26, 2020 at 08:51:21AM -0700, Evan Green wrote: >> On Thu, Mar 26, 2020 at 7:53 AM Christoph Hellwig <hch@infradead.org> wrote: >>> >>> On Tue, Mar 17, 2020 at 05:51:06PM +0100, Andrzej Pietrasiewicz wrote: >>>> From: Evan Green <evgreen@chromium.org> >>>> >>>> Properly plumb out EOPNOTSUPP from loop driver operations, which may >>>> get returned when for instance a discard operation is attempted but not >>>> supported by the underlying block device. Before this change, everything >>>> was reported in the log as an I/O error, which is scary and not >>>> helpful in debugging. >>> >>> This really should be using errno_to_blk_status. >> >> I had that here in v7: >> https://lore.kernel.org/lkml/20191114235008.185111-1-evgreen@chromium.org/ > > Well, it wasn't in the version you sent the ping for.. > It was me who pinged. I didn't notice the v7, sorry. Is it merged yet? Andrzej
diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 739b372a5112..87307454f768 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -460,7 +460,9 @@ static void lo_complete_rq(struct request *rq) if (!cmd->use_aio || cmd->ret < 0 || cmd->ret == blk_rq_bytes(rq) || req_op(rq) != REQ_OP_READ) { - if (cmd->ret < 0) + if (cmd->ret == -EOPNOTSUPP) + ret = BLK_STS_NOTSUPP; + else if (cmd->ret < 0) ret = BLK_STS_IOERR; goto end_io; } @@ -1953,7 +1955,10 @@ static void loop_handle_cmd(struct loop_cmd *cmd) failed: /* complete non-aio request */ if (!cmd->use_aio || ret) { - cmd->ret = ret ? -EIO : 0; + if (ret == -EOPNOTSUPP) + cmd->ret = ret; + else + cmd->ret = ret ? -EIO : 0; blk_mq_complete_request(rq); } }