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 now. The partition mistake
> might be unfixable, but at least bdev_dax_pgoff() is dead. Notifier
> call chains have their o
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
Looks good,
Reviewed-by: Christoph Hellwig
Dan, can you send this to Linux for 5.17 so that we can get it out of
the
On Sun, Dec 26, 2021 at 10:34:36PM +0800, Shiyang Ruan wrote:
> Since it is not a DAX-specific function, move it into mm and rename it
> to be a generic helper.
>
> Signed-off-by: Shiyang Ruan
Looks good,
Reviewed-by: Christoph Hellwig
Please only build the new DAX code if CONFIG_FS_DAX is set.
On Sun, Dec 26, 2021 at 10:34:39PM +0800, Shiyang Ruan wrote:
> +#define FS_DAX_MAPPING_COW 1UL
> +
> +#define MAPPING_SET_COW(m) (m = (struct address_space *)FS_DAX_MAPPING_COW)
> +#define MAPPING_TEST_COW(m) (((unsigned long)m & FS_DAX_MAPPING_COW) == \
> +
在 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 now. The partition mistake
might be unfixable, but at least bdev_dax_pgoff() is
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
在 2022/1/20 16:59, Christoph Hellwig 写道:
On Sun, Dec 26, 2021 at 10:34:39PM +0800, Shiyang Ruan wrote:
+#define FS_DAX_MAPPING_COW 1UL
+
+#define MAPPING_SET_COW(m) (m = (struct address_space *)FS_DAX_MAPPING_COW)
+#define MAPPING_TEST_COW(m)(((unsigned long)m & FS_DAX_MAPPING_COW
On Fri, Jan 21, 2022 at 10:33:58AM +0800, Shiyang Ruan wrote:
> >
> > But different question, how does this not conflict with:
> >
> > #define PAGE_MAPPING_ANON 0x1
> >
> > in page-flags.h?
>
> Now we are treating dax pages, so I think its flags should be different from
> normal page. In
On Thu, Jan 20, 2022 at 06:22:00PM -0800, Darrick J. Wong wrote:
> Hm, so that means XFS can only support dax+pmem when there aren't
> partitions in use? Ew.
Yes. Or any sensible DAX usage going forward for that matter.
>
> > > (2) extent the holder mechanism to cover a rangeo
>
> I don't t
The flush_cache_page() only remove a PAGE_SIZE sized range from the cache.
However, it does not cover the full pages in a THP except a head page.
Replace it with flush_cache_range() to fix this issue. At least, no
problems were found due to this. Maybe because the architectures that
have virtual in
The flush_cache_page() only remove a PAGE_SIZE sized range from the cache.
However, it does not cover the full pages in a THP except a head page.
Replace it with flush_cache_range() to fix this issue.
Fixes: f729c8c9b24f ("dax: wrprotect pmd_t in dax_mapping_entry_mkclean")
Signed-off-by: Muchun S
page_vma_mapped_walk() is supposed to check if a page is mapped into a vma.
However, not all page frames (e.g. PFN_DEV) have a associated struct page
with it. There is going to be some duplicate codes similar with this function
if someone want to check if a pfn (without a struct page) is mapped int
Currently dax_mapping_entry_mkclean() fails to clean and write protect
the pte entry within a DAX PMD entry during an *sync operation. This
can result in data loss in the following sequence:
1) process A mmap write to DAX PMD, dirtying PMD radix tree entry and
making the pmd entry dirty and
The only user (DAX) of range parameter of follow_invalidate_pte()
is gone, it safe to remove the range paramter and make it static
to simlify the code.
Signed-off-by: Muchun Song
---
include/linux/mm.h | 3 ---
mm/memory.c| 23 +++
2 files changed, 3 insertions(+), 2
15 matches
Mail list logo
