On Wed, Apr 10, 2019 at 09:20:36AM +0800, Huang Shijie wrote:
> On Tue, Apr 09, 2019 at 02:55:31PM +, Weiny, Ira wrote:
> > > On Tue, Apr 09, 2019 at 11:04:18AM +0800, Huang Shijie wrote:
> > > > On Mon, Apr 08, 2019 at 07:49:29PM -0700, Matthew Wilcox wrote:
> > > > > On Tue, Apr 09, 2019 at
On Wed, Apr 10, 2019 at 09:18:50AM +0800, Huang Shijie wrote:
> On Tue, Apr 09, 2019 at 01:23:16PM -0700, Ira Weiny wrote:
> > On Tue, Apr 09, 2019 at 09:08:33AM +0800, Huang Shijie wrote:
> > > On Mon, Apr 08, 2019 at 07:13:13AM -0700, Matthew Wilcox wrote:
> > > >
On Thu, Apr 04, 2019 at 03:23:47PM +0800, Huang Shijie wrote:
> When CONFIG_HAVE_GENERIC_GUP is defined, the kernel will use its own
> get_user_pages_fast().
>
> In the following scenario, we will may meet the bug in the DMA case:
> .
>
On Sun, Apr 07, 2019 at 03:11:00PM -0700, Dan Williams wrote:
> On Thu, Apr 4, 2019 at 2:47 AM Robin Murphy wrote:
> >
> > On 04/04/2019 06:04, Dan Williams wrote:
> > > On Wed, Apr 3, 2019 at 9:42 PM Anshuman Khandual
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 04/03/2019 07:28 PM, Robin Murphy
On Wed, Mar 20, 2019 at 12:33:20AM -0400, Jerome Glisse wrote:
> On Tue, Mar 19, 2019 at 06:43:45PM -0700, John Hubbard wrote:
> > On 3/19/19 5:08 PM, Jerome Glisse wrote:
> > > On Wed, Mar 20, 2019 at 10:57:52AM +1100, Dave Chinner wrote:
> > >> On Tue, Mar 19, 2019 at 06:06:55PM -0400, Jerome
On Tue, Mar 19, 2019 at 03:19:30PM -0700, Andrew Morton wrote:
> On Sun, 17 Mar 2019 11:34:31 -0700 ira.we...@intel.com wrote:
>
> > Resending after rebasing to the latest mm tree.
> >
> > HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
> > advantages. These pages can be
On Mon, Mar 25, 2019 at 10:40:02AM -0400, Jerome Glisse wrote:
> From: Jérôme Glisse
>
> Every time i read the code to check that the HMM structure does not
> vanish before it should thanks to the many lock protecting its removal
> i get a headache. Switch to reference counting instead it is
On Mon, Mar 25, 2019 at 10:40:06AM -0400, Jerome Glisse wrote:
> From: Jérôme Glisse
>
> A common use case for HMM mirror is user trying to mirror a range
> and before they could program the hardware it get invalidated by
> some core mm event. Instead of having user re-try right away to
> mirror
entries in pfns array.
>
> Changes since v1:
> - updated documentation
> - reformated some comments
>
> Signed-off-by: Jérôme Glisse
> Reviewed-by: Ralph Campbell
> Reviewed-by: John Hubbard
Reviewed-by: Ira Weiny
> Cc: Andrew Morton
> Cc: Dan Wil
On Mon, Mar 25, 2019 at 10:40:05AM -0400, Jerome Glisse wrote:
> From: Jérôme Glisse
>
> Rename for consistency between code, comments and documentation. Also
> improves the comments on all the possible returns values. Improve the
> function by returning the number of populated entries in pfns
On Mon, Mar 25, 2019 at 10:40:06AM -0400, Jerome Glisse wrote:
> From: Jérôme Glisse
>
> A common use case for HMM mirror is user trying to mirror a range
> and before they could program the hardware it get invalidated by
> some core mm event. Instead of having user re-try right away to
> mirror
On Thu, Mar 28, 2019 at 04:28:47PM -0700, John Hubbard wrote:
> On 3/28/19 4:21 PM, Jerome Glisse wrote:
> > On Thu, Mar 28, 2019 at 03:40:42PM -0700, John Hubbard wrote:
> >> On 3/28/19 3:31 PM, Jerome Glisse wrote:
> >>> On Thu, Mar 28, 2019 at 03:19:06PM -0700, John Hubbard wrote:
> On
On Thu, Mar 28, 2019 at 05:39:26PM -0700, John Hubbard wrote:
> On 3/28/19 2:21 PM, Jerome Glisse wrote:
> > On Thu, Mar 28, 2019 at 01:43:13PM -0700, John Hubbard wrote:
> >> On 3/28/19 12:11 PM, Jerome Glisse wrote:
> >>> On Thu, Mar 28, 2019 at 04:07:20AM -0700,
a_walk *hmm_vma_walk = walk->private;
> struct hmm_range *range = hmm_vma_walk->range;
> uint64_t *pfns = range->pfns;
> - unsigned long i;
> + unsigned long i, page_size;
>
> hmm_vma_walk->last = addr;
> - i = (addr - range->start) >
On Mon, Mar 25, 2019 at 10:40:09AM -0400, Jerome Glisse wrote:
> From: Jérôme Glisse
>
> HMM mirror is a device driver helpers to mirror range of virtual address.
> It means that the process jobs running on the device can access the same
> virtual address as the CPU threads of that process. This
On Thu, Mar 28, 2019 at 09:50:03PM -0400, Jerome Glisse wrote:
> On Thu, Mar 28, 2019 at 06:18:35PM -0700, John Hubbard wrote:
> > On 3/28/19 6:00 PM, Jerome Glisse wrote:
> > > On Thu, Mar 28, 2019 at 09:57:09AM -0700, Ira Weiny wrote:
> > >> On Thu, Mar 28, 2019 at
On Thu, Mar 28, 2019 at 04:34:04PM -0700, John Hubbard wrote:
> On 3/28/19 4:24 PM, Jerome Glisse wrote:
> > On Thu, Mar 28, 2019 at 04:20:37PM -0700, John Hubbard wrote:
> >> On 3/28/19 4:05 PM, Jerome Glisse wrote:
> >>> On Thu, Mar 28, 2019 at 03:43:33PM -0700, John Hubbard wrote:
> On
On Thu, Mar 28, 2019 at 08:56:54PM -0400, Jerome Glisse wrote:
> On Thu, Mar 28, 2019 at 09:12:21AM -0700, Ira Weiny wrote:
> > On Mon, Mar 25, 2019 at 10:40:06AM -0400, Jerome Glisse wrote:
> > > From: Jérôme Glisse
> > >
[snip]
> > > +/*
> > > +
From: Ira Weiny
DAX pages were previously unprotected from longterm pins when users
called get_user_pages_fast().
Use the new FOLL_LONGTERM flag to check for DEVMAP pages and fall
back to regular GUP processing if a DEVMAP page is encountered.
Signed-off-by: Ira Weiny
---
mm/gup.c | 24
From: Ira Weiny
To facilitate additional options to get_user_pages_fast() change the
singular write parameter to be gup_flags.
This patch does not change any functionality. New functionality will
follow in subsequent patches.
Some of the get_user_pages_fast() call sites were unchanged because
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/hfi1/user_pages.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/mthca/mthca_memfree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mthca
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/qib/qib_user_sdma.c
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
From: Ira Weiny
Rather than have a separate get_user_pages_longterm() call,
introduce FOLL_LONGTERM and change the longterm callers to use
it.
This patch does not change any functionality.
FOLL_LONGTERM can only be supported with get_user_pages() as it
requires vmas to determine if DAX
From: Ira Weiny
Resending these as I had only 1 minor comment which I believe we have covered
in this series. I was anticipating these going through the mm tree as they
depend on a cleanup patch there and the IB changes are very minor. But they
could just as well go through the IB tree.
NOTE
On Tue, Mar 12, 2019 at 05:23:21AM +, Christopher Lameter wrote:
> On Mon, 11 Mar 2019, Dave Chinner wrote:
>
> > > Direct IO on a mmapped file backed page doesnt make any sense.
> >
> > People have used it for many, many years as zero-copy data movement
> > pattern. i.e. mmap the destination
On Wed, Mar 13, 2019 at 09:11:13AM +1100, Dave Chinner wrote:
> On Tue, Mar 12, 2019 at 03:39:33AM -0700, Ira Weiny wrote:
> > IMHO I don't think that the copy_file_range() is going to carry us through
> > the
> > next wave of user performance requirements.
king of these pages. This tracking will be separate from
>the existing struct page refcounting.
>
> 4) Use the tracking and identification of these pages, to implement
>special handling (especially in writeback paths) when the pages are
>backed by a filesystem.
>
&
On Tue, Mar 12, 2019 at 05:38:55PM -0700, John Hubbard wrote:
> On 3/12/19 8:30 AM, Ira Weiny wrote:
> > On Wed, Mar 06, 2019 at 03:54:55PM -0800, john.hubb...@gmail.com wrote:
> > > From: John Hubbard
> > >
> > > Introduces put_user_page(), which simply c
On Wed, Feb 20, 2019 at 07:19:30AM -0800, Christoph Hellwig wrote:
> On Tue, Feb 19, 2019 at 09:30:33PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Resending these as I had only 1 minor comment which I believe we have
> > covered
> > in
On Sun, Feb 03, 2019 at 09:21:33PM -0800, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
[snip]
>
> +/*
> + * GUP_PIN_COUNTING_BIAS, and the associated functions that use it, overload
> + * the page's refcount so that two separate items are tracked: the original
> page
> + * reference
On Thu, Feb 21, 2019 at 08:48:41AM +0530, Souptick Joarder wrote:
> Hi Ira,
>
> On Wed, Feb 20, 2019 at 11:01 AM wrote:
> >
> > From: Ira Weiny
> >
> > To facilitate additional options to get_user_pages_fast() change the
> > singular write parameter t
ove that entire phrase.
>
> 4. Minor: As long as I'm here, shorten up a couple of long lines
> in the same function, without harming the ability to
> grep for the printed error message.
>
> Cc: Ira Weiny
> Cc: Jason Gunthorpe
> Cc: Andrew Morton
> Cc: Doug Ledford
On Sun, Mar 03, 2019 at 11:52:41AM +0200, Artemy Kovalyov wrote:
>
>
> On 02/03/2019 21:44, Ira Weiny wrote:
> >
> > On Sat, Mar 02, 2019 at 12:24:35PM -0800, john.hubb...@gmail.com wrote:
> > > From: John Hubbard
> > >
> > > ...
>
nement: for that same cleanup code, release_pages()
> is better than put_page() in a loop.
>
> Cc: Leon Romanovsky
> Cc: Ira Weiny
> Cc: Jason Gunthorpe
> Cc: Andrew Morton
> Cc: Doug Ledford
> Cc: linux-r...@vger.kernel.org
> Cc: linux...@kvack.org
> Sig
nement: for that same cleanup code, release_pages()
> is better than put_page() in a loop.
>
> Cc: Leon Romanovsky
> Cc: Ira Weiny
> Cc: Jason Gunthorpe
> Cc: Andrew Morton
> Cc: Doug Ledford
> Cc: linux-r...@vger.kernel.org
> Cc: linux...@kvack.org
> Signed-off-by
On Mon, Mar 04, 2019 at 03:11:05PM -0800, John Hubbard wrote:
> On 3/3/19 8:55 AM, Ira Weiny wrote:
> > On Sun, Mar 03, 2019 at 11:52:41AM +0200, Artemy Kovalyov wrote:
> >>
> >>
> >> On 02/03/2019 21:44, Ira Weiny wrote:
> >>>
> >>> On S
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
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 :(
>
ange get_user_pages() to use the new FOLL_LONGTERM flag and
> remove the specialized get_user_pages_longterm call.
>
> [1] https://lkml.org/lkml/2019/2/11/237
> [2] https://lkml.org/lkml/2019/2/11/1789
Any comments on this series? I've touched a lot of subsystems which I think
require revi
On Fri, Feb 15, 2019 at 03:00:31PM -0700, Jason Gunthorpe wrote:
> On Fri, Feb 15, 2019 at 06:31:36PM +, Christopher Lameter wrote:
> > On Fri, 15 Feb 2019, Matthew Wilcox wrote:
> >
> > > > Since RDMA is something similar: Can we say that a file that is used for
> > > > RDMA should not use
> * Reduced down to just one patch, in order to avoid dependencies between
>subsystem git repos.
>
> * Rebased to latest linux.git: commit afe6fe7036c6 ("Merge tag
>'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
>
> * Added Ira's rev
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
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
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
ce 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/rdma/hfi1/
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
and the new Protection Key for Supervisor
> > (PKS) in subsequent patches.
> >
> > Co-developed-by: Ira Weiny
> > Signed-off-by: Ira Weiny
> > Signed-off-by: Fenghua Yu
> > ---
> > arch/x86/include/asm/pkeys.h | 2 ++
> > arch/x86/kernel/fpu/
On Fri, Oct 16, 2020 at 01:12:26PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 13, 2020 at 11:31:45AM -0700, Dave Hansen wrote:
> > > +/**
> > > + * It should also be noted that the underlying WRMSR(MSR_IA32_PKRS) is
> > > not
> > > + * serializing but still maintains ordering properties similar
On Fri, Oct 16, 2020 at 01:06:36PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 12:42:53PM -0700, ira.we...@intel.com wrote:
>
> > @@ -644,6 +663,8 @@ void __switch_to_xtra(struct task_struct *prev_p,
> > struct task_struct *next_p)
> >
> > if ((tifp ^ tifn) & _TIF_SLD)
> >
On Fri, Oct 16, 2020 at 01:07:47PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 12:42:54PM -0700, ira.we...@intel.com wrote:
> > +static inline void pks_update_protection(int pkey, unsigned long
> > protection)
> > +{
> > + current->thread.saved_pkrs =
On Fri, Oct 16, 2020 at 02:55:21PM +0200, Thomas Gleixner wrote:
> On Fri, Oct 16 2020 at 13:45, Peter Zijlstra wrote:
> > On Fri, Oct 09, 2020 at 12:42:55PM -0700, ira.we...@intel.com wrote:
> >> @@ -238,7 +236,7 @@ noinstr void idtentry_exit_nmi(struct pt_regs *regs,
> >> bool restore)
> >>
>
On Mon, Oct 19, 2020 at 11:37:14AM +0200, Peter Zijlstra wrote:
> On Fri, Oct 16, 2020 at 10:14:10PM -0700, Ira Weiny wrote:
> > > so it either needs to
> > > explicitly do so, or have an assertion that preemption is indeed
> > > disabled.
> >
> > H
On Mon, Oct 19, 2020 at 11:32:50AM +0200, Thomas Gleixner wrote:
> On Sun, Oct 18 2020 at 22:37, Ira Weiny wrote:
> > On Fri, Oct 16, 2020 at 02:55:21PM +0200, Thomas Gleixner wrote:
> >> Subject: x86/entry: Move nmi entry/exit into common code
> >> From: Thomas Gleix
Thomas,
Is there any chance of this landing before the kmap stuff gets sorted out?
It would be nice to have this in 5.11 to build off of.
Ira
On Fri, Nov 06, 2020 at 03:28:58PM -0800, 'Ira Weiny' wrote:
> From: Ira Weiny
>
> Changes from V2 [4]
> Rebased on tip-tre
From: Ira Weiny
kmap_atomic() is being deprecated in favor of kmap_local_page().
Replace the uses of kmap_atomic() within the highmem code.
Signed-off-by: Ira Weiny
---
include/linux/highmem.h | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git
From: Ira Weiny
Working through a conversion to a call such as kmap_thread() 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 Viro
further
From: Ira Weiny
These are based on tip/core/mm. As I was looking at converting the calls to
kmap_local_page() I realized that there were a number of calls in highmem.h
which should also be converted.
So I've added a second prelim patch to convert those.
This is a V2 to get into 5.11 so
On Tue, Dec 08, 2020 at 12:23:16PM +, Matthew Wilcox wrote:
> On Mon, Dec 07, 2020 at 02:57:03PM -0800, ira.we...@intel.com wrote:
> > Placing these functions in 'highmem.h' is suboptimal especially with the
> > changes being proposed in the functionality of kmap. From a caller
> >
On Tue, Dec 08, 2020 at 04:55:54PM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Mon, Dec 07 2020 at 14:14, Ira Weiny wrote:
> > Is there any chance of this landing before the kmap stuff gets sorted out?
>
> I have marked this as needs an update because the change log o
On Mon, Dec 07, 2020 at 03:49:55PM -0800, Dan Williams wrote:
> On Mon, Dec 7, 2020 at 3:40 PM Matthew Wilcox wrote:
> >
> > On Mon, Dec 07, 2020 at 03:34:44PM -0800, Dan Williams wrote:
> > > On Mon, Dec 7, 2020 at 3:27 PM Matthew Wilcox wrote:
> > > >
> > > > On Mon, Dec 07, 2020 at 02:57:03PM
On Tue, Dec 08, 2020 at 03:40:52PM -0800, Dan Williams wrote:
> On Tue, Dec 8, 2020 at 2:49 PM Darrick J. Wong
> wrote:
> [..]
> > > So what's your preferred poison?
> > >
> > > 1. Corrupt random data in whatever's been mapped into the next page (which
> > >is what the helpers currently do)
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
On Thu, Feb 04, 2021 at 04:26:08PM +0100, David Sterba wrote:
> On Wed, Feb 03, 2021 at 04:56:48PM +0100, David Sterba wrote:
> > On Wed, Jan 27, 2021 at 10:15:03PM -0800, ira.we...@intel.com wrote:
> > > From: Ira Weiny
> > >
> > > When a qstripe is
On Wed, Feb 03, 2021 at 12:45:33AM +0200, Jarkko Sakkinen wrote:
> On Tue, Feb 02, 2021 at 11:47:19AM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > kmap is inefficient and we are trying to reduce the usage in the kernel.
> > There is no readily app
On Fri, Feb 05, 2021 at 04:34:41PM +0100, David Sterba wrote:
> On Thu, Feb 04, 2021 at 07:52:36PM -0800, Ira Weiny wrote:
> > On Thu, Feb 04, 2021 at 04:26:08PM +0100, David Sterba wrote:
> > > On Wed, Feb 03, 2021 at 04:56:48PM +0100, David Sterba wrote:
> > > >
On Tue, Feb 09, 2021 at 04:11:23PM +0100, David Sterba wrote:
> On Fri, Feb 05, 2021 at 03:23:00PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > There are many places where kmap//kunmap patterns occur. We lift
> > these various patterns to core co
On Tue, Feb 09, 2021 at 01:11:03PM -0800, Andrew Morton wrote:
> > >
> > > It would be best to merge [1/4] via the btrfs tree. Please add my
> > >
> > > Acked-by: Andrew Morton
> > >
> > >
> > > Although I think it would be better if [1/4] merely did the code
> > > movement. Adding those
On Tue, Feb 09, 2021 at 01:58:37PM -0800, Andrew Morton wrote:
> On Tue, 9 Feb 2021 13:52:29 -0800 Ira Weiny wrote:
>
> > >
> > > Let's please queue this up separately.
> >
> > Ok can I retain your Ack on the move part of the patch?
>
> I mis
On Tue, Feb 09, 2021 at 11:09:31AM -0800, Andrew Morton wrote:
> On Tue, 9 Feb 2021 16:11:23 +0100 David Sterba wrote:
>
> > On Fri, Feb 05, 2021 at 03:23:00PM -0800, ira.we...@intel.com wrote:
> > > From: Ira Weiny
> > >
> > > There are many places
From: Ira Weiny
There are many places where the pattern kmap/memcpy/kunmap occurs.
This pattern was lifted to the core common functions
memcpy_[to|from]_page().
Use these new functions to reduce the code, eliminate direct uses of
kmap, and leverage the new core functions use of kmap_local_page
From: Ira Weiny
There are many places where kmap/memove/kunmap patterns occur.
This pattern exists in the core common function copy_highpage().
Use copy_highpage to avoid open coding the use of kmap and leverages the
core functions use of kmap_local_page().
Development of this patch was aided
From: Ira Weiny
There are many places where kmap/memset/kunmap patterns occur.
This pattern exists in the core as zero_user()
Use zero_user() 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
From: Ira Weiny
Changes from V1:
Rework commit messages because they were very weak
Change 'fs/btrfs: X' to 'btrfs: x'
https://lore.kernel.org/lkml/20210209151442.gu1...@suse.cz/
Per Andrew
Split out changes to highmem.h
From: Ira Weiny
3 more common kmap patterns are kmap/memcpy/kunmap, kmap/memmove/kunmap.
and kmap/memset/kunmap.
Add helper functions for those patterns which use kmap_local_page().
Cc: Andrew Morton
Cc: Christoph Hellwig
Signed-off-by: Ira Weiny
---
New for V2
---
include/linux/highmem.h
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
kmap_local_page() is more efficient and is well suited for these calls.
Convert the kmap() to kmap_local_page()
Cc: Andrew Morton
Cc: Christoph Hellwig
Signed-off-by: Ira Weiny
---
New for V2
---
include/linux/highmem.h | 8
1 file changed, 4 insertions(+), 4
From: Ira Weiny
zero_user() is already defined with the same interface and contains the
same code pattern as memzero_page(). Remove memzero_page() and use the
already defined common function zero_user()
To: Alexander Viro
Cc: Andrew Morton
Cc: Christoph Hellwig
Signed-off-by: Ira Weiny
From: Ira Weiny
Add VM_BUG_ON bounds checks to ensure the newly lifted and created page
memory operations do not result in corrupted data in neighbor pages and
to make them consistent with zero_user().[1][2]
[1]
https://lore.kernel.org/lkml/20201210053502.gs1563...@iweiny-desk2.sc.intel.com
On Wed, Feb 10, 2021 at 12:55:02PM +, Christoph Hellwig wrote:
> On Tue, Feb 09, 2021 at 10:22:17PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Add VM_BUG_ON bounds checks to ensure the newly lifted and created page
> > memory operations do n
On Wed, Feb 10, 2021 at 06:57:30AM +, Chaitanya Kulkarni wrote:
> On 2/9/21 22:25, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Add VM_BUG_ON bounds checks to ensure the newly lifted and created page
> > memory operations do not result in corru
On Wed, Feb 10, 2021 at 04:41:34PM +, Christoph Hellwig wrote:
> On Wed, Feb 10, 2021 at 08:29:01AM -0800, Ira Weiny wrote:
> > On Wed, Feb 10, 2021 at 12:55:02PM +, Christoph Hellwig wrote:
> > > On Tue, Feb 09, 2021 at 10:22:17PM -0800, ira.we...@intel.com wrote:
>
From: Ira Weiny
Add VM_BUG_ON bounds checks to ensure the newly lifted and created page
memory operations do not result in corrupted data in neighbor pages.[1][2]
[1]
https://lore.kernel.org/lkml/20201210053502.gs1563...@iweiny-desk2.sc.intel.com/
[2]
https://lore.kernel.org/lkml
On Wed, Feb 10, 2021 at 06:56:06PM +, Matthew Wilcox wrote:
> On Wed, Feb 10, 2021 at 08:29:01AM -0800, Ira Weiny wrote:
> > And I thought it was a good idea. Any file system development should have
> > tests with DEBUG_VM which should cover Matthew's concern w
On Thu, Feb 04, 2021 at 01:02:53PM +0530, Prathu Baronia wrote:
> From: Ira Weiny
>
> kmap_atomic() is being deprecated in favor of kmap_local_page().
>
> Replace the uses of kmap_atomic() within the highmem code.
>
> On profiling clear_huge_page() using ftrace a
On Mon, Mar 22, 2021 at 09:05:43AM -0700, Sean Christopherson wrote:
> On Sun, Mar 21, 2021, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > PKey faults may now happen on kernel mappings if the feature is enabled.
> > Remove the warning in the fault path if PK
Jan,
Why does ext2_set_link() need to call ext2_put_page()?
I don't see any reason that we could not match up the ext2_put_page() calls
with the ext2_find_entry().
Similarly am I missing something by moving the ext2_put_page() out of
ext2_delete_entry()?
See below patch.
I'm in the process of
On Mon, Mar 22, 2021 at 06:00:40PM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./tools/testing/nvdimm/test/ndtest.c:491:2-7: WARNING: NULL check before
> some freeing functions is not needed.
I don't think there is anything wrong with this patch specifically but why
From: Ira Weiny
kmap is inefficient and is being replaced by kmap_local_page(), if
possible.
That said, there is no readily apparent reason why initp_page needs to
be allocated and kmap'ed() except that 'sigstruct' needs to be page
aligned and 'token' 512 byte aligned.
Rather than change
On Wed, Mar 24, 2021 at 03:16:35PM +0100, Robert Richter wrote:
> Typically the mem_commands[] array is in sync with 'enum { CXL_CMDS }'.
> Current code works well.
>
> However, the array size of mem_commands[] may not strictly be the same
> as CXL_MEM_COMMAND_ID_MAX. E.g. if a new CXL_CMD() is
701 - 800 of 968 matches
Mail list logo
