Re: [PATCH v2 06/30] arc: Implement the new page table range API

2023-02-27 Thread Vineet Gupta




On 2/27/23 09:57, Matthew Wilcox (Oracle) wrote:

Add set_ptes(), update_mmu_cache_range(), flush_dcache_folio()
and flush_icache_pages().

Change the PG_dc_clean flag from being per-page to per-folio (which
means it cannot always be set as we don't know that all pages in this
folio were cleaned).  Enhance the internal flush routines to take 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 --
  arch/arc/mm/tlb.c | 18 +++--


You need to split ARC and ARM into separate patches.

Also it'd be best to drop all the VIPT aliasing bits for ARC, they are a 
needless maintenance burden.

I can send a patch which you could carry in your tree for easier logistics.

-Vineet


  arch/arm/include/asm/cacheflush.h | 24 +++---
  arch/arm/include/asm/pgtable.h|  5 +-
  arch/arm/include/asm/tlbflush.h   | 13 +--
  arch/arm/mm/copypage-v4mc.c   |  5 +-
  arch/arm/mm/copypage-v6.c |  5 +-
  arch/arm/mm/copypage-xscale.c |  5 +-
  arch/arm/mm/dma-mapping.c | 24 +++---
  arch/arm/mm/fault-armv.c  | 14 ++--
  arch/arm/mm/flush.c   | 99 ++-
  arch/arm/mm/mm.h  |  2 +-
  arch/arm/mm/mmu.c | 14 +++-
  15 files changed, 193 insertions(+), 123 deletions(-)

diff --git a/arch/arc/include/asm/cacheflush.h 
b/arch/arc/include/asm/cacheflush.h
index e201b4b1655a..04f65f588510 100644
--- a/arch/arc/include/asm/cacheflush.h
+++ b/arch/arc/include/asm/cacheflush.h
@@ -25,17 +25,20 @@
   * in update_mmu_cache()
   */
  #define flush_icache_page(vma, page)
+#define flush_icache_pages(vma, page, nr)
  
  void flush_cache_all(void);
  
  void flush_icache_range(unsigned long kstart, unsigned long kend);

  void __sync_icache_dcache(phys_addr_t paddr, unsigned long vaddr, int len);
-void __inv_icache_page(phys_addr_t paddr, unsigned long vaddr);
-void __flush_dcache_page(phys_addr_t paddr, unsigned long vaddr);
+void __inv_icache_pages(phys_addr_t paddr, unsigned long vaddr, unsigned nr);
+void __flush_dcache_pages(phys_addr_t paddr, unsigned long vaddr, unsigned nr);
  
  #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
  
  void flush_dcache_page(struct page *page);

+void flush_dcache_folio(struct folio *folio);
+#define flush_dcache_folio flush_dcache_folio
  
  void dma_cache_wback_inv(phys_addr_t start, unsigned long sz);

  void dma_cache_inv(phys_addr_t start, unsigned long sz);
diff --git a/arch/arc/include/asm/pgtable-bits-arcv2.h 
b/arch/arc/include/asm/pgtable-bits-arcv2.h
index 6e9f8ca6d6a1..4a1b2ce204c6 100644
--- a/arch/arc/include/asm/pgtable-bits-arcv2.h
+++ b/arch/arc/include/asm/pgtable-bits-arcv2.h
@@ -100,14 +100,24 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t 
newprot)
return __pte((pte_val(pte) & _PAGE_CHG_MASK) | pgprot_val(newprot));
  }
  
-static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,

- pte_t *ptep, pte_t pteval)
+static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
+   pte_t *ptep, pte_t pte, unsigned int nr)
  {
-   set_pte(ptep, pteval);
+   for (;;) {
+   set_pte(ptep, pte);
+   if (--nr == 0)
+   break;
+   ptep++;
+   pte_val(pte) += PAGE_SIZE;
+   }
  }
+#define set_pte_at(mm, addr, ptep, pte) set_ptes(mm, addr, ptep, pte, 1)
  
-void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,

- pte_t *ptep);
+void update_mmu_cache_range(struct vm_area_struct *vma, unsigned long address,
+ pte_t *ptep, unsigned int nr);
+
+#define update_mmu_cache(vma, addr, ptep) \
+   update_mmu_cache_range(vma, addr, ptep, 1)
  
  /*

   * Encode/decode swap entries and swap PTEs. Swap PTEs are all PTEs that
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 55c6de138eae..3c16ee942a5c 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -752,17 +752,17 @@ static inline void arc_slc_enable(void)
   * There's a corollary case, where kernel READs from a userspace mapped page.
   * If the U-mapping is not congruent to K-mapping, former needs flushing.
   */
