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

[priyama2]

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. 
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


On 05/05/26 2:15 pm, Daniel Wagner wrote:
> Hi Priyama,
>
> Sorry for top-posting, but I have a broader question here.
>
> First of all, thanks for working on this and for looking into NVMe 
> coverage.
>
> Before going further, could you please explain the intended 
> LTP-specific value of
> this test? blktests already has a dedicated NVMe test group with much 
> broader
> coverage, including controller/namespace discovery, NVMe commands, 
> fabrics, etc.:
>
> https://github.com/linux-blktests/blktests/tree/master/tests/nvme 
> <https://github.com/linux-blktests/blktests/tree/master/tests/nvme>
>
> So I think we should be careful not to duplicate coverage unless there 
> is a clear
> reason for having a small LTP-level smoke test as well. Maybe your 
> intention is
> different? Could you please clarify?
>
> Cheers,
> Sebastian