Re: [PATCHv2 blktests 2/2] nvme: add test for writing to file-ns just after disabling it

[Nilay Shroff <nilay@linux.ibm.com>]

On 12/5/24 16:17, Daniel Wagner wrote:
> On Thu, Dec 05, 2024 at 03:10:23PM +0530, Nilay Shroff wrote:
>>>> +	img="$(mktemp /tmp/blk_img_XXXXXX)"
>>>> +	dd if=/dev/urandom of="$img" bs=512 count=1 status=none
>>>
>>> why can't we just use the standard block device backed ns ?
>> Using standard block device would also work however using the file backed block 
>> device would be handy in case user doesn't have a spare standard block device 
>> available which could be used for writing a random junk to it.
> 
> If I understood Chaitanya correctly, he would prefer to use the existing
> helpers to setup the backend, either file or block. If so, I am also on
> board with this idea, not to hard code backend into the test. We have
> moved this into the helpers so that it's a test parameter.
> 
>> OK I think maybe there's a confusion, let me clarify one thing here: We're
>> *not* disabling AEN functionality but only masking the ns-changed async even 
>> notification from target and I believe that's perfectly legal per spec. I 
>> shall update the comment added in the test case to avoid this confusion. 
>>
>>> Can this be an exception for some reason ?
>>>
>>> Shinichiro, Daniel any thoughts ?
> 
> I haven't really checked what the spec says on this topic. Nilay, could
> you give a pointer, so I don't spend too much time trying to find the
> right spot in the spec. Thanks!
> 
Sure, you may refer "5.27.1.8 Asynchronous Event Configuration (Feature Identifier 0Bh)"
in NVMe base spec 2.0. And then refer Figure 236, Namespace Attribute Notices: 

>>> +unsigned int ns_disable_error_inject;
>>> +module_param(ns_disable_error_inject, int, 0644);
>>> +MODULE_PARM_DESC(ns_disable_error_inject,
>>> +                "delay xa_erase() in ns-disable path in seconds 
>>> (default 0)");
>>> +
> 
> Please no. This type of debugging/testing interface is hard to use IMO.
> It should be in one of the psydo FS, sysfs, configfs or debugfs if
> really needed.
> 
> Daniel
> 
Thanks,
--Nilay