-void flush_dcache_page(struct page *page)
+void flush_dcache_folio(struct folio *folio)
  {
struct address_space *mapping;
  
  	if (!cache_is_vipt_aliasing()) {

-   clear_bit(PG_dc_clean, >flags);
+   clear_bit(PG_dc_clean, >flags);
return;
}
  
  	/* don't handle anon pages here */

-   mapping = page_mapping_file(page);
+   mapping = folio_flush_mapping(folio);
if (!mapping)
return;

[PATCH v7 13/41] mm: Make pte_mkwrite() take a VMA

2023-02-27 Thread Rick Edgecombe
The x86 Control-flow Enforcement Technology (CET) feature includes a new
type of memory called shadow stack. This shadow stack memory has some
unusual properties, which requires some core mm changes to function
properly.

One of these unusual properties is that shadow stack memory is writable,
but only in limited ways. These limits are applied via a specific PTE
bit combination. Nevertheless, the memory is writable, and core mm code
will need to apply the writable permissions in the typical paths that
call pte_mkwrite().

In addition to VM_WRITE, the shadow stack VMA's will have a flag denoting
that they are special shadow stack flavor of writable memory. So make
pte_mkwrite() take a VMA, so that the x86 implementation of it can know to
create regular writable memory or shadow stack memory.

Apply the same changes for pmd_mkwrite() and huge_pte_mkwrite().

No functional change.

Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-al...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-c...@vger.kernel.org
Cc: linux-hexa...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: loonga...@lists.linux.dev
Cc: linux-m...@lists.linux-m68k.org
Cc: Michal Simek 
Cc: Dinh Nguyen 
Cc: linux-m...@vger.kernel.org
Cc: linux-openr...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux...@lists.infradead.org
Cc: xen-de...@lists.xenproject.org
Cc: linux-a...@vger.kernel.org
Cc: linux...@kvack.org
Tested-by: Pengfei Xu 
Tested-by: John Allen 
Tested-by: Kees Cook 
Acked-by: Mike Rapoport (IBM) 
Acked-by: Michael Ellerman 
Acked-by: David Hildenbrand 
Reviewed-by: Kees Cook 
Suggested-by: David Hildenbrand 
Signed-off-by: Rick Edgecombe 

---
Hi Non-x86 Arch’s,

x86 has a feature that allows for the creation of a special type of
writable memory (shadow stack) that is only writable in limited specific
ways. Previously, changes were proposed to core MM code to teach it to
decide when to create normally writable memory or the special shadow stack
writable memory, but David Hildenbrand suggested[0] to change
pXX_mkwrite() to take a VMA, so awareness of shadow stack memory can be
moved into x86 code.

Since pXX_mkwrite() is defined in every arch, it requires some tree-wide
changes. So that is why you are seeing some patches out of a big x86
series pop up in your arch mailing list. There is no functional change.
After this refactor, the shadow stack series goes on to use the arch
helpers to push shadow stack memory details inside arch/x86.

Testing was just 0-day build testing.

Hopefully that is enough context. Thanks!

[0] 
https://lore.kernel.org/lkml/0e29a2d0-08d8-bcd6-ff26-4bea0e403...@redhat.com/#t

v6:
 - New patch
---
 Documentation/mm/arch_pgtable_helpers.rst|  9 ++---
 arch/alpha/include/asm/pgtable.h |  6 +-
 arch/arc/include/asm/hugepage.h  |  2 +-
 arch/arc/include/asm/pgtable-bits-arcv2.h|  7 ++-
 arch/arm/include/asm/pgtable-3level.h|  7 ++-
 arch/arm/include/asm/pgtable.h   |  2 +-
 arch/arm64/include/asm/pgtable.h |  4 ++--
 arch/csky/include/asm/pgtable.h  |  2 +-
 arch/hexagon/include/asm/pgtable.h   |  2 +-
 arch/ia64/include/asm/pgtable.h  |  2 +-
 arch/loongarch/include/asm/pgtable.h |  4 ++--
 arch/m68k/include/asm/mcf_pgtable.h  |  2 +-
 arch/m68k/include/asm/motorola_pgtable.h |  6 +-
 arch/m68k/include/asm/sun3_pgtable.h |  6 +-
 arch/microblaze/include/asm/pgtable.h|  2 +-
 arch/mips/include/asm/pgtable.h  |  6 +++---
 arch/nios2/include/asm/pgtable.h |  2 +-
 arch/openrisc/include/asm/pgtable.h  |  2 +-
 arch/parisc/include/asm/pgtable.h|  6 +-
 arch/powerpc/include/asm/book3s/32/pgtable.h |  2 +-
 arch/powerpc/include/asm/book3s/64/pgtable.h |  4 ++--
 arch/powerpc/include/asm/nohash/32/pgtable.h |  2 +-
 arch/powerpc/include/asm/nohash/32/pte-8xx.h |  2 +-
 arch/powerpc/include/asm/nohash/64/pgtable.h |  2 +-
 arch/riscv/include/asm/pgtable.h |  6 +++---
 arch/s390/include/asm/hugetlb.h  |  4 ++--
 arch/s390/include/asm/pgtable.h  |  4 ++--
 arch/sh/include/asm/pgtable_32.h | 10 --
 arch/sparc/include/asm/pgtable_32.h  |  2 +-
 arch/sparc/include/asm/pgtable_64.h  |  6 +++---
 arch/um/include/asm/pgtable.h|  2 +-
 arch/x86/include/asm/pgtable.h   |  6 --
 arch/xtensa/include/asm/pgtable.h|  2 +-
 include/asm-generic/hugetlb.h|  4 ++--
 include/linux/mm.h   |  2 +-
 mm/debug_vm_pgtable.c| 16 
 mm/huge_memory.c |  6 +++---
 mm/hugetlb.c 

Re: [PATCH mm-unstable v1 11/26] microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-02-27 Thread Geert Uytterhoeven
Hi David,

On Mon, Feb 27, 2023 at 6:01 PM David Hildenbrand  wrote:
> /*
>  * Externally used page protection values.
>  diff --git a/arch/microblaze/include/asm/pgtable.h 
>  b/arch/microblaze/include/asm/pgtable.h
>  index 42f5988e998b..7e3de54bf426 100644
>  --- a/arch/microblaze/include/asm/pgtable.h
>  +++ b/arch/microblaze/include/asm/pgtable.h

>  * - All other bits of the PTE are loaded into TLBLO without
>  *  * modification, leaving us only the bits 20, 21, 24, 25, 26, 30 
>  for
>  * software PTE bits.  We actually use bits 21, 24, 25, and
>  @@ -155,6 +155,9 @@ extern pte_t *va_to_pte(unsigned long address);
> #define _PAGE_ACCESSED 0x400   /* software: R: page referenced */
> #define _PMD_PRESENT   PAGE_MASK
> 
>  +/* We borrow bit 24 to store the exclusive marker in swap PTEs. */
>  +#define _PAGE_SWP_EXCLUSIVE_PAGE_DIRTY
> >>>
> >>> _PAGE_DIRTY is 0x80, so this is also bit 7, thus the new comment is
> >>> wrong?
> >>
> >> In the example, I use MSB-0 bit numbering (which I determined to be
> >> correct in microblaze context eventually, but I got confused a couple a
> >> times because it's very inconsistent). That should be MSB-0 bit 24.
> >
> > Thanks, TIL microblaze uses IBM bit numbering...
>
> I assume IBM bit numbering corresponds to MSB-0 bit numbering, correct?

Correct, as seen in s370 and PowerPC manuals...

> I recall that I used the comment above "/* Definitions for MicroBlaze.
> */" as an orientation.
>
> 0  1  2  3  4  ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31
> RPN.  0  0 EX WR ZSEL...  W  I  M  G

Indeed, that's where I noticed the "unconventional" numbering...

> So ... either we adjust both or we leave it as is. (again, depends on
> what the right thing to to is -- which I don't know :) )

It depends whether you want to match the hardware documentation,
or the Linux BIT() macro and friends...

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


[PATCH v2 06/30] arc: Implement the new page table range API

2023-02-27 Thread Matthew Wilcox (Oracle)
Add set_ptes(), update_mmu_cache_range(), flush_dcache_folio()
and flush_icache_pages().

Change the PG_dc_clean flag from being per-page to per-folio (which
means it cannot always be set as we don't know that all pages in this
folio were cleaned).  Enhance the internal flush routines to take 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 --
 arch/arc/mm/tlb.c | 18 +++--
 arch/arm/include/asm/cacheflush.h | 24 +++---
 arch/arm/include/asm/pgtable.h|  5 +-
 arch/arm/include/asm/tlbflush.h   | 13 +--
 arch/arm/mm/copypage-v4mc.c   |  5 +-
 arch/arm/mm/copypage-v6.c |  5 +-
 arch/arm/mm/copypage-xscale.c |  5 +-
 arch/arm/mm/dma-mapping.c | 24 +++---
 arch/arm/mm/fault-armv.c  | 14 ++--
 arch/arm/mm/flush.c   | 99 ++-
 arch/arm/mm/mm.h  |  2 +-
 arch/arm/mm/mmu.c | 14 +++-
 15 files changed, 193 insertions(+), 123 deletions(-)

diff --git a/arch/arc/include/asm/cacheflush.h 
b/arch/arc/include/asm/cacheflush.h
index e201b4b1655a..04f65f588510 100644
--- a/arch/arc/include/asm/cacheflush.h
+++ b/arch/arc/include/asm/cacheflush.h
@@ -25,17 +25,20 @@
  * in update_mmu_cache()
  */
 #define flush_icache_page(vma, page)
+#define flush_icache_pages(vma, page, nr)
 
 void flush_cache_all(void);
 
 void flush_icache_range(unsigned long kstart, unsigned long kend);
 void __sync_icache_dcache(phys_addr_t paddr, unsigned long vaddr, int len);
-void __inv_icache_page(phys_addr_t paddr, unsigned long vaddr);
-void __flush_dcache_page(phys_addr_t paddr, unsigned long vaddr);
+void __inv_icache_pages(phys_addr_t paddr, unsigned long vaddr, unsigned nr);
+void __flush_dcache_pages(phys_addr_t paddr, unsigned long vaddr, unsigned nr);
 
 #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
 
 void flush_dcache_page(struct page *page);
+void flush_dcache_folio(struct folio *folio);
+#define flush_dcache_folio flush_dcache_folio
 
 void dma_cache_wback_inv(phys_addr_t start, unsigned long sz);
 void dma_cache_inv(phys_addr_t start, unsigned long sz);
diff --git a/arch/arc/include/asm/pgtable-bits-arcv2.h 
b/arch/arc/include/asm/pgtable-bits-arcv2.h
index 6e9f8ca6d6a1..4a1b2ce204c6 100644
--- a/arch/arc/include/asm/pgtable-bits-arcv2.h
+++ b/arch/arc/include/asm/pgtable-bits-arcv2.h
@@ -100,14 +100,24 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t 
newprot)
return __pte((pte_val(pte) & _PAGE_CHG_MASK) | pgprot_val(newprot));
 }
 
-static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
- pte_t *ptep, pte_t pteval)
+static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
+   pte_t *ptep, pte_t pte, unsigned int nr)
 {
-   set_pte(ptep, pteval);
+   for (;;) {
+   set_pte(ptep, pte);
+   if (--nr == 0)
+   break;
+   ptep++;
+   pte_val(pte) += PAGE_SIZE;
+   }
 }
