On Tue, Feb 19, 2019 at 09:30:33PM -0800, 'Ira Weiny' wrote:
> 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 the
From: Ira Weiny
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 held for a significant time. But
get_user_pages_fast() does not protect against mapping FS DAX pages.
Introduce FOLL_LONGTERM
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 is in
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
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
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 | 29
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/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
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
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 he
On Fri, Mar 22, 2019 at 02:24:40PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > Rather than have a separate get_user_pages_longterm() call,
> > introduce FOLL_LONGTERM and change the longterm callers to us
On Fri, Mar 22, 2019 at 03:05:53PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > To facilitate additional options to get_user_pages_fast() change the
> > singular write parameter to be gup_flags.
>
On Fri, Mar 22, 2019 at 03:12:55PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > DAX pages were previously unprotected from longterm pins when users
> > called get_user_pages_fast().
> >
> > Use t
On Fri, Mar 22, 2019 at 03:14:26PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
> > FS DAX pages being mapped.
> >
> > S
On Mon, Mar 25, 2019 at 09:45:12AM -0700, Dan Williams wrote:
> On Mon, Mar 25, 2019 at 7:21 AM Ira Weiny wrote:
> [..]
> > > > @@ -1268,10 +1246,14 @@ static long
> > > > check_and_migrate_cma_pages(unsi
On Mon, Mar 25, 2019 at 01:47:13PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 25, 2019 at 01:42:26AM -0700, Ira Weiny wrote:
> > On Fri, Mar 22, 2019 at 03:12:55PM -0700, Dan Williams wrote:
> > > On Sun, Mar 17, 2019 at 7:36 PM wrote:
> > > >
> > > >
On Fri, Mar 22, 2019 at 02:24:40PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
[snip]
> > + * __gup_longterm_locked() is a wrapper for __get_uer_pages_locked which
>
> s/uer/user/
>
> > + * allows us to process the FOLL_LONGTERM flag if present.
> > + *
> > + * FOLL_LON
On Mon, Mar 25, 2019 at 02:51:50PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 25, 2019 at 02:23:15AM -0700, Ira Weiny wrote:
> > > > Unfortunately holding the lock is required to support FOLL_LONGTERM (to
> > > > check
> > > > the VMAs) but we do
On Mon, Mar 25, 2019 at 03:36:28PM -0700, Dan Williams wrote:
> On Mon, Mar 25, 2019 at 3:22 PM Ira Weiny wrote:
> [..]
> > FWIW this thread is making me think my original patch which simply
> > implemented
> > get_user_pages_fast_longterm() would be more clear. There i
From: Ira Weiny
This patch 1 of 7, starts a series which aims to support
FOLL_LONGTERM in get_user_pages_fast(). Some callers who would
like to do a longterm (user controlled pin) of pages with
the fast variant of GUP for performance purposes.
Rather than have a separate
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.
Reviewed-by: Dan Williams
Signed-off-by: Ira Weiny
From: Ira Weiny
Following discussion and review[1] here are the cleanups requested.
The biggest change for V3 was the disabling of the ability to use FOLL_LONGTERM
in get_user_pages[unlocked|locked|remote]
Comments were also enhanced throughout to show potential users what
FOLL_LONGTERM is all
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
---
Changes from V2
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
---
Changes from V2
Per Dan Williams: set FOLL_LONGTERM on declaration line
drivers/infiniband/hw/hfi1/user_pages.c | 4 ++--
1 file changed, 2
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.
Reviewed-by: Dan Williams
Signed-off-by: Ira Weiny
---
Changes from V2:
added reviewed-by
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
1 file changed, 1 insertion
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
---
Changes from V2:
drivers/infiniband/hw/mthca/mthca_memfree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers
On Thu, Mar 28, 2019 at 01:44:15AM -0700, 'Ira Weiny' wrote:
> From: Ira Weiny
>
> Following discussion and review[1] here are the cleanups requested.
>
> The biggest change for V3 was the disabling of the ability to use
> FOLL_LONGTERM
> in get_user_pages[unlock
the real situation is clearer.
>
> Signed-off-by: Robin Murphy
Reviewed-by: Ira Weiny
> ---
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 -
> arch/x86/Kconfig | 2 +-
> arch/x86/inclu
tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
Thanks Stephen
Looks good for my changes.
Acked-by: Ira Weiny
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
&
> diff --git a/arch/powerpc/lib/pmem.c b/arch/powerpc/lib/pmem.c
> index 377712e85605..2e661a08dae5 100644
> --- a/arch/powerpc/lib/pmem.c
> +++ b/arch/powerpc/lib/pmem.c
> @@ -17,14 +17,31 @@ void arch_wb_cache_pmem(void *addr, size_t size)
> unsigned long start = (unsigned long) addr;
>
On Wed, Oct 30, 2019 at 03:49:12PM -0700, John Hubbard wrote:
> A subsequent patch requires access to gup flags, so
> pass the flags argument through to the __gup_device_*
> functions.
>
> Also placate checkpatch.pl by shortening a nearby line.
>
Reviewed-by: Ira Wein
On Wed, Oct 30, 2019 at 03:49:13PM -0700, John Hubbard wrote:
> There are four locations in gup.c that have a fair amount of code
> duplication. This means that changing one requires making the same
> changes in four places, not to mention reading the same code four
> times, and wondering if there
On Wed, Oct 30, 2019 at 03:49:14PM -0700, John Hubbard wrote:
> 1. Avoid naming conflicts: rename local static function from
> "pin_user_pages()" to "pin_goldfish_pages()".
>
> An upcoming patch will introduce a global pin_user_pages()
> function.
>
Re
On Thu, Oct 31, 2019 at 11:43:37AM -0700, John Hubbard wrote:
> On 10/31/19 11:35 AM, Ira Weiny wrote:
> > On Wed, Oct 30, 2019 at 03:49:13PM -0700, John Hubbard wrote:
> ...
> >> +
> >> +static void __remove_refs_from_head(struct page *page, int refs)
> >>
On Wed, Oct 30, 2019 at 03:49:16PM -0700, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> basically documented. (An upcoming patch provides mor
ink we are going to need a lot more documentation on which flags are
"user" accessible vs not...
Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
> ---
> drivers/infiniband/core/umem.c | 5 ++---
> drivers/infiniband/core/umem_odp.c | 10 +
a put_user_page*().
>
> Also, rename "pages" to "pinned_pages", as this makes for
> easier reading of process_vm_rw_single_vec().
Ok... but it made review a bit harder...
Reviewed-by: Ira Weiny
>
> Signed-off-by: John Hubbard
> ---
> mm/process_vm_access.c
ut_user_page().
>
Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
> ---
> drivers/gpu/drm/via/via_dmablit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/via/via_dmablit.c
> b/drivers/gpu/drm/via/via_dmablit.c
> index 3db000aacd26..
>
Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
> ---
> fs/io_uring.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index a30c4f622cb3..d3924b1760eb 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_
On Wed, Oct 30, 2019 at 03:49:22PM -0700, John Hubbard wrote:
> Convert net/xdp to use the new pin_longterm_pages() call, which sets
> FOLL_PIN. Setting FOLL_PIN is now required for code that requires
> tracking of pinned pages.
>
Reviewed-by: Ira Weiny
> Signed-off-b
rt the put_page() call over to
> put_user_pages_dirty_lock().
>
Reviewed-by: Ira Weiny
> Cc: Mauro Carvalho Chehab
> Signed-off-by: John Hubbard
> ---
> drivers/media/v4l2-core/videobuf-dma-sg.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
On Wed, Oct 30, 2019 at 03:49:30PM -0700, John Hubbard wrote:
> Document the new pin_user_pages() and related calls
> and behavior.
>
> Thanks to Jan Kara and Vlastimil Babka for explaining the 4 cases
> in this documentation. (I've reworded it and expanded on it slightly.)
As I said before I thi
>
>
> ...
> >> +This document describes the following functions: ::
> >> +
> >> + pin_user_pages
> >> + pin_user_pages_fast
> >> + pin_user_pages_remote
> >> +
> >> + pin_longterm_pages
> >> + pin_longterm_pages_fast
> >> + pin_longterm_pages_remote
> >> +
> >> +Basic description of FOLL_PIN
> >>
On Mon, Nov 04, 2019 at 04:57:38PM -0400, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2019 at 12:48:13PM -0800, John Hubbard wrote:
> > On 11/4/19 12:33 PM, Jason Gunthorpe wrote:
> > ...
> > >> diff --git a/drivers/infiniband/core/umem.c
> > >> b/drivers/infiniband/core/umem.c
> > >> index 24244a2f6
> > +/**
> > + * pin_user_pages_fast() - pin user pages in memory without taking locks
> > + *
> > + * Nearly the same as get_user_pages_fast(), except that FOLL_PIN is set.
> > See
> > + * get_user_pages_fast() for documentation on the function arguments,
> > because
> > + * the arguments here a
On Tue, Nov 12, 2019 at 08:26:50PM -0800, John Hubbard wrote:
> An upcoming patch uses try_get_compound_head() more widely,
> so move it to the top of gup.c.
>
> Also fix a tiny spelling error and a checkpatch.pl warning.
>
> Signed-off-by: John Hubbard
Simple enough...
Revi
, which in turn
> calls check_dax_vmas(). It's lightly explained in the comments as well.
>
> Thanks to Jason Gunthorpe for pointing out a clean way to fix this,
> and to Dan Williams for helping clarify the DAX refactoring.
>
> Suggested-by: Jason Gunthorpe
> Cc: Dan William
On Tue, Nov 12, 2019 at 08:26:56PM -0800, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> thoroughly documented.
>
> The pin_longterm*() varia
user_pages*() calls. This
> makes it harder to overlook, instead of having little "gup_flags & 1"
> phrases in the function calls.
>
> Signed-off-by: John Hubbard
Reviewed-by: Ira Weiny
> ---
> mm/gup_benchmark.c | 9 ++---
> tool
things being equal.
>
> Signed-off-by: John Hubbard
Reviewed-by: Ira Weiny
> ---
> tools/testing/selftests/vm/run_vmtests | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/tools/testing/selftests/vm/run_vmtests
> b/tools/testing/
On Tue, Nov 12, 2019 at 08:27:10PM -0800, John Hubbard wrote:
> Now that all other kernel callers of get_user_pages(FOLL_LONGTERM)
> have been converted to pin_longterm_pages(), lock it down:
>
> 1) Add an assertion to get_user_pages(), preventing callers from
>passing FOLL_LONGTERM (in additi
put_user_pages(),
> check each page: if page_dma_pinned() returns false, then
> WARN and return.
>
> Do this outside of the benchmark timestamps, so that it doesn't
> affect reported times.
>
> Signed-off-by: John Hubbard
Reviewed-by: Ira Weiny
> ---
> mm
to Jason Gunthorpe for pointing out a clean way to fix this,
> > and to Dan Williams for helping clarify the DAX refactoring.
> >
> > Suggested-by: Jason Gunthorpe
> > Cc: Dan Williams
> > Cc: Jerome Glisse
> > Cc: Ira Weiny
> > Signed-off-by: John Hub
, which in turn
> calls check_dax_vmas(). It's lightly explained in the comments as well.
>
> Thanks to Jason Gunthorpe for pointing out a clean way to fix this,
> and to Dan Williams for helping clarify the DAX refactoring.
>
> Suggested-by: Jason Gunthorpe
> Cc: Dan William
From: Ira Weiny
The kmap infrastructure has been copied almost verbatim to every architecture.
This series consolidates obvious duplicated code. (k[un]map_atmoic has some
additional duplication between some of the architectures but the differences
were such to not warrant further changes
From: Ira Weiny
All architectures do exactly the same thing for kunmap(); remove all the
duplicate definitions and lift the call to the core.
Reviewed-by: Dan Williams
Signed-off-by: Ira Weiny
---
arch/arc/include/asm/highmem.h| 9 -
arch/arm/include/asm/highmem.h
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
Signed-off-by: Ira
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.
Reviewed-by: Dan Williams
Signed-off-by: Ira Weiny
---
arch/arc
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 to indicate if an
arch needs a special kmap.
This also has the benefit of changing kmap() on a number of
architectures to be an inline call rather than an
From: Ira Weiny
Every arch has the same check for a not HIGHMEM page. Define
kmap_atomic_fast() to quickly return already mapped pages and reduce the
code duplication by lifting this check to the core.
Reviewed-by: Dan Williams
Signed-off-by: Ira Weiny
---
arch/arc/mm/highmem.c| 7
On Sun, Apr 26, 2020 at 12:17:15AM -0700, Christoph Hellwig wrote:
> On Sat, Apr 25, 2020 at 10:54:03PM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The kmap code for all the architectures is almost 100% identical.
> >
> > Lift the common code t
On Sun, Apr 26, 2020 at 12:26:42AM -0700, Christoph Hellwig wrote:
> > diff --git a/arch/arc/mm/highmem.c b/arch/arc/mm/highmem.c
> > index 4db13a6b9f3b..1cae4b911a33 100644
> > --- a/arch/arc/mm/highmem.c
> > +++ b/arch/arc/mm/highmem.c
> > @@ -53,11 +53,10 @@ void *kmap_atomic(struct page *page)
From: Ira Weiny
The kmap infrastructure has been copied almost verbatim to every architecture.
This series consolidates obvious duplicated code by defining core functions
which call into the architectures only when needed.
Some of the k[un]map_atomic() implementations have some similarities but
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
Signed-off-by: Ira
From: Ira Weiny
Move the kmap() build bug to kmap_init() to facilitate patches to lift
kmap() to the core.
Signed-off-by: Ira Weiny
---
arch/xtensa/include/asm/highmem.h | 5 -
arch/xtensa/mm/highmem.c | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch
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 V0
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.
Signed-off-by: Ira
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
To support kmap_atomic_prot(), all architectures need to support
protections passed to their kmap_atomic_high() function. Pass
protections into kmap_atomic_high() and change the name to
kmap_atomic_high_prot() to match.
Then define kmap_atomic_prot() as a core function which
From: Ira Weiny
kmap_atomic_prot() is now exported by all architectures. Use this
function rather than open coding a driver specific kmap_atomic.
Signed-off-by: Ira Weiny
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 56 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 16
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
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 kmap_prot value
rather than a hard coded value which was equal.
Signed-off-by: Ira Weiny
---
arch/csky/mm/highmem.c
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
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
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
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(), all architectures need to support
protections passed to their kmap_atomic_high() function. Pass
protections into kmap_atomic_high() and change the name to
kmap_atomic_high_prot() to match.
Then define kmap_atomic_prot() as a core function which
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
kmap_atomic_prot() is now exported by all architectures. Use this
function rather than open coding a driver specific kmap_atomic.
Reviewed-by: Christian König
Reviewed-by: Christoph Hellwig
Signed-off-by: Ira Weiny
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 56
From: Ira Weiny
The kmap infrastructure has been copied almost verbatim to every architecture.
This series consolidates obvious duplicated code by defining core functions
which call into the architectures only when needed.
Some of the k[un]map_atomic() implementations have some similarities but
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
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
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
Move the kmap() build bug to kmap_init() to facilitate patches to lift
kmap() to the core.
Reviewed-by: Christoph Hellwig
Signed-off-by: Ira Weiny
---
Changes from V1:
combine code onto 1 line.
---
arch/xtensa/include/asm/highmem.h | 5 -
arch/xtensa/mm/highmem.c
On Mon, May 04, 2020 at 02:35:09AM +0100, Al Viro wrote:
> On Sun, May 03, 2020 at 06:09:01PM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The kmap infrastructure has been copied almost verbatim to every
> > architecture.
> > This series consol
On Mon, May 04, 2020 at 06:33:57AM +0100, Al Viro wrote:
> On Sun, May 03, 2020 at 10:04:47PM -0700, Ira Weiny wrote:
>
> > Grepping for 'asm/highmem.h' and investigations don't reveal any issues...
> > But
> > you do have me worried. That said 0-day has
On Mon, May 04, 2020 at 01:18:51PM +0200, Daniel Vetter wrote:
> On Mon, May 4, 2020 at 3:09 AM wrote:
> >
> > From: Ira Weiny
> >
> > kmap_atomic_prot() is now exported by all architectures. Use this
> > function rather than open coding a driver specific
On Mon, May 04, 2020 at 10:02:25PM +0100, Al Viro wrote:
> On Mon, May 04, 2020 at 01:17:41PM -0700, Ira Weiny wrote:
>
> > > || * arm: much, much worse. We have several files that pull
> > > linux/highmem.h:
> > > || arch/arm/mm/cache-feroceon-l2.c, arch/arm
On Tue, May 05, 2020 at 11:11:13PM -0700, Christoph Hellwig wrote:
> On Sun, May 03, 2020 at 06:09:06PM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > During this kmap() conversion series we must maintain bisect-ability.
> > To do this, kmap_atomic_
On Tue, May 05, 2020 at 11:13:26PM -0700, Christoph Hellwig wrote:
> On Sun, May 03, 2020 at 06:09:09PM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > We want to support kmap_atomic_prot() on all architectures and it makes
> > sense to define kmap_
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
The kmap infrastructure has been copied almost verbatim to every architecture.
This series consolidates obvious duplicated code by defining core functions
which call into the architectures only when needed.
Some of the k[un]map_atomic() implementations have some similarities but
From: Ira Weiny
Move the kmap() build bug to kmap_init() to facilitate patches to lift
kmap() to the core.
Reviewed-by: Christoph Hellwig
Signed-off-by: Ira Weiny
---
Changes from V1:
combine code onto 1 line.
---
arch/xtensa/include/asm/highmem.h | 5 -
arch/xtensa/mm/highmem.c
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
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
1 - 100 of 294 matches
Mail list logo
