On Wed, Dec 02, 2020 at 12:23:25AM -0500, Pavel Tatashin wrote:
> There is no need to check_dax_vmas() and run through the npage loop of
> pinned pages if FS_DAX is not enabled.
>
> Add a stub check_dax_vmas() function for no-FS_DAX case.
This looks like a good idea.
>
> Signed-off-by: Pavel Ta
On Wed, Dec 02, 2020 at 12:23:27AM -0500, Pavel Tatashin wrote:
> __gup_longterm_locked() has CMA || FS_DAX version and a common stub
> version. In the preparation of prohibiting longterm pinning of pages from
> movable zone make the CMA || FS_DAX version common, and delete the stub
> version.
>
>
On Wed, Dec 02, 2020 at 08:31:45AM -0800, 'Ira Weiny' wrote:
> On Wed, Dec 02, 2020 at 12:23:27AM -0500, Pavel Tatashin wrote:
> > __gup_longterm_locked() has CMA || FS_DAX version and a common stub
> > version. In the preparation of prohibiting longterm pinning of pages f
On Wed, Dec 02, 2020 at 11:10:50AM -0600, Eric Sandeen wrote:
> On 12/2/20 10:07 AM, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > There is a conflict with the user visible statx bits 'mount root' and
> > 'dax'. The kernel is shifting th
From: Ira Weiny
There is a conflict with the user visible statx bits 'mount root' and
'dax'. The kernel is changing the dax bit to correct this conflict.[1]
Adjust _check_s_dax() to use the new bit. Because DAX tests do not run
on root mounts, STATX_ATTR_MOUNT_ROO
From: Ira Weiny
There is a conflict with the user visible statx bits 'mount root' and
'dax'. The kernel is changing the dax bit to correct this conflict.[1]
Adjust _check_s_dax() to use the new bit. Because DAX tests do not run
on root mounts, STATX_ATTR_MOUNT_ROO
On Wed, Dec 02, 2020 at 12:42:08PM -0800, Linus Torvalds wrote:
> On Tue, Dec 1, 2020 at 6:16 PM Ira Weiny wrote:
> >
> > This will force a change to xfstests at a minimum. And I do know of users
> > who
> > have been using this value. But I have gotten inquires a
On Mon, Nov 30, 2020 at 11:22:32AM +0200, Joonas Lahtinen wrote:
> Quoting Matthew Wilcox (2020-11-27 15:20:06)
> > On Fri, Nov 27, 2020 at 03:06:24PM +0200, Joonas Lahtinen wrote:
> > > Quoting ira.we...@intel.com (2020-11-24 08:07:39)
> > > > From: Ira Weiny
>
On Tue, Feb 16, 2021 at 06:48:22PM -0800, 'Ira Weiny' wrote:
> From: Ira Weiny
>
> I am submitting these for 5.13.
Just a friendly ping on this set.
Ira
>
> Further work to remove more kmap() calls in favor of the kmap_local_page()
> this
> series converts
On Fri, Mar 12, 2021 at 07:54:13AM +0100, Christoph Hellwig wrote:
> So with the new kmap_local interface is it possible / advisable to
> use local kmaps over code that might schedule(), e.g. to wait for I/O?
It is possible yes. "Advisable" I think so. Thomas knows better than I what
performance
On Fri, Mar 12, 2021 at 07:58:39PM +0100, David Sterba wrote:
> On Tue, Feb 16, 2021 at 06:48:23PM -0800, ira.we...@intel.com wrote:
> > --- a/fs/btrfs/lzo.c
> > +++ b/fs/btrfs/lzo.c
> > @@ -118,7 +118,7 @@ int lzo_compress_pages(struct list_head *ws, struct
> > address_space *mapping,
> > str
On Fri, Mar 12, 2021 at 08:41:41PM +0100, David Sterba wrote:
> On Tue, Feb 16, 2021 at 06:48:22PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > I am submitting these for 5.13.
> >
> > Further work to remove more kmap() calls in favor o
On Thu, Mar 11, 2021 at 04:31:34PM -0700, Logan Gunthorpe wrote:
> Introduce pci_p2pdma_should_map_bus() which is meant to be called by
> DMA map functions to determine how to map a given p2pdma page.
>
> pci_p2pdma_bus_offset() is also added to allow callers to get the bus
> offset if they need t
On Thu, Mar 11, 2021 at 04:31:34PM -0700, Logan Gunthorpe wrote:
> Introduce pci_p2pdma_should_map_bus() which is meant to be called by
^
pci_p2pdma_dma_map_type() ???
FWIW I find this name confusing with pci_p2pdma_map_type() and looking at the
impl
On Thu, Mar 11, 2021 at 04:31:37PM -0700, Logan Gunthorpe wrote:
> +int dma_pci_p2pdma_supported(struct device *dev)
^^^
bool?
> +{
> + const struct dma_map_ops *ops = get_dma_ops(dev);
> +
> + return !ops || ops->flags & DMA_F_PCI_P2PDMA_SUPPORTED;
Is this logic correct? I would
On Wed, Mar 10, 2021 at 03:58:36PM -0800, Andrew Morton wrote:
> On Tue, 9 Mar 2021 13:21:34 -0800 ira.we...@intel.com wrote:
>
> > Previously this was submitted to convert to zero_user()[1]. zero_user() is
> > not
> > the same as memzero_user() and in fact some zero_user() calls may be better
On Tue, Mar 09, 2021 at 08:53:04PM +, Chaitanya Kulkarni wrote:
> Ira,
>
> On 3/4/21 00:23, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 61b205f579911a11f0b576f73275eca2aed0d108 ("mm/highmem: Convert
> > memcpy_[to|fro
From: Ira Weiny
Previously this was submitted to convert to zero_user()[1]. zero_user() is not
the same as memzero_user() and in fact some zero_user() calls may be better off
as memzero_user(). Regardless it was incorrect to convert btrfs to
zero_user().
This series corrects this by lifting
From: Ira Weiny
memzero_page() can replace the kmap/memset/kunmap pattern in other
places in the code. While zero_user() has the same interface it is not
the same call and its use should be limited and some of those calls may
be better converted from zero_user() to memzero_page().[1] But that
From: Ira Weiny
There are many places where kmap/memset/kunmap patterns occur.
Use the newly lifted memzero_page() to eliminate direct uses of kmap and
leverage the new core functions use of kmap_local_page().
The development of this patch was aided by the following coccinelle
script
From: Ira Weiny
The memset() does not need to be performed atomically. Use
kmap_local_page() which will improved performance for this call.
Cc: Chaitanya Kulkarni
Cc: David Sterba
Signed-off-by: Ira Weiny
---
include/linux/highmem.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
From: Ira Weiny
Working through a conversion to a call kmap_local_page() instead of
kmap() revealed many places where the pattern kmap/memcpy/kunmap
occurred.
Eric Biggers, Matthew Wilcox, Christoph Hellwig, Dan Williams, and Al
Viro all suggested putting this code into helper functions. Al
From: Ira Weiny
Development of this patch was aided by the following coccinelle script:
//
// SPDX-License-Identifier: GPL-2.0-only
// Find kmap/copypage/kunmap pattern and replace with copy_highpage calls
//
// NOTE: The expressions in the copy page version of this kmap pattern are
// overly
From: Ira Weiny
Development of this patch was aided by the coccinelle script:
//
// SPDX-License-Identifier: GPL-2.0-only
// Find kmap/memcpy/kunmap pattern and replace with memcpy*page calls
//
// NOTE: Offsets and other expressions may be more complex than what the script
// will
From: Ira Weiny
The development of this patch was aided by the following coccinelle
script:
//
// SPDX-License-Identifier: GPL-2.0-only
// Find kmap/memset/kunmap pattern and replace with memset*page calls
//
// NOTE: Offsets and other expressions may be more complex than what the script
From: Ira Weiny
There are many places where kmap//kunmap patterns occur. We lift
these various patterns to core common functions and use them in the btrfs file
system. At the same time we convert those core functions to use
kmap_local_page() which is more efficient in those calls.
I think
On Sun, Feb 07, 2021 at 01:46:47AM +, Chaitanya Kulkarni wrote:
> On 2/5/21 18:35, ira.we...@intel.com wrote:
> > +static inline void memmove_page(struct page *dst_page, size_t dst_off,
> > + struct page *src_page, size_t src_off,
> > + size_t l
dax_direct_access()")
> Reported-by: kernel test robot
> Signed-off-by: Randy Dunlap
Looks reasonable
Reviewed-by: Ira Weiny
> Cc: Vineet Gupta
> Cc: linux-snps-...@lists.infradead.org
> Cc: Dan Williams
> Acked-by: Vineet Gupta
> Cc: Andrew Morton
> Cc: Ma
On Mon, Jan 04, 2021 at 10:40:40AM +0800, Hao Li wrote:
> After commit 77573fa310d9 ("fs: Kill DCACHE_DONTCACHE dentry even if
> DCACHE_REFERENCED is set"), changes to DAX policy will take effect
> as soon as all references to this file are gone.
>
> Update the documentation accordingly.
>
> Sign
From: Ira Weiny
When a qstripe is required an extra page is allocated and mapped. There
were 3 problems.
1) There is no reason to map the qstripe page more than 1 time if the
number of bits set in rbio->dbitmap is greater than one.
2) There is no reason to map the parity page and unmap
documentation accordingly.
>
> Signed-off-by: Hao Li
LGTM
Reviewed-by: Ira Weiny
> ---
> Changes in v2:
> * simplify sentences and fix style problems.
>
> Documentation/filesystems/dax.txt | 17 +++--
> 1 file changed, 3 insertions(+), 14 deletions(-)
>
&
On Fri, Dec 11, 2020 at 02:14:28PM -0800, Andy Lutomirski wrote:
> On Mon, Nov 23, 2020 at 10:10 PM wrote:
> >
> > From: Ira Weiny
> >
> > Currently struct irqentry_state_t only contains a single bool value
> > which makes passing it by value is reasonable.
On Tue, Dec 15, 2020 at 06:09:02PM -0800, Andy Lutomirski wrote:
> On Tue, Dec 15, 2020 at 5:32 PM Ira Weiny wrote:
> >
> > On Fri, Dec 11, 2020 at 02:14:28PM -0800, Andy Lutomirski wrote:
> > > On Mon, Nov 23, 2020 at 10:10 PM wrote:
>
> > > IOW we have:
On Thu, Apr 14, 2016 at 10:45:50AM -0600, Jason Gunthorpe wrote:
> On Thu, Apr 14, 2016 at 08:41:35AM -0700, Dennis Dalessandro wrote:
> > This patch series removes the write() interface for user access in favor of
> > an
> > ioctl() based approach. This is in response to the complaint that we had
ference to `crc32_le'
>
> Signed-off-by: Markus Böhme
Doug did you pick this up?
Reviewed-by: Ira Weiny
> ---
> drivers/staging/rdma/hfi1/Kconfig |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/rdma/hfi1/Kconfig
> b/drivers/staging/
On Fri, Apr 15, 2016 at 07:01:26AM +0300, Leon Romanovsky wrote:
> On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote:
> > On Thu, Apr 14, 2016 at 10:45:50AM -0600, Jason Gunthorpe wrote:
> > > On Thu, Apr 14, 2016 at 08:41:35AM -0700, Dennis Dalessandro wrote:
> &g
On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
>
> Intel as usual decided to do it in their way and the result is presented
> on this mailing list.
Excuse me, but this statement is completely unfair. We were specifically asked
by Al and Linus to fix our char device with regard
On Mon, Apr 18, 2016 at 11:24:11AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 18, 2016 at 11:40:47AM -0600, Jason Gunthorpe wrote:
> > I wasn't arguing this should integrate into verbs in some way, only
> > that the way to access the driver-specific uAPI of a RDMA device should
> > be through th
From: Ira Weiny
This interface has no current users and is obsolete.
Signed-off-by: Ira Weiny
---
This has undergone a medium level of testing. I have run it against
mlx4, qib, and OPA hardware and it does not seem to cause any regressions.
drivers/infiniband/core/mad.c | 226
On Sun, Feb 10, 2019 at 08:39:44PM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Sat, 9 Feb 2019, ira.we...@intel.com wrote:
>
> nice patch. Just a few nitpicks vs. the subject and the change log.
>
> > Subject: [PATCH] mm/gup.c: Remove unused write variable
>
> We usually avoid filenames in the
From: Ira Weiny
The write argument is unused in gup_fast_permitted() so remove it.
Acked-by: Kirill A. Shutemov
Signed-off-by: Ira Weiny
---
Changes since V1
Clean up commit message
arch/x86/include/asm/pgtable_64.h | 3 +--
mm/gup.c | 6 +++---
2 files
On Mon, Feb 11, 2019 at 11:06:54AM -0700, Jason Gunthorpe wrote:
> On Mon, Feb 11, 2019 at 09:22:58AM -0800, Dan Williams wrote:
>
> > I honestly don't like the idea that random subsystems can pin down
> > file blocks as a side effect of gup on the result of mmap. Recall that
> > it's not just RDM
From: Ira Weiny
NOTE: This series depends on my clean up patch to remove the write parameter
from gup_fast_permitted()[1]
HFI1 uses get_user_pages_fast() due to it performance advantages. Like RDMA,
HFI1 pages can be held for a significant time. But get_user_pages_fast() does
not protect
From: Ira Weiny
Use the new get_user_pages_fast_longterm() call to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/hfi1/user_pages.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c
b
From: Ira Weiny
Users of get_user_pages_fast are not protected against mapping
pages within FS DAX. Introduce a call which protects them.
We do this by checking for DEVMAP pages during the fast walk and
falling back to the longterm gup call to check for FS DAX if needed.
Signed-off-by: Ira
From: Ira Weiny
In order to support more options in the GUP fast walk, change the
write parameter to flags throughout the call stack.
This patch does not change functionality and passes FOLL_WRITE
where write was previously used.
Signed-off-by: Ira Weiny
---
mm/gup.c | 52
On Mon, Feb 11, 2019 at 01:13:56PM -0800, John Hubbard wrote:
> On 2/11/19 12:39 PM, Jason Gunthorpe wrote:
> > On Mon, Feb 11, 2019 at 12:16:42PM -0800, ira.we...@intel.com wrote:
> >> From: Ira Weiny
> [...]
> >> +static inline int get_user_pages_fast_lon
On Mon, Feb 11, 2019 at 12:34:17PM -0800, Davidlohr Bueso wrote:
> On Mon, 11 Feb 2019, ira.we...@intel.com wrote:
> > Ira Weiny (3):
> > mm/gup: Change "write" parameter to flags
> > mm/gup: Introduce get_user_pages_fast_longterm()
> > IB/HFI1: Use new ge
On Mon, Feb 11, 2019 at 01:47:10PM -0700, Jason Gunthorpe wrote:
> On Mon, Feb 11, 2019 at 12:34:17PM -0800, Davidlohr Bueso wrote:
> > On Mon, 11 Feb 2019, ira.we...@intel.com wrote:
> > > Ira Weiny (3):
> > > mm/gup: Change "write" parame
On Mon, Feb 11, 2019 at 01:39:12PM -0800, John Hubbard wrote:
> On 2/11/19 1:26 PM, Ira Weiny wrote:
> > On Mon, Feb 11, 2019 at 01:13:56PM -0800, John Hubbard wrote:
> >> On 2/11/19 12:39 PM, Jason Gunthorpe wrote:
> >>> On Mon, Feb 11, 2019 at 12:16:42PM -0
On Mon, Feb 11, 2019 at 04:25:10PM -0700, Jason Gunthorpe wrote:
> On Mon, Feb 11, 2019 at 02:55:10PM -0800, Dan Williams wrote:
>
> > > I also wonder if someone should think about making fast into a flag
> > > too..
> > >
> > > But I'm not sure when fast should be used vs when it shouldn't :(
> >
On Tue, Mar 19, 2019 at 09:30:05AM -0400, Jerome Glisse wrote:
> On Mon, Mar 18, 2019 at 08:29:45PM -0700, Dan Williams wrote:
> > On Mon, Mar 18, 2019 at 3:15 PM Jerome Glisse wrote:
> > >
> > > On Mon, Mar 18, 2019 at 02:30:15PM -0700, Dan Williams wrote:
> > > > On Mon, Mar 18, 2019 at 1:41 PM
On Tue, Mar 19, 2019 at 04:36:44PM +0100, Jan Kara wrote:
> On Tue 19-03-19 17:29:18, Kirill A. Shutemov wrote:
> > On Tue, Mar 19, 2019 at 10:14:16AM -0400, Jerome Glisse wrote:
> > > On Tue, Mar 19, 2019 at 09:47:24AM -0400, Jerome Glisse wrote:
> > > > On Tue, Mar 19, 2019 at 03:04:17PM +0300, K
On Tue, Mar 19, 2019 at 01:10:43PM -0400, Jerome Glisse wrote:
> On Tue, Mar 19, 2019 at 01:44:57AM -0700, Ira Weiny wrote:
> > On Tue, Mar 19, 2019 at 09:30:05AM -0400, Jerome Glisse wrote:
> > > On Mon, Mar 18, 2019 at 08:29:45PM -0700, Dan Williams wrote:
> > > > O
On Tue, Mar 19, 2019 at 12:13:40PM -0700, Dan Williams wrote:
> On Tue, Mar 19, 2019 at 12:05 PM Jerome Glisse wrote:
> >
> > On Tue, Mar 19, 2019 at 11:42:00AM -0700, Dan Williams wrote:
> > > On Tue, Mar 19, 2019 at 10:45 AM Jerome Glisse wrote:
> > > >
> > > > On Tue, Mar 19, 2019 at 10:33:57A
On Mon, Aug 26, 2019 at 03:55:10PM +1000, Dave Chinner wrote:
> On Fri, Aug 23, 2019 at 10:08:36PM -0700, Ira Weiny wrote:
> > On Sat, Aug 24, 2019 at 10:11:24AM +1000, Dave Chinner wrote:
> > > On Fri, Aug 23, 2019 at 09:04:29AM -0300, Jason Gunthorpe wrote:
> > >
>
On Wed, Aug 28, 2019 at 08:27:23PM -0700, John Hubbard wrote:
> On 8/28/19 7:02 PM, Ira Weiny wrote:
> > On Mon, Aug 26, 2019 at 03:55:10PM +1000, Dave Chinner wrote:
> > > On Fri, Aug 23, 2019 at 10:08:36PM -0700, Ira Weiny wrote:
> > > > On Sat, Aug 24, 2019 at
On Fri, Aug 23, 2019 at 11:18:26AM -0400, Vivek Goyal wrote:
> On Fri, Aug 09, 2019 at 03:58:20PM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Callers of dax_layout_busy_page() are only rarely operating on the
> > entire file of concern.
> >
&g
Missed this. sorry.
On Mon, Aug 26, 2019 at 06:41:07AM -0400, Jeff Layton wrote:
> On Thu, 2019-08-15 at 07:56 +1000, Dave Chinner wrote:
> > On Wed, Aug 14, 2019 at 10:15:06AM -0400, Jeff Layton wrote:
> > > On Fri, 2019-08-09 at 15:58 -0700, ira.we...@intel.com wrote:
>
On Tue, Aug 20, 2019 at 08:55:15AM -0300, Jason Gunthorpe wrote:
> On Tue, Aug 20, 2019 at 11:12:10AM +1000, Dave Chinner wrote:
> > On Mon, Aug 19, 2019 at 09:38:41AM -0300, Jason Gunthorpe wrote:
> > > On Mon, Aug 19, 2019 at 07:24:09PM +1000, Dave Chinner wrote:
> > >
> > > > So that leaves jus
On Wed, Aug 21, 2019 at 03:13:43PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 21, 2019 at 11:02:00AM -0700, Ira Weiny wrote:
> > On Tue, Aug 20, 2019 at 08:55:15AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Aug 20, 2019 at 11:12:10AM +1000, Dave Chinner wrote:
> > > &
On Wed, Aug 21, 2019 at 11:57:03AM -0700, 'Ira Weiny' wrote:
> On Wed, Aug 21, 2019 at 03:13:43PM -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 21, 2019 at 11:02:00AM -0700, Ira Weiny wrote:
> > > On Tue, Aug 20, 2019 at 08:55:15AM -0300, Jason Gunthorpe wrote:
> &
hn Hubbard wrote:
> > > > > On 8/19/19 2:24 AM, Dave Chinner wrote:
> > > > > > On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan Kara wrote:
> > > > > > > On Sat 17-08-19 12:26:03, Dave Chinner wrote:
> > > > > > > > On
On Wed, Aug 21, 2019 at 04:48:10PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 21, 2019 at 11:57:03AM -0700, Ira Weiny wrote:
>
> > > Oh, I didn't think we were talking about that. Hanging the close of
> > > the datafile fd contingent on some other FD's clos
On Tue, Aug 20, 2019 at 09:07:24PM -0700, John Hubbard wrote:
> Hi Ira,
>
> This is for your tree. I'm dropping the RFC because this aspect is
> starting to firm up pretty well.
>
> I've moved FOLL_PIN inside the vaddr_pin_*() routines, and moved
> FOLL_LONGTERM outside, based on our recent discu
On Wed, Aug 14, 2019 at 09:23:08AM -0300, Jason Gunthorpe wrote:
> On Tue, Aug 13, 2019 at 01:38:59PM -0700, Ira Weiny wrote:
> > On Tue, Aug 13, 2019 at 03:00:22PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Aug 13, 2019 at 10:41:42AM -0700, Ira Weiny wrote:
> > >
&g
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.
> >
> > Based on the feedback from LSFmm, the LWN article, the RFC series since
> > then, and a ton of sce
On Tue, Aug 13, 2019 at 05:56:31PM -0700, John Hubbard wrote:
> On 8/13/19 5:51 PM, John Hubbard wrote:
> > On 8/13/19 2:08 PM, Ira Weiny wrote:
> >> On Mon, Aug 12, 2019 at 05:07:32PM -0700, John Hubbard wrote:
> >>> On 8/12/19 4:49 PM, Ira Weiny wrote:
> >&g
On Thu, Aug 15, 2019 at 03:35:10PM +0200, Jan Kara wrote:
> On Thu 15-08-19 15:26:22, Jan Kara wrote:
> > On Wed 14-08-19 20:01:07, John Hubbard wrote:
> > > On 8/14/19 5:02 PM, John Hubbard wrote:
> > >
> > > Hold on, I *was* forgetting something: this was a two part thing, and
> > > you're confl
On Fri, Aug 16, 2019 at 05:41:08PM +0200, Jan Kara wrote:
> On Thu 15-08-19 19:14:08, John Hubbard wrote:
> > On 8/15/19 10:41 AM, John Hubbard wrote:
> > > On 8/15/19 10:32 AM, Ira Weiny wrote:
> > >> On Thu, Aug 15, 2019 at 03:35:10PM +0200, Jan Kara wrote:
> &g
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, Jan Kara wrote:
> > > Hello!
> > >
> > > On Fri 09-08-19 15:58:14, ira.we...@int
On Fri, Aug 16, 2019 at 11:50:09AM -0700, John Hubbard wrote:
> On 8/16/19 11:33 AM, Ira Weiny wrote:
> > On Fri, Aug 16, 2019 at 05:41:08PM +0200, Jan Kara wrote:
> > > On Thu 15-08-19 19:14:08, John Hubbard wrote:
> > > > On 8/15/19 10:41 AM, John Hubbard 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, Jan Kara wrote:
> > > > Hello!
> >
em_region
> - export the memremap_pages and munmap_pages as kvmppc can be a module
Except for the questions from Andrew this does not look to change anything so:
Reviewed-by: Ira Weiny
> ___
> Linux-nvdimm mailing list
> linux-nvd...@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
On Fri, Aug 23, 2019 at 10:59:14AM +1000, Dave Chinner wrote:
> On Wed, Aug 21, 2019 at 11:02:00AM -0700, Ira Weiny wrote:
> > On Tue, Aug 20, 2019 at 08:55:15AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Aug 20, 2019 at 11:12:10AM +1000, Dave Chinner wrote:
> > > >
On Fri, Aug 23, 2019 at 01:23:45PM +1000, Dave Chinner wrote:
> On Wed, Aug 21, 2019 at 01:44:21PM -0700, Ira Weiny wrote:
> > On Wed, Aug 21, 2019 at 04:48:10PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 21, 2019 at 11:57:03AM -0700, Ira Weiny wrote:
> > >
>
On Sat, Aug 24, 2019 at 10:11:24AM +1000, Dave Chinner wrote:
> On Fri, Aug 23, 2019 at 09:04:29AM -0300, Jason Gunthorpe wrote:
> > On Fri, Aug 23, 2019 at 01:23:45PM +1000, Dave Chinner wrote:
> >
> > > > But the fact that RDMA, and potentially others, can "pass the
> > > > pins" to other proces
On Tue, Sep 03, 2019 at 08:26:18AM +1000, Dave Chinner wrote:
> On Wed, Aug 28, 2019 at 07:02:31PM -0700, Ira Weiny wrote:
> > On Mon, Aug 26, 2019 at 03:55:10PM +1000, Dave Chinner wrote:
> > > On Fri, Aug 23, 2019 at 10:08:36PM -0700, Ira Weiny wrote:
> > > > On S
On Wed, Aug 14, 2019 at 09:23:08AM -0300, Jason Gunthorpe wrote:
> On Tue, Aug 13, 2019 at 01:38:59PM -0700, Ira Weiny wrote:
> > On Tue, Aug 13, 2019 at 03:00:22PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Aug 13, 2019 at 10:41:42AM -0700, Ira Weiny wrote:
> > >
&g
On Thu, Oct 03, 2019 at 11:01:10AM +0200, Jan Kara wrote:
> On Tue 01-10-19 11:17:00, Ira Weiny wrote:
> > On Mon, Sep 23, 2019 at 04:17:59PM -0400, Jeff Layton wrote:
> > > On Mon, 2019-09-23 at 12:08 -0700, Ira Weiny wrote:
> > >
> > > Will userland requir
On Mon, Sep 23, 2019 at 04:17:59PM -0400, Jeff Layton wrote:
> On Mon, 2019-09-23 at 12:08 -0700, Ira Weiny wrote:
> > Since the last RFC patch set[1] much of the discussion of supporting RDMA
> > with
> > FS DAX has been around the semantics of the lease mechanism.[2] With
On Mon, Sep 30, 2019 at 06:42:33PM +1000, Dave Chinner wrote:
> On Wed, Sep 25, 2019 at 04:46:03PM -0700, Ira Weiny wrote:
> > On Tue, Sep 24, 2019 at 08:26:20AM +1000, Dave Chinner wrote:
> > > Hence, AFIACT, the above definition of a F_RDLCK|F_LAYOUT lease
> > > does
From: Ira Weiny
Signed-off-by: Ira Weiny
---
include/linux/nd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/nd.h b/include/linux/nd.h
index f778f962d1b6..55c735997805 100644
--- a/include/linux/nd.h
+++ b/include/linux/nd.h
@@ -147,7 +147,7 @@ static
Avoid this by including linux/acpi.h in nfit_test.h, which allows us to
> remove both the typedef and the forward declaration of acpi_object.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/660
> Signed-off-by: Nathan Chancellor
Reviewed-by: Ira Weiny
> ---
>
> I
On Tue, Sep 24, 2019 at 08:26:20AM +1000, Dave Chinner wrote:
> On Mon, Sep 23, 2019 at 12:08:53PM -0700, Ira Weiny wrote:
> >
> > Since the last RFC patch set[1] much of the discussion of supporting RDMA
> > with
> > FS DAX has been around the semantics of the lease
Since the last RFC patch set[1] much of the discussion of supporting RDMA with
FS DAX has been around the semantics of the lease mechanism.[2] Within that
thread it was suggested I try and write some documentation and/or tests for the
new mechanism being proposed. I have created a foundation to
From: Ira Weiny
The parens used in the while loop would result in error being assigned
the value 1 rather than the intended errno value.
This is required to return -ETXTBSY from follow on break_layout()
changes.
Signed-off-by: Ira Weiny
---
fs/xfs/xfs_pnfs.c | 2 +-
1 file changed, 1
On Mon, Aug 19, 2019 at 09:38:41AM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 19, 2019 at 07:24:09PM +1000, Dave Chinner wrote:
>
> > So that leaves just the normal close() syscall exit case, where the
> > application has full control of the order in which resources are
> > released. We've alread
it is a useful hack for other
> subsystems device_lock() debug sessions. Quoting Greg:
>
> "Yeah, it feels a bit hacky but it's really up to a subsystem to mess up
> using it as much as anything else, so user beware :)
>
> I don't object to it if it makes t
On Fri, May 01, 2020 at 01:44:46AM -0700, Christoph Hellwig wrote:
> > --- a/arch/sparc/mm/highmem.c
> > +++ b/arch/sparc/mm/highmem.c
> > @@ -33,6 +33,7 @@
> > #include
> >
> > pgprot_t kmap_prot;
> > +EXPORT_SYMBOL(kmap_prot);
>
> Btw, I don't see why sparc needs this as a variable, as ther
On Fri, May 01, 2020 at 01:54:56AM -0700, Christoph Hellwig wrote:
> In addition to the work already it the series, it seems like
> LAST_PKMAP_MASK, PKMAP_ADDR and PKMAP_NR can also be consolidated
> to common code.
Agreed, I mentioned in the cover letter there are similarities...
>
> Also kmap_
On Fri, May 01, 2020 at 04:20:20AM +0100, Al Viro wrote:
> On Fri, May 01, 2020 at 03:37:34AM +0100, Al Viro wrote:
> > On Thu, Apr 30, 2020 at 01:38:44PM -0700, ira.we...@intel.com wrote:
> >
> > > -static inline void *kmap_atomic(struct page *page)
> > > +static inline void *kmap_atomic_prot(str
From: Ira Weiny
Replace the use of BUG_ON(in_interrupt()) in the kmap() and kunmap()
in favor of might_sleep().
Besides the benefits of might_sleep(), this normalizes the
implementations such that they can be made generic in subsequent
patches.
Reviewed-by: Dan Williams
Reviewed-by: Christoph
From: Ira Weiny
Every single architecture (including !CONFIG_HIGHMEM) calls...
pagefault_enable();
preempt_enable();
... before returning from __kunmap_atomic(). Lift this code into the
kunmap_atomic() macro.
While we are at it rename __kunmap_atomic() to kunmap_atomic_high
From: Ira Weiny
The kmap code for all the architectures is almost 100% identical.
Lift the common code to the core. Use ARCH_HAS_KMAP_FLUSH_TLB to
indicate if an arch defines kmap_flush_tlb() and call if if needed.
This also has the benefit of changing kmap() on a number of
architectures to
From: Ira Weiny
During this kmap() conversion series we must maintain bisect-ability.
To do this, kmap_atomic_prot() in x86, powerpc, and microblaze need to
remain functional.
Create a temporary inline version of kmap_atomic_prot within these
architectures so we can rework their kmap_atomic
From: Ira Weiny
Every arch has the same code to ensure atomic operations and a check for
!HIGHMEM page.
Remove the duplicate code by defining a core kmap_atomic() which only
calls the arch specific kmap_atomic_high() when the page is high memory.
Signed-off-by: Ira Weiny
---
Changes from V1
From: Ira Weiny
To support kmap_atomic_prot() on all architectures each arch must
support protections passed in to them.
Change csky, mips, nds32 and xtensa to use their global constant
kmap_prot rather than a hard coded value which was equal.
Reviewed-by: Christoph Hellwig
Signed-off-by: Ira
From: Ira Weiny
We want to support kmap_atomic_prot() on all architectures and it makes
sense to define kmap_atomic() to use the default kmap_prot.
So we ensure all arch's have a globally available kmap_prot either as a
define or exported symbol.
Signed-off-by: Ira Weiny
---
arch/micro
From: Ira Weiny
All architectures do exactly the same thing for kunmap(); remove all the
duplicate definitions and lift the call to the core.
This also has the benefit of changing kmap_unmap() on a number of
architectures to be an inline call rather than an actual function.
Reviewed-by
301 - 400 of 969 matches
Mail list logo
