Re: [PATCH v3] kbuild: Show marked Kconfig fragments in "help"

2023-09-01 Thread Michael Ellerman
Kees Cook  writes:
> Currently the Kconfig fragments in kernel/configs and arch/*/configs
> that aren't used internally aren't discoverable through "make help",
> which consists of hard-coded lists of config fragments. Instead, list
> all the fragment targets that have a "# Help: " comment prefix so the
> targets can be generated dynamically.
>
> Add logic to the Makefile to search for and display the fragment and
> comment. Add comments to fragments that are intended to be direct targets.
>
> Cc: Nicolas Schier 
> Cc: Michael Ellerman 
> Cc: Christophe Leroy 
> Cc: Randy Dunlap 
> Cc: linux-ker...@vger.kernel.org
> Cc: x...@kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ri...@lists.infradead.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux-kbu...@vger.kernel.org
> Cc: linux-harden...@vger.kernel.org
> Signed-off-by: Kees Cook 
> Co-developed-by: Masahiro Yamada 
> ---
> v3:
> - Use Makefile logic from Masahiro Yamada
> - Use "# Help: " prefix, but only on desired fragment targets
> v2: https://lore.kernel.org/all/20230825194329.gonna.911-k...@kernel.org
> v1: https://lore.kernel.org/all/20230824223606.never.762-k...@kernel.org
> ---
>  Makefile   |  1 -
>  arch/arm/configs/dram_0x.config|  1 +
>  arch/arm/configs/dram_0xc000.config|  1 +
>  arch/arm/configs/dram_0xd000.config|  1 +
>  arch/arm/configs/lpae.config   |  1 +
>  arch/arm64/configs/virt.config |  1 +
>  arch/powerpc/configs/disable-werror.config |  1 +
>  arch/powerpc/configs/security.config   |  4 +++-
  
Acked-by: Michael Ellerman  (powerpc)

cheers


Re: [PATCH gmem FIXUP] mm, compaction: make testing mapping_unmovable() safe

2023-09-01 Thread kirill . shutemov
On Fri, Sep 01, 2023 at 10:20:26AM +0200, Vlastimil Babka wrote:
> As Kirill pointed out, mapping can be removed under us due to
> truncation. Test it under folio lock as already done for the async
> compaction / dirty folio case. To prevent locking every folio with
> mapping to do the test, do it only for unevictable folios, as we can
> expect the unmovable mapping folios are also unevictable - it is the
> case for guest memfd folios.
> 
> Also incorporate comment update suggested by Matthew.
> 
> Fixes: 3424873596ce ("mm: Add AS_UNMOVABLE to mark mapping as completely 
> unmovable")
> Signed-off-by: Vlastimil Babka 

Superficially looks good to me. But I don't really understand this
code path to Ack.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov


Re: [PATCH v3] kbuild: Show marked Kconfig fragments in "help"

2023-09-01 Thread Kees Cook
On Fri, Sep 01, 2023 at 04:58:37PM +0900, Masahiro Yamada wrote:
> On Fri, Sep 1, 2023 at 4:13 AM Kees Cook  wrote:
> >
> > Currently the Kconfig fragments in kernel/configs and arch/*/configs
> > that aren't used internally aren't discoverable through "make help",
> > which consists of hard-coded lists of config fragments. Instead, list
> > all the fragment targets that have a "# Help: " comment prefix so the
> > targets can be generated dynamically.
> >
> > Add logic to the Makefile to search for and display the fragment and
> > comment. Add comments to fragments that are intended to be direct targets.
> >
> > Cc: Nicolas Schier 
> > Cc: Michael Ellerman 
> > Cc: Christophe Leroy 
> > Cc: Randy Dunlap 
> > Cc: linux-ker...@vger.kernel.org
> > Cc: x...@kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Cc: linux-ri...@lists.infradead.org
> > Cc: linux-s...@vger.kernel.org
> > Cc: linux-kbu...@vger.kernel.org
> > Cc: linux-harden...@vger.kernel.org
> > Signed-off-by: Kees Cook 
> > Co-developed-by: Masahiro Yamada 
> > ---
> > v3:
> > - Use Makefile logic from Masahiro Yamada
> > - Use "# Help: " prefix, but only on desired fragment targets
> > v2: https://lore.kernel.org/all/20230825194329.gonna.911-k...@kernel.org
> > v1: https://lore.kernel.org/all/20230824223606.never.762-k...@kernel.org
> > ---
> >  Makefile   |  1 -
> >  arch/arm/configs/dram_0x.config|  1 +
> >  arch/arm/configs/dram_0xc000.config|  1 +
> >  arch/arm/configs/dram_0xd000.config|  1 +
> >  arch/arm/configs/lpae.config   |  1 +
> >  arch/arm64/configs/virt.config |  1 +
> >  arch/powerpc/configs/disable-werror.config |  1 +
> >  arch/powerpc/configs/security.config   |  4 +++-
> >  arch/riscv/configs/32-bit.config   |  1 +
> >  arch/riscv/configs/64-bit.config   |  1 +
> >  arch/s390/configs/btf.config   |  1 +
> >  arch/s390/configs/kasan.config |  1 +
> >  arch/x86/Makefile  |  4 
> >  kernel/configs/debug.config|  2 ++
> >  kernel/configs/kvm_guest.config|  1 +
> >  kernel/configs/nopm.config |  2 ++
> >  kernel/configs/rust.config |  1 +
> >  kernel/configs/tiny.config |  2 ++
> >  kernel/configs/x86_debug.config|  1 +
> >  kernel/configs/xen.config  |  2 ++
> >  scripts/kconfig/Makefile   | 15 ---
> >  21 files changed, 36 insertions(+), 9 deletions(-)
> >
> 
> 
> Just one thing.
> 
> 
> 
> 
> 
> > diff --git a/kernel/configs/tiny.config b/kernel/configs/tiny.config
> > index 9f7d0835..60a4b6d80b36 100644
> > --- a/kernel/configs/tiny.config
> > +++ b/kernel/configs/tiny.config
> > @@ -1,3 +1,5 @@
> > +# Help: Size-optimized kernel image
> 
> 
> I will drop this.
> 
> 
> We already have a hard-coded help message.
> 
>   tinyconfig   - Configure the tiniest possible kernel
> 
> 
> 
> 
> Then, some lines below, again.
> 
>   tiny.config   - Size-optimized kernel image
> 
> 
> 
> tiny.config is for internal use for tinyconfig.

Shall I send a v4, or did you fix this up already?

-- 
Kees Cook


[PATCH 2/2] powerpc/fadump: make is_kdump_kernel() return false when fadump is active

2023-09-01 Thread Hari Bathini
Currently, is_kdump_kernel() returns true in crash dump capture kernel
for both kdump and fadump crash dump capturing methods, as both these
methods set elfcorehdr_addr. Some restrictions enforced for crash dump
capture kernel, based on is_kdump_kernel(), are specifically meant for
kdump case and not desirable for fadump - eg. IO queues restriction in
device drivers. So, define is_kdump_kernel() to return false when f/w
assisted adump is active. For fadump case, is_fadump_active() can be
used for capture kernel specific checks.

