public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
* [PATCH] nvme: ignore starting sector while error logging for passthrough requests
       [not found] <CGME20221006091054eucas1p1e4113b6dfd108907c2cd5ba7127a3f92@eucas1p1.samsung.com>
@ 2022-10-06  9:10 ` Pankaj Raghav
  2022-10-18 13:48   ` Pankaj Raghav
  0 siblings, 1 reply; 6+ messages in thread
From: Pankaj Raghav @ 2022-10-06  9:10 UTC (permalink / raw)
  To: hch; +Cc: gost.dev, linux-nvme, Pankaj Raghav

Error log will print a garbage value as the starting LBA for passthrough
requests and requests with uninitialized starting sector that return an
error. Print LBA as 0 instead for these requests. This behaviour is
similar what tracing does for these type of requests.

Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
---
 drivers/nvme/host/core.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 059737c1a2c1..41e0a257f1c2 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -305,6 +305,13 @@ static void nvme_retry_req(struct request *req)
 	blk_mq_delay_kick_requeue_list(req->q, delay);
 }
 
+static inline u64 nvme_log_error_rq_lba(struct nvme_ns *ns, struct request *rq)
+{
+	if (blk_rq_is_passthrough(rq) || blk_rq_pos(rq) == (sector_t)-1)
+		return 0;
+	return nvme_sect_to_lba(ns, blk_rq_pos(rq));
+}
+
 static void nvme_log_error(struct request *req)
 {
 	struct nvme_ns *ns = req->q->queuedata;
@@ -315,7 +322,7 @@ static void nvme_log_error(struct request *req)
 		       ns->disk ? ns->disk->disk_name : "?",
 		       nvme_get_opcode_str(nr->cmd->common.opcode),
 		       nr->cmd->common.opcode,
-		       (unsigned long long)nvme_sect_to_lba(ns, blk_rq_pos(req)),
+		       (unsigned long long)nvme_log_error_rq_lba(ns, req),
 		       (unsigned long long)blk_rq_bytes(req) >> ns->lba_shift,
 		       nvme_get_error_status_str(nr->status),
 		       nr->status >> 8 & 7,	/* Status Code Type */
-- 
2.25.1



^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] nvme: ignore starting sector while error logging for passthrough requests
  2022-10-06  9:10 ` [PATCH] nvme: ignore starting sector while error logging for passthrough requests Pankaj Raghav
@ 2022-10-18 13:48   ` Pankaj Raghav
  2022-10-18 14:45     ` Christoph Hellwig
  0 siblings, 1 reply; 6+ messages in thread
From: Pankaj Raghav @ 2022-10-18 13:48 UTC (permalink / raw)
  To: hch, Keith Busch, Daniel Wagner, Alan Adamson; +Cc: gost.dev, linux-nvme

The final consensus in Daniel's patch[1] seems to be adding an opt in to
log error only for admin commands, and logging error for user IO commands
will remain as is.

In that case, should we reconsider this patch to avoid printing a garbage
value ((sector_t)-1) while logging error for IO passthrough commands?

[1]
https://lore.kernel.org/all/79E937D0-58DA-4AE2-A0B8-A30185CE7FCE@oracle.com/

On 2022-10-06 11:10, Pankaj Raghav wrote:
> Error log will print a garbage value as the starting LBA for passthrough
> requests and requests with uninitialized starting sector that return an
> error. Print LBA as 0 instead for these requests. This behaviour is
> similar what tracing does for these type of requests.
> 
> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
> ---
>  drivers/nvme/host/core.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 059737c1a2c1..41e0a257f1c2 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -305,6 +305,13 @@ static void nvme_retry_req(struct request *req)
>  	blk_mq_delay_kick_requeue_list(req->q, delay);
>  }
>  
> +static inline u64 nvme_log_error_rq_lba(struct nvme_ns *ns, struct request *rq)
> +{
> +	if (blk_rq_is_passthrough(rq) || blk_rq_pos(rq) == (sector_t)-1)
> +		return 0;
> +	return nvme_sect_to_lba(ns, blk_rq_pos(rq));
> +}
> +
>  static void nvme_log_error(struct request *req)
>  {
>  	struct nvme_ns *ns = req->q->queuedata;
> @@ -315,7 +322,7 @@ static void nvme_log_error(struct request *req)
>  		       ns->disk ? ns->disk->disk_name : "?",
>  		       nvme_get_opcode_str(nr->cmd->common.opcode),
>  		       nr->cmd->common.opcode,
> -		       (unsigned long long)nvme_sect_to_lba(ns, blk_rq_pos(req)),
> +		       (unsigned long long)nvme_log_error_rq_lba(ns, req),
>  		       (unsigned long long)blk_rq_bytes(req) >> ns->lba_shift,
>  		       nvme_get_error_status_str(nr->status),
>  		       nr->status >> 8 & 7,	/* Status Code Type */


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] nvme: ignore starting sector while error logging for passthrough requests
  2022-10-18 13:48   ` Pankaj Raghav
