the
number of pages to flush.
Signed-off-by: Matthew Wilcox (Oracle)
Acked-by: Mike Rapoport (IBM)
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
---
arch/arc/include/asm/cacheflush.h | 7 ++-
arch/arc/include/asm/pgtable-bits-arcv2.h | 12 ++---
arch/arc/include/asm/pgtable
the
number of pages to flush.
Signed-off-by: Matthew Wilcox (Oracle)
Acked-by: Mike Rapoport (IBM)
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
---
arch/arc/include/asm/cacheflush.h | 7 ++-
arch/arc/include/asm/pgtable-bits-arcv2.h | 12 ++---
arch/arc/include/asm/pgtable
the
number of pages to flush.
Signed-off-by: Matthew Wilcox (Oracle)
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
---
arch/arc/include/asm/cacheflush.h | 7 ++-
arch/arc/include/asm/pgtable-bits-arcv2.h | 11 ++--
arch/arc/include/asm/pgtable-levels.h | 1 +
arch/arc/mm
the
number of pages to flush.
Signed-off-by: Matthew Wilcox (Oracle)
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
---
arch/arc/include/asm/cacheflush.h | 7 ++-
arch/arc/include/asm/pgtable-bits-arcv2.h | 20 ++--
arch/arc/mm/cache.c | 61
On Mon, Feb 27, 2023 at 10:34:05PM -0800, Vineet Gupta wrote:
> You need to split ARC and ARM into separate patches.
Ugh. Looks like I inadvertently squashed them together during a rebase.
c228f5b4e007 HEAD@{121}: rebase (reword): arm64: Implement the new page table ra
nge API
22744c8ae873
the
number of pages to flush.
Signed-off-by: Matthew Wilcox (Oracle)
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
---
arch/arc/include/asm/cacheflush.h | 7 +-
arch/arc/include/asm/pgtable-bits-arcv2.h | 20 +++--
arch/arc/mm/cache.c | 61
On Wed, Feb 15, 2023 at 08:59:18PM -0800, Vineet Gupta wrote:
> On 2/10/23 09:06, Matthew Wilcox wrote:
> > I see a discrepancy here ...
> >
> > arch/arc/include/asm/shmparam.h:
> > /* Handle upto 2 cache bins */
> > #define SHMLBA (2 * PAGE_SIZE)
> >
I see a discrepancy here ...
arch/arc/include/asm/shmparam.h:
/* Handle upto 2 cache bins */
#define SHMLBA (2 * PAGE_SIZE)
arch/arc/include/asm/cacheflush.h:
#define CACHE_COLORS_NUM4
(there are some other problems with the arc cache flushing code; I'm
working on patches to address
On Tue, Apr 20, 2021 at 09:39:54AM +0200, Geert Uytterhoeven wrote:
> > +++ b/include/linux/mm_types.h
> > @@ -97,10 +97,10 @@ struct page {
> > };
> > struct {/* page_pool used by netstack */
> > /**
> > -*
On Tue, Apr 20, 2021 at 02:48:17AM +, Vineet Gupta wrote:
> > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> > page inadvertently expanded in 2019.
>
> FWIW, ARC doesn't require 8 byte alignment
On Sat, Apr 17, 2021 at 09:18:57PM +, David Laight wrote:
> Ugly as well.
Thank you for expressing your opinion. Again.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Sat, Apr 17, 2021 at 09:13:45PM +, David Laight wrote:
> > struct {/* page_pool used by netstack */
> > - /**
> > -* @dma_addr: might require a 64-bit value on
> > -* 32-bit architectures.
> > -
Replacement patch to fix compiler warning.
From: "Matthew Wilcox (Oracle)"
Date: Fri, 16 Apr 2021 16:34:55 -0400
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
To: bro...@redhat.com
Cc: linux-ker...@vger.kernel.org,
linux...@kvack.org,
net...@vger.
loc().
Since page_pool doesn't want to set its magic value on pages which are
pfmemalloc, we can use bit 1 of compound_head to indicate that the page
came from the memory reserves.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/mm.h | 12 +++-
include/linux/mm_types.h |
get_user_pages_fast()
could dereference a bogus compound_head().
Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/mm_types.h | 4 ++--
include/net/page_pool.h | 12 +++-
net/core/page_pool.c | 12 +++
functionality. It is much less urgent.
I'd really like to see Mel & Michal's thoughts on it.
I have only compile-tested these patches.
Matthew Wilcox (Oracle) (2):
mm: Fix struct page layout on 32-bit systems
mm: Indicate pfmemalloc pages in compound_head
include/linux/mm.h
On Mon, Jan 04, 2021 at 12:13:02PM -0800, Dan Williams wrote:
> On Thu, Dec 31, 2020 at 8:29 PM Randy Dunlap wrote:
> > +++ lnx-511-rc1/fs/dax.c
> > @@ -25,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> I would expect this to come from one of the linux/ includes like
On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote:
> This series provides kmap_local.* iomap_local variants which only disable
> migration to keep the virtual mapping address stable accross preemption,
> but do neither disable pagefaults nor preemption. The new functions can be
>
On Sat, Sep 19, 2020 at 10:18:54AM -0700, Linus Torvalds wrote:
> On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
> >
> > this provides a preemptible variant of kmap_atomic & related
> > interfaces. This is achieved by:
>
> Ack. This looks really nice, even apart from the new capability.
If your arch does not support HAVE_ARCH_TRANSPARENT_HUGEPAGE, you can
stop reading now. Although maybe you're curious about adding support.
$ git grep -w HAVE_ARCH_TRANSPARENT_HUGEPAGE arch
arch/Kconfig:config HAVE_ARCH_TRANSPARENT_HUGEPAGE
arch/arc/Kconfig:config HAVE_ARCH_TRANSPARENT_HUGEPAGE
On Sat, Jun 27, 2020 at 05:34:49PM +0300, Mike Rapoport wrote:
> More elaborate versions on arm64 and x86 account memory for the user page
> tables and call to pgtable_pmd_page_ctor() as the part of PMD page
> initialization.
>
> Move the arm64 version to include/asm-generic/pgalloc.h and use the
it used to be so the inaccuracy is starting to matter.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/mm.h | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index dc7b87310c10..b283e25fcffa 100644
ctions where
> appropriate.
For the series:
Reviewed-by: Matthew Wilcox (Oracle)
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Tue, May 12, 2020 at 09:44:18PM +0300, Mike Rapoport wrote:
> +++ b/include/linux/pgtable.h
> @@ -28,6 +28,24 @@
> #define USER_PGTABLES_CEILING0UL
> #endif
>
> +/* FIXME: */
Fix you what? Add documentation?
> +static inline pmd_t *pmd_off(struct mm_struct *mm, unsigned long va)
On Tue, May 12, 2020 at 09:44:13PM +0300, Mike Rapoport wrote:
> diff --git a/arch/alpha/kernel/proto.h b/arch/alpha/kernel/proto.h
> index a093cd45ec79..701a05090141 100644
> --- a/arch/alpha/kernel/proto.h
> +++ b/arch/alpha/kernel/proto.h
> @@ -2,8 +2,6 @@
> #include
> #include
>
>
On Mon, Oct 14, 2019 at 01:38:34PM -0700, Linus Torvalds wrote:
> And now I've said pgd/pud/p4d/pmd so many times that I've confused
> myself and think I'm wrong again, and I think that historically -
> originally - we always had a pgd, and then the pmd didn't exist
> because it was folded into
On Mon, Aug 26, 2019 at 08:07:13AM +0530, Anshuman Khandual wrote:
> On 08/09/2019 07:22 PM, Matthew Wilcox wrote:
> > On Fri, Aug 09, 2019 at 04:05:07PM +0530, Anshuman Khandual wrote:
> >> On 08/09/2019 03:46 PM, Matthew Wilcox wrote:
> >>> On Fri, Aug 09, 2019
On Fri, Aug 09, 2019 at 04:05:07PM +0530, Anshuman Khandual wrote:
> On 08/09/2019 03:46 PM, Matthew Wilcox wrote:
> > On Fri, Aug 09, 2019 at 01:03:17PM +0530, Anshuman Khandual wrote:
> >> Should alloc_gigantic_page() be made available as an interface for general
> >>
On Fri, Aug 09, 2019 at 01:03:17PM +0530, Anshuman Khandual wrote:
> Should alloc_gigantic_page() be made available as an interface for general
> use in the kernel. The test module here uses very similar implementation from
> HugeTLB to allocate a PUD aligned memory block. Similar for mm_alloc()
On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote:
> arch/powerpc/include/asm/pte-common.h | 3 ---
> arch/riscv/Kconfig | 1 +
> arch/s390/Kconfig | 1 +
You forgot to delete
On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > > Current implementation doesn't randomize address returned by mmap.
> >
On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR
On Mon, Mar 13, 2017 at 03:14:13PM -0700, Till Smejkal wrote:
> +/**
> + * Create a new VAS segment.
> + *
> + * @param[in] name: The name of the new VAS segment.
> + * @param[in] start: The address where the VAS segment begins.
> + * @param[in] end: The address where
33 matches
Mail list logo