Signed-off-by: Hari Bathini 
---
 arch/powerpc/include/asm/kexec.h |  8 ++--
 arch/powerpc/kernel/crash_dump.c | 12 
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index a1ddba01e7d1..e1b43aa12175 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -99,10 +99,14 @@ void relocate_new_kernel(unsigned long indirection_page, 
unsigned long reboot_co
 
 void kexec_copy_flush(struct kimage *image);
 
-#if defined(CONFIG_CRASH_DUMP) && defined(CONFIG_PPC_RTAS)
+#if defined(CONFIG_CRASH_DUMP)
+bool is_kdump_kernel(void);
+#define is_kdump_kernelis_kdump_kernel
+#if defined(CONFIG_PPC_RTAS)
 void crash_free_reserved_phys_range(unsigned long begin, unsigned long end);
 #define crash_free_reserved_phys_range crash_free_reserved_phys_range
-#endif
+#endif /* CONFIG_PPC_RTAS */
+#endif /* CONFIG_CRASH_DUMP */
 
 #ifdef CONFIG_KEXEC_FILE
 extern const struct kexec_file_ops kexec_elf64_ops;
diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index 9a3b85bfc83f..2086fa6cdc25 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef DEBUG
 #include 
@@ -92,6 +93,17 @@ ssize_t copy_oldmem_page(struct iov_iter *iter, unsigned 
long pfn,
return csize;
 }
 
+/*
+ * Return true only when kexec based kernel dump capturing method is used.
+ * This ensures all restritions applied for kdump case are not automatically
+ * applied for fadump case.
+ */
+bool is_kdump_kernel(void)
+{
+   return !is_fadump_active() && elfcorehdr_addr != ELFCORE_ADDR_MAX;
+}
+EXPORT_SYMBOL_GPL(is_kdump_kernel);
+
 #ifdef CONFIG_PPC_RTAS
 /*
  * The crashkernel region will almost always overlap the RTAS region, so
-- 
2.41.0



[PATCH 1/2] vmcore: allow alternate dump capturing methods to export vmcore without is_kdump_kernel()

2023-09-01 Thread Hari Bathini
Currently, is_kdump_kernel() returns true when elfcorehdr_addr is set.
While elfcorehdr_addr is set for kexec based kernel dump mechanism,
alternate dump capturing methods like fadump [1] also set it to export
the vmcore. is_kdump_kernel() is used to restrict resources in crash
dump capture kernel but such restrictions may not be desirable for
fadump. Allow is_kdump_kernel() to be defined differently for such
scenarios. With this, is_kdump_kernel() could be false while vmcore
is usable. So, introduce is_crashdump_kernel() to return true when
elfcorehdr_addr is set and use it for vmcore related checks.

[1] https://docs.kernel.org/powerpc/firmware-assisted-dump.html

Signed-off-by: Hari Bathini 
---
 include/linux/crash_dump.h | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index 0f3a656293b0..1052a0faf0dd 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -50,6 +50,7 @@ void vmcore_cleanup(void);
 #define vmcore_elf64_check_arch(x) (elf_check_arch(x) || 
vmcore_elf_check_arch_cross(x))
 #endif
 
+#ifndef is_kdump_kernel
 /*
  * is_kdump_kernel() checks whether this kernel is booting after a panic of
  * previous kernel or not. This is determined by checking if previous kernel
@@ -64,6 +65,19 @@ static inline bool is_kdump_kernel(void)
 {
return elfcorehdr_addr != ELFCORE_ADDR_MAX;
 }
+#endif
+
+/*
+ * Return true if this is a dump capture kernel, where vmcore needs to be
+ * exported, irrespective of the dump capture mechanism in use.
+ *
+ * Same as is_kdump_kernel() unless arch specific code defines 
is_kdump_kernel()
+ * differently while supporting other dump capturing mechanisms.
+ */
+static inline bool is_crashdump_kernel(void)
+{
+   return elfcorehdr_addr != ELFCORE_ADDR_MAX;
+}
 
 /* is_vmcore_usable() checks if the kernel is booting after a panic and
  * the vmcore region is usable.
@@ -75,7 +89,7 @@ static inline bool is_kdump_kernel(void)
 
 static inline int is_vmcore_usable(void)
 {
-   return is_kdump_kernel() && elfcorehdr_addr != ELFCORE_ADDR_ERR ? 1 : 0;
+   return is_crashdump_kernel() && elfcorehdr_addr != ELFCORE_ADDR_ERR ? 1 
: 0;
 }
 
 /* vmcore_unusable() marks the vmcore as unusable,
@@ -84,7 +98,7 @@ static inline int is_vmcore_usable(void)
 
 static inline void vmcore_unusable(void)
 {
-   if (is_kdump_kernel())
+   if (is_crashdump_kernel())
elfcorehdr_addr = ELFCORE_ADDR_ERR;
 }
 
-- 
2.41.0



Re: [PATCH v2 3/3] kconfig: add dependencies of POWER_RESET for PowerMac

2023-09-01 Thread Yuan Tan

Hi,

On 9/1/2023 2:10 PM, Christophe Leroy wrote:


Le 01/09/2023 à 04:43, Yuan Tan a écrit :

PowerMac's power off depends on ADB_CUDA to work. Enable it when
POWER_RESET is set for convenience.

Suggested-by: Zhangjin Wu 
Signed-off-by: Yuan Tan 
---
   arch/powerpc/platforms/powermac/Kconfig | 1 +
   1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/platforms/powermac/Kconfig 
b/arch/powerpc/platforms/powermac/Kconfig
index 130707ec9f99..9e633d7e8367 100644
--- a/arch/powerpc/platforms/powermac/Kconfig
+++ b/arch/powerpc/platforms/powermac/Kconfig
@@ -2,6 +2,7 @@
   config PPC_PMAC
bool "Apple PowerMac based machines"
depends on PPC_BOOK3S && CPU_BIG_ENDIAN
+   select ADB_CUDA if POWER_RESET

ADB_CUDA depends on !PPC_PMAC64.

What will happen if PPC_PMAC64 is selected ?


select MPIC
select FORCE_PCI
select PPC_INDIRECT_PCI if PPC32


I didn't notice that ADB_CUDA depends on !PPC_PMAC64. In the case where 
PPC_PMAC64 is set, ADB_CUDA indeed should not be enabled. Thank you for 
pointing that out.


I will fix it in v3 and check again in x86 and mips :)




Re: [PATCH] powerpc/powernv: use appropiate error code

2023-09-01 Thread Immad Mir



On 01/09/23 11:10 pm, Christophe Leroy wrote:


Le 01/09/2023 à 19:19, mirim...@outlook.com a écrit :

[Vous ne recevez pas souvent de courriers de mirim...@outlook.com. Découvrez 
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

From: Immad Mir 

-1 is not a valid error code. This patch replaces it with -EPERM.

Can you explain how it will work ?
In scom_debug_init() rc is built by oring the value returned by
scom_debug_init_one().
What will be the result when oring some valid values with -EPERM ?
It was working well with -1 because when you or -1 with anything you get
-1 as result. But with your change I don't think it will work.



if EPERM is not always necessarily equal to 1, we can put a check in 
scom_debug_init before returning rc. If it is less than 1 (because AFAIK 
or-ring with negative number results back into the same negative number) 
we set rc equal to -1.


Immad.



Christophe


Signed-off-by: Immad Mir 
---
   arch/powerpc/platforms/powernv/opal-xscom.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-xscom.c 
b/arch/powerpc/platforms/powernv/opal-xscom.c
index 262cd6fac..ce4b089dd 100644
--- a/arch/powerpc/platforms/powernv/opal-xscom.c
+++ b/arch/powerpc/platforms/powernv/opal-xscom.c
@@ -171,7 +171,7 @@ static int scom_debug_init_one(struct dentry *root, struct 
device_node *dn,
  if (IS_ERR(dir)) {
  kfree(ent->path.data);
  kfree(ent);
-   return -1;
+   return -EPERM;
  }

  debugfs_create_blob("devspec", 0400, dir, >path);
@@ -191,7 +191,7 @@ static int scom_debug_init(void)

  root = debugfs_create_dir("scom", arch_debugfs_dir);
  if (IS_ERR(root))
-   return -1;
+   return -EPERM;

  rc = 0;
  for_each_node_with_property(dn, "scom-controller") {
--
2.40.0



Re: [PATCH] powerpc/powernv: use appropiate error code

2023-09-01 Thread Immad Mir



On 01/09/23 11:10 pm, Christophe Leroy wrote:


Le 01/09/2023 à 19:19, mirim...@outlook.com a écrit :

[Vous ne recevez pas souvent de courriers de mirim...@outlook.com. Découvrez 
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

From: Immad Mir 

-1 is not a valid error code. This patch replaces it with -EPERM.

Can you explain how it will work ?
In scom_debug_init() rc is built by oring the value returned by
scom_debug_init_one().
What will be the result when oring some valid values with -EPERM ?
It was working well with -1 because when you or -1 with anything you get
-1 as result. But with your change I don't think it will work.


But Isn't EPERM defined to be 1.


Immad.



Christophe


Signed-off-by: Immad Mir 
---
   arch/powerpc/platforms/powernv/opal-xscom.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-xscom.c 
b/arch/powerpc/platforms/powernv/opal-xscom.c
index 262cd6fac..ce4b089dd 100644
--- a/arch/powerpc/platforms/powernv/opal-xscom.c
+++ b/arch/powerpc/platforms/powernv/opal-xscom.c
@@ -171,7 +171,7 @@ static int scom_debug_init_one(struct dentry *root, struct 
device_node *dn,
  if (IS_ERR(dir)) {
  kfree(ent->path.data);
  kfree(ent);
-   return -1;
+   return -EPERM;
  }

  debugfs_create_blob("devspec", 0400, dir, >path);
@@ -191,7 +191,7 @@ static int scom_debug_init(void)

  root = debugfs_create_dir("scom", arch_debugfs_dir);
  if (IS_ERR(root))
-   return -1;
+   return -EPERM;

  rc = 0;
  for_each_node_with_property(dn, "scom-controller") {
--
2.40.0



Re: [PATCH] powerpc/powernv: use appropiate error code

2023-09-01 Thread Christophe Leroy


Le 01/09/2023 à 19:19, mirim...@outlook.com a écrit :
> [Vous ne recevez pas souvent de courriers de mirim...@outlook.com. Découvrez 
> pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> 
> From: Immad Mir 
> 
> -1 is not a valid error code. This patch replaces it with -EPERM.

Can you explain how it will work ?
In scom_debug_init() rc is built by oring the value returned by 
scom_debug_init_one().
What will be the result when oring some valid values with -EPERM ?
It was working well with -1 because when you or -1 with anything you get 
-1 as result. But with your change I don't think it will work.

Christophe

> 
> Signed-off-by: Immad Mir 
> ---
>   arch/powerpc/platforms/powernv/opal-xscom.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/opal-xscom.c 
> b/arch/powerpc/platforms/powernv/opal-xscom.c
> index 262cd6fac..ce4b089dd 100644
> --- a/arch/powerpc/platforms/powernv/opal-xscom.c
> +++ b/arch/powerpc/platforms/powernv/opal-xscom.c
> @@ -171,7 +171,7 @@ static int scom_debug_init_one(struct dentry *root, 
> struct device_node *dn,
>  if (IS_ERR(dir)) {
>  kfree(ent->path.data);
>  kfree(ent);
> -   return -1;
> +   return -EPERM;
>  }
> 
>  debugfs_create_blob("devspec", 0400, dir, >path);
> @@ -191,7 +191,7 @@ static int scom_debug_init(void)
> 
>  root = debugfs_create_dir("scom", arch_debugfs_dir);
>  if (IS_ERR(root))
> -   return -1;
> +   return -EPERM;
> 
>  rc = 0;
>  for_each_node_with_property(dn, "scom-controller") {
> --
> 2.40.0
> 


[PATCH] powerpc/powernv: use appropiate error code

2023-09-01 Thread mirimmad
From: Immad Mir 

-1 is not a valid error code. This patch replaces it with -EPERM.

Signed-off-by: Immad Mir 
---
 arch/powerpc/platforms/powernv/opal-xscom.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-xscom.c 
b/arch/powerpc/platforms/powernv/opal-xscom.c
index 262cd6fac..ce4b089dd 100644
--- a/arch/powerpc/platforms/powernv/opal-xscom.c
+++ b/arch/powerpc/platforms/powernv/opal-xscom.c
@@ -171,7 +171,7 @@ static int scom_debug_init_one(struct dentry *root, struct 
device_node *dn,
if (IS_ERR(dir)) {
kfree(ent->path.data);
kfree(ent);
-   return -1;
+   return -EPERM;
}

debugfs_create_blob("devspec", 0400, dir, >path);
@@ -191,7 +191,7 @@ static int scom_debug_init(void)

root = debugfs_create_dir("scom", arch_debugfs_dir);
if (IS_ERR(root))
-   return -1;
+   return -EPERM;

rc = 0;
for_each_node_with_property(dn, "scom-controller") {
--
2.40.0



Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory

2023-09-01 Thread Ackerley Tng
Binbin Wu  writes:

> 
>
>>
>> I'm not sure whose refcount the folio_put() in kvm_gmem_allocate() is
>> dropping though:
>>
>> + The refcount for the filemap depends on whether this is a hugepage or
>>not, but folio_put() strictly drops a refcount of 1.
>> + The refcount for the lru list is just 1, but doesn't the page still
>>remain in the lru list?
>
> I guess the refcount drop here is the one get on the fresh allocation.
> Now the filemap has grabbed the folio, so the lifecycle of the folio now 
> is decided by the filemap/inode?
>

This makes sense! So folio_put() here is saying, I'm not using this
folio anymore, but the filemap and the lru list are stil using the
folio.

> 


[PATCH 4/4] fbdev: Replace fb_pgprotect() with fb_pgprot_device()

2023-09-01 Thread Thomas Zimmermann
Rename the fbdev mmap helper fb_pgprotect() to fb_pgprot_device().
The helper sets VMA page-access flags for framebuffers in device I/O
memory. The new name follows pgprot_device(), which does the same for
arbitrary devices.

Also clean up the helper's parameters and return value. Instead of
the VMA instance, pass the individial parameters separately: existing
page-access flags, the VMAs start and end addresses and the offset
in the underlying device memory rsp file. Return the new page-access
flags. These changes align fb_pgprot_device() closer with pgprot_device.

Signed-off-by: Thomas Zimmermann 
---
 arch/ia64/include/asm/fb.h   | 15 +++
 arch/m68k/include/asm/fb.h   | 19 ++-
 arch/mips/include/asm/fb.h   | 11 +--
 arch/powerpc/include/asm/fb.h| 13 +
 arch/sparc/include/asm/fb.h  | 15 +--
 arch/x86/include/asm/fb.h| 10 ++
 arch/x86/video/fbdev.c   | 15 ---
 drivers/video/fbdev/core/fb_chrdev.c |  3 ++-
 include/asm-generic/fb.h | 12 ++--
 9 files changed, 58 insertions(+), 55 deletions(-)

diff --git a/arch/ia64/include/asm/fb.h b/arch/ia64/include/asm/fb.h
index 1717b26fd423..2fbad4a9fc15 100644
--- a/arch/ia64/include/asm/fb.h
+++ b/arch/ia64/include/asm/fb.h
@@ -8,17 +8,16 @@
 
 #include 
 
-struct file;
-
-static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
-   unsigned long off)
+static inline pgprot_t fb_pgprot_device(pgprot_t prot,
+   unsigned long vm_start, unsigned long 
vm_end,
+   unsigned long offset)
 {
-   if (efi_range_is_wc(vma->vm_start, vma->vm_end - vma->vm_start))
-   vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+   if (efi_range_is_wc(vm_start, vm_end - vm_start))
+   return pgprot_writecombine(prot);
else
-   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+   return pgprot_noncached(prot);
 }
-#define fb_pgprotect fb_pgprotect
+#define fb_pgprot_device fb_pgprot_device
 
 static inline void fb_memcpy_fromio(void *to, const volatile void __iomem 
*from, size_t n)
 {
diff --git a/arch/m68k/include/asm/fb.h b/arch/m68k/include/asm/fb.h
index 24273fc7ad91..4acdf5b62871 100644
--- a/arch/m68k/include/asm/fb.h
+++ b/arch/m68k/include/asm/fb.h
@@ -5,26 +5,27 @@
 #include 
 #include 
 
-struct file;
-
-static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
-   unsigned long off)
+static inline pgprot_t fb_pgprot_device(pgprot_t prot,
+   unsigned long vm_start, unsigned long 
vm_end,
+   unsigned long offset)
 {
 #ifdef CONFIG_MMU
 #ifdef CONFIG_SUN3
-   pgprot_val(vma->vm_page_prot) |= SUN3_PAGE_NOCACHE;
+   pgprot_val(prot) |= SUN3_PAGE_NOCACHE;
 #else
if (CPU_IS_020_OR_030)
-   pgprot_val(vma->vm_page_prot) |= _PAGE_NOCACHE030;
+   pgprot_val(prot) |= _PAGE_NOCACHE030;
if (CPU_IS_040_OR_060) {
-   pgprot_val(vma->vm_page_prot) &= _CACHEMASK040;
+   pgprot_val(prot) &= _CACHEMASK040;
/* Use no-cache mode, serialized */
-   pgprot_val(vma->vm_page_prot) |= _PAGE_NOCACHE_S;
+   pgprot_val(prot) |= _PAGE_NOCACHE_S;
}
 #endif /* CONFIG_SUN3 */
 #endif /* CONFIG_MMU */