@ 2022-10-18 14:45     ` Christoph Hellwig
  2022-10-18 15:23       ` Keith Busch
  2022-10-18 16:35       ` Pankaj Raghav
  0 siblings, 2 replies; 6+ messages in thread
From: Christoph Hellwig @ 2022-10-18 14:45 UTC (permalink / raw)
  To: Pankaj Raghav
  Cc: hch, Keith Busch, Daniel Wagner, Alan Adamson, gost.dev,
	linux-nvme

On Tue, Oct 18, 2022 at 03:48:57PM +0200, Pankaj Raghav wrote:
> The final consensus in Daniel's patch[1] seems to be adding an opt in to
> log error only for admin commands, and logging error for user IO commands
> will remain as is.

Hmm, is it?  I'd think even for I/O commands the opt in makes some
sense.

> In that case, should we reconsider this patch to avoid printing a garbage
> value ((sector_t)-1) while logging error for IO passthrough commands?

We should probably do this, but it should probably go along with the
opt-in for I/O commands.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] nvme: ignore starting sector while error logging for passthrough requests
  2022-10-18 14:45     ` Christoph Hellwig
@ 2022-10-18 15:23       ` Keith Busch
  2022-10-18 15:26         ` Christoph Hellwig
  2022-10-18 16:35       ` Pankaj Raghav
  1 sibling, 1 reply; 6+ messages in thread
From: Keith Busch @ 2022-10-18 15:23 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Pankaj Raghav, Daniel Wagner, Alan Adamson, gost.dev, linux-nvme

On Tue, Oct 18, 2022 at 04:45:35PM +0200, Christoph Hellwig wrote:
> On Tue, Oct 18, 2022 at 03:48:57PM +0200, Pankaj Raghav wrote:
> > The final consensus in Daniel's patch[1] seems to be adding an opt in to
> > log error only for admin commands, and logging error for user IO commands
> > will remain as is.
> 
> Hmm, is it?  I'd think even for I/O commands the opt in makes some
> sense.
> 
> > In that case, should we reconsider this patch to avoid printing a garbage
> > value ((sector_t)-1) while logging error for IO passthrough commands?
> 
> We should probably do this, but it should probably go along with the
> opt-in for I/O commands.

What's the preferred opt-in mechanism? If we want to do it per-command,
we have an unsused 'flags' field in the ioctl structures that we can
start defining options for these kinds of things. If we don't want that
level of fine grained control, we could set it at the controller or
module level with a new sysfs file, though I'm not sure this warrants
creating new exports there.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] nvme: ignore starting sector while error logging for passthrough requests
  2022-10-18 15:23       ` Keith Busch
@ 2022-10-18 15:26         ` Christoph Hellwig
  0 siblings, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2022-10-18 15:26 UTC (permalink / raw)
  To: Keith Busch
  Cc: Christoph Hellwig, Pankaj Raghav, Daniel Wagner, Alan Adamson,
	gost.dev, linux-nvme

On Tue, Oct 18, 2022 at 09:23:37AM -0600, Keith Busch wrote:
> What's the preferred opt-in mechanism? If we want to do it per-command,
> we have an unsused 'flags' field in the ioctl structures that we can
> start defining options for these kinds of things. If we don't want that
> level of fine grained control, we could set it at the controller or
> module level with a new sysfs file, though I'm not sure this warrants
> creating new exports there.

The flags field is what I had in mind.  There's also another thing
on the plate as some folks really want to opt into kernel error
handling for passthrough commands, and that seems to be the only
way to do it.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] nvme: ignore starting sector while error logging for passthrough requests
  2022-10-18 14:45     ` Christoph Hellwig
  2022-10-18 15:23       ` Keith Busch
@ 2022-10-18 16:35       ` Pankaj Raghav
  1 sibling, 0 replies; 6+ messages in thread
From: Pankaj Raghav @ 2022-10-18 16:35 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Keith Busch, Daniel Wagner, Alan Adamson, gost.dev, linux-nvme

>> In that case, should we reconsider this patch to avoid printing a garbage
>> value ((sector_t)-1) while logging error for IO passthrough commands?
> 
> We should probably do this, but it should probably go along with the
> opt-in for I/O commands.

Hmm, I think this patch will be orthogonal unless we put some of the opt-in
logic in the nvme_log_error() function itself.

Currently, we always log the error with the -1 sector value for passthrough
requests, which should be changed to print 0 so that we remain consistent
with the tracing infra. The same behavior should also be applicable when we
have the opt-in support, and the user decides to opt-in to log error for
passthrough requests.

That said, I am fine with this update going along with the opt-in support.


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-10-18 16:35 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <CGME20221006091054eucas1p1e4113b6dfd108907c2cd5ba7127a3f92@eucas1p1.samsung.com>
2022-10-06  9:10 ` [PATCH] nvme: ignore starting sector while error logging for passthrough requests Pankaj Raghav
2022-10-18 13:48   ` Pankaj Raghav
2022-10-18 14:45     ` Christoph Hellwig
2022-10-18 15:23       ` Keith Busch
2022-10-18 15:26         ` Christoph Hellwig
2022-10-18 16:35       ` Pankaj Raghav

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox