[PATCH v4] nvme/069: add a test for multipath cdev lifetime
Nilay Shroff
nilay at linux.ibm.com
Fri Jul 17 02:49:02 PDT 2026
On 7/17/26 2:36 PM, John Garry wrote:
> On 17/07/2026 08:00, Nilay Shroff wrote:
>> On 7/16/26 10: 06 PM, John Garry wrote: > On 16/07/2026 16: 16, Nilay Shroff
>> wrote: >>> + kill(getppid(), SIGUSR2); >>> + count = 0; >>> + for (;;)
>> { >>> + fd1 = open(argv[1], O_RDONLY); >>>
>>
>>
>> On 7/16/26 10:06 PM, John Garry wrote:
>>> On 16/07/2026 16:16, Nilay Shroff wrote:
>>>>> + kill(getppid(), SIGUSR2);
>>>>> + count = 0;
>>>>> + for (;;) {
>>>>> + fd1 = open(argv[1], O_RDONLY);
>>>>> + usleep(500000);
>>>>> + if (fd1 < 0)
>>>>> + break;
>>>>
>>>> Does it make sense to check for errno set to ENODEV or ENOENT
>>>> before breaking out here?
>>>
>>> ehh, if the errno is not ENODEV or ENOENT, then how to handle? Would it to fail the test due to unexpected errno?
>>
>> I think yes, something like below:
>>
>> for (;;) {
>> fd1 = open(argv[1], O_RDONLY);
>> if (fd1 < 0) {
>> if (errno == EINTR)
>> continue;
>>
>> if (errno == ENOENT || errno == ENODEV)
>> break;
>>
>> perror("open");
>
> if fd1 < 0, how is it open? Or maybe this message is too vague...
>
Yes, if fd1 < 0 then it implies errno is non-zero and device is not
opened. Later we evaluate the error code and take necessary
action.
>> return EINVAL;
>
> So are ENOENT, ENODEV, and EINTR the only expected error codes? Others are just unsupported and we fail the test (if and when we get them), right?
Yes. My thinking is that, apart from EINTR, any failure from open() is an error.
For this particular test, we're specifically waiting until the device node
disappears, so ENOENT or ENODEV indicate the expected condition and we can
break out of the loop and issue the ioctl() on the original fd. Any other
errno would be unexpected, so I'd treat it as a test failure by logging the
error and exiting.
Thanks,
--Nilay
More information about the Linux-nvme
mailing list