On Mon, Jan 22, 2024 at 02:02:28PM -0800, Linus Torvalds wrote:
> On Mon, 22 Jan 2024 at 13:59, Darrick J. Wong wrote:
> >
> > though I don't think
> > leaking raw kernel pointers is an awesome idea.
>
> Yeah, I wasn't all that comfortable even with trying to
On Tue, Jan 16, 2024 at 05:55:32PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The dentries and inodes are created in the readdir for the sole purpose of
> getting a consistent inode number. Linus stated that is unnecessary, and
> that all inodes can have the same inode
On Mon, Mar 20, 2023 at 06:02:05PM +0800, Shiyang Ruan wrote:
>
>
> 在 2023/3/18 4:35, Darrick J. Wong 写道:
> > On Fri, Mar 17, 2023 at 03:59:48AM +, Shiyang Ruan wrote:
> > > As is mentioned[1] before, the generic/388 will randomly fail with dmesg
> > >
On Fri, Mar 17, 2023 at 03:59:48AM +, Shiyang Ruan wrote:
> As is mentioned[1] before, the generic/388 will randomly fail with dmesg
> warning. This case uses fsstress with a lot of random operations. It is hard
> to reproduce. Finally I found a 100% reproduce condition, which is setting
>
the flag needs to be renamed to PAGE_MAPPING_DAX_SHARED.
>
> Signed-off-by: Shiyang Ruan
> Reviewed-by: Allison Henderson
Looks fine to me,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 38 ++
> include/linux/m
On Mon, Dec 05, 2022 at 01:56:24PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/12/3 10:07, Dan Williams 写道:
> > Shiyang Ruan wrote:
> > > fsdax page is used not only when CoW, but also mapread. To make the it
> > > easily understood, use 'share' to indicate that the dax page is shared
> > > by more
On Thu, Dec 01, 2022 at 03:32:53PM +, Shiyang Ruan wrote:
> Since the basic function for fsdax and reflink has been implemented,
> remove the restrictions of them for widly test.
>
> Signed-off-by: Shiyang Ruan
Looks ok,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/x
On Thu, Dec 01, 2022 at 03:32:10PM +, Shiyang Ruan wrote:
> Zero and truncate on a dax file may execute CoW. So use dax ops which
> contains end work for CoW.
>
> Signed-off-by: Shiyang Ruan
LGTM
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/xfs_iomap.c | 4 ++--
&g
them called at the same time.
>
> Signed-off-by: Shiyang Ruan
Thank you for adding that explanation, it makes the problem much more
obvious. :)
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --
;
> Signed-off-by: Shiyang Ruan
Makes sense.
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 19 +++
> fs/xfs/xfs_iomap.c | 2 +-
> 2 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 6b6e07ad8d8
* dax_iomap_cow_copy - Copy the data from source to destination before write
> + * dax_iomap_copy_around - Copy the data from source to destination before
> write
* dax_iomap_copy_around - Prepare for an unaligned write to a
* shared/cow page by copying the data before and after the range to be
On Thu, Dec 01, 2022 at 11:39:12PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/12/1 5:08, Darrick J. Wong 写道:
> > On Tue, Nov 29, 2022 at 11:05:30PM -0800, Dan Williams wrote:
> > > Darrick J. Wong wrote:
> > > > On Tue, Nov 29, 2022 at 07:59:14PM -0800, Dan Wi
share state when CoW happens, in both dax_iomap_rw() and
> dax_zero_iter().
>
> Signed-off-by: Shiyang Ruan
Looks ok,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/fs/d
On Thu, Dec 01, 2022 at 03:28:51PM +, Shiyang Ruan wrote:
> fsdax page is used not only when CoW, but also mapread. To make the it
> easily understood, use 'share' to indicate that the dax page is shared
> by more than one extent. And add helper functions to use it.
>
> Also, the flag needs
On Wed, Nov 30, 2022 at 01:48:59PM -0800, Dan Williams wrote:
> Andrew Morton wrote:
> > On Tue, 29 Nov 2022 19:59:14 -0800 Dan Williams
> > wrote:
> >
> > > [ add Andrew ]
> > >
> > > Shiyang Ruan wrote:
> > > > Many testcases failed in dax+reflink mode with warning message in dmesg.
> > > >
On Tue, Nov 29, 2022 at 11:05:30PM -0800, Dan Williams wrote:
> Darrick J. Wong wrote:
> > On Tue, Nov 29, 2022 at 07:59:14PM -0800, Dan Williams wrote:
> > > [ add Andrew ]
> > >
> > > Shiyang Ruan wrote:
> > > > Many testcases failed i
On Wed, Nov 30, 2022 at 04:58:32PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/11/30 12:08, Darrick J. Wong 写道:
> > On Thu, Nov 24, 2022 at 02:54:53PM +, Shiyang Ruan wrote:
> > > This patch fixes the warning message reported in dax_associate_entry()
> >
On Tue, Nov 29, 2022 at 07:59:14PM -0800, Dan Williams wrote:
> [ add Andrew ]
>
> Shiyang Ruan wrote:
> > Many testcases failed in dax+reflink mode with warning message in dmesg.
> > This also effects dax+noreflink mode if we run the test after a
> > dax+reflink test. So, the most urgent thing
On Thu, Nov 24, 2022 at 02:54:53PM +, Shiyang Ruan wrote:
> This patch fixes the warning message reported in dax_associate_entry()
> and dax_disassociate_entry().
Hmm, that's quite a bit to put in a single patch, but I'll try to get
through this...
> 1. reset page->mapping and ->index when
On Thu, Nov 24, 2022 at 02:54:54PM +, Shiyang Ruan wrote:
> Implement unshare in fsdax mode: copy data from srcmap to iomap.
>
> Signed-off-by: Shiyang Ruan
Heh, I had a version nearly like this in my tree. Makes reviewing
easier:
Reviewed-by: Darrick J. Wong
--D
> ---
On Mon, Nov 28, 2022 at 10:16:23AM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/11/28 2:38, Darrick J. Wong 写道:
> > On Thu, Nov 24, 2022 at 02:54:52PM +, Shiyang Ruan wrote:
> > > Many testcases failed in dax+reflink mode with warning message in dmesg.
> > > Thi
On Thu, Nov 24, 2022 at 02:54:52PM +, Shiyang Ruan wrote:
> Many testcases failed in dax+reflink mode with warning message in dmesg.
> This also effects dax+noreflink mode if we run the test after a
> dax+reflink test. So, the most urgent thing is solving the warning
> messages.
>
> Patch 1
On Sun, Oct 16, 2022 at 10:05:17PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/10/14 23:50, Darrick J. Wong 写道:
> > On Fri, Oct 14, 2022 at 10:24:29AM +0800, Shiyang Ruan wrote:
> > >
> > >
> > > 在 2022/10/14 2:30, Darrick J. Wong 写道:
> > > &g
On Fri, Oct 14, 2022 at 10:24:29AM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/10/14 2:30, Darrick J. Wong 写道:
> > On Thu, Sep 29, 2022 at 12:05:14PM -0700, Darrick J. Wong wrote:
> > > On Wed, Sep 28, 2022 at 10:46:17PM +0800, Shiyang Ruan wrote:
> > > >
>
On Thu, Sep 29, 2022 at 12:05:14PM -0700, Darrick J. Wong wrote:
> On Wed, Sep 28, 2022 at 10:46:17PM +0800, Shiyang Ruan wrote:
> >
> >
> > 在 2022/9/28 7:51, Dave Chinner 写道:
> > > On Tue, Sep 27, 2022 at 09:02:48AM -0700, Darrick J. Wong wrote:
> > > >
On Wed, Sep 28, 2022 at 10:46:17PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/9/28 7:51, Dave Chinner 写道:
> > On Tue, Sep 27, 2022 at 09:02:48AM -0700, Darrick J. Wong wrote:
> > > On Tue, Sep 27, 2022 at 02:53:14PM +0800, Shiyang Ruan wrote:
> ...
> > > >
On Tue, Sep 27, 2022 at 02:53:14PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/9/20 5:15, Dave Chinner 写道:
> > On Mon, Sep 19, 2022 at 02:50:03PM +1000, Dave Chinner wrote:
> > > On Thu, Sep 15, 2022 at 09:26:42AM +, Shiyang Ruan wrote:
> > > > Since reflink can work together now, the last
On Tue, Sep 20, 2022 at 12:45:19PM +1000, Dave Chinner wrote:
> On Fri, Sep 02, 2022 at 10:36:01AM +, Shiyang Ruan wrote:
> > This patch is inspired by Dan's "mm, dax, pmem: Introduce
> > dev_pagemap_failure()"[1]. With the help of dax_holder and
> > ->notify_failure() mechanism, the pmem
On Thu, Sep 15, 2022 at 10:56:09AM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/9/15 2:15, Darrick J. Wong 写道:
> > On Wed, Sep 14, 2022 at 11:09:23AM -0700, Darrick J. Wong wrote:
> > > On Wed, Sep 07, 2022 at 05:46:00PM +0800, Shiyang Ruan wrote:
> > > > pi
On Fri, Sep 02, 2022 at 10:36:00AM +, Shiyang Ruan wrote:
> xfs_notify_failure requires a method to invalidate all mappings.
> drop_pagecache_sb() can do this but it is a static function and only
> build with CONFIG_SYSCTL. Now, move it to super.c and make it available
> for others.
>
>
On Wed, Sep 14, 2022 at 11:09:23AM -0700, Darrick J. Wong wrote:
> On Wed, Sep 07, 2022 at 05:46:00PM +0800, Shiyang Ruan wrote:
> > ping
> >
> > 在 2022/9/2 18:35, Shiyang Ruan 写道:
> > > Changes since v7:
> > >1. Add P1 to fix calculation mistake
>
On Fri, Sep 02, 2022 at 10:36:01AM +, Shiyang Ruan wrote:
> This patch is inspired by Dan's "mm, dax, pmem: Introduce
> dev_pagemap_failure()"[1]. With the help of dax_holder and
> ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> (or mapped device) on it to unmap all
On Fri, Sep 02, 2022 at 10:35:59AM +, Shiyang Ruan wrote:
> The end should be start + length - 1. Also fix the calculation of the
> length when seeking for intersection of notify range and device.
>
> Signed-off-by: Shiyang Ruan
Looks correct to me,
Reviewed-by: Darrick J
On Wed, Sep 07, 2022 at 05:46:00PM +0800, Shiyang Ruan wrote:
> ping
>
> 在 2022/9/2 18:35, Shiyang Ruan 写道:
> > Changes since v7:
> >1. Add P1 to fix calculation mistake
> >2. Add P2 to move drop_pagecache_sb() to super.c for xfs to use
> >3. P3: Add invalidate all mappings after
On Wed, Sep 14, 2022 at 08:34:26AM -0400, Brian Foster wrote:
> On Wed, Sep 14, 2022 at 05:38:02PM +0800, Yang, Xiao/杨 晓 wrote:
> > On 2022/9/14 14:44, Yang, Xiao/杨 晓 wrote:
> > > On 2022/9/9 21:01, Brian Foster wrote:
> > > > Yes.. I don't recall all the internals of the tools and test, but IIRC
gt; 2. hold s_umount before sync_filesystem()
> > > 3. do sync_filesystem() after SB_BORN check
> > > 4. Rebased on next-20220714
> > >
> > > [1]:
> > > https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.st...@dwillia2-d
On Thu, Aug 18, 2022 at 07:19:28PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/8/3 12:33, Darrick J. Wong 写道:
> > On Wed, Aug 03, 2022 at 02:43:20AM +, ruansy.f...@fujitsu.com wrote:
> > >
> > > 在 2022/7/19 6:56, Dan Williams 写道:
> > > > Darrick
From: Darrick J. Wong
xfs_dax_failure_fn is used to scan the filesystem during a memory
failure event to look for memory mappings to revoke. Unfortunately, if
it encounters an rmap record for filesystem metadata, it will shut down
the filesystem and the scan immediately. This means that we
On Wed, Aug 03, 2022 at 06:47:24AM +, ruansy.f...@fujitsu.com wrote:
>
>
> 在 2022/7/29 12:54, Darrick J. Wong 写道:
> > On Fri, Jul 29, 2022 at 03:55:24AM +, ruansy.f...@fujitsu.com wrote:
> >>
> >>
> >> 在 2022/7/22 0:16, Darrick J. Wong 写道:
>
On Wed, Aug 03, 2022 at 02:43:20AM +, ruansy.f...@fujitsu.com wrote:
>
> 在 2022/7/19 6:56, Dan Williams 写道:
> > Darrick J. Wong wrote:
> >> On Thu, Jul 14, 2022 at 11:21:44AM -0700, Dan Williams wrote:
> >>> ruansy.f...@fujitsu.com wrote:
> >>>>
On Fri, Jul 29, 2022 at 03:55:24AM +, ruansy.f...@fujitsu.com wrote:
>
>
> 在 2022/7/22 0:16, Darrick J. Wong 写道:
> > On Thu, Jul 21, 2022 at 02:06:10PM +, ruansy.f...@fujitsu.com wrote:
> >> 在 2022/7/1 8:31, Darrick J. Wong 写道:
> >>> On Thu, Jun 09, 20
int ret;
>
> + if (!iomi.len)
> + return 0;
Hmm, most of the callers of dax_iomap_rw skip the whole call if
iov_iter_count(to)==0, so I wonder if fuse_dax_read_iter should do the
same?
That said, iomap_dio_rw bails early if you pass it iomi.len, so I don't
have any real objection
On Thu, Jul 21, 2022 at 02:06:10PM +, ruansy.f...@fujitsu.com wrote:
> 在 2022/7/1 8:31, Darrick J. Wong 写道:
> > On Thu, Jun 09, 2022 at 10:34:35PM +0800, Shiyang Ruan wrote:
> >> Failure notification is not supported on partitions. So, when we mount
> >> a reflink
On Thu, Jul 14, 2022 at 11:21:44AM -0700, Dan Williams wrote:
> ruansy.f...@fujitsu.com wrote:
> > This patch is inspired by Dan's "mm, dax, pmem: Introduce
> > dev_pagemap_failure()"[1]. With the help of dax_holder and
> > ->notify_failure() mechanism, the pmem driver is able to ask filesystem
>
based on next-20220714
>
> Changes since v4:
> 1. sync_filesystem() at the beginning when MF_MEM_REMOVE
> 2. Rebased on next-20220706
>
> [1]:
> https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.st...@dwillia2-desk3.amr.corp.intel.com/
>
&
On Fri, Jul 08, 2022 at 05:42:22AM +, ruansy.f...@fujitsu.com wrote:
> This patch is inspired by Dan's "mm, dax, pmem: Introduce
> dev_pagemap_failure()"[1]. With the help of dax_holder and
> ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> (or mapped device) on it to
On Sun, Jul 03, 2022 at 09:08:38PM +0800, Shiyang Ruan wrote:
> This patch is inspired by Dan's "mm, dax, pmem: Introduce
> dev_pagemap_failure()"[1]. With the help of dax_holder and
> ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> (or mapped device) on it to unmap all
though I think this patch applies to ... wherever all
those rmap+reflink+dax patches went. I think that's akpm's tree, right?
Ideally this would go in through there to keep the pieces together, but
I don't mind tossing this in at the end of the 5.20 merge window if akpm
is unwilling.
Reviewed-by:
On Wed, Jun 15, 2022 at 08:54:00PM +0800, Shiyang Ruan wrote:
> This patch is inspired by Dan's "mm, dax, pmem: Introduce
> dev_pagemap_failure()"[1]. With the help of dax_holder and
> ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> (or mapped device) on it to unmap all
I don't see any of the patches 1-5,7-13 in current upstream, so
I'm guessing this means Andrew isn't taking it for 5.19?
--D
>
>
> --
> Thanks,
> Ruan.
>
>
> 在 2022/5/12 20:27, Shiyang Ruan 写道:
> >
> >
> > 在 2022/5/11 23:46, Dan Williams 写道:
> >
Oan Tue, May 10, 2022 at 10:24:28PM -0700, Andrew Morton wrote:
> On Tue, 10 May 2022 19:43:01 -0700 "Darrick J. Wong"
> wrote:
>
> > On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote:
> > > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
> &g
On Tue, May 10, 2022 at 09:20:57PM -0700, Dan Williams wrote:
> On Tue, May 10, 2022 at 7:29 PM Andrew Morton
> wrote:
> >
> > On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
> > wrote:
> >
> > > > It'll need to be a stable branch somewhere, but I don't think it
> > > > really matters where al
On Tue, May 10, 2022 at 07:28:53PM -0700, Andrew Morton wrote:
> On Tue, 10 May 2022 18:55:50 -0700 Dan Williams
> wrote:
>
> > > It'll need to be a stable branch somewhere, but I don't think it
> > > really matters where al long as it's merged into the xfs for-next
> > > tree so it gets
On Sun, May 08, 2022 at 10:36:06PM +0800, Shiyang Ruan wrote:
> This is a combination of two patchsets:
> 1.fsdax-rmap:
> https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/
> 2.fsdax-reflink:
>
s as part
> of the memory_failure handler after the file system performed a reverse
> mapping from the storage address to the file and file offset.
>
> Signed-off-by: Shiyang Ruan
> Reviewed-by: Dan Williams
> Reviewed-by: Christoph Hellwig
Looks ok,
Reviewed-by: Darrick J. Wong
--D
> -
we exit to the caller with the magic return value, having
not set *page. Either the comment for this function should note that
the caller must set *page to a known value (NULL?) before the call, or
we should set *page = NULL here.
AFAICT the callers in this series initialize page to NULL be
Ruan
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Dan Williams
Looks good to me now that we've ironed out the earlier unit questions,
Reviewed-by: Darrick J. Wong
--D
> ---
> drivers/nvdimm/pmem.c| 17 +
> include/linux/memremap.h | 12
> m
e
>can finally track to the filesystem we needed.
>
> The holder and holder_ops will be set when filesystem is being mounted,
> or an target device is being activated.
>
> Signed-off-by: Shiyang Ruan
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Dan Wi
AGE_MAPPING_FLAGS (PAGE_MAPPING_ANON | PAGE_MAPPING_MOVABLE)
>
> +/*
> + * Different with flags above, this flag is used only for fsdax mode. It
> + * indicates that this page->mapping is now under reflink case.
> + */
> +#define PAGE_MAPPING_DAX_COW 0x1
The logic looks sound enough, I guess.
Though I do wonder -- if this were defined like this:
#define PAGE_MAPPING_DAX_COW((struct address_space *)0x1)
Could you then avoid all uintptr_t/unsigned long casts above?
It's probably not worth holding up the whole patchset though, so
Reviewed-by: Darrick J. Wong
--D
> +
> static __always_inline int PageMappingFlags(struct page *page)
> {
> return ((unsigned long)page->mapping & PAGE_MAPPING_FLAGS) != 0;
> --
> 2.35.1
>
>
>
e processes who are
> using those files.
>
> Signed-off-by: Shiyang Ruan
> Reviewed-by: Christoph Hellwig
Looks good now, thank you for your persistence!
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/Makefile | 5 +
> fs/xfs/xfs_buf.c|
On Tue, Apr 19, 2022 at 12:50:44PM +0800, Shiyang Ruan wrote:
> Introduce xfs_notify_failure.c to handle failure related works, such as
> implement ->notify_failure(), register/unregister dax holder in xfs, and
> so on.
>
> If the rmap feature of XFS enabled, we can query it to find files and
>
On Tue, Apr 05, 2022 at 06:22:48PM -0700, Dan Williams wrote:
> On Tue, Apr 5, 2022 at 5:55 PM Jane Chu wrote:
> >
> > On 3/30/2022 9:18 AM, Darrick J. Wong wrote:
> > > On Wed, Mar 30, 2022 at 08:49:29AM -0700, Christoph Hellwig wrote:
> > >> On Wed, Mar 3
On Wed, Mar 30, 2022 at 08:49:29AM -0700, Christoph Hellwig wrote:
> On Wed, Mar 30, 2022 at 06:58:21PM +0800, Shiyang Ruan wrote:
> > As the code I pasted before, pmem driver will subtract its ->data_offset,
> > which is byte-based. And the filesystem who implements ->notify_failure()
> > will
On Sun, Feb 13, 2022 at 09:02:24PM +0800, Shiyang Ruan wrote:
> v10.1 update:
> - Handle the error code returns by dax_register_holder()
> - In v10.1, dax_register_holder() will hold a write lock so XFS
> doesn't need to hold a lock
> - Fix the mistake in failure notification over two AGs
On Thu, Jan 27, 2022 at 08:40:57PM +0800, Shiyang Ruan wrote:
> Introduce xfs_notify_failure.c to handle failure related works, such as
> implement ->notify_failure(), register/unregister dax holder in xfs, and
> so on.
>
> If the rmap feature of XFS enabled, we can query it to find files and
>
On Fri, Jan 21, 2022 at 09:26:52AM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/1/20 16:46, Christoph Hellwig 写道:
> > On Wed, Jan 05, 2022 at 04:12:04PM -0800, Dan Williams wrote:
> > > We ended up with explicit callbacks after hch balked at a notifier
> > > call-chain, but I think we're back to that
On Wed, Jan 05, 2022 at 03:01:22PM -0800, Dan Williams wrote:
> On Wed, Jan 5, 2022 at 2:47 PM Darrick J. Wong wrote:
> >
> > On Wed, Jan 05, 2022 at 11:20:12AM -0800, Dan Williams wrote:
> > > On Wed, Jan 5, 2022 at 10:56 AM Darrick J. Wong wrote:
> > > >
&
On Wed, Jan 05, 2022 at 11:20:12AM -0800, Dan Williams wrote:
> On Wed, Jan 5, 2022 at 10:56 AM Darrick J. Wong wrote:
> >
> > On Wed, Jan 05, 2022 at 10:23:08AM -0800, Dan Williams wrote:
> > > On Wed, Jan 5, 2022 at 10:12 AM Darrick J. Wong wrote:
> > > >
&
On Sun, Dec 26, 2021 at 10:34:33PM +0800, Shiyang Ruan wrote:
> When memory-failure occurs, we call this function which is implemented
> by each kind of devices. For the fsdax case, pmem device driver
> implements it. Pmem device driver will find out the filesystem in which
> the corrupted page
On Wed, Jan 05, 2022 at 10:23:08AM -0800, Dan Williams wrote:
> On Wed, Jan 5, 2022 at 10:12 AM Darrick J. Wong wrote:
> >
> > On Sun, Dec 26, 2021 at 10:34:31PM +0800, Shiyang Ruan wrote:
> > > To easily track filesystem from a pmem device, we introduce a holder for
&g
On Sun, Dec 26, 2021 at 10:34:38PM +0800, Shiyang Ruan wrote:
> Introduce xfs_notify_failure.c to handle failure related works, such as
> implement ->notify_failure(), register/unregister dax holder in xfs, and
> so on.
>
> If the rmap feature of XFS enabled, we can query it to find files and
>
On Sun, Dec 26, 2021 at 10:34:31PM +0800, Shiyang Ruan wrote:
> To easily track filesystem from a pmem device, we introduce a holder for
> dax_device structure, and also its operation. This holder is used to
> remember who is using this dax_device:
> - When it is the backend of a filesystem, the
On Sun, Dec 26, 2021 at 10:34:34PM +0800, Shiyang Ruan wrote:
> The function name has been changed, so the description should be updated
> too.
>
> Signed-off-by: Shiyang Ruan
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Tue, Jan 04, 2022 at 02:44:08PM -0800, Dan Williams wrote:
> On Sun, Dec 26, 2021 at 6:35 AM Shiyang Ruan wrote:
> >
> > In order to introduce dax holder registration, we need a write lock for
> > dax.
>
> As far as I can see, no, a write lock is not needed while the holder
> is being
On Thu, Dec 02, 2021 at 04:48:55PM +0800, Shiyang Ruan wrote:
> Introduce xfs_notify_failure.c to handle failure related works, such as
> implement ->notify_failure(), register/unregister dax holder in xfs, and
> so on.
>
> If the rmap feature of XFS enabled, we can query it to find files and
>
On Fri, Sep 24, 2021 at 09:09:57PM +0800, Shiyang Ruan wrote:
> This function is called at the end of RMAP routine, i.e. filesystem
> recovery function, to collect and kill processes using a shared page of
> DAX file. The difference between mf_generic_kill_procs() is,
> it accepts file's
On Fri, Sep 24, 2021 at 09:09:59PM +0800, Shiyang Ruan wrote:
> For reflinked files, one dax page may be associated more than once with
> different fime mapping and index. It will report warning. Now, since
> we have introduced dax-RMAP for this case and also have to keep its
> functionality for
On Fri, Sep 24, 2021 at 09:09:58PM +0800, Shiyang Ruan wrote:
> This function is used to handle errors which may cause data lost in
> filesystem. Such as memory failure in fsdax mode.
>
> If the rmap feature of XFS enabled, we can query it to find files and
> metadata which are associated with
On Fri, Sep 24, 2021 at 09:09:56PM +0800, Shiyang Ruan wrote:
> The current dax_lock_page() locks dax entry by obtaining mapping and
> index in page. To support 1-to-N RMAP in NVDIMM, we need a new function
> to lock a specific dax entry corresponding to this file's mapping,index.
> And BTW,
On Fri, Sep 24, 2021 at 09:09:55PM +0800, Shiyang Ruan wrote:
> When memory-failure occurs, we call this function which is implemented
> by each kind of devices. For the fsdax case, pmem device driver
> implements it. Pmem device driver will find out the filesystem in which
> the corrupted page
ke a reasonable hoist...
Reviewed-by: Darrick J. Wong
--D
> ---
> mm/memory-failure.c | 140
> 1 file changed, 76 insertions(+), 64 deletions(-)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 54879c339024..8ff9
On Fri, Sep 24, 2021 at 09:09:53PM +0800, Shiyang Ruan wrote:
> To easily track filesystem from a pmem device, we introduce a holder for
> dax_device structure, and also its operation. This holder is used to
> remember who is using this dax_device:
> - When it is the backend of a filesystem, the
On Fri, Sep 24, 2021 at 09:09:52PM +0800, Shiyang Ruan wrote:
> In order to introduce dax holder registration, we need a write lock for
> dax. Because of the rarity of notification failures and the infrequency
> of registration events, it would be better to be a global lock rather
> than
;iomap_end() to do the remapping work.
>
> Signed-off-by: Shiyang Ruan
I think this patch looks good, so:
Reviewed-by: Darrick J. Wong
A big thank you to Shiyang for persisting in getting this series
finished! :)
Judging from the conversation Christoph and I had the last time this
patchset
On Fri, Sep 17, 2021 at 01:21:25PM -0700, Dan Williams wrote:
> On Fri, Sep 17, 2021 at 8:27 AM Darrick J. Wong wrote:
> >
> > On Fri, Sep 17, 2021 at 01:53:33PM +0100, Christoph Hellwig wrote:
> > > On Thu, Sep 16, 2021 at 11:40:28AM -0700, Dan Williams wrote:
> >
On Thu, Sep 16, 2021 at 08:32:51AM +0200, Christoph Hellwig wrote:
> On Wed, Sep 15, 2021 at 05:22:27PM -0700, Darrick J. Wong wrote:
> > > xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
> > > ret = dax_iomap_fault
On Fri, Sep 17, 2021 at 01:53:33PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 16, 2021 at 11:40:28AM -0700, Dan Williams wrote:
> > > That was my gut feeling. If everyone feels 100% comfortable with
> > > zeroingas the mechanism to clear poisoning I'll cave in. The most
> > > important bit is
On Thu, Sep 16, 2021 at 04:49:19PM +0800, Shiyang Ruan wrote:
>
>
> On 2021/9/16 14:16, Christoph Hellwig wrote:
> > On Wed, Sep 15, 2021 at 06:44:58PM +0800, Shiyang Ruan wrote:
> > > + rc = dax_direct_access(iomap->dax_dev, pgoff, 1, , NULL);
> > > + if (rc < 0)
> > > + goto out;
> > >
On Thu, Sep 16, 2021 at 12:01:18PM +0800, Shiyang Ruan wrote:
>
>
> On 2021/9/16 8:30, Darrick J. Wong wrote:
> > On Wed, Sep 15, 2021 at 06:45:01PM +0800, Shiyang Ruan wrote:
> > > Introduce xfs_mmaplock_two_inodes_and_break_dax_layout() for dax files
> > > wh
uan
> Reviewed-by: Darrick J. Wong
> Reviewed-by: Christoph Hellwig
> ---
> fs/xfs/xfs_file.c| 2 +-
> fs/xfs/xfs_inode.c | 80 +---
> fs/xfs/xfs_inode.h | 1 +
> fs/xfs/xfs_reflink.c | 4 +--
> 4 files changed, 80 insertions(
On Wed, Sep 15, 2021 at 06:45:00PM +0800, Shiyang Ruan wrote:
> In fsdax mode, WRITE and ZERO on a shared extent need CoW performed.
> After that, new allocated extents needs to be remapped to the file.
> So, add a CoW identification in ->iomap_begin(), and implement
> ->iomap_end() to do the
On Wed, Sep 15, 2021 at 06:44:57PM +0800, Shiyang Ruan wrote:
> Let dax_iomap_zero() support iter model.
>
> Signed-off-by: Shiyang Ruan
Oops, I guess we forgot this one when we did the iter conversion last
cycle. :(
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c
ewed-by: Christoph Hellwig
> Reviewed-by: Ritesh Harjani
> Reviewed-by: Dan Williams
Could've sworn I reviewed this a few revisions ago...
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/dax.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> d
On Wed, Sep 15, 2021 at 01:27:47PM -0700, Dan Williams wrote:
> On Wed, Sep 15, 2021 at 9:15 AM Darrick J. Wong wrote:
> >
> > On Wed, Sep 15, 2021 at 12:22:05AM -0700, Jane Chu wrote:
> > > Hi, Dan,
> > >
> > > On 9/14/2021 9:44 PM, Dan Williams wrot
On Wed, Sep 15, 2021 at 12:22:05AM -0700, Jane Chu wrote:
> Hi, Dan,
>
> On 9/14/2021 9:44 PM, Dan Williams wrote:
> > On Tue, Sep 14, 2021 at 4:32 PM Jane Chu wrote:
> > >
> > > If pwrite(2) encounters poison in a pmem range, it fails with EIO.
> > > This is unecessary if hardware is capable
On Thu, Sep 02, 2021 at 09:43:08AM +0200, Christoph Hellwig wrote:
> On Sun, Aug 29, 2021 at 08:25:16PM +0800, Shiyang Ruan wrote:
> > In fsdax mode, WRITE and ZERO on a shared extent need CoW performed.
> > After that, new allocated extents needs to be remapped to the file. Add
> > an
On Tue, Apr 20, 2021 at 06:06:52PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix
> the following warnings by replacing /* fall through */ comments,
> and its variants, with the new pseudo-keyword macro fallthrough:
>
>
On Mon, Apr 19, 2021 at 10:49:48AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the vfs tree got a conflict in:
>
> fs/xfs/xfs_ioctl.c
>
> between commit:
>
> b2197a36c0ef ("xfs: remove XFS_IFEXTENTS")
>
> from the xfs tree and commit:
>
> 9fefd5db08ce
On Mon, Apr 12, 2021 at 12:22:11PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the vfs tree got a conflict in:
>
> fs/xfs/xfs_ioctl.c
>
> between commits:
>
> ceaf603c7024 ("xfs: move the di_projid field to struct xfs_inode")
> 031474c28a3a ("xfs: move the
On Mon, Apr 12, 2021 at 04:29:06PM +0100, Christoph Hellwig wrote:
> > Below are the results of running xfstests for "all" with the following
> > configuration in local.config:
>
> ...
>
> > Other tests might need to be run in order to verify everything is working
> > as expected. For such
1 - 100 of 1690 matches
Mail list logo
