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:09, Adrian Huang12 wrote:
> Hi Coly,
> 
>> -----Original Message-----
>> From: Coly Li <colyli@suse.de>
>> Sent: Thursday, September 3, 2020 1:20 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 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.
> 
> I confirmed that Mike's symptom can be easily reproduced with brd devices after running the tool 'lvm2-testsuite'.
> 
> And, Coly's right. The dax_dev pointer is *NOT* NULL when the tool executes the command ' lvchange $vg/foo -a y'. Please see the following log (with applying Coly's patch).
> 
> So, the 'if' statement should be logical OR operator instead of logical AND operator. Thanks, Coly.
> 
> ------------------------------------------------------
> # lvm2-testsuite --only activate-minor
> ....
> [ 0:00] aux prepare_vg 2
> [ 0:00] #activate-minor.sh:22+ aux prepare_vg 2
> [ 0:00] ## preparing ramdisk device...ok (/dev/ram0)
> [ 0:01] 6,3160,167857640,-;brd: module loaded
> [ 0:01] ## preparing 2 devices...ok
> [ 0:01] 6,3161,167877024,-;dax_dev: 0000000000000000
> [ 0:01] 6,3162,167877026,-;bdev_dax_supported(): 0
> [ 0:01] 6,3163,167877041,-;dax_dev: 0000000000000000
> [ 0:01] 6,3164,167877042,-;bdev_dax_supported(): 0
> [ 0:01] 6,3165,167877160,-;dax_dev: 0000000000000000
> [ 0:01] 6,3166,167877162,-;bdev_dax_supported(): 0
> [ 0:01] 6,3167,167877407,-;dax_dev: 0000000000000000
> [ 0:01] 6,3168,167877412,-;bdev_dax_supported(): 0
> [ 0:01] 6,3169,167877430,-;dax_dev: 0000000000000000
> [ 0:01] 6,3170,167877430,-;bdev_dax_supported(): 0
> [ 0:01] 6,3171,167877572,-;dax_dev: 0000000000000000
> [ 0:01] 6,3172,167877574,-;bdev_dax_supported(): 0
> .......
> [ 0:01] lvchange $vg/foo -a y
> [ 0:01] #activate-minor.sh:25+ lvchange LVMTEST12338vg/foo -a y
> [ 0:01]   /tmp/LVMTEST12338.9M4A4QfLHQ/dev/mapper/LVMTEST12338vg-foo not set up by udev: Falling back to direct node creation.
> [ 0:01] 6,3173,168081520,-;dax_dev: 000000007f8e88a7
> [ 0:01] 6,3174,168081524,-;bdev_dax_supported(): 0
> [ 0:01] 6,3175,168081543,-;dax_dev: 000000007f8e88a7
> [ 0:01] 6,3176,168081544,-;bdev_dax_supported(): 0
> [ 0:01] 6,3177,168081749,-;dax_dev: 000000007f8e88a7
> [ 0:01] 6,3178,168081750,-;bdev_dax_supported(): 0
> -----------------------------------------------------

Hi Adrian,

Thanks for double check. I will post the fixes for you and Mike to review.

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