uses
> rcu_read_lock() to protect against the inode being freed, and
> revalidates the page->mapping association under xa_lock().
>
> Cc: Christoph Hellwig
> Cc: Matthew Wilcox
> Cc: Ross Zwisler
> Cc: Jan Kara
> Signed-off-by: Dan Williams
Just got back from vacati
EMORY_DEVICE_HOST
> dev_pagemap pages that have poison consumed by userspace. Mark the
> memory as UC instead of unmapping it completely to allow ongoing access
> via the device driver (nd_pmem). Later, nd_pmem will grow support for
> marking the page back to WB when the error is cleared.
>
&
On Fri 27-07-18 10:28:51, Ross Zwisler wrote:
> + fsdevel and the xfs list.
>
> On Wed, Jul 25, 2018 at 4:28 PM Ross Zwisler
> wrote:
> > On Wed, Jul 11, 2018 at 10:17:41AM +0200, Jan Kara wrote:
> > > On Tue 10-07-18 13:10:29, Ross Zwisler wrote:
> > > >
description should be in terms of what kind of memory is
the MEMORY_DEVICE_DEV_DAX type, not how users use this type. See comments
for other memory types...
Honza
> */
> enum memory_type {
> MEMORY_DEVICE_PR
nt about this
part of the kernel... But feel free to add my:
Acked-by: Jan Kara
Honza
> ---
> include/linux/mm.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/lin
pushing it with them during the
merge window. It's not necessary though - the patches already make the
problematic behavior much less likely, this patch just hopefully completely
closes the race window.
> Signed-off-by: Ross Zwisler
> Reviewed-by: Jan Kara
tinue looping as long as dax_layout_busy_page() gives us
> a page which it found with an elevated refcount.
>
> Signed-off-by: Dave Jiang
The patch looks good to me. You can add:
Reviewed-by: Jan Kara
Just one minor nit below:
> @@ -746,9 +744,10 @@ xfs_break_dax_layouts(
>
tinue looping as long as dax_layout_busy_page() gives us
> a page which it found with an elevated refcount.
>
> Signed-off-by: Dave Jiang
I think I gave you my reviewed-by tag already for the previous version. But
here it is again:
Reviewed-by: Jan Kara
uces a new memory type, MEMORY_DEVICE_DEV_DAX. And set this flag
> while dax driver hotplug the device memory.
>
> Signed-off-by: Zhang Yi
> Signed-off-by: Zhang Yu
Looks good to me now. You can add:
Reviewed-by: Jan Kara
AX: Jan
> [PATCH V3 3/4] Acked-by: Jan in V2
Hum, but it is not the the patch...
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
XT4-fs (pmem0): mounted filesystem with ordered data mode.
> Opts: acl,user_xattr,block_validity,dax
> [ 117.796623] EXT4-fs (pmem1): DAX enabled. Warning: EXPERIMENTAL, use at
> your own risk
> [ 117.798546] EXT4-fs (pmem1): mounted filesystem with ordered data mode.
> Opts: acl,user_xattr,block_validity,dax
> _check_dmesg: something found in dmesg (see
> /results/ext4/results-dax/generic/344.dmesg)
>
> - Ted
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On Mon 13-08-18 12:12:52, Jan Kara wrote:
> On Fri 10-08-18 22:10:53, Theodore Y. Ts'o wrote:
> > The generic/344 failure seems to be caused by a WARNING triggered in
> > the nvdimm code:
>
> OK, apparently this is nothing new for you as generic/344 fails for you
>
the cryptic
failure makes it even worse (it took me quite a while to understand what is
failing and why). OTOH I see the rationale behind Ross' change as well.
Honza
--
Jan Kara
SUSE Labs, CR
___
On Mon 13-08-18 12:12:52, Jan Kara wrote:
> On Fri 10-08-18 22:10:53, Theodore Y. Ts'o wrote:
> > On Fri, Aug 10, 2018 at 04:33:49PM -0400, Theodore Y. Ts'o wrote:
> > > I just kicked off a DAX test ("gce-xfstests -c dax -g auto") with
> > > CONFIG_KA
On Mon 27-08-18 16:43:28, Kani, Toshi wrote:
> On Mon, 2018-08-27 at 18:07 +0200, Jan Kara wrote:
> > Hi,
> >
> > I've been analyzing why fstest generic/081 fails when the backing device is
> > capable of DAX. The problem boils down to the failure of:
> &g
On Tue 28-08-18 13:56:30, Mike Snitzer wrote:
> On Tue, Aug 28 2018 at 3:50am -0400,
> Jan Kara wrote:
>
> > On Mon 27-08-18 16:43:28, Kani, Toshi wrote:
> > > On Mon, 2018-08-27 at 18:07 +0200, Jan Kara wrote:
> > > > Hi,
> > > >
> > >
On Thu 30-08-18 15:17:16, Jeff Moyer wrote:
> Jan Kara writes:
>
> > On Tue 28-08-18 13:56:30, Mike Snitzer wrote:
> >> On Tue, Aug 28 2018 at 3:50am -0400,
> >> Jan Kara wrote:
> >>
> >> > On Mon 27-08-18 16:43:28, Kani, Toshi wrote:
> &g
>
> Hmmmm. ISTR that someone has been making a few noises recently about
> virtual block address space mapping interfaces that could help solve
> this problem
:-) Yes, virtual block address space mapping would be a nice solution for
this. But that's a bit larger overhaul, isn't it?
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On Thu 30-08-18 14:49:07, Mike Snitzer wrote:
> On Thu, Aug 30 2018 at 5:30am -0400,
> Jan Kara wrote:
>
> > On Tue 28-08-18 13:56:30, Mike Snitzer wrote:
> > > On Tue, Aug 28 2018 at 3:50am -0400,
> > > Jan Kara wrote:
> > >
> > > > On
On Thu 30-08-18 15:44:57, Mikulas Patocka wrote:
> On Thu, 30 Aug 2018, Mike Snitzer wrote:
>
> > On Thu, Aug 30 2018 at 5:30am -0400,
> > Jan Kara wrote:
> >
> > > On Tue 28-08-18 13:56:30, Mike Snitzer wrote:
> > > > On Tue, Aug 28 2
mm/huge_memory.c:824!
>
> Applying the same change that was applied to vmf_insert_pfn_pmd() in the
> original patch.
>
> Fixes: e1fb4a08649 ("dax: remove VM_MIXEDMAP for fsdax and device dax")
>
> Reported-by: Vishal Verma
> Signed-off-by: Dave
On Fri 07-09-18 21:23:19, Kani, Toshi wrote:
> I noticed that both ext4_da_aops and ext4_dax_aops are used on DAX
> mounted ext4 files. Looking at open() path:
>
> New file
>
> lookup_open
> ext4_create
> __ext4_new_inode
> ext4_set_inode_flags // Set S_DAX flag
>
On Mon 10-09-18 17:18:49, Eric Sandeen wrote:
> On 8/7/18 3:45 AM, Jan Kara wrote:
> > On Fri 27-07-18 10:28:51, Ross Zwisler wrote:
> >> + fsdevel and the xfs list.
> >>
> >> On Wed, Jul 25, 2018 at 4:28 PM Ross Zwisler
> >> wrote:
> >>>
On Tue 11-09-18 17:14:21, Jan Kara wrote:
> On Mon 10-09-18 17:18:49, Eric Sandeen wrote:
> > On 8/7/18 3:45 AM, Jan Kara wrote:
> > >
> > > OK, this is a good catch and the patch looks good. You can add:
> > >
> > > Reviewed-by: Jan Kara
> > &
s in this inode.
> >
> > Instead, always continue looping as long as dax_layout_busy_page() gives us
> > a page which it found with an elevated refcount.
> >
> > Signed-off-by: Ross Zwisler
> > Reviewed-by: Jan Kara
t; >
> >
> > Will do.
> >
>
> Also check if the same problem exists with ext2.
The problem also exists in ext2 so that needs fixing as well.
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
ournal inode.
>
> Fixes: 5f0663bb4a64f588f0a2dd6d1be68d40f9af0086
> Signed-off-by: Toshi Kani
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: "Theodore Ts'o"
> Cc: Andreas Dilger
The journal inode is similar to any other 'system' inode we have in ext4.
We
ops to ext4_da_aops
> > ext4_set_inode_flags // Set S_DAX flag
> >
> > Change ext4_iget() to call ext4_set_inode_flags() before ext4_set_aops().
> >
> > Fixes: 5f0663bb4a64f588f0a2dd6d1be68d40f9af0086
>
> Same format nit:
>
> Fixes: 5f06
On Wed 12-09-18 15:47:12, Kani, Toshi wrote:
> On Wed, 2018-09-12 at 11:24 +0200, Jan Kara wrote:
> > On Tue 11-09-18 09:42:45, Toshi Kani wrote:
> > > Ext4 mount path calls ext4_iget() to obtain the journal inode. This
> > > inode does not support DAX, and 'ex
dax_aops', since S_DAX flag is set after
> ext2_set_aops() in the open path.
>
> Similar to ext4, change ext2_iget() to initialize i_flags before
> ext2_set_aops().
>
> Fixes: fb094c90748f ("ext2, dax: introduce ext2_dax_aops")
> Signed-off-by: Toshi Kani
>
&slot,
> > + entry_wait_revalidate);
> > + if (!entry) {
> > + xa_unlock_irq(&mapping->i_pages);
> > + break;
> > + } else if (IS_ERR(entry)) {
> > + WARN_ON_ONCE(PT
Fixes: c2a7d2a115525d3501d38e23d24875a79a07e15e
Reported-by: Barret Rhoden
Signed-off-by: Jan Kara
---
fs/dax.c | 1 +
1 file changed, 1 insertion(+)
Dan, can you please get this merged? Otherwise dax_lock_mapping_entry()
deadlocks as soon as there's any contention.
diff --git a/fs/dax.c b/fs/dax.c
index b
On Thu 27-09-18 06:28:43, Matthew Wilcox wrote:
> On Thu, Sep 27, 2018 at 01:23:32PM +0200, Jan Kara wrote:
> > When dax_lock_mapping_entry() has to sleep to obtain entry lock, it will
> > fail to unlock mapping->i_pages spinlock and thus immediately deadlock
> > against
open to other suggestions...
Honza
--
Jan Kara
SUSE Labs, CR
>From a3bfac5e1582d9c31e67090b306efedf7c392d36 Mon Sep 17 00:00:00 2001
From: Jan Kara
Date: Tue, 2 Oct 2018 11:58:22 +0200
Subject: [PATCH] proc: Show DAX mappings as having VM
On Tue 02-10-18 12:50:58, Michal Hocko wrote:
> On Tue 02-10-18 12:05:31, Jan Kara wrote:
> > Hello,
> >
> > commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
> > removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in
[Added ext4, xfs, and linux-api folks to CC for the interface discussion]
On Tue 02-10-18 14:10:39, Johannes Thumshirn wrote:
> On Tue, Oct 02, 2018 at 12:05:31PM +0200, Jan Kara wrote:
> > Hello,
> >
> > commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and d
On Tue 02-10-18 07:37:13, Christoph Hellwig wrote:
> On Tue, Oct 02, 2018 at 04:29:59PM +0200, Jan Kara wrote:
> > > OK naive question from me, how do we want an application to be able to
> > > check if it is running on a DAX mapping?
> >
> > The question from
y
modifying mmaped database files if they do small updates... So they really
want to be able to use close to all DRAM for the DB and not leave slack
space for the kernel page cache to cache 1TB of database files.
Honza
--
Jan Kara
SUSE
On Tue 02-10-18 13:18:54, Dan Williams wrote:
> On Tue, Oct 2, 2018 at 8:32 AM Jan Kara wrote:
> >
> > On Tue 02-10-18 07:52:06, Christoph Hellwig wrote:
> > > On Tue, Oct 02, 2018 at 04:44:13PM +0200, Johannes Thumshirn wrote:
> > > > On Tue, Oct 02, 2018 at
On Wed 03-10-18 07:38:50, Dan Williams wrote:
> On Wed, Oct 3, 2018 at 5:51 AM Jan Kara wrote:
> >
> > On Tue 02-10-18 13:18:54, Dan Williams wrote:
> > > On Tue, Oct 2, 2018 at 8:32 AM Jan Kara wrote:
> > > >
> > > > On Tue 02-10-18 07:52:06, C
On Wed 03-10-18 08:13:37, Dan Williams wrote:
> On Wed, Oct 3, 2018 at 8:07 AM Jan Kara wrote:
> > WRT per-inode DAX property, AFAIU that inode flag is just going to be
> > advisory thing - i.e., use DAX if possible. If you mount a filesystem with
> > these inode flags s
On Thu 27-09-18 11:22:22, Dan Williams wrote:
> On Thu, Sep 27, 2018 at 6:41 AM Jan Kara wrote:
> >
> > On Thu 27-09-18 06:28:43, Matthew Wilcox wrote:
> > > On Thu, Sep 27, 2018 at 01:23:32PM +0200, Jan Kara wrote:
> > > > When dax_lock_mapping_entry() has to
On Thu 04-10-18 21:28:14, Dan Williams wrote:
> On Thu, Oct 4, 2018 at 9:01 PM Dan Williams wrote:
> >
> > On Thu, Oct 4, 2018 at 7:52 PM Matthew Wilcox wrote:
> > >
> > > On Thu, Oct 04, 2018 at 06:57:52PM -0700, Dan Williams wrote:
> > > > O
Fix this locally for the filesystem-dax case by
> checking for dax-multi-order entries. Going forward new users of
> multi-order entries need to be similarly careful, or we need a generic
> way to report the page increment in the radix iterator.
>
> Fixes: 5fac7408d828 ("mm, fs, dax
a...@vger.kernel.org
Signed-off-by: Jan Kara
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 4 ++--
arch/x86/include/asm/pgtable_types.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
b/arch/powerpc/include/asm/book3
On Tue 09-10-18 10:55:14, Dan Williams wrote:
> On Tue, Oct 9, 2018 at 3:19 AM Jan Kara wrote:
> >
> > Currently _PAGE_DEVMAP bit is not preserved in mprotect(2) calls. As a
> > result we will see warnings such as:
> >
> > BUG: Bad page map in process Job
Hi Jeff,
On Tue 09-10-18 15:43:41, Jeff Moyer wrote:
> Jan Kara writes:
> > commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
> > removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the
> > mean time certain customer of
they can't provide MAP_DIRECT in all cases." And that
> doesn't seem like a very good solution to me.
These are good points. I'm just somewhat wary of the situation where users
will map files with MAP_DIRECT and then the machine s
> int madvice(void *addr, size_t length, int *advice);
After some thought, I'm not 100% sure this is really needed. I know about
apps that want to make sure DRAM is not consumed - for those mmap / madvise
flag is fine if it returns error in case the feature cannot be provided.
Most
It creates unneeded negative feelings to those who wanted to be in
> > > > this list, but for any reason they don't. Those reviewers will feel
> > > > "untrusted".
> > >
> > > Yeah, perhaps something like "most active reviewers" would sound
> > > better.
> >
> > I would recommend to remove this section at all.
> > New maintainers won't come out of blue, but will be come
> > from existing community and such individuals for sure will see
> > and judge by themselves to whom they trust and to whom not.
>
> I see your point, but, on the other hand, having a list with the ones
> that are actively doing reviews helps newcomers.
How exactly? Do you expect people to CC patches to these directly? And if
yes, why is not picking patches from the mailing list good enough?
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
wait_unlocked_entry(&xas, entry);
> rcu_read_lock();
> continue;
The continue here actually is not safe either because if the mapping got
freed, page->mapping will be NULL and we oops at the beginning of the loop.
So that !dax_mapp
acquire the lock or dereference the address_space in any way.
>
> Fixes: c2a7d2a11552 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Matthew Wilcox
The patch looks good. You can add:
Reviewed-by: Jan Kara
Just one
ot;filesystem-dax: Introduce dax_lock_mapping_entry()")
> Cc: sta...@vger.kernel.org
> Reported-by: Jan Kara
> Signed-off-by: Matthew Wilcox
Thanks for writing this fix. The patch looks good. You can add:
Reviewed-by: Jan Kara
de0
> ext4_dax_huge_fault+0x16f/0x1f0
> ? up_read+0x1c/0xa0
> __do_fault+0x1f/0x160
> __handle_mm_fault+0x1033/0x1490
> handle_mm_fault+0x18b/0x3d0
>
> Link: https://lkml.kernel.org/r/20181130154902.gl10...@bombadil.infradead.org
> Fixes: 9f32d221301c ("dax: Co
not guaranteed. So, I
> believe the intent, Willy correct me if I am wrong, was to keep all
> waits "exclusive" for some sense of symmetry, but this one can and
> should be a non-exclusive wait.
Agreed. I didn't realize this when reviewing Matthew's patch and
misunderstood his comment to this end.
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
extra wakeup, just switch to a non-exclusive wait.
>
> Cc: Jan Kara
> Cc: Matthew Wilcox
> Reported-by: Linus Torvalds
> Signed-off-by: Dan Williams
> ---
> fs/dax.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
Thanks for cleaning this up!
re rather be some generic way of doing this? Having
virtio_pmem_host_cache_enabled() check in filesystem code just looks like
filesystem sniffing into details is should not care about... Maybe just
naming this (or having a wrapper) dax_dev_map_sync_supported()?
; resources like the page cache.
Right. Thinking about this I would be more concerned about the fact that
guest can effectively pin amount of host's page cache upto size of the
device/file passed to guest as PMEM, can't it Pankaj? Or is there some Q
mem is going to work. Thanks for
explanation! So can I imagine this as guest mmaping the host file and
providing the mapped range as "NVDIMM pages" to the kernel inside the
guest? Or is it more complex?
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
s.
>
> The linux-nvdimm mailing hosts a patchwork instance for both DAX and
> NVDIMM patches.
>
> Cc: Jan Kara
> Cc: Ira Weiny
> Cc: Ross Zwisler
> Cc: Keith Busch
> Cc: Matthew Wilcox
> Signed-off-by: Dan Williams
Acked-by: Jan Kara
v_pagemap, Xarray entries, and sector-to-pfn
> translation established for pmem namespaces.
>
> Cc: Jan Kara
> Cc: "Darrick J. Wong"
> Signed-off-by: Dan Williams
> ---
> drivers/dax/super.c | 39 +--
> 1 file changed,
but does nothing with it). So I think
we are reasonably free in defining the semantics. Also I think this is
closely related to Dan's topic "What should be done to remove experimental
tag from DAX" (or however it was called).
dax_wake_entry(xas, entry, false);
>
> - trace_dax_writeback_one(mapping->host, xas->xa_index,
> - size >> PAGE_SHIFT);
> + trace_dax_writeback_one(mapping->host, xas->xa_index, count);
> return ret;
>
> put_unlocked:
> --
> 2.20.1
>
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
ize >> PAGE_SHIFT);
> + trace_dax_writeback_one(mapping->host, xas->xa_index, count);
I think here should be 'index' as well, shouldn't it? Otherwise the tracing
data will be somewhat misleading... Besides this the patch looks good to me
now so feel free to add:
R
mem_copy_from_iter+0x2c/0x50 [nd_pmem]
> > dax_copy_from_iter+0x40/0x70
> > dax_iomap_actor+0x134/0x360
> > iomap_apply+0xfc/0x1b0
> > dax_iomap_rw+0xac/0x130
> > ext4_file_write_iter+0x254/0x460 [ext4]
> > __vfs_write+0x120/0x1e0
> > vfs_write+0xd8/0x220
&
CC: sta...@vger.kernel.org
> Signed-off-by: Aneesh Kumar K.V
Thanks for fixing this! The patch looks good to me. Feel free to add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/huge_memory.c | 31 ++
ithout this patch we also see the below message in kernel log
> "BUG: non-zero pgtables_bytes on freeing mm:"
>
> CC: sta...@vger.kernel.org
> Reported-by: Chandan Rajendra
> Signed-off-by: Aneesh Kumar K.V
Looks good to me. You can add:
Reviewed-by: Jan Kara
On Wed 03-04-19 16:10:17, Pankaj Gupta wrote:
> Virtio pmem provides asynchronous host page cache flush
> mechanism. We don't support 'MAP_SYNC' with virtio pmem
> and ext4.
>
> Signed-off-by: Pankaj Gupta
The patch looks good to me. You c
(filp, dax_dev);
> + if (err)
> + return err;
> + }
>
> file_accessed(filp);
> vma->vm_ops = &xfs_file_vm_ops;
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8b42df09b04c..add017de3dd7 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2162,6 +2162,20 @@ static inline void file_accessed(struct file *file)
> touch_atime(&file->f_path);
> }
>
> +struct dax_device;
> +extern bool dax_synchronous(struct dax_device *dax_dev);
> +static inline int is_synchronous(struct file *filp, struct dax_device
> *dax_dev)
> +{
> + struct inode *inode = file_inode(filp);
> +
> + if (!IS_DAX(inode))
> + return -EOPNOTSUPP;
> + if (!dax_synchronous(dax_dev))
> + return -EOPNOTSUPP;
> +
> + return 0;
> +}
> +
> int sync_inode(struct inode *inode, struct writeback_control *wbc);
> int sync_inode_metadata(struct inode *inode, int wait);
>
> -
>
> Thanks,
> Pankaj
>
>
>
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
onous and
> does not not support VM_SYNC.
>
> Suggested-by: Jan Kara
> Signed-off-by: Pankaj Gupta
> ---
> include/linux/dax.h | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index b896706
Is there a need to define dax_synchronous() for !CONFIG_DAX? Because that
property of dax device is pretty much undefined and I don't see anything
needing to call it for !CONFIG_DAX...
H
== NULL mean generic_nvdimm_flush(). Just so that people don't
get confused by the code.
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
onous and
> does not not support VM_SYNC.
>
> Suggested-by: Jan Kara
> Signed-off-by: Pankaj Gupta
The patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> include/linux/dax.h | 17
xt4.
>
> Signed-off-by: Pankaj Gupta
The patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/ext4/file.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
in dax_insert_pfn_mkwrite() -- does
> > that need to change too?
>
> It wasn't clear to me that it was a problem. I think that one already
> happens to be pmd-aligned.
Why would it need to be? The address is taken from vmf->address and that's
set up in _
y sailed for option 2) to be
feasible without angry users and Linus reverting the change.
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
oing to be somewhat interesting. On the other hand clever
udev rule that detects partition table on pmem device and uses kpartx to
partition these devices (like what happens e.g. for dm-multipath devices)
could possibly be used as a replacement for kernel support so there's a way
out of this...
ompat_test() only if the kernel has
the required functionality.
Signed-off-by: Jan Kara
---
tools/testing/nvdimm/test/nfit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/nvdimm/test/nfit.c b/tools/testing/nvdimm/test/nfit.c
index bf6422a6af7f..a8ee5c4d41eb 100644
--- a/too
doesn't pass that flag through to iomap_apply.
>
> With this patch applied, generic/471 passes for me.
>
> Signed-off-by: Jeff Moyer
The patch looks good to me. You can add:
Reviewed-by: Jan Kara
BTW, I've just noticed ext4 seems to be buggy in this regard and even this
patch
On Thu 06-02-20 09:33:39, Jeff Moyer wrote:
> Jan Kara writes:
>
> > On Wed 05-02-20 14:15:58, Jeff Moyer wrote:
> >> fstests generic/471 reports a failure when run with MOUNT_OPTIONS="-o
> >> dax". The reason is that the initial pwrite to an empty fil
On Thu 23-01-20 16:47:20, Jan Kara wrote:
> When a kernel is configured without CONFIG_DEV_DAX_PMEM_COMPAT, the
> compilation of tools/testing/nvdimm fails with:
>
> Building modules, stage 2.
> MODPOST 11 modules
> ERROR: "dax_pmem_compat_test" [tools/test
On Wed 12-02-20 12:49:41, Dan Williams wrote:
> On Wed, Feb 12, 2020 at 6:04 AM Jeff Moyer wrote:
> >
> > Jan Kara writes:
> >
> > > When a kernel is configured without CONFIG_DEV_DAX_PMEM_COMPAT, the
> > > compilation of tools/testing/nvdimm fails with:
On Fri 14-02-20 08:13:59, Dan Williams wrote:
> On Fri, Feb 14, 2020 at 1:42 AM Jan Kara wrote:
> > > > But, I understand if you want to prevent build bots from hitting
> > > > compilation failures due to this.
> > >
> > > Hmm
http://lore.kernel.org/r/20200123154720.12097-1-j...@suse.cz
> Cc: Jan Kara
> Signed-off-by: Dan Williams
The patch looks good to me. Thanks for fixing this! I just have to say that
the strstr(3) usage in this function looks rather unusu
http://lore.kernel.org/r/20200123154720.12097-1-j...@suse.cz
> Cc: Jan Kara
> Signed-off-by: Dan Williams
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> test/core.c |8
> 1 file changed, 8 inser
On Tue 03-03-20 14:58:30, Dan Williams wrote:
> Update nfit_test_init() to use strcmp() instead of strstr() to filter
> which modules are probed to come from the out-of-tree unit-test set.
>
> Reported-by: Jan Kara
> Link: http://lore.kernel.org/r/20200303132850.ga21...@quack2.s
tion? I'd rather
expect something like __releases(xas->xa->xa_lock) here...
Honza
> {
> struct wait_exceptional_entry_queue ewait;
> wait_queue_head_t *wq;
> --
> 2.24.1
>
--
Jan Kara
SU
s(xas->xa->xa_lock) annotation
>
> Signed-off-by: Jules Irenge
The patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/dax.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --g
t; > > +unsigned long default_map_sync_mask = 0;
> > > +#endif
> > > +
I'm not sure CONFIG is really the right approach here. For a distro that would
basically mean to disable MAP_SYNC for all PPC kernels unless application
explicitly uses the right prctl. Shouldn't we ra
On Sat 30-05-20 09:35:19, Dan Williams wrote:
> On Sat, May 30, 2020 at 12:18 AM Aneesh Kumar K.V
> wrote:
> >
> > On 5/30/20 12:52 AM, Dan Williams wrote:
> > > On Fri, May 29, 2020 at 3:55 AM Aneesh Kumar K.V
> > > wrote:
> > >>
>
On Fri 29-05-20 16:25:35, Aneesh Kumar K.V wrote:
> On 5/29/20 3:22 PM, Jan Kara wrote:
> > On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
> > > Thanks Michal. I also missed Jeff in this email thread.
> >
> > And I think you'll also need some of the sched
On Mon 01-06-20 17:31:50, Aneesh Kumar K.V wrote:
> On 6/1/20 3:39 PM, Jan Kara wrote:
> > On Fri 29-05-20 16:25:35, Aneesh Kumar K.V wrote:
> > > On 5/29/20 3:22 PM, Jan Kara wrote:
> > > > On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
> > > > > Th
On Tue 02-06-20 17:59:08, Williams, Dan J wrote:
> [ forgive formatting, a series of unfortunate events has me using Outlook for
> the moment ]
>
> > From: Jan Kara
> > > > > These flags are device properties that affect the kernel and
> > >
esg output,
> [ 2705.500885] pmem0: error: unsupported blocksize for dax
> [ 2705.500888] EXT4-fs (pmem0): DAX unsupported by block device.
> Now the users may have idea the mount failure is from pmem driver for
> unsupported block size.
>
> Reported-by: Michal Suchanek
>
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
or other
> + * get_user_pages() usages.
> + *
> + * It is expected that the filesystem is holding locks to block the
> + * establishment of new mappings in this address_space. I.e. it expects
> + * to be able to run unmap_mapping_range() and subsequently not race
> + * mapping_mapp
ned-off-by: Stefan Hajnoczi
> Signed-off-by: Vivek Goyal
> Cc: Christoph Hellwig
> Cc: Dan Williams
> Cc: linux-nvdimm@lists.01.org
This patch looks OK to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
>
e of pages do not have any
> references (and don't want to unmap all the pages of inode).
>
> Hence, create a range version of this function named
> dax_layout_busy_page_range() which can be used to pass a range which
> needs to be unmapped.
>
> Cc: Dan Williams
>
or this and have Jan do one for
> ext2, I just applied these two directly as "ObviouslyCorrect(tm)".
OK, thanks!
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mail
ext2_dax_fault(struct
> ret = dax_iomap_fault(vmf, PE_SIZE_PTE, NULL, NULL, &ext2_iomap_ops);
>
> up_read(&ei->dax_sem);
> - if (vmf->flags & FAULT_FLAG_WRITE)
> + if (write)
> sb_end_pagefault(inode->i_sb);
> return ret;
> }
>
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
1 - 100 of 780 matches
Mail list logo