+
+   return prot;
 }
-#define fb_pgprotect fb_pgprotect
+#define fb_pgprot_device fb_pgprot_device
 
 #include 
 
diff --git a/arch/mips/include/asm/fb.h b/arch/mips/include/asm/fb.h
index 18b7226403ba..98e63d14a71f 100644
--- a/arch/mips/include/asm/fb.h
+++ b/arch/mips/include/asm/fb.h
@@ -3,14 +3,13 @@
 
 #include 
 
-struct file;
-
-static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
-   unsigned long off)
+static inline pgprot_t fb_pgprot_device(pgprot_t prot,
+   unsigned long vm_start, unsigned long 
vm_end,
+   unsigned long offset)
 {
-   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+   return pgprot_noncached(prot);
 }
-#define fb_pgprotect fb_pgprotect
+#define fb_pgprot_device fb_pgprot_device
 
 /*
  * MIPS doesn't define __raw_ I/O macros, so the helpers
diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/fb.h
index 0f1fe1310924..8e6a7fc4ae86 100644
--- a/arch/powerpc/include/asm/fb.h
+++ b/arch/powerpc/include/asm/fb.h
@@ -2,18 +2,15 @@
 #ifndef _ASM_FB_H_
 #define _ASM_FB_H_
 
-#include 
-
 #include 
 
-static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
-   unsigned long off)
+static inline pgprot_t fb_pgprot_device(pgprot_t prot,
+   

[PATCH 0/4] ppc, fbdev: Clean up fbdev mmap helper

2023-09-01 Thread Thomas Zimmermann
Refactor fb_pgprotect() in PowerPC to work without struct file. Then
clean up and rename fb_pgprotect(). This change has been discussed at
[1] in the context of refactoring fbdev's mmap code.

The first three patches adapt PowerPC's internal interfaces to
provide a phys_mem_access_prot() that works without struct file. Neither
the architecture code or fbdev helpers need the parameter.

Patch 4 replaces fbdev's fb_pgprotect() with fb_pgprot_device() on
all architectures. The new helper with its stream-lined interface
enables more refactoring within fbdev's mmap implementation.

[1] 
https://lore.kernel.org/linuxppc-dev/5501ba80-bdb0-6344-16b0-0466a950f...@suse.com/

Thomas Zimmermann (4):
  arch/powerpc: Remove trailing whitespaces
  arch/powerpc: Remove file parameter from phys_mem_access_prot code
  arch/powerpc: Call internal __phys_mem_access_prot() in fbdev code
  fbdev: Replace fb_pgprotect() with fb_pgprot_device()

 arch/ia64/include/asm/fb.h| 15 +++
 arch/m68k/include/asm/fb.h| 19 ++-
 arch/mips/include/asm/fb.h| 11 +--
 arch/powerpc/include/asm/book3s/pgtable.h | 10 --
 arch/powerpc/include/asm/fb.h | 13 +
 arch/powerpc/include/asm/machdep.h| 13 ++---
 arch/powerpc/include/asm/nohash/pgtable.h | 10 --
 arch/powerpc/include/asm/pci.h|  4 +---
 arch/powerpc/kernel/pci-common.c  |  3 +--
 arch/powerpc/mm/mem.c |  8 
 arch/sparc/include/asm/fb.h   | 15 +--
 arch/x86/include/asm/fb.h | 10 ++
 arch/x86/video/fbdev.c| 15 ---
 drivers/video/fbdev/core/fb_chrdev.c  |  3 ++-
 include/asm-generic/fb.h  | 12 ++--
 15 files changed, 86 insertions(+), 75 deletions(-)

-- 
2.41.0



[PATCH 2/4] arch/powerpc: Remove file parameter from phys_mem_access_prot code

2023-09-01 Thread Thomas Zimmermann
Remove 'file' parameter from struct machdep_calls.phys_mem_access_prot
and its implementation in pci_phys_mem_access_prot(). The file is not
used on PowerPC. By removing it, a later patch can simplify fbdev's
mmap code, which uses phys_mem_access_prot() on PowerPC.

Signed-off-by: Thomas Zimmermann 
---
 arch/powerpc/include/asm/book3s/pgtable.h | 10 --
 arch/powerpc/include/asm/machdep.h|  3 +--
 arch/powerpc/include/asm/nohash/pgtable.h | 10 --
 arch/powerpc/include/asm/pci.h|  4 +---
 arch/powerpc/kernel/pci-common.c  |  3 +--
 arch/powerpc/mm/mem.c |  8 
 6 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/pgtable.h 
b/arch/powerpc/include/asm/book3s/pgtable.h
index d18b748ea3ae..84e36a572641 100644
--- a/arch/powerpc/include/asm/book3s/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/pgtable.h
@@ -20,9 +20,15 @@ extern void set_pte_at(struct mm_struct *mm, unsigned long 
addr, pte_t *ptep,
 extern int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long 
address,
 pte_t *ptep, pte_t entry, int dirty);
 
+extern pgprot_t __phys_mem_access_prot(unsigned long pfn, unsigned long size,
+  pgprot_t vma_prot);
+
 struct file;
-extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
-unsigned long size, pgprot_t vma_prot);
+static inline pgprot_t phys_mem_access_prot(struct file *file, unsigned long 
pfn,
+   unsigned long size, pgprot_t 
vma_prot)
+{
+   return __phys_mem_access_prot(pfn, size, vma_prot);
+}
 #define __HAVE_PHYS_MEM_ACCESS_PROT
 
 void __update_mmu_cache(struct vm_area_struct *vma, unsigned long address, 
pte_t *ptep);
diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 933465ed4c43..d31a5ec1550d 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -106,8 +106,7 @@ struct machdep_calls {
int (*pci_get_legacy_ide_irq)(struct pci_dev *dev, int 
channel);
 
/* Get access protection for /dev/mem */
-   pgprot_t(*phys_mem_access_prot)(struct file *file,
-   unsigned long pfn,
+   pgprot_t(*phys_mem_access_prot)(unsigned long pfn,
unsigned long size,
pgprot_t vma_prot);
 
diff --git a/arch/powerpc/include/asm/nohash/pgtable.h 
b/arch/powerpc/include/asm/nohash/pgtable.h
index a6cb6f92..90366b0b3ad9 100644
--- a/arch/powerpc/include/asm/nohash/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/pgtable.h
@@ -246,9 +246,15 @@ extern int ptep_set_access_flags(struct vm_area_struct 
*vma, unsigned long addre
 
 #define pgprot_writecombine pgprot_noncached_wc
 
+extern pgprot_t __phys_mem_access_prot(unsigned long pfn, unsigned long size,
+  pgprot_t vma_prot);
+
 struct file;
-extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
-unsigned long size, pgprot_t vma_prot);
+static inline pgprot_t phys_mem_access_prot(struct file *file, unsigned long 
pfn,
+   unsigned long size, pgprot_t 
vma_prot)
+{
+   return __phys_mem_access_prot(pfn, size, vma_prot);
+}
 #define __HAVE_PHYS_MEM_ACCESS_PROT
 
 #ifdef CONFIG_HUGETLB_PAGE
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 289f1ec85bc5..34ed4d51c546 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -104,9 +104,7 @@ extern void of_scan_pci_bridge(struct pci_dev *dev);
 extern void of_scan_bus(struct device_node *node, struct pci_bus *bus);
 extern void of_rescan_bus(struct device_node *node, struct pci_bus *bus);
 
-struct file;
-extern pgprot_tpci_phys_mem_access_prot(struct file *file,
-unsigned long pfn,
+extern pgprot_tpci_phys_mem_access_prot(unsigned long pfn,
 unsigned long size,
 pgprot_t prot);
 
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index e88d7c9feeec..73f12a17e572 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -521,8 +521,7 @@ int pci_iobar_pfn(struct pci_dev *pdev, int bar, struct 
vm_area_struct *vma)
  * PCI device, it tries to find the PCI device first and calls the
  * above routine
  */
-pgprot_t pci_phys_mem_access_prot(struct file *file,
- unsigned long pfn,
+pgprot_t pci_phys_mem_access_prot(unsigned long pfn,
  unsigned long size,
  pgprot_t prot)
 {
diff --git 

[PATCH 3/4] arch/powerpc: Call internal __phys_mem_access_prot() in fbdev code

2023-09-01 Thread Thomas Zimmermann
Call __phys_mem_access_prot() from the fbdev mmap helper fb_pgprotect().
Allows us to avoid the file argument, which can then be removed from
fB_pgprotect() entirely. No other architecture uses the parameter.

Signed-off-by: Thomas Zimmermann 
---
 arch/powerpc/include/asm/fb.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/fb.h
index 5f1a2e5f7654..0f1fe1310924 100644
--- a/arch/powerpc/include/asm/fb.h
+++ b/arch/powerpc/include/asm/fb.h
@@ -9,9 +9,9 @@
 static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
unsigned long off)
 {
-   vma->vm_page_prot = phys_mem_access_prot(file, off >> PAGE_SHIFT,
-vma->vm_end - vma->vm_start,
-vma->vm_page_prot);
+   vma->vm_page_prot = __phys_mem_access_prot(PHYS_PFN(off),
+  vma->vm_end - vma->vm_start,
+  vma->vm_page_prot);
 }
 #define fb_pgprotect fb_pgprotect
 
-- 
2.41.0



[PATCH 1/4] arch/powerpc: Remove trailing whitespaces

2023-09-01 Thread Thomas Zimmermann
Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 arch/powerpc/include/asm/machdep.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 4f6e7d7ee388..933465ed4c43 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -10,7 +10,7 @@
 #include 
 
 struct pt_regs;
-struct pci_bus;
+struct pci_bus;
 struct device_node;
 struct iommu_table;
 struct rtc_time;
@@ -78,8 +78,8 @@ struct machdep_calls {
unsigned char   (*nvram_read_val)(int addr);
void(*nvram_write_val)(int addr, unsigned char val);
ssize_t (*nvram_write)(char *buf, size_t count, loff_t *index);
-   ssize_t (*nvram_read)(char *buf, size_t count, loff_t *index);  
-   ssize_t (*nvram_size)(void);
+   ssize_t (*nvram_read)(char *buf, size_t count, loff_t *index);
+   ssize_t (*nvram_size)(void);
void(*nvram_sync)(void);
 
/* Exception handlers */
@@ -102,9 +102,9 @@ struct machdep_calls {
 */
long(*feature_call)(unsigned int feature, ...);
 
-   /* Get legacy PCI/IDE interrupt mapping */ 
+   /* Get legacy PCI/IDE interrupt mapping */
int (*pci_get_legacy_ide_irq)(struct pci_dev *dev, int 
channel);
-   
+
/* Get access protection for /dev/mem */
pgprot_t(*phys_mem_access_prot)(struct file *file,
unsigned long pfn,
-- 
2.41.0



Re: [PATCH v3] fsl_ucc_hdlc: process the result of hold_open()

2023-09-01 Thread Denis Kirjanov



On 9/1/23 13:48, Александра Дюпина wrote:
> Thanks for the review!
> 
> 28.08.2023 22:38, Jakub Kicinski пишет:
>> Don't you have to undo all the things done prior to hdlc_open()?
> Yes, it looks like I really need to undo everything that was done before 
> hdlc_open().
> But the question arose - would it be enough to call the uhdlc_close(dev) 
> function?

looks like it is.

> In addition, it seems to me and my colleagues that a call to hdlc_close(dev) 
> should be added to the uhdlc_close() function, similar to the 

yes, take a look at the comment for hdlc_close()

following functions:
> 1. drivers/net/wan/n2.c (n2_close function)
> 2. drivers/net/wan/pc300too.c (pc300_close function)
> 3. drivers/net/wan/pci200syn.c (pci200_close function)
> 4. drivers/net/wan/wanxl.c (wanxl_close function)
> Tell me, please, are we wrong?
> 


Re: [PATCH v3] fsl_ucc_hdlc: process the result of hold_open()

2023-09-01 Thread Александра Дюпина

Thanks for the review!

28.08.2023 22:38, Jakub Kicinski пишет:

Don't you have to undo all the things done prior to hdlc_open()?
Yes, it looks like I really need to undo everything that was done before 
hdlc_open().
But the question arose - would it be enough to call the uhdlc_close(dev) 
function?
In addition, it seems to me and my colleagues that a call to 
hdlc_close(dev) should be added to the uhdlc_close() function, similar 
to the following functions:

1. drivers/net/wan/n2.c (n2_close function)
2. drivers/net/wan/pc300too.c (pc300_close function)
3. drivers/net/wan/pci200syn.c (pci200_close function)
4. drivers/net/wan/wanxl.c (wanxl_close function)
Tell me, please, are we wrong?


Re: [RFC PATCH v11 10/29] mm: Add AS_UNMOVABLE to mark mapping as completely unmovable

2023-09-01 Thread Vlastimil Babka
On 7/25/23 14:51, Matthew Wilcox wrote:
> On Tue, Jul 25, 2023 at 01:24:03PM +0300, Kirill A . Shutemov wrote:
>> On Tue, Jul 18, 2023 at 04:44:53PM -0700, Sean Christopherson wrote:
>> > diff --git a/mm/compaction.c b/mm/compaction.c
>> > index dbc9f86b1934..a3d2b132df52 100644
>> > --- a/mm/compaction.c
>> > +++ b/mm/compaction.c
>> > @@ -1047,6 +1047,10 @@ isolate_migratepages_block(struct compact_control 
>> > *cc, unsigned long low_pfn,
>> >if (!mapping && (folio_ref_count(folio) - 1) > 
>> > folio_mapcount(folio))
>> >goto isolate_fail_put;
>> >  
>> > +  /* The mapping truly isn't movable. */
>> > +  if (mapping && mapping_unmovable(mapping))
>> > +  goto isolate_fail_put;
>> > +
>> 
>> I doubt that it is safe to dereference mapping here. I believe the folio
>> can be truncated from under us and the mapping freed with the inode.
>> 
>> The folio has to be locked to dereference mapping safely (given that the
>> mapping is still tied to the folio).
> 
> There's even a comment to that effect later on in the function:
> 
> /*
>  * Only pages without mappings or that have a
>  * ->migrate_folio callback are possible to migrate
>  * without blocking. However, we can be racing with
>  * truncation so it's necessary to lock the page
>  * to stabilise the mapping as truncation holds
>  * the page lock until after the page is removed
>  * from the page cache.
>  */
> 
> (that could be reworded to make it clear how dangerous dereferencing
> ->mapping is without the lock ... and it does need to be changed to say
> "folio lock" instead of "page lock", so ...)
> 
> How does this look?
> 
> /*
>  * Only folios without mappings or that have
>  * a ->migrate_folio callback are possible to
>  * migrate without blocking. However, we can
>  * be racing with truncation, which can free
>  * the mapping.  Truncation holds the folio lock
>  * until after the folio is removed from the page
>  * cache so holding it ourselves is sufficient.
>  */

Incorporated to my attempt at a fix (posted separately per the requested
process):

https://lore.kernel.org/all/20230901082025.20548-2-vba...@suse.cz/


[PATCH gmem FIXUP] mm, compaction: make testing mapping_unmovable() safe

2023-09-01 Thread Vlastimil Babka
As Kirill pointed out, mapping can be removed under us due to
truncation. Test it under folio lock as already done for the async
compaction / dirty folio case. To prevent locking every folio with
mapping to do the test, do it only for unevictable folios, as we can
expect the unmovable mapping folios are also unevictable - it is the
case for guest memfd folios.

Also incorporate comment update suggested by Matthew.

Fixes: 3424873596ce ("mm: Add AS_UNMOVABLE to mark mapping as completely 
unmovable")
Signed-off-by: Vlastimil Babka 
---
Feel free to squash into 3424873596ce.

 mm/compaction.c | 49 -
 1 file changed, 32 insertions(+), 17 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index a3d2b132df52..e0e439b105b5 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -862,6 +862,7 @@ isolate_migratepages_block(struct compact_control *cc, 
unsigned long low_pfn,
 
/* Time to isolate some pages for migration */
for (; low_pfn < end_pfn; low_pfn++) {
+   bool is_dirty, is_unevictable;
 
if (skip_on_failure && low_pfn >= next_skip_pfn) {
/*
@@ -1047,10 +1048,6 @@ isolate_migratepages_block(struct compact_control *cc, 
unsigned long low_pfn,
if (!mapping && (folio_ref_count(folio) - 1) > 
folio_mapcount(folio))
goto isolate_fail_put;
 
-   /* The mapping truly isn't movable. */
-   if (mapping && mapping_unmovable(mapping))
-   goto isolate_fail_put;
-
/*
 * Only allow to migrate anonymous pages in GFP_NOFS context
 * because those do not depend on fs locks.
@@ -1062,8 +1059,10 @@ isolate_migratepages_block(struct compact_control *cc, 
unsigned long low_pfn,
if (!folio_test_lru(folio))
goto isolate_fail_put;
 
+   is_unevictable = folio_test_unevictable(folio);
+
/* Compaction might skip unevictable pages but CMA takes them */
-   if (!(mode & ISOLATE_UNEVICTABLE) && 
folio_test_unevictable(folio))
+   if (!(mode & ISOLATE_UNEVICTABLE) && is_unevictable)
goto isolate_fail_put;
 
/*
@@ -1075,26 +1074,42 @@ isolate_migratepages_block(struct compact_control *cc, 
unsigned long low_pfn,
if ((mode & ISOLATE_ASYNC_MIGRATE) && 
folio_test_writeback(folio))
goto isolate_fail_put;
 
-   if ((mode & ISOLATE_ASYNC_MIGRATE) && folio_test_dirty(folio)) {
-   bool migrate_dirty;
+   is_dirty = folio_test_dirty(folio);
+
+   if (((mode & ISOLATE_ASYNC_MIGRATE) && is_dirty)
+   || (mapping && is_unevictable)) {
+   bool migrate_dirty = true;
+   bool is_unmovable;
 
/*
-* Only pages without mappings or that have a
-* ->migrate_folio callback are possible to migrate
-* without blocking. However, we can be racing with
-* truncation so it's necessary to lock the page
-* to stabilise the mapping as truncation holds
-* the page lock until after the page is removed
-* from the page cache.
+* Only folios without mappings or that have
+* a ->migrate_folio callback are possible to migrate
+* without blocking.
+*
+* Folios from unmovable mappings are not migratable.
+*
+* However, we can be racing with truncation, which can
+* free the mapping that we need to check. Truncation
+* holds the folio lock until after the folio is removed
+* from the page so holding it ourselves is sufficient.
+*
+* To avoid this folio locking to inspect every folio
+* with mapping for being unmovable, we assume every
+* such folio is also unevictable, which is a cheaper
+* test. If our assumption goes wrong, it's not a bug,
+* just potentially wasted cycles.
 */
if (!folio_trylock(folio))
goto isolate_fail_put;
 
mapping = folio_mapping(folio);
-   migrate_dirty = !mapping ||
-   mapping->a_ops->migrate_folio;
+   if ((mode & ISOLATE_ASYNC_MIGRATE) && is_dirty) {
+   migrate_dirty = !mapping ||
+   

Re: [PATCH v3] kbuild: Show marked Kconfig fragments in "help"

2023-09-01 Thread Masahiro Yamada
On Fri, Sep 1, 2023 at 4:13 AM Kees Cook  wrote:
>
> Currently the Kconfig fragments in kernel/configs and arch/*/configs
> that aren't used internally aren't discoverable through "make help",
> which consists of hard-coded lists of config fragments. Instead, list
> all the fragment targets that have a "# Help: " comment prefix so the
> targets can be generated dynamically.
>
> Add logic to the Makefile to search for and display the fragment and
> comment. Add comments to fragments that are intended to be direct targets.
>
> Cc: Nicolas Schier 
> Cc: Michael Ellerman 
> Cc: Christophe Leroy 
> Cc: Randy Dunlap 
> Cc: linux-ker...@vger.kernel.org
> Cc: x...@kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ri...@lists.infradead.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux-kbu...@vger.kernel.org
> Cc: linux-harden...@vger.kernel.org
> Signed-off-by: Kees Cook 
> Co-developed-by: Masahiro Yamada 
> ---
> v3:
> - Use Makefile logic from Masahiro Yamada
> - Use "# Help: " prefix, but only on desired fragment targets
> v2: https://lore.kernel.org/all/20230825194329.gonna.911-k...@kernel.org
> v1: https://lore.kernel.org/all/20230824223606.never.762-k...@kernel.org
> ---
>  Makefile   |  1 -
>  arch/arm/configs/dram_0x.config|  1 +
>  arch/arm/configs/dram_0xc000.config|  1 +
>  arch/arm/configs/dram_0xd000.config|  1 +
>  arch/arm/configs/lpae.config   |  1 +
>  arch/arm64/configs/virt.config |  1 +
>  arch/powerpc/configs/disable-werror.config |  1 +
>  arch/powerpc/configs/security.config   |  4 +++-
>  arch/riscv/configs/32-bit.config   |  1 +
>  arch/riscv/configs/64-bit.config   |  1 +
>  arch/s390/configs/btf.config   |  1 +
>  arch/s390/configs/kasan.config |  1 +
>  arch/x86/Makefile  |  4 
>  kernel/configs/debug.config|  2 ++
>  kernel/configs/kvm_guest.config|  1 +
>  kernel/configs/nopm.config |  2 ++
>  kernel/configs/rust.config |  1 +
>  kernel/configs/tiny.config |  2 ++
>  kernel/configs/x86_debug.config|  1 +
>  kernel/configs/xen.config  |  2 ++
>  scripts/kconfig/Makefile   | 15 ---
>  21 files changed, 36 insertions(+), 9 deletions(-)
>


Just one thing.





> diff --git a/kernel/configs/tiny.config b/kernel/configs/tiny.config
> index 9f7d0835..60a4b6d80b36 100644
> --- a/kernel/configs/tiny.config
> +++ b/kernel/configs/tiny.config
> @@ -1,3 +1,5 @@
> +# Help: Size-optimized kernel image


I will drop this.


We already have a hard-coded help message.

  tinyconfig   - Configure the tiniest possible kernel




Then, some lines below, again.

  tiny.config   - Size-optimized kernel image



tiny.config is for internal use for tinyconfig.




-- 
Best Regards
Masahiro Yamada


Re: KASAN debug kernel fails to boot at early stage when CONFIG_SMP=y is set (kernel 6.5-rc5, PowerMac G4 3,6)

2023-09-01 Thread Christophe Leroy


Le 01/09/2023 à 00:44, Erhard Furtner a écrit :
> On Thu, 31 Aug 2023 05:32:46 +
> Christophe Leroy  wrote:
> 
>> Ok so there is some corrupted memory somewhere.
>>
>> Can you try what happens when you remove the call to kasan_init() at the
>> start of setup_arch() in arch/powerpc/kernel/setup-common.c
> 
> Ok, so I left the other patches in place + btext_map() instead of 
> btext_unmap() at the end of MMU_init() + Michaels patch and additionally 
> commented-out kasan_init() as stated above. The outcome is rather 
> interesting! Now I deterministically get this output at boot OF console, 
> regardless wheter it's a cold boot or warm boot:

Ah, my bad. You also need to remove the call to kasan_late_init() in 
mem_init() in arch/powerpc/mm/mem.c

Nevertheless, your result is interesting as it shows that the boot goes 
much further when we don't initialise KASAN.

It probably means that kasan_init() messed up things. I will try to dig 
a bit more in kasan_init() and see what we can look at.

Christophe

> 
> via-pmu: Server Mode is disabled
> PMU driver v2 initialized for Core99, firmware: 0c
> ioremap() called early from pmac_nvram_init+0x208/0x7c0. Use early_ioremap() 
> instead
> nvram: Checking bank 0...
> nvram: gen0=3234, gen1=3235
> nvram: Active bank is: 1
> nvram: OF partition at 0x410
> nvram: XP partition at 0x1020
> nvram: NR partition at 0x1120
> Top of RAM: 0x8000, Total RAM: 0x8000
> Memory hole size: 0MB
> Zone ranges:
>DMA  [mem 0x-0x2fff]
>Normal   empty
>HighMem  [mem 0x3000-0x7fff]
> Movable zone start for each node
> Early memory node ranges
>node   0: [mem 0x-0x7fff]
> Initmem setup node 0 [mem 0x-0x7fff]
> percpu: Embedded 14 pages/cpu s24608 r8192 d24544 u57344
> pcpu-alloc: s24608 r8192 d24544 u57344 alloc=14*4096
> pcpu-alloc: [0] 0
> Kernel command line: ro root=/dev/sda5 nr_cpus=1 zswap.max_pool_percent=16 
> slub_debug=FZP page_poison=1 
> netconsole=@192.168.178.8/eth0,@192.168.178.3/70:85:C2:30:EC:01 
> init=/usr/lib/systemd/systemd
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
> Built 1 zonelists, mobility grouping on.  Total pages: 522560
> mem auto-init: stack:all(pattern), heap alloc:off, heap free:off
> stackdepot: allocating hash table via alloc_large_system_hash
> stackdepot hash table entries: 1048576 (order: 10, 4194304 bytes, linear)
> ==
> BUG: KASAN: stack-out-of-bounds in __kernel_poison_pages+0x6c/0xd0
> Write of size 4896 at addr c17a7000 by task swapper/0
> 
> CPU: 0 PID: 0 Comm: swapper Tainted: GT 
> 6.5.0-rc7-PMacG4-dirty #7
> Hardware name: PowerMac3,6 7455 0x80010303 PowerMac
> Call Trace:
> [c1717ce0] [c0f4ec40] dump_stack_lvl+0x60/0xa4 (unreliable)
> [c1717d00] [c0368380] print_report+0x154/0x548
> [c1717d50] [c036813c] kasan_report+0xd0/0x160
> [c1717db0] [c0369bb4] kasan_check_range+0x1c8/0x308
> [c1717dc0] [c036ae88] memset+0x34/0x90
> [c1717de0] [c035b6e0] __kernel_poison_pages+0x6c/0xd0
> [c1717e00] [c03355e4] __free_pages_ok+0x418/0x500
> [c1717e60] [c14372c8] memblock_free_all+0x268/0x400
> [c1717f20] [c14103fc] mem_init+0x8c/0x274
> [c1717f60] [c1431cd0] mm_core_init+0x240/0x4e0
> [c1717fc0] [c1404694] start_kernel+0x150/0x2d8
> [c1717f00] [35d0] 0x35d0
> 
> The buggy address belongs to the physical page:
> page:(ptrval) refcount:0 mapcount:0 mapping: index:0x0 pfn:0x17a7
> flags: 0x0(zone=0)
> page_type: 0x()
> raw:  eee15380 eee15380     
> raw: 
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>   c17a7d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   c17a7d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> c17a7e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
>   ^
>   c17a7e80: f1 f1 04 f2 04 f2 00 f3 f3 f3 00 00 00 00 00 00
>   c17a7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==
> Disabling lock debugging due to kernel taint
> 
>> I'd also be curious to know what happens when CONFIG_DEBUG_SPINLOCK is
>> disabled.
> 
> Disabling CONFIG_DEBUG_SPINLOCK does not change the output above. ^^
> 
>> Another question which I'm no sure I asked already: Is it a new problem
>> you have got with recent kernels or is it just that you never tried such
>> a config with older kernels ?
> 
> I wanted to revisit https://bugzilla.kernel.org/show_bug.cgi?id=216041 and 
> verify whether it was resolved. KASAN worked around 2019-2021 on my G4 as I 
> reported some bugs with it around that time and you fixed some of the bugs. 
> ;) Like kernel bugzilla #205099, #216190, #205885.
> 

Re: Framebuffer mmap on PowerPC

2023-09-01 Thread Thomas Zimmermann

Hi

Am 31.08.23 um 19:38 schrieb Christophe Leroy:



Le 31/08/2023 à 16:41, Thomas Zimmermann a écrit :

Hi,

there's a per-architecture function called fb_pgprotect() that sets
VMA's vm_page_prot for mmaped framebuffers. Most architectures use a
simple implementation based on pgprot_writecomine() [1] or
pgprot_noncached(). [2]

On PPC this function uses phys_mem_access_prot() and therefore requires
the mmap call's file struct. [3] Removing the file argument would help
with simplifying the caller of fb_pgprotect(). [4]

Why is the file even required on PPC?

Is it possible to replace phys_mem_access_prot() with something simpler
that does not use the file struct?


Looks like phys_mem_access_prot() defaults to calling pgprot_noncached()
see
https://elixir.bootlin.com/linux/v6.5/source/arch/powerpc/mm/mem.c#L37
but for a few platforms that's superseeded by
pci_phys_mem_access_prot(), see
https://elixir.bootlin.com/linux/v6.5/source/arch/powerpc/kernel/pci-common.c#L524

However, as far as I can see pci_phys_mem_access_prot() doesn't use file
so you could likely drop that argument on phys_mem_access_prot() on
powerpc. But when I for instance look at arm, I see that the file
argument is used, see
https://elixir.bootlin.com/linux/v6.5/source/arch/arm/mm/mmu.c#L713


Right, I've seen these various implementations. Luckily, the ARM 
framebuffers use a plain pgprot_writecombine() without any references on 
to file.




So, the simplest is maybe the following, allthough that's probably worth
a comment:


Could we drop the file argument from PPC's internal functions and 
provide this interface to fb_pgprotect()? phys_mem_access_prot() would 
be a trivial wrapper around that internal API. I'd provide a patch to do 
that.


Best regards
Thomas



diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/fb.h
index 5f1a2e5f7654..8b9b856f476e 100644
--- a/arch/powerpc/include/asm/fb.h
+++ b/arch/powerpc/include/asm/fb.h
@@ -6,10 +6,9 @@

   #include 

-static inline void fb_pgprotect(struct file *file, struct
vm_area_struct *vma,
-   unsigned long off)
+static inline void fb_pgprotect(struct vm_area_struct *vma, unsigned
long off)
   {
-   vma->vm_page_prot = phys_mem_access_prot(file, off >> PAGE_SHIFT,
+   vma->vm_page_prot = phys_mem_access_prot(NULL, off >> PAGE_SHIFT,
 vma->vm_end - vma->vm_start,
 vma->vm_page_prot);
   }


Christophe




Best regards
Thomas


[1]
https://elixir.bootlin.com/linux/v6.5/source/include/asm-generic/fb.h#L19
[2]
https://elixir.bootlin.com/linux/v6.5/source/arch/mips/include/asm/fb.h#L11
[3]
https://elixir.bootlin.com/linux/v6.5/source/arch/powerpc/include/asm/fb.h#L12
[4]
https://elixir.bootlin.com/linux/v6.5/source/drivers/video/fbdev/core/fbmem.c#L1299




--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH v2 3/3] kconfig: add dependencies of POWER_RESET for PowerMac

2023-09-01 Thread Christophe Leroy


Le 01/09/2023 à 04:43, Yuan Tan a écrit :
> PowerMac's power off depends on ADB_CUDA to work. Enable it when
> POWER_RESET is set for convenience.
> 
> Suggested-by: Zhangjin Wu 
> Signed-off-by: Yuan Tan 
> ---
>   arch/powerpc/platforms/powermac/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/platforms/powermac/Kconfig 
> b/arch/powerpc/platforms/powermac/Kconfig
> index 130707ec9f99..9e633d7e8367 100644
> --- a/arch/powerpc/platforms/powermac/Kconfig
> +++ b/arch/powerpc/platforms/powermac/Kconfig
> @@ -2,6 +2,7 @@
>   config PPC_PMAC
>   bool "Apple PowerMac based machines"
>   depends on PPC_BOOK3S && CPU_BIG_ENDIAN
> + select ADB_CUDA if POWER_RESET

ADB_CUDA depends on !PPC_PMAC64.

What will happen if PPC_PMAC64 is selected ?

>   select MPIC
>   select FORCE_PCI
>   select PPC_INDIRECT_PCI if PPC32