Re: [External] Re: flood of "dm-X: error: dax access failed" due to 5.9 commit 231609785cbfb

[Coly Li <colyli@suse.de>]

On 2020/9/3 19:24, Adrian Huang12 wrote:
> 
>> -----Original Message-----
>> From: Coly Li <colyli@suse.de>
>> Sent: Thursday, September 3, 2020 4:37 PM
>> To: Mike Snitzer <snitzer@redhat.com>
>> Cc: Jan Kara <jack@suse.com>; Ira Weiny <ira.weiny@intel.com>; Pankaj Gupta
>> <pankaj.gupta.linux@gmail.com>; Vishal Verma <vishal.l.verma@intel.com>;
>> linux-nvdimm@lists.01.org; Adrian Huang12 <ahuang12@lenovo.com>
>> Subject: [External] Re: flood of "dm-X: error: dax access failed" due to 5.9
>> commit 231609785cbfb
>>
>> On 2020/9/3 13:20, Coly Li wrote:
>>> On 2020/9/3 00:51, Mike Snitzer wrote:
>>>> On Wed, Sep 02 2020 at 12:46pm -0400, Coly Li <colyli@suse.de> wrote:
>>>>
>>>>> On 2020/9/3 00:44, Mike Snitzer wrote:
>>>>>> On Wed, Sep 02 2020 at 12:40pm -0400, Coly Li <colyli@suse.de>
>>>>>> wrote:
>>>>>>
>>>>>>> On 2020/9/3 00:04, Mike Snitzer wrote:
>>>>>>>> 5.9 commit 231609785cbfb ("dax: print error message by pr_info()
>>>>>>>> in
>>>>>>>> __generic_fsdax_supported()") switched from pr_debug() to pr_info().
>>>>>>>>
>>>>>>>> The justification in the commit header is really inadequate.  If
>>>>>>>> there is a problem that you need to drill in on, repeat the
>>>>>>>> testing after enabling the dynamic debugging.
>>>>>>>>
>>>>>>>> Otherwise, now all DM devices that aren't layered on DAX capable
>>>>>>>> devices spew really confusing noise to users when they simply
>>>>>>>> activate their non-DAX DM devices:
>>>>>>>>
>>>>>>>> [66567.129798] dm-6: error: dax access failed (-5) [66567.134400]
>>>>>>>> dm-6: error: dax access failed (-5) [66567.139152] dm-6: error:
>>>>>>>> dax access failed (-5) [66567.314546] dm-2: error: dax access
>>>>>>>> failed (-95) [66567.319380] dm-2: error: dax access failed (-95)
>>>>>>>> [66567.324254] dm-2: error: dax access failed (-95)
>>>>>>>> [66567.479025] dm-2: error: dax access failed (-95)
>>>>>>>> [66567.483713] dm-2: error: dax access failed (-95)
>>>>>>>> [66567.488722] dm-2: error: dax access failed (-95)
>>>>>>>> [66567.494061] dm-2: error: dax access failed (-95)
>>>>>>>> [66567.498823] dm-2: error: dax access failed (-95)
>>>>>>>> [66567.503693] dm-2: error: dax access failed (-95)
>>>>>>>>
>>>>>>>> commit 231609785cbfb must be reverted.
>>>>>>>>
>>>>>>>> Please advise, thanks.
>>>>>>>
>>>>>>> Adrian Huang from Lenovo posted a patch, which titled: dax: do not
>>>>>>> print error message for non-persistent memory block device
>>>>>>>
>>>>>>> It fixes the issue, but no response for now. Maybe we should take this fix.
>>>>>>
>>>>>> OK, yes sounds like it.  It was merged and is commit
>>>>>> c2affe920b0e066
>>>>>> ("dax: do not print error message for non-persistent memory block
>>>>>> device")
>>>>>
>>>>> Thanks for informing me this patch is merged, I am going to update
>>>>> my local one :-)
>>>>
>>>> So the thing is I'm running v5.9-rc3 (which includes this commit) but
>>>> I'm still seeing all these warnings when I run the lvm2 testsuite.
>>>> The reason _seems_ to be because the lvm2 testsuite uses brd devices
>>>> for test devices.  So there is something about the brd device that
>>>> shows commit c2affe920b0e066 isn't enough :(
>>>
>>> [Resend and CC Adrian Huang]
>>>
>>> Hi Mike,
>>>
>>> Could you please apply and test this attached patch based on v5.9-rc3 ?
>>>
>>> It seems the pointer dax_dev of __generic_fsdax_supported() parameter
>>> is not initialized (IMHO this is not a dm bug), therefore the &&
>>> should be
>>> || to check the dax support state.
>>>
>>> Also I add two pr_info() to print the variables value, let's see
>>> whether my guess makes sense.
>>
>> Also I suggest some kind of change like this in drivers/md/dm.c,
>>
>> diff --git a/drivers/md/dm.c b/drivers/md/dm.c index
>> fb0255d25e4b..566d8208df47 100644
>> --- a/drivers/md/dm.c
>> +++ b/drivers/md/dm.c
>> @@ -818,6 +818,8 @@ int dm_get_table_device(struct mapped_device *md,
>> dev_t dev, fmode_t mode,
>>                         return -ENOMEM;
>>                 }
>>
>> +               memset(td, 0, sizeof(struct table_device));
>> +
> 
> This does not help. See the following log.
> 
> -----------------
> # lvm2-testsuite --only activate-minor
> .......
> [ 0:00] #activate-minor.sh:22+ aux prepare_vg 2
> [ 0:00] ## preparing ramdisk device...ok (/dev/ram0)
> [ 0:01] 6,3160,150710756,-;brd: module loaded
> [ 0:01] ## preparing 2 devices...ok
> [ 0:01] 6,3161,150730864,-;dax_dev: 0000000000000000
> [ 0:01] 6,3162,150730866,-;bdev_dax_supported(): 0
> [ 0:01] 6,3163,150730903,-;dax_dev: 0000000000000000
> [ 0:01] 6,3164,150730905,-;bdev_dax_supported(): 0
> [ 0:01] 6,3165,150731019,-;dax_dev: 0000000000000000
> [ 0:01] 6,3166,150731020,-;bdev_dax_supported(): 0
> [ 0:01] 6,3167,150731512,-;dax_dev: 0000000000000000
> [ 0:01] 6,3168,150731514,-;bdev_dax_supported(): 0
> [ 0:01] 6,3169,150731525,-;dax_dev: 0000000000000000
> [ 0:01] 6,3170,150731525,-;bdev_dax_supported(): 0
> [ 0:01] 6,3171,150731656,-;dax_dev: 0000000000000000
> [ 0:01] 6,3172,150731657,-;bdev_dax_supported(): 0
> .......
> [ 0:01] lvchange $vg/foo -a y
> [ 0:01] #activate-minor.sh:25+ lvchange LVMTEST12302vg/foo -a y
> [ 0:01]   /tmp/LVMTEST12302.W0HGxyzxst/dev/mapper/LVMTEST12302vg-foo not set up by udev: Falling back to direct node creation.
> [ 0:01] 6,3173,150927070,-;dax_dev: 00000000f0a5865d
> [ 0:01] 6,3174,150927072,-;bdev_dax_supported(): 0
> [ 0:01] 6,3175,150927081,-;dax_dev: 00000000f0a5865d
> [ 0:01] 6,3176,150927082,-;bdev_dax_supported(): 0
> [ 0:01] 6,3177,150927241,-;dax_dev: 00000000f0a5865d
> [ 0:01] 6,3178,150927242,-;bdev_dax_supported(): 0
> ----------------


It seems I didn't cache all the locations to set dax_dev pointer to NULL
if the defice does not support dax. Thanks for point out of this :-)

Coly Li
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org