Am 30.04.20 um 22:38 schrieb ira.we...@intel.com:
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
Ah, yes looking into this once more this was on my TODO list for quit
On Thu, Apr 30, 2020 at 01:38:36PM -0700, ira.we...@intel.com wrote:
> 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
On Thu, Apr 30, 2020 at 01:38:37PM -0700, ira.we...@intel.com wrote:
> @@ -88,6 +88,11 @@ void __init kmap_init(void)
> {
> unsigned long kmap_vstart;
>
> + /* Check if this memory layout is broken because PKMAP overlaps
> + * page table.
> + */
> + BUILD_BUG_ON(PKMAP_BAS
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Thu, Apr 30, 2020 at 01:38:39PM -0700, ira.we...@intel.com wrote:
> 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
> archi
On Thu, Apr 30, 2020 at 01:38:40PM -0700, ira.we...@intel.com wrote:
> 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_hig
On Thu, Apr 30, 2020 at 01:38:41PM -0700, ira.we...@intel.com wrote:
> 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_at
> --- 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 there is just
a single assignment to it.
If sparc is sorted out we can always make it a
On Thu, Apr 30, 2020 at 01:38:43PM -0700, ira.we...@intel.com wrote:
> 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 c
On Thu, Apr 30, 2020 at 01:38:44PM -0700, ira.we...@intel.com wrote:
> 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_h
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
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.
Also kmap_atomic_high_prot / kmap_atomic_pfn could move into common
code, maybe keyed off a symbol selected by the actual users that
need it. It also seem
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_
14 matches
Mail list logo
