[PATCH] fix nvme test

[PATCH] fix nvme test

[Mikulas Patocka]

Hi

The strncmp function should compare 4 bytes.

But I'm wondering what's the purpose of this test at all? bio-based 
interface doesn't support partial completions for any device - so why do 
we need special code path just for nvme and why can't we use it for other 
block devices?

Mikulas


Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

---
 drivers/md/dm-table.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/drivers/md/dm-table.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-table.c	2018-02-24 03:40:18.000000000 +0100
+++ linux-2.6/drivers/md/dm-table.c	2018-02-26 19:36:29.728499000 +0100
@@ -1755,7 +1755,7 @@ static int device_no_partial_completion(
 	char b[BDEVNAME_SIZE];
 
 	/* For now, NVMe devices are the only devices of this class */
-	return (strncmp(bdevname(dev->bdev, b), "nvme", 3) == 0);
+	return (strncmp(bdevname(dev->bdev, b), "nvme", 4) == 0);
 }
 
 static bool dm_table_does_not_support_partial_completion(struct dm_table *t)

Re: fix nvme test

[Mike Snitzer]

On Mon, Feb 26 2018 at  3:22pm -0500,
Mikulas Patocka <mpatocka@redhat.com> wrote:

> Hi
> 
> The strncmp function should compare 4 bytes.

Ah yeap, thanks.

> But I'm wondering what's the purpose of this test at all? bio-based 
> interface doesn't support partial completions for any device - so why do 
> we need special code path just for nvme?

request-based does support partial completions, it is the underlying
devices that matter here, not the upper layer DM device type.

The rationale for this atomic operation requirement is mainly historic:
previously DM_TYPE_NVME_BIO_BASED was (ab)using blk_steal_bios() to
retry a request that failed with a retryable error (as part of a hook
that never was allowed to be introduced to the NVMe request completion
code-path).  For that model it was important that the underlying device
not partially complete its request; because on retry all of the bios
were getting stolen from the request and resubmitted in their entirety
back to the upper layer bio-based device (multipath in my historic
case).

Now that DM_TYPE_NVME_BIO_BASED isn't making use of blk_steal_bios() we
_could_ relax this constraint but I'd prefer to have the option of
using blk_steal_bios() in the future.

> and why can't we use it for other block devices?

I'm not exactly sure about what you mean by "it" but I'll assume you
mean: why can't we use direct_make_request() for other devices?  I've
purposely constrained DM_TYPE_NVME_BIO_BASED to mean we have a target
that is an immutable singleton that is only layered on an NVMe device.
I know this case to currently be uniquely suited for use with
direct_make_request(): no splitting can occur and no partial completion
is used by the underlying driver (the latter less important than the
former).

Mike