On 2020/9/4 00:00, Mike Snitzer wrote:
> On Thu, Sep 03 2020 at 11:28am -0400,
> Coly Li <colyli@xxxxxxx> wrote:
>
>> When calling __generic_fsdax_supported(), a dax-unsupported device may
>> not have dax_dev as NULL, e.g. the dax related code block is not enabled
>> by Kconfig.
>>
>> Therefore in __generic_fsdax_supported(), to check whether a device
>> supports DAX or not, the following order should be performed,
>> - If dax_dev pointer is NULL, it means the device driver explicitly
>> announce it doesn't support DAX. Then it is OK to directly return
>> false from __generic_fsdax_supported().
>> - If dax_dev pointer is NOT NULL, it might be because the driver doesn't
>> support DAX and not explicitly initialize related data structure. Then
>> bdev_dax_supported() should be called for further check.
>>
>> IMHO if device driver desn't explicitly set its dax_dev pointer to NULL,
>> this is not a bug. Calling bdev_dax_supported() makes sure they can be
>> recognized as dax-unsupported eventually.
>>
>> This patch does the following change for the above purpose,
>> - if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
>> + if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
>
> Don't think I've ever seen a one-liner fix document the diff in its
> patch header. Really no need for that.
>
Oops, I just see this comment when I maximum my email client window now.
OK, I will post a v4 version to remove the above diff-like style comment.
Coly Li
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
