All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Arnd Bergmann <arnd@arndb.de>, Dave Chinner <david@fromorbit.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Matthew Wilcox <willy@infradead.org>,
	Russell King <linux@armlinux.org.uk>,
	nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, dm-devel@lists.linux.dev
Subject: Re: [RFC PATCH v3 2/4] dax: Check for data cache aliasing at runtime
Date: Fri, 2 Feb 2024 11:32:00 -0500	[thread overview]
Message-ID: <da4c7c2c-0400-40d7-8263-22d284ecca8c@efficios.com> (raw)
In-Reply-To: <f1d14941-2d22-452a-99e6-42db806b6d7f@efficios.com>

On 2024-02-01 10:44, Mathieu Desnoyers wrote:
> On 2024-01-31 17:18, Dan Williams wrote:

[...]


>> diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
>> index 5f1be1da92ce..11053a70f5ab 100644
>> --- a/fs/fuse/virtio_fs.c
>> +++ b/fs/fuse/virtio_fs.c
>> @@ -16,6 +16,7 @@
>>   #include <linux/fs_context.h>
>>   #include <linux/fs_parser.h>
>>   #include <linux/highmem.h>
>> +#include <linux/cleanup.h>
>>   #include <linux/uio.h>
>>   #include "fuse_i.h"
>> @@ -795,8 +796,11 @@ static void virtio_fs_cleanup_dax(void *data)
>>       put_dax(dax_dev);
>>   }
>> +DEFINE_FREE(cleanup_dax, struct dax_dev *, if (!IS_ERR_OR_NULL(_T)) 
>> virtio_fs_cleanup_dax(_T))
>> +
>>   static int virtio_fs_setup_dax(struct virtio_device *vdev, struct 
>> virtio_fs *fs)
> 
> So either I'm completely missing how ownership works in this function, or
> we should be really concerned about the fact that it does no actual
> cleanup of anything on any error.
[...]
> 
> Here what I'm seeing so far:
> 
> - devm_release_mem_region() is never called after 
> devm_request_mem_region(). Not
>    on error, neither on teardown,
> - pgmap is never freed on error after devm_kzalloc.

I was indeed missing something: the devm_ family of functions
keeps ownership at the device level, so we would not need explicit
teardown.

> 
>>   {
>> +    struct dax_device *dax_dev __free(cleanup_dax) = NULL;
>>       struct virtio_shm_region cache_reg;
>>       struct dev_pagemap *pgmap;
>>       bool have_cache;
>> @@ -804,6 +808,15 @@ static int virtio_fs_setup_dax(struct 
>> virtio_device *vdev, struct virtio_fs *fs)
>>       if (!IS_ENABLED(CONFIG_FUSE_DAX))
>>           return 0;
>> +    dax_dev = alloc_dax(fs, &virtio_fs_dax_ops);
>> +    if (IS_ERR(dax_dev)) {
>> +        int rc = PTR_ERR(dax_dev);
>> +
>> +        if (rc == -EOPNOTSUPP)
>> +            return 0;
>> +        return rc;
>> +    }
> 
> What is gained by moving this allocation here ?

I'm still concerned about moving the call to alloc_dax() before
the setup of the memory region it will use. Are those completely
independent ?

> 
>> +
>>       /* Get cache region */
>>       have_cache = virtio_get_shm_region(vdev, &cache_reg,
>>                          (u8)VIRTIO_FS_SHMCAP_ID_CACHE);
>> @@ -849,10 +862,7 @@ static int virtio_fs_setup_dax(struct 
>> virtio_device *vdev, struct virtio_fs *fs)
>>       dev_dbg(&vdev->dev, "%s: window kaddr 0x%px phys_addr 0x%llx len 
>> 0x%llx\n",
>>           __func__, fs->window_kaddr, cache_reg.addr, cache_reg.len);
>> -    fs->dax_dev = alloc_dax(fs, &virtio_fs_dax_ops);
>> -    if (IS_ERR(fs->dax_dev))
>> -        return PTR_ERR(fs->dax_dev);
>> -
>> +    fs->dax_dev = no_free_ptr(dax_dev);
>>       return devm_add_action_or_reset(&vdev->dev, virtio_fs_cleanup_dax,
>>                       fs->dax_dev);
>>   }
> 

[...]

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com


  parent reply	other threads:[~2024-02-02 16:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31 16:25 [RFC PATCH v3 0/4] Introduce cpu_dcache_is_aliasing() to fix DAX regression Mathieu Desnoyers
2024-01-31 16:25 ` [RFC PATCH v3 1/4] dm: Treat alloc_dax failure as non-fatal Mathieu Desnoyers
2024-01-31 16:25 ` [RFC PATCH v3 2/4] dax: Check for data cache aliasing at runtime Mathieu Desnoyers
2024-01-31 21:02   ` Dan Williams
2024-01-31 21:39     ` Mathieu Desnoyers
2024-01-31 22:18       ` Dan Williams
2024-02-01 15:44         ` Mathieu Desnoyers
2024-02-02 14:40           ` Mathieu Desnoyers
2024-02-02 16:32           ` Mathieu Desnoyers [this message]
2024-02-02 17:37           ` Dan Williams
2024-02-02 19:29             ` Mathieu Desnoyers
2024-02-02 19:41               ` Dan Williams
2024-02-02 20:02                 ` Mathieu Desnoyers
2024-02-02 20:14                   ` Dan Williams
2024-02-02 20:18                     ` Mathieu Desnoyers
2024-01-31 16:25 ` [RFC PATCH v3 3/4] Introduce cpu_dcache_is_aliasing() across all architectures Mathieu Desnoyers
2024-01-31 17:17   ` Christoph Hellwig
2024-01-31 17:59     ` Mathieu Desnoyers
2024-01-31 20:42       ` Dan Williams
2024-01-31 16:25 ` [RFC PATCH v3 4/4] dax: Fix incorrect list of data cache aliasing architectures Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=da4c7c2c-0400-40d7-8263-22d284ecca8c@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=david@fromorbit.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --cc=nvdimm@lists.linux.dev \
    --cc=torvalds@linux-foundation.org \
    --cc=vishal.l.verma@intel.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.