+#define set_pte_at(mm, addr, ptep, pte) set_ptes(mm, addr, ptep, pte, 1)
 
-void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
- pte_t *ptep);
+void update_mmu_cache_range(struct vm_area_struct *vma, unsigned long address,
+ pte_t *ptep, unsigned int nr);
+
+#define update_mmu_cache(vma, addr, ptep) \
+   update_mmu_cache_range(vma, addr, ptep, 1)
 
 /*
  * Encode/decode swap entries and swap PTEs. Swap PTEs are all PTEs that
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 55c6de138eae..3c16ee942a5c 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -752,17 +752,17 @@ static inline void arc_slc_enable(void)
  * There's a corollary case, where kernel READs from a userspace mapped page.
  * If the U-mapping is not congruent to K-mapping, former needs flushing.
  */
-void flush_dcache_page(struct page *page)
+void flush_dcache_folio(struct folio *folio)
 {
struct address_space *mapping;
 
if (!cache_is_vipt_aliasing()) {
-   clear_bit(PG_dc_clean, >flags);
+   clear_bit(PG_dc_clean, >flags);
return;
}
 
/* don't handle anon pages here */
-   mapping = page_mapping_file(page);
+   mapping = folio_flush_mapping(folio);
if (!mapping)
return;
 
@@ -771,17 +771,27 @@ void flush_dcache_page(struct page *page)
 * Make a note that K-mapping is dirty
 */
if (!mapping_mapped(mapping)) {
-   clear_bit(PG_dc_clean, >flags);
-   } else if (page_mapcount(page)) {
-
+   clear_bit(PG_dc_clean, >flags);
+   } else if 

Re: [PATCH mm-unstable v1 11/26] microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-02-27 Thread David Hildenbrand

   /*
* Externally used page protection values.
diff --git a/arch/microblaze/include/asm/pgtable.h 
b/arch/microblaze/include/asm/pgtable.h
index 42f5988e998b..7e3de54bf426 100644
--- a/arch/microblaze/include/asm/pgtable.h
+++ b/arch/microblaze/include/asm/pgtable.h
@@ -131,10 +131,10 @@ extern pte_t *va_to_pte(unsigned long address);
* of the 16 available.  Bit 24-26 of the TLB are cleared in the TLB
* miss handler.  Bit 27 is PAGE_USER, thus selecting the correct
* zone.
- * - PRESENT *must* be in the bottom two bits because swap cache
- * entries use the top 30 bits.  Because 4xx doesn't support SMP
- * anyway, M is irrelevant so we borrow it for PAGE_PRESENT.  Bit 30
- * is cleared in the TLB miss handler before the TLB entry is loaded.
+ * - PRESENT *must* be in the bottom two bits because swap PTEs use the top
+ * 30 bits.  Because 4xx doesn't support SMP anyway, M is irrelevant so we
+ * borrow it for PAGE_PRESENT.  Bit 30 is cleared in the TLB miss handler
+ * before the TLB entry is loaded.


So the PowerPC 4xx comment is still here?


I only dropped the comment above __swp_type(). I guess you mean that we
could also drop the "Because 4xx doesn't support SMP anyway, M is
irrelevant so we borrow it for PAGE_PRESENT." sentence, correct? Not


Yes, that's what I meant.


sure about the "Bit 30 is cleared in the TLB miss handler" comment, if
that can similarly be dropped.


No idea, didn't check. But if it was copied from PPC, chances are
high it's no longer true


I'll have a look.




* - All other bits of the PTE are loaded into TLBLO without
*  * modification, leaving us only the bits 20, 21, 24, 25, 26, 30 for
* software PTE bits.  We actually use bits 21, 24, 25, and
@@ -155,6 +155,9 @@ extern pte_t *va_to_pte(unsigned long address);
   #define _PAGE_ACCESSED 0x400   /* software: R: page referenced */
   #define _PMD_PRESENT   PAGE_MASK

+/* We borrow bit 24 to store the exclusive marker in swap PTEs. */
+#define _PAGE_SWP_EXCLUSIVE_PAGE_DIRTY


_PAGE_DIRTY is 0x80, so this is also bit 7, thus the new comment is
wrong?


In the example, I use MSB-0 bit numbering (which I determined to be
correct in microblaze context eventually, but I got confused a couple a
times because it's very inconsistent). That should be MSB-0 bit 24.


Thanks, TIL microblaze uses IBM bit numbering...


I assume IBM bit numbering corresponds to MSB-0 bit numbering, correct?


I recall that I used the comment above "/* Definitions for MicroBlaze. 
*/" as an orientation.


0  1  2  3  4  ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31
RPN.  0  0 EX WR ZSEL...  W  I  M  G


So ... either we adjust both or we leave it as is. (again, depends on 
what the right thing to to is -- which I don't know :) )


--
Thanks,

David / dhildenb


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH mm-unstable v1 11/26] microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-02-27 Thread Geert Uytterhoeven
Hi David,

On Mon, Feb 27, 2023 at 2:31 PM David Hildenbrand  wrote:
> On 26.02.23 21:13, Geert Uytterhoeven wrote:
> > On Fri, Jan 13, 2023 at 6:16 PM David Hildenbrand  wrote:
> >> Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit
> >> from the type. Generic MM currently only uses 5 bits for the type
> >> (MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused.
> >>
> >> The shift by 2 when converting between PTE and arch-specific swap entry
> >> makes the swap PTE layout a little bit harder to decipher.
> >>
> >> While at it, drop the comment from paulus---copy-and-paste leftover
> >> from powerpc where we actually have _PAGE_HASHPTE---and mask the type in
> >> __swp_entry_to_pte() as well.
> >>
> >> Cc: Michal Simek 
> >> Signed-off-by: David Hildenbrand 
> >
> > Thanks for your patch, which is now commit b5c88f21531c3457
> > ("microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE") in
> >
>
> Right, it went upstream, so we can only fixup.
>
> >>   arch/m68k/include/asm/mcf_pgtable.h   |  4 +--
> >
> > What is this m68k change doing here?
> > Sorry for not noticing this earlier.
>
> Thanks for the late review, still valuable :)
>
> That hunk should have gone into the previous patch, looks like I messed
> that up when reworking.
>
> >
> > Furthermore, several things below look strange to me...
> >
> >>   arch/microblaze/include/asm/pgtable.h | 45 +--
> >>   2 files changed, 37 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/arch/m68k/include/asm/mcf_pgtable.h 
> >> b/arch/m68k/include/asm/mcf_pgtable.h
> >> index 3f8f4d0e66dd..e573d7b649f7 100644
> >> --- a/arch/m68k/include/asm/mcf_pgtable.h
> >> +++ b/arch/m68k/include/asm/mcf_pgtable.h
> >> @@ -46,8 +46,8 @@
> >>   #define _CACHEMASK040  (~0x060)
> >>   #define _PAGE_GLOBAL0400x400   /* 68040 global bit, used 
> >> for kva descs */
> >>
> >> -/* We borrow bit 7 to store the exclusive marker in swap PTEs. */
> >> -#define _PAGE_SWP_EXCLUSIVE0x080
> >> +/* We borrow bit 24 to store the exclusive marker in swap PTEs. */
> >> +#define _PAGE_SWP_EXCLUSIVECF_PAGE_NOCACHE
> >
> > CF_PAGE_NOCACHE is 0x80, so this is still bit 7, thus the new comment
> > is wrong?
>
> You're right, it's still bit 7 (and we use LSB-0 bit numbering in that
> file). I'll send a fixup.

OK.

> >>   /*
> >>* Externally used page protection values.
> >> diff --git a/arch/microblaze/include/asm/pgtable.h 
> >> b/arch/microblaze/include/asm/pgtable.h
> >> index 42f5988e998b..7e3de54bf426 100644
> >> --- a/arch/microblaze/include/asm/pgtable.h
> >> +++ b/arch/microblaze/include/asm/pgtable.h
> >> @@ -131,10 +131,10 @@ extern pte_t *va_to_pte(unsigned long address);
> >>* of the 16 available.  Bit 24-26 of the TLB are cleared in the TLB
> >>* miss handler.  Bit 27 is PAGE_USER, thus selecting the correct
> >>* zone.
> >> - * - PRESENT *must* be in the bottom two bits because swap cache
> >> - * entries use the top 30 bits.  Because 4xx doesn't support SMP
> >> - * anyway, M is irrelevant so we borrow it for PAGE_PRESENT.  Bit 30
> >> - * is cleared in the TLB miss handler before the TLB entry is loaded.
> >> + * - PRESENT *must* be in the bottom two bits because swap PTEs use the 
> >> top
> >> + * 30 bits.  Because 4xx doesn't support SMP anyway, M is irrelevant so we
> >> + * borrow it for PAGE_PRESENT.  Bit 30 is cleared in the TLB miss handler
> >> + * before the TLB entry is loaded.
> >
> > So the PowerPC 4xx comment is still here?
>
> I only dropped the comment above __swp_type(). I guess you mean that we
> could also drop the "Because 4xx doesn't support SMP anyway, M is
> irrelevant so we borrow it for PAGE_PRESENT." sentence, correct? Not

Yes, that's what I meant.

> sure about the "Bit 30 is cleared in the TLB miss handler" comment, if
> that can similarly be dropped.

No idea, didn't check. But if it was copied from PPC, chances are
high it's no longer true

> >>* - All other bits of the PTE are loaded into TLBLO without
> >>*  * modification, leaving us only the bits 20, 21, 24, 25, 26, 30 for
> >>* software PTE bits.  We actually use bits 21, 24, 25, and
> >> @@ -155,6 +155,9 @@ extern pte_t *va_to_pte(unsigned long address);
> >>   #define _PAGE_ACCESSED 0x400   /* software: R: page referenced */
> >>   #define _PMD_PRESENT   PAGE_MASK
> >>
> >> +/* We borrow bit 24 to store the exclusive marker in swap PTEs. */
> >> +#define _PAGE_SWP_EXCLUSIVE_PAGE_DIRTY
> >
> > _PAGE_DIRTY is 0x80, so this is also bit 7, thus the new comment is
> > wrong?
>
> In the example, I use MSB-0 bit numbering (which I determined to be
> correct in microblaze context eventually, but I got confused a couple a
> times because it's very inconsistent). That should be MSB-0 bit 24.

Thanks, TIL microblaze uses IBM bit numbering...

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal 

Re: [Intel-gfx] [PATCH v5 0/7] Introduce __xchg, non-atomic xchg

2023-02-27 Thread Peter Zijlstra
On Thu, Feb 23, 2023 at 10:24:19PM +0100, Andrzej Hajda wrote:
> On 22.02.2023 18:04, Peter Zijlstra wrote:
> > On Wed, Jan 18, 2023 at 04:35:22PM +0100, Andrzej Hajda wrote:
> > 
> > > Andrzej Hajda (7):
> > >arch: rename all internal names __xchg to __arch_xchg
> > >linux/include: add non-atomic version of xchg
> > >arch/*/uprobes: simplify arch_uretprobe_hijack_return_addr
> > >llist: simplify __llist_del_all
> > >io_uring: use __xchg if possible
> > >qed: use __xchg if possible
> > >drm/i915/gt: use __xchg instead of internal helper
> > 
> > Nothing crazy in here I suppose, I somewhat wonder why you went through
> > the trouble, but meh.
> 
> If you are asking why I have proposed this patchset, then the answer is
> simple, 1st I've tried to find a way to move internal i915 helper to core
> (see patch 7).
> Then I was looking for possible other users of this helper. And apparently
> there are many of them, patches 3-7 shows some.
> 
> 
> > 
> > You want me to take this through te locking tree (for the next cycle,
> > not this one) where I normally take atomic things or does someone else
> > want this?
> 
> If you could take it I will be happy.

OK, I'll go queue it in tip/locking/core after -rc1. Thanks!

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH mm-unstable v1 11/26] microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-02-27 Thread David Hildenbrand

On 26.02.23 21:13, Geert Uytterhoeven wrote:

Hi David,


Hi Geert,



On Fri, Jan 13, 2023 at 6:16 PM David Hildenbrand  wrote:

Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit
from the type. Generic MM currently only uses 5 bits for the type
(MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused.

The shift by 2 when converting between PTE and arch-specific swap entry
makes the swap PTE layout a little bit harder to decipher.

While at it, drop the comment from paulus---copy-and-paste leftover
from powerpc where we actually have _PAGE_HASHPTE---and mask the type in
__swp_entry_to_pte() as well.

Cc: Michal Simek 
Signed-off-by: David Hildenbrand 


Thanks for your patch, which is now commit b5c88f21531c3457
("microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE") in



Right, it went upstream, so we can only fixup.


  arch/m68k/include/asm/mcf_pgtable.h   |  4 +--


What is this m68k change doing here?
Sorry for not noticing this earlier.


Thanks for the late review, still valuable :)

That hunk should have gone into the previous patch, looks like I messed 
that up when reworking.




Furthermore, several things below look strange to me...


  arch/microblaze/include/asm/pgtable.h | 45 +--
  2 files changed, 37 insertions(+), 12 deletions(-)

diff --git a/arch/m68k/include/asm/mcf_pgtable.h 
b/arch/m68k/include/asm/mcf_pgtable.h
index 3f8f4d0e66dd..e573d7b649f7 100644
--- a/arch/m68k/include/asm/mcf_pgtable.h
+++ b/arch/m68k/include/asm/mcf_pgtable.h
@@ -46,8 +46,8 @@
  #define _CACHEMASK040  (~0x060)
  #define _PAGE_GLOBAL0400x400   /* 68040 global bit, used for 
kva descs */

-/* We borrow bit 7 to store the exclusive marker in swap PTEs. */
-#define _PAGE_SWP_EXCLUSIVE0x080
+/* We borrow bit 24 to store the exclusive marker in swap PTEs. */
+#define _PAGE_SWP_EXCLUSIVECF_PAGE_NOCACHE


CF_PAGE_NOCACHE is 0x80, so this is still bit 7, thus the new comment
is wrong?


You're right, it's still bit 7 (and we use LSB-0 bit numbering in that 
file). I'll send a fixup.






  /*
   * Externally used page protection values.
diff --git a/arch/microblaze/include/asm/pgtable.h 
b/arch/microblaze/include/asm/pgtable.h
index 42f5988e998b..7e3de54bf426 100644
--- a/arch/microblaze/include/asm/pgtable.h
+++ b/arch/microblaze/include/asm/pgtable.h
@@ -131,10 +131,10 @@ extern pte_t *va_to_pte(unsigned long address);
   * of the 16 available.  Bit 24-26 of the TLB are cleared in the TLB
   * miss handler.  Bit 27 is PAGE_USER, thus selecting the correct
   * zone.
- * - PRESENT *must* be in the bottom two bits because swap cache
- * entries use the top 30 bits.  Because 4xx doesn't support SMP
- * anyway, M is irrelevant so we borrow it for PAGE_PRESENT.  Bit 30
- * is cleared in the TLB miss handler before the TLB entry is loaded.
+ * - PRESENT *must* be in the bottom two bits because swap PTEs use the top
+ * 30 bits.  Because 4xx doesn't support SMP anyway, M is irrelevant so we
+ * borrow it for PAGE_PRESENT.  Bit 30 is cleared in the TLB miss handler
+ * before the TLB entry is loaded.


So the PowerPC 4xx comment is still here?


I only dropped the comment above __swp_type(). I guess you mean that we 
could also drop the "Because 4xx doesn't support SMP anyway, M is 
irrelevant so we borrow it for PAGE_PRESENT." sentence, correct? Not 
sure about the "Bit 30 is cleared in the TLB miss handler" comment, if 
that can similarly be dropped.





   * - All other bits of the PTE are loaded into TLBLO without
   *  * modification, leaving us only the bits 20, 21, 24, 25, 26, 30 for
   * software PTE bits.  We actually use bits 21, 24, 25, and
@@ -155,6 +155,9 @@ extern pte_t *va_to_pte(unsigned long address);
  #define _PAGE_ACCESSED 0x400   /* software: R: page referenced */
  #define _PMD_PRESENT   PAGE_MASK

+/* We borrow bit 24 to store the exclusive marker in swap PTEs. */
+#define _PAGE_SWP_EXCLUSIVE_PAGE_DIRTY


_PAGE_DIRTY is 0x80, so this is also bit 7, thus the new comment is
wrong?


In the example, I use MSB-0 bit numbering (which I determined to be 
correct in microblaze context eventually, but I got confused a couple a 
times because it's very inconsistent). That should be MSB-0 bit 24.


Thanks!

--
Thanks,

David / dhildenb


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [Intel-gfx] [PATCH v5 5/7] io_uring: use __xchg if possible

2023-02-27 Thread Andi Shyti
Hi Andrzej,

On Wed, Jan 18, 2023 at 04:44:48PM +0100, Andrzej Hajda wrote:
> Recently introduced helper simplifies the code.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Andi Shyti 

Thanks,
Andi

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [Intel-gfx] [PATCH v5 7/7] drm/i915/gt: use __xchg instead of internal helper

2023-02-27 Thread Andi Shyti
Hi Andrzej,

On Wed, Jan 18, 2023 at 04:44:50PM +0100, Andrzej Hajda wrote:
> Prefer core helper if available.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Andi Shyti 

Thanks,
Andi

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [Intel-gfx] [PATCH v5 6/7] qed: use __xchg if possible

2023-02-27 Thread Andi Shyti
Hi Andrzej,

On Wed, Jan 18, 2023 at 04:44:49PM +0100, Andrzej Hajda wrote:
> Recently introduced helper simplifies the code.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Andi Shyti 

Thanks,
Andi

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [Intel-gfx] [PATCH v5 4/7] llist: simplify __llist_del_all

2023-02-27 Thread Andi Shyti
Hi Andrzej,

On Wed, Jan 18, 2023 at 04:44:47PM +0100, Andrzej Hajda wrote:
> llist_del_all uses xchg, let's use __xchg here.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Andi Shyti 

Thanks,
Andi

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [Intel-gfx] [PATCH v5 3/7] arch/*/uprobes: simplify arch_uretprobe_hijack_return_addr

2023-02-27 Thread Andi Shyti
Hi Andrzej,

On Wed, Jan 18, 2023 at 04:44:46PM +0100, Andrzej Hajda wrote:
> In all architectures, except x86, arch_uretprobe_hijack_return_addr
> is just __xchg.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Andi Shyti 

Thanks,
Andi

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [Intel-gfx] [PATCH v5 2/7] linux/include: add non-atomic version of xchg

2023-02-27 Thread Andi Shyti
Hi Andrzej,

On Wed, Jan 18, 2023 at 04:44:45PM +0100, Andrzej Hajda wrote:
> The pattern of setting variable with new value and returning old
> one is very common in kernel. Usually atomicity of the operation
> is not required, so xchg seems to be suboptimal and confusing in
> such cases.
> 
> Signed-off-by: Andrzej Hajda 
> Reviewed-by: Andy Shevchenko 

Reviewed-by: Andi Shyti 

Thanks,
Andi

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [Intel-gfx] [PATCH v5 1/7] arch: rename all internal names __xchg to __arch_xchg

2023-02-27 Thread Andi Shyti
Hi Andrzej,

On Wed, Jan 18, 2023 at 04:44:44PM +0100, Andrzej Hajda wrote:
> __xchg will be used for non-atomic xchg macro.
> 
> Signed-off-by: Andrzej Hajda 
> Reviewed-by: Arnd Bergmann 
> Acked-by: Geert Uytterhoeven  [m68k]
> Acked-by: Palmer Dabbelt  [riscv]

Reviewed-by: Andi Shyti 

Thanks,
Andi

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc