[LTP] [PATCH v3] testcases/kernel/device-drivers/nvme: Add NVMe device discovery test

[Sebastian Chlad]

Hi Priyama, Shin'ichiro,

On Tue, 26 May 2026 at 03:21, Shin'ichiro Kawasaki <
shinichiro.kawasaki@wdc.com> wrote:

> Hello Priyama,
>
> From blktests maintainer side, let me share my views on your proposal.
>
> Blktests started as the community effort among the kernel storage
> sub-system
> developers. It was discussed at LSF/MM 2017, and started as the place to
> stock
> test scripts for the kernel stroage sub-system. In my understanding, the
> developers expect blktests is the test set to run before posting patches
> for the
> storage subsystem. In the same manner, I expect and hope that nvme driver
> patches tested with the nvme test group in blktests, to reduce the load of
> reviewers and maintainers.
>
> When LTP supports the nvme tests as you propose, what will be your
> expectation
> for nvme driver patch submitters? Do you expect they run both blktests
> nvme test
> group and LTP nvme group? If so, I suggest to add linux-nvme mailing list
> to
> this discussion thread to ask their opinions.
>
> Also, please find my inline comment below.
>
> On May 25, 2026 / 11:00, priyama2 wrote:
> > Hi Sebastian,
> >
> > Thank you for raising this important question. After reviewing blktests'
> > coverage, I see the concern about duplication.
> >
> > *Proposed LTP NVMe Test Suite - System Integration Focus:*
> >
> > Rather than duplicating blktests' comprehensive NVMe protocol testing, I
> > propose LTP focus on system-level integration and kernel API validation.
>
> The primary role of the blktests nvme test group is to cover the nvme
> driver
> codes in the kernel source tree. It is not intended to test NVMe protocol
> or
> NVMe devices. Blktests can be used for NVMe protocol/device testing as
> just a
> side effect.
>
>   It is often discussed to extend blktests to cover NVMe device
> compatibility
>   test with Linux nvme driver, but it is still an idea at this moment.
>
> I guess you misunderstood this point, so the list below still has
> duplications
> with the blktests coverage. It will make it difficult to tell which test
> framework (blktests or LTP) to add new nvme driver tests.
>
>
Personally I agree with the above - the list still has duplications.
If we get clinical and define things carefully, we still - I believe -
expose ourselves to such duplications in the future.
Effectively we would have NVMe tests in both LTP and blktests, people will
contribute to both and we end up with competing tests...

LTP is oftentimes used for some regression testing. From this standpoint I
would assume it might make sense to introduce some sort
of NVMe sometests - basic coverage to see if things are terribly broken.
Personally I would still prefer to use blktests/nvme as that one is
well maintained and goes deeper into details.

But yeah your ideas are great however -  writing directly -  I would just
implement them in the blktests, so we end up with more mature coverage in
there
rather than spreading the effort on 2 testing tools (ltp and blktests).

I would also emphasize the point made here by Shin'ichiro and earlier by
Daniel - blktests are run on the relevant -next trees, so we would be
better off
with more mature tests in the blktests.

cheers,
Sebastian


>   Said that, the list below includes testing aspects that is not yet
> covered.
>   I agree that those ideas are great.
>
>
> > Here's an overview of the planned test suite:
> >
> > *1. nvme01 - Device Discovery & System Integration (Current Patch)*
> >
> >  * Basic device enumeration through /sys and /dev interfaces
> >  * Driver binding verification
> >  * *LTP-specific angle*: Validates kernel's sysfs/devfs integration,
> >    not NVMe protocol
> >
> > *2. nvme02 - File System Operations (Planned)*
> >
> >  * Standard POSIX I/O operations (open, read, write, close, fsync)
> >  * O_DIRECT, O_SYNC flag behavior
> >  * mmap() operations on NVMe-backed files
> >  * File locking (flock, fcntl) with NVMe storage
> >  * *Differentiation*: Tests syscall interface, not NVMe commands
> >
> > *3. nvme03 - Process & Thread Safety (Planned)*
> >
> >  * Concurrent access from multiple processes
> >  * fork() with open NVMe file descriptors
> >  * Thread-safe I/O operations
> >  * Signal handling during NVMe I/O
> >  * *Differentiation*: Multi-process integration, not device-level testing
> >
> > *4. nvme04 - Resource Management & Limits (Planned)*
> >
> >  * Cgroup I/O throttling with NVMe devices
> >  * ulimit enforcement (RLIMIT_FSIZE, RLIMIT_NOFILE)
> >  * Disk quota behavior on NVMe filesystems
> >  * Memory pressure scenarios
> >  * *Differentiation*: Kernel resource management integration
> >
> > *Key Differentiators from blktests:*
> >
> > Aspect        blktests        LTP (Proposed)
> > *Focus*       NVMe protocol & features        System call & kernel API
> > *Scope*       Block layer specifics   Multi-subsystem integration
> > *Interface*   NVMe commands, ioctl    POSIX syscalls (read/write/open)
> > *Duration*    Comprehensive (longer)  Smoke tests (<5 min total)
> > *Use Case*    NVMe validation         System regression detection
> >
> > *Concrete Examples of LTP-Specific Value:*
> >
> > 1. *System Integration*: Does|fsync()|properly flush NVMe write cache
> >    through the kernel's VFS layer?
> > 2. *Process Safety*: Can a child process inherit and use parent's NVMe
> >    file descriptor after|fork()|?
> > 3. *Resource Limits*: Does cgroup I/O throttling correctly limit NVMe
> >    bandwidth?
> > 4. *Platform Coverage*: Does NVMe work in PowerPC LPAR, s390x LPAR, ARM
> >    virtualization?
> > 5. *Container Integration*: Are NVMe devices properly accessible in
> >    containerized environments?
> >
> > *Positioning:*
> >
> >  * *blktests*: "Does NVMe hardware/protocol work correctly?"
> >  * *LTP*: "Does the kernel's NVMe integration work with the rest of the
> >    system?"
> >
> > *Current Status & Next Steps:*
> >
> > The current nvme01 patch is admittedly basic. I'm happy to:
> >
> > 1. *Withdraw*if LTP prefers no NVMe coverage
> > 2. *Refocus*nvme01 on system integration (e.g., test sysfs attribute
> >    access patterns)
> > 3. *Proceed*with the differentiated test suite outlined above
> > 4. *Collaborate*with blktests maintainers to ensure no overlap
> >
> > Please let know which direction would the LTP community prefer?
> >
> > Best regards, priyama2
>