waiters when a dax entry
> has been invalidated. This seems to fix the deadlock I am facing
> and I can make forward progress.
>
> Reported-by: Sergio Lopez
> Fixes: ac401cc78242 ("dax: New fault locking")
> Suggested-by: Dan Williams
> Signed-off-by: Vivek Goyal
gt; Suggested-by: Dan Williams
> Signed-off-by: Vivek Goyal
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/dax.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> d
E_ALL: wake all waiters in the waitqueue
Otherwise the patch looks good so feel free to add:
Reviewed-by: Jan Kara
Honza
> + */
> +enum dax_entry_wake_mode {
> + WAKE_NEXT,
> + WAKE_ALL,
> +};
> +
> st
t; > {
> > > - /* If we were the only waiter woken, wake the next one */
> > > - if (entry && !dax_is_conflict(entry))
> > > - dax_wake_entry(xas, entry, false);
> > > + if (dax_is_conflict(entry)
ap_util.c | 6 +-
> fs/xfs/xfs_file.c | 30 ++-
> fs/xfs/xfs_inode.c | 8 +-
> fs/xfs/xfs_inode.h | 1 +
> fs/xfs/xfs_iomap.c | 3 +-
> fs/xfs/xfs_iops.c | 11 ++-
> fs/xfs/xfs_reflink.c | 23 -
> include/linux/dax.h | 5 ++
>
ate solution for this read problem. And
I'm also against duplicating ->read_iter functionatily in ->read handler.
The maintenance burden of this code duplication is IMHO just too big. We
rather need to improve the generic code so that the fast path i
t gendisk *disk, bool
> verbose);
> bool bdev_check_media_change(struct block_device *bdev);
> int __invalidate_device(struct block_device *bdev, bool kill_dirty);
> void bd_set_nr_sectors(struct block_device *bdev, sector_t sectors);
> +int bd_corrupted_range(struct block_device *bdev, loff_t disk_off,
> +loff_t bdev_off, size_t len, void *data);
>
> /* for drivers/char/raw.c: */
> int blkdev_ioctl(struct block_device *, fmode_t, unsigned, unsigned long);
> --
> 2.29.2
>
>
>
--
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
largest mapping to avoid breaking up
> - * device-dax mappings which are constant size. The
> - * actual size of the mapping being torn down is
> - * communicated in siginfo, see kill_proc()
> - */
> - start = (page->index <&
d *to_kill,
>* to be informed of all such data corruptions.
>*/
> if (vma->vm_mm == t->mm)
> - add_to_kill(t, page, vma, to_kill);
> + add_to_kill(t, pa
t; reporting")
> Signed-off-by: Jason Gunthorpe
Nice cleanup. The patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/gup.c | 103 +--
>
r internal xarray usage so DAX could use only higher bits. For
classical value entries, only the lowest bit is reserved for xarray usage,
all the rest is available for the user (and so DAX uses it).
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
mapping, vmf, *entry, pfn,
> -DAX_PMD | DAX_ZERO_PAGE, false);
> +XA_ZERO_PMD_ENTRY, false);
>
> if (arch_needs_pgtable_deposit()) {
> pgtable = pte_alloc_one(vma->vm_mm);
> --
> 2.29.2
--
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
> Reviewed-by: Christoph Hellwig
> Acked-by: Darrick J. Wong
> Acked-by: Theodore Ts'o # for fs/ext4/inode.c
The patch looks good to me. Feel free to add:
Reviewed-by: Jan Kara
Honza
> ---
>
> Changes in
> \
> + ___wait_var_event(&(_page)->_refcount, \
> + dax_layout_is_idle_page(_page), \
> + TASK_INTERRUPTIBLE, 0, 0, _wait_cb(_inode))
> +
> #ifdef CONFIG_DEV_DAX_HMEM_DEVICES
> void hmem_register_device(int target_nid, struct resource *r);
> #else
> --
> 2.20.1
>
--
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
d yes, it does
significantly improve performance for some workloads but you have to have
some way to recover from crashes so it's mostly used for scratch
filesystems (e.g. in build systems, Google uses this feature a lot for some
of their infrastructure as well).
On Mon 21-09-20 11:23:07, Naresh Kamboju wrote:
> On Fri, 18 Sep 2020 at 11:18, Dan Williams wrote:
> >
> > From: Jan Kara
> >
> > DM was calling generic_fsdax_supported() to determine whether a device
> > referenced in the DM table supports DAX. However this i
uper.c:451:1: note: declare 'static' if the function is not
> intended to be used outside of this translation unit
>void run_dax(struct dax_device *dax_dev)
>^
>static
>1 warning and 1 error generated.
Attached patch should fix the build error.
all my local builds are breaking now too with this :(
>
> Was there a proposed patch anywhere for this?
Attached patch should fix the build breakage. I'm sorry for that.
Honza
--
Jan Kara
SUSE Labs, CR
>From 8b8c7d
On Thu 17-09-20 02:28:57, Dan Williams wrote:
> On Wed, Sep 16, 2020 at 8:15 AM Jan Kara wrote:
> >
> > DM was calling generic_fsdax_supported() to determine whether a device
> > referenced in the DM table supports DAX. However this is a helper for
> > "leaf&
On Wed 16-09-20 11:22:05, Mike Snitzer wrote:
> On Wed, Sep 16 2020 at 11:14am -0400,
> Jan Kara wrote:
>
> > DM was calling generic_fsdax_supported() to determine whether a device
> > referenced in the DM table supports DAX. However this is a helper for
> > &q
ported check to span multiple
devices")
Tested-by: Adrian Huang
Signed-off-by: Jan Kara
---
drivers/dax/super.c | 4
drivers/md/dm-table.c | 3 +--
include/linux/dax.h | 11 +--
3 files changed, 14 insertions(+), 4 deletions(-)
This patch should go in together with Adrian&
On Wed 16-09-20 14:02:19, Adrian Huang12 wrote:
> > -Original Message-
> > From: Jan Kara
> > Sent: Wednesday, September 16, 2020 7:19 PM
> > >
> > > dm-3: error: dax access failed (-95)
> > > dm-3: error: dax access failed (-95)
> > &g
KNSCGG3QJFO7HT/
> [4]
> https://lists.01.org/hyperkitty/list/linux-nvdimm@lists.01.org/message/7E2X6UGX5RQ2ISGYNAF66VLY5BKBFI4M/
>
> Fixes: 6180bb446ab6 ("dax: fix detection of dax support for non-persistent
> memory block devices")
> Cc: Coly Li
> Cc: Jan Kara
> Cc: Ira Weiny
> Cc: Joh
On Tue 15-09-20 12:49:10, Dan Williams wrote:
> On Tue, Sep 15, 2020 at 1:01 AM Jan Kara wrote:
> >
> > Hi!
> >
> > On Tue 15-09-20 11:03:29, col...@suse.de wrote:
> > > Could you please to take a look? I am offline in the next two weeks.
> >
On Wed 16-09-20 07:02:12, Adrian Huang12 wrote:
> > -Original Message-
> > From: Jan Kara
> >
> > I'm not sure how you can get __generic_fsdax_supported() called for dm-0?
> > Possibly because there's another dm device stacked on top of
On Tue 15-09-20 15:12:21, Verma, Vishal L wrote:
> On Tue, 2020-09-15 at 10:01 +0200, Jan Kara wrote:
> > Hi!
> >
> > On Tue 15-09-20 11:03:29, col...@suse.de wrote:
> > > Could you please to take a look? I am offline in the next two weeks.
> >
>
ical disk)
> + * that does not support DAX (dax_dev = NULL). This case
> + * is observed when physical disks are configured by
> + * lvm2 (device mapper).
> + */
> + if (len != -EOPNOTSUPP && len2 != -EOPNOTSUPP) {
> +
4日周一半夜11:48
> 收件人： Coly Li , Dan Williams ,
> Dave Jiang
> 抄送： Jan Kara , Vishal Verma ,
> Adrian Huang , Ira Weiny , Mike
> Snitzer , Pankaj Gupta ,
> linux-nvdimm@lists.01.org
> 主题： regression caused by patch 6180bb446ab624b9ab8bf201ed251ca87f07b413
> ("dax: fix d
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
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
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
>
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
> ---
>
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
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
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
>
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
> > >
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 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 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:
> > >>
>
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
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
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
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
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
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
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
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 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 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
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
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
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...
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
periments.
> Since then, Jérôme Glisse suggested the refactoring described above.
>
> Cc: Jan Kara
> Cc: Jérôme Glisse
> Cc: Christoph Hellwig
> Cc: Dan Williams
> Suggested-by: Jérôme Glisse
> Signed-off-by
em issue w.r.t ARM architecture ?
I've CCed Dan, he might have idea what that comment means :)
Out of curiosity, why do you care?
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm maili
fallback to lookup the correct order.
>
> Reported-by: Jeff Smits
> Reported-by: Doug Nelson
> Cc:
> Fixes: 23c84eb78375 ("dax: Fix missed wakeup with PMD faults")
> Cc: Jan Kara
> Cc: Matthew Wilcox (Oracle)
> Signed-off-by: Dan Williams
Good catch! The pat
g to make it
> useless for anything else.
I agree we should not tailor the layout lease definition to just RDMA
usecase. But let's talk about the semantics once our confusion about how
pNFS currently uses layout leases is clear out.
ur /proc// files you had in your
patches should do that, shouldn't they? Maybe they were not tied to the
right structure... They really need to be tied to the existence of a lease.
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
gt; >
> > >
> > > I'd definitely not multiplex this over F_SETLEASE. An F_SETLAYOUT cmd
> > > would probably be sufficient, and maybe just reuse
> > > F_RDLCK/F_WRLCK/F_UNLCK for the iomode?
> > >
> > > For the byte ranges, the catch there is that extending the userland
> > > interface for that later will be difficult.
> >
> > Why would it be difficult?
> >
>
> Legacy userland code that wanted to use byte range enabled layouts would
> have to be rebuilt to take advantage of them. If we require a range from
> the get-go, then they will get the benefit of them once they're
> available.
I don't think this is true. Because current implementation of locking the
whole file may hide implementation bugs in userspace. So the new
range lock handling may break userspace and history shows such
problems with APIs are actually rather common. So I think switching to
range locking *must* be conscious decision of the application and as
such having separate API for that is the most natural thing to do.
> > > What I'd probably suggest
> > > (and what would jive with the way pNFS works) would be to go ahead and
> > > add an offset and length to the arguments and result (maybe also
> > > whence?).
> >
> > Why not add new commands with range arguments later if it turns out to
> > be necessary?
>
> We could do that. It'd be a little ugly, IMO, simply because then we'd
> end up with two interfaces that do almost the exact same thing.
>
> Should byte-range layouts at that point conflict with non-byte range
> layouts, or should they be in different "spaces" (a'la POSIX and flock
> locks)? When it's all one interface, those sorts of questions sort of
> answer themselves. When they aren't we'll have to document them clearly
> and I think the result will be more confusing for userland programmers.
>
> If you felt strongly about leaving those out for now, you could just do
> something similar to what Aleksa is planning for openat2 -- have a
> struct pointer and length as arguments for this cmd, and only have a
> single iomode member in there for now.
>
> The kernel would have to know how to deal with "legacy" and byte-range-
> enabled variants if we ever extend it, but that's not too hard to
> handle.
Yeah, so we can discuss how to make possible future extension towards
range locking the least confusing to userspace. E.g. we can just put the
ranges in the API and require that start is always 0 and end is always
ULONG_MAX or whatever. But switching to smaller ranges must be the decision
in the application after the kernel supports it.
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
vice. So there is no need to take reference and drop reference to
> dax_device on each call of this function.
>
> Suggested-by: Christoph Hellwig
> Signed-off-by: Vivek Goyal
Looks good to me. You can add:
Reviewed-by: Jan Kara
On Fri 16-08-19 16:20:07, Ira Weiny wrote:
> On Fri, Aug 16, 2019 at 12:05:28PM -0700, 'Ira Weiny' wrote:
> > On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote:
> > > On Wed 14-08-19 11:08:49, Ira Weiny wrote:
> > > > On Wed, Aug 14, 2019 at 12:17:14P
On Sat 17-08-19 12:26:03, Dave Chinner wrote:
> On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira Weiny wrote:
> > On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote:
> > > On Wed 14-08-19 11:08:49, Ira Weiny wrote:
> > > > On Wed, Aug 14, 2019 at 12:17:14PM +0200,
On Wed 14-08-19 11:08:49, Ira Weiny wrote:
> On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote:
> > Hello!
> >
> > On Fri 09-08-19 15:58:14, ira.we...@intel.com wrote:
> > > Pre-requisites
> > > ==
> > > Based on mmotm tree.
&g
ed "owning file" variant in your patch set, then
I'd just implement that and leave "owning mm" variant for later if it
proves to be necessary. The things are complex enough as is...
> 9) Truncation of pages which are not actively pinned nor covered by a lease
>
On Tue 16-07-19 20:39:46, Dan Williams wrote:
> On Fri, Jul 12, 2019 at 2:14 AM Jan Kara wrote:
> >
> > On Thu 11-07-19 08:25:50, Matthew Wilcox wrote:
> > > On Thu, Jul 11, 2019 at 07:13:50AM -0700, Matthew Wilcox wrote:
> > > > However, the XA_RETRY_ENTRY
e only waiter woken, wake the next one */
> - if (entry)
> + if (entry && dax_is_conflict(entry))
This should be !dax_is_conflict(entry)...
> dax_wake_entry(xas, entry, false);
> }
Otherwise the patch l
On Wed 10-07-19 13:15:39, Matthew Wilcox wrote:
> On Wed, Jul 10, 2019 at 09:02:04PM +0200, Jan Kara wrote:
> > +#define DAX_ENTRY_CONFLICT dax_make_entry(pfn_to_pfn_t(1), DAX_EMPTY)
>
> I was hoping to get rid of DAX_EMPTY ... it's almost unused now. Once
> we switch to h
On Wed 10-07-19 20:35:55, Matthew Wilcox wrote:
> On Wed, Jul 10, 2019 at 09:02:04PM +0200, Jan Kara wrote:
> > So how about the attached patch? That keeps the interface sane and passes a
> > smoketest for me (full fstest run running). Obviously it also needs a
>
On Wed 10-07-19 20:08:55, Matthew Wilcox wrote:
> On Wed, Jul 10, 2019 at 09:02:04PM +0200, Jan Kara wrote:
> > @@ -848,7 +853,7 @@ static int dax_writeback_one(struct xa_state *xas,
> > struct dax_device *dax_dev,
> > if (unlikely(dax_is_locked(entry))) {
> >
; > > > On Thu, Jul 04, 2019 at 06:54:50PM +0200, Jan Kara wrote:
> > > > > On Wed 03-07-19 20:27:28, Matthew Wilcox wrote:
> > > > > > So I think we're good for all current users.
> > > > >
> > > > > Agreed but it i
ble and
still keep the interfaces sane. For example get_unlocked_entry() could
return special "error code" indicating that there's no entry with matching
order in xarray but there's a conflict with it. That would be much less
error-prone interface.
On Wed 03-07-19 08:47:00, Matthew Wilcox wrote:
> On Mon, Jul 01, 2019 at 02:11:19PM +0200, Jan Kara wrote:
> > BTW, looking into the xarray code, I think I found another difference
> > between the old radix tree code and the new xarray code that could cause
> > issues. In th
se
issues. In the old radix tree code if we tried to insert PMD entry but
there was some PTE entry in the covered range, we'd get EEXIST error back
and the DAX fault code relies on this. I don't see how similar behavior is
achieved by xas_store()...
On Mon 24-06-19 09:25:00, Miklos Szeredi wrote:
> [cc: vivek, stefan, dgilbert]
>
> On Fri, Jun 21, 2019 at 12:04 AM Liu Bo wrote:
> >
> > On Thu, Jun 20, 2019 at 1:36 AM Jan Kara wrote:
> > >
> > > [added some relevant lists to CC - this can safe some
for doing something stupid and unsupportable...
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
b0
> [ 129.121018] path_openat+0x15f/0x1380
> [ 129.121614] ? generic_update_time+0x6b/0xd0
> [ 129.122316] do_filp_open+0x91/0x100
> [ 129.122876] do_sys_open+0x126/0x210
> [ 129.123453] do_syscall_64+0x55/0x180
> [ 129.124036] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 129.12482
On Wed 12-06-19 15:13:36, Ira Weiny wrote:
> On Wed, Jun 12, 2019 at 04:14:21PM -0300, Jason Gunthorpe wrote:
> > On Wed, Jun 12, 2019 at 02:09:07PM +0200, Jan Kara wrote:
> > > On Wed 12-06-19 08:47:21, Jason Gunthorpe wrote:
> > > > On Wed, Jun 12, 2019 at 12
On Wed 12-06-19 11:49:52, Dan Williams wrote:
> On Wed, Jun 12, 2019 at 3:29 AM Jan Kara wrote:
> >
> > On Fri 07-06-19 07:52:13, Ira Weiny wrote:
> > > On Fri, Jun 07, 2019 at 09:17:29AM -0300, Jason Gunthorpe wrote:
> > > > On Fri, Jun 07, 2019
On Wed 12-06-19 11:41:53, Dan Williams wrote:
> On Wed, Jun 12, 2019 at 5:09 AM Jan Kara wrote:
> >
> > On Wed 12-06-19 08:47:21, Jason Gunthorpe wrote:
> > > On Wed, Jun 12, 2019 at 12:29:17PM +0200, Jan Kara wrote:
> > >
> > > > > > The main
On Wed 12-06-19 08:47:21, Jason Gunthorpe wrote:
> On Wed, Jun 12, 2019 at 12:29:17PM +0200, Jan Kara wrote:
>
> > > > The main objection to the current ODP & DAX solution is that very
> > > > little HW can actually implement it, having the alternative still
On Fri 07-06-19 07:52:13, Ira Weiny wrote:
> On Fri, Jun 07, 2019 at 09:17:29AM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 07, 2019 at 12:36:36PM +0200, Jan Kara wrote:
> >
> > > Because the pins would be invisible to sysadmin from that point on.
> >
> > I
s
> because the NFS lease is non-exclusive where the user space one (for the
> purpose of GUP pinning) would need to be.
>
> FWIW I have not worked out exactly what this new "exclusive" code will look
> like. Jan said:
>
>
hat's a good thing as upgrading kernels is
going to be nightmare due to this on PPC64. So I believe we should make
defaults for old superblocks such that working setups keep working without
sysadmin having to touch anything.
Honza
--
J
On Thu 06-06-19 15:03:30, Ira Weiny wrote:
> On Thu, Jun 06, 2019 at 12:42:03PM +0200, Jan Kara wrote:
> > On Wed 05-06-19 18:45:33, ira.we...@intel.com wrote:
> > > From: Ira Weiny
> >
> > So I'd like to actually mandate that you *must* hold the file lease u
On Thu 06-06-19 15:22:28, Ira Weiny wrote:
> On Thu, Jun 06, 2019 at 04:51:15PM -0300, Jason Gunthorpe wrote:
> > On Thu, Jun 06, 2019 at 12:42:03PM +0200, Jan Kara wrote:
> >
> > > So I'd like to actually mandate that you *must* hold the file lease until
> >
On Thu 06-06-19 10:00:01, Dan Williams wrote:
> On Thu, Jun 6, 2019 at 2:10 AM Jan Kara wrote:
> >
> > When inserting entry into xarray, we store mapping and index in
> > corresponding struct pages for memory error handling. When it happened
> > that one proc
with
pins (breaking such lease would return error and not break it) and if
breaking leases succeeds (i.e., there are no long-term pinned pages), we'd
just wait for the remaining references as we do now.
Honza
--
Jan Kara
SUSE
.c| 6 +-
> fs/ext4/inode.c | 26 +--
> fs/locks.c | 97 ---
> fs/xfs/xfs_file.c| 24 --
> fs/xfs/xfs_inode.h | 5 +-
> fs/xfs/xfs_ioctl.c | 15 +++-
>
empty entries is just
no-op so there's no reason to complicate the code with trying to avoid
the calls for these cases).
Signed-off-by: Jan Kara
---
fs/dax.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index f74386293632..9fd908f3df32 1
On Thu 30-05-19 08:14:45, Dave Chinner wrote:
> On Wed, May 29, 2019 at 03:46:29PM +0200, Jan Kara wrote:
> > On Wed 29-05-19 14:46:58, Dave Chinner wrote:
> > > iomap_apply()
> > >
> > > ->iomap_begin()
> > > map old data extent that
58AM +0800, Shiyang Ruan wrote:
> > > > > On 5/28/19 5:17 PM, Jan Kara wrote:
> > > > > > I'm sorry but I don't follow what you suggest. One COW operation is
> > > > > > a call
> > > > > > to dax_iomap_rw(), isn't it?
t may call iomap_apply() several times,
each invocation calls ->iomap_begin(), ->actor() (dax_iomap_actor()),
->iomap_end() once. So I don't see a difference between doing something in
->actor() and ->iomap_end() (besides the passed arguments but that does not
seem to be your co
On Thu 23-05-19 10:27:22, Goldwyn Rodrigues wrote:
> On 16:04 23/05, Jan Kara wrote:
> > On Mon 29-04-19 12:26:47, Goldwyn Rodrigues wrote:
> > > From: Goldwyn Rodrigues
> > >
> > > Inorder to make sure mmap'd files don't change after snapshot,
>
apping_range(mapping,
> fs_info->fs_devices->latest_bdev,
> wbc);
> }
> @@ -9981,6 +9990,8 @@ static void btrfs_run_delalloc_work(struct btrfs_work
> *work)
> delalloc_work = container_of(work, struct btrfs_delalloc_work,
>
IG_FS_DAX
> + .mmap_supported_flags = MAP_SYNC,
> +#endif
> .open = btrfs_file_open,
> .release= btrfs_release_file,
> .fsync = btrfs_sync_file,
> --
> 2.16.4
>
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
+ (xas->xa_index & PG_PMD_COLOUR) ==
dax_to_pfn(new_entry))) {
/* New entry is a subset of the current one? Skip update... */
xas_load(xas);
} else {
do work...
}
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
t; because the actor returns vm_fault_t, not bytes copied. I guess that
> makes it a tiny bit more complicated to pass in two (struct iomap *) to
> the iomap_begin function...
Hum, right. We could actually reimplement dax_iomap_{pte|pmd}_fault() using
iomap_apply(). We would just need to propagate error code out of our
'actor' inside the structure pointed to by 'data'. But that's doable.
Honza
--
Jan Kara
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
in the changelog. And the above paragraph helped me
clarify which checks in dax_iomap_actor() you think replace those usercopy
checks. So I think it would be good to add that paragraph to those
copy_from_pmem() functions as a comment just in case we are wondering in
the future why we are
r asked for with
CONFIG_HARDENED_USERCOPY... Kees?
Honza
>
> Bypass this overhead and call the 'no check' versions of the
> copy_{to,from}_iter operations directly.
>
> Fixes: 0aed55af8834 ("x86, uaccess: in
d route upper-level bdev_dax_supported() requests.
>
> Fixes: ad428cdb525a ("dax: Check the end of the block-device...")
> Cc:
> Cc: Jan Kara
> Cc: Ira Weiny
> Cc: Dave Jiang
> Cc: Mike Snitzer
> Cc: Keith Busch
> Cc: Matthew Wilcox
> Cc: Visha
1 - 100 of 780 matches
Mail list logo
