From: Kanchan Joshi <joshi.k@samsung.com>
To: Shin'ichiro Kawasaki <shinichiro@fastmail.com>
Cc: shinichiro.kawasaki@wdc.com, linux-nvme@lists.infradead.org,
linux-block@vger.kernel.org, mcgrof@kernel.org
Subject: Re: [PATCH blktests 2/2] nvme/047: add test for uring-passthrough
Date: Mon, 10 Apr 2023 18:13:33 +0530 [thread overview]
Message-ID: <20230410124333.GC16047@green5> (raw)
In-Reply-To: <20230407080746.tx4sgperc6pvjsbu@shinhome>
[-- Attachment #1: Type: text/plain, Size: 3714 bytes --]
On Fri, Apr 07, 2023 at 05:07:46PM +0900, Shin'ichiro Kawasaki wrote:
>Thanks for the patch. I think it's good to have this test case to cover the
>uring-passthrough codes in the nvme driver code. Please find my comments in
>line.
>
>Also, I ran the new test case on my Fedora system using QEMU NVME device and
>found the test case fails with errors like,
>
> fio: io_u error on file /dev/ng0n1: Permission denied: read offset=266240, buflen=4096
>
>I took a look in this and learned that SELinux on my system does not allow
>IORING_OP_URING_CMD by default. I needed to do "setenforce 0" or add a local
>policy to allow IORING_OP_URING_CMD so that the test case passes.
>
>I think this test case should check this security requirement. I'm not sure what
>is the best way to do it. One idea is to just run fio with io_uring_cmd engine
>and check its error message. I created a patch below, and it looks working on my
>system. I suggest to add it, unless anyone knows other better way.
I will use the latest one you posted. Thanks for taking care of it.
>diff --git a/tests/nvme/047 b/tests/nvme/047
>index a0cc8b2..30961ff 100755
>--- a/tests/nvme/047
>+++ b/tests/nvme/047
>@@ -14,6 +14,22 @@ requires() {
> _have_fio_ver 3 33
> }
>
>+device_requires() {
>+ local ngdev=${TEST_DEV/nvme/ng}
>+ local fio_output
>+
>+ if fio_output=$(fio --name=check --size=4k --filename="$ngdev" \
>+ --rw=read --ioengine=io_uring_cmd 2>&1); then
>+ return 0
>+ fi
>+ if grep -qe "Permission denied" <<< "$fio_output"; then
>+ SKIP_REASONS+=("IORING_OP_URING_CMD is not allowed for $ngdev")
>+ else
>+ SKIP_REASONS+=("IORING_OP_URING_CMD check for $ngdev failed")
>+ fi
>+ return 1
>+}
>+
> test_device() {
> echo "Running ${TEST_NAME}"
> local ngdev=${TEST_DEV/nvme/ng}
>
>
>On Mar 31, 2023 / 09:14, Kanchan Joshi wrote:
>> User can communicate to NVMe char device (/dev/ngXnY) using the
>> uring-passthrough interface. This test exercises some of these
>> communication pathways, using the 'io_uring_cmd' ioengine of fio.
>>
>> Signed-off-by: Kanchan Joshi <joshi.k@samsung.com>
>> ---
>> tests/nvme/047 | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>> tests/nvme/047.out | 2 ++
>> 2 files changed, 48 insertions(+)
>> create mode 100755 tests/nvme/047
>> create mode 100644 tests/nvme/047.out
>>
>> diff --git a/tests/nvme/047 b/tests/nvme/047
>> new file mode 100755
>> index 0000000..a0cc8b2
>> --- /dev/null
>> +++ b/tests/nvme/047
>> @@ -0,0 +1,46 @@
>> +#!/bin/bash
>> +# SPDX-License-Identifier: GPL-3.0+
>> +# Copyright (C) 2023 Kanchan Joshi, Samsung Electronics
>> +# Test exercising uring passthrough IO on nvme char device
>> +
>> +. tests/nvme/rc
>> +
>> +DESCRIPTION="basic test for uring-passthrough io on /dev/ngX"
>> +QUICK=1
>> +
>> +requires() {
>> + _nvme_requires
>> + _have_kver 6 1
>
>In general, it's the better not to depend on version number to check dependency.
>Is kernel version the only way to check the kernel dependency?
The tests checks for iopoll and fixed-buffer paths which are present
from 6.1 onwards, therefore this check. Hope that is ok?
>Also, I think this test case assumes that the kernel is built with
>CONFIG_IO_URING. I suggest to add "_have_kernel_option IO_URING" to ensure it.
Sure, will add.
>> + _have_fio_ver 3 33
>
>Is io_uring_cmd engine the reason to check this fio version? If so, I suggest to
>check "fio --enghelp" output. We can add a new helper function with name like
>_have_fio_io_uring_cmd_engine. _have_fio_zbd_zonemode in common/fio can be a
>reference.
fixed-buffer support[1] went into this fio relese, therefore check for
the specific version.
[1]https://lore.kernel.org/fio/20221003033152.314763-1-anuj20.g@samsung.com/
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2023-04-10 12:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20230331034524epcas5p31c3793c0c2071846ed82ff0f1369e90d@epcas5p3.samsung.com>
2023-03-31 3:44 ` [PATCH blktests 0/2] nvme uring-passthrough test Kanchan Joshi
2023-03-31 3:44 ` [PATCH blktests 1/2] common,fio: helper for version check Kanchan Joshi
2023-03-31 3:44 ` [PATCH blktests 2/2] nvme/047: add test for uring-passthrough Kanchan Joshi
2023-04-07 8:07 ` Shin'ichiro Kawasaki
2023-04-10 0:43 ` Shin'ichiro Kawasaki
2023-04-10 12:43 ` Kanchan Joshi [this message]
2023-04-11 1:35 ` Shin'ichiro Kawasaki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230410124333.GC16047@green5 \
--to=joshi.k@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mcgrof@kernel.org \
--cc=shinichiro.kawasaki@wdc.com \
--cc=shinichiro@fastmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.