Re: [PATCH v2 2/3] arch: Remove struct fb_info from video helpers

2024-03-28 Thread Helge Deller

On 3/28/24 14:33, Thomas Zimmermann wrote:

Am 28.03.24 um 12:04 schrieb Helge Deller:

On 3/27/24 21:41, Thomas Zimmermann wrote:

The per-architecture video helpers do not depend on struct fb_info
or anything else from fbdev. Remove it from the interface and replace
fb_is_primary_device() with video_is_primary_device(). The new helper


Since you rename this function, wouldn't something similar to

device_is_primary_display()
or
device_is_primary_console()
or
is_primary_graphics_device()
or
is_primary_display_device()

be a better name?


The video_ prefix is there to signal that the code is part of the video 
subsystem.

But there's too much code that tried to figure out a default video
device. So I actually have different plans for this function. I'd
like to replace it with a helper that returns the default device
instead of just testing for it. Sample code for x86 is already in
vgaarb.c. [1] The function's name would then be
video_default_device() and return the appropriate struct device*.
video_is_primary device() will be removed. This rename here is the
easiest step towards the new helper. Ok?

Sounds ok.

Helge


Re: [PATCH v2 3/3] arch: Rename fbdev header and source files

2024-03-28 Thread Helge Deller

On 3/27/24 21:41, Thomas Zimmermann wrote:

The per-architecture fbdev code has no dependencies on fbdev and can
be used for any video-related subsystem. Rename the files to 'video'.
Use video-sti.c on parisc as the source file depends on CONFIG_STI_CORE.

Further update all includes statements, includ guards, and Makefiles.
Also update a few strings and comments to refer to video instead of
fbdev.

Signed-off-by: Thomas Zimmermann 
Cc: Vineet Gupta 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Huacai Chen 
Cc: WANG Xuerui 
Cc: Geert Uytterhoeven 
Cc: Thomas Bogendoerfer 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: John Paul Adrian Glaubitz 
Cc: "David S. Miller" 
Cc: Andreas Larsson 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
---
  arch/arc/include/asm/fb.h|  8 
  arch/arc/include/asm/video.h |  8 
  arch/arm/include/asm/fb.h|  6 --
  arch/arm/include/asm/video.h |  6 ++
  arch/arm64/include/asm/fb.h  | 10 --
  arch/arm64/include/asm/video.h   | 10 ++
  arch/loongarch/include/asm/{fb.h => video.h} |  8 
  arch/m68k/include/asm/{fb.h => video.h}  |  8 
  arch/mips/include/asm/{fb.h => video.h}  | 12 ++--
  arch/parisc/include/asm/{fb.h => video.h}|  8 
  arch/parisc/video/Makefile   |  2 +-
  arch/parisc/video/{fbdev.c => video-sti.c}   |  2 +-
  arch/powerpc/include/asm/{fb.h => video.h}   |  8 
  arch/powerpc/kernel/pci-common.c |  2 +-
  arch/sh/include/asm/fb.h |  7 ---
  arch/sh/include/asm/video.h  |  7 +++
  arch/sparc/include/asm/{fb.h => video.h} |  8 
  arch/sparc/video/Makefile|  2 +-
  arch/sparc/video/{fbdev.c => video.c}|  4 ++--
  arch/x86/include/asm/{fb.h => video.h}   |  8 
  arch/x86/video/Makefile  |  2 +-
  arch/x86/video/{fbdev.c => video.c}  |  3 ++-
  include/asm-generic/Kbuild   |  2 +-
  include/asm-generic/{fb.h => video.h}|  6 +++---
  include/linux/fb.h   |  2 +-
  25 files changed, 75 insertions(+), 74 deletions(-)
  delete mode 100644 arch/arc/include/asm/fb.h
  create mode 100644 arch/arc/include/asm/video.h
  delete mode 100644 arch/arm/include/asm/fb.h
  create mode 100644 arch/arm/include/asm/video.h
  delete mode 100644 arch/arm64/include/asm/fb.h
  create mode 100644 arch/arm64/include/asm/video.h
  rename arch/loongarch/include/asm/{fb.h => video.h} (86%)
  rename arch/m68k/include/asm/{fb.h => video.h} (86%)
  rename arch/mips/include/asm/{fb.h => video.h} (76%)
  rename arch/parisc/include/asm/{fb.h => video.h} (68%)
  rename arch/parisc/video/{fbdev.c => video-sti.c} (96%)
  rename arch/powerpc/include/asm/{fb.h => video.h} (76%)
  delete mode 100644 arch/sh/include/asm/fb.h
  create mode 100644 arch/sh/include/asm/video.h
  rename arch/sparc/include/asm/{fb.h => video.h} (89%)
  rename arch/sparc/video/{fbdev.c => video.c} (86%)
  rename arch/x86/include/asm/{fb.h => video.h} (77%)
  rename arch/x86/video/{fbdev.c => video.c} (97%)
  rename include/asm-generic/{fb.h => video.h} (96%)

diff --git a/arch/arc/include/asm/fb.h b/arch/arc/include/asm/fb.h
deleted file mode 100644
index 9c2383d29cbb9..0
--- a/arch/arc/include/asm/fb.h
+++ /dev/null
@@ -1,8 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-
-#ifndef _ASM_FB_H_
-#define _ASM_FB_H_
-
-#include 
-
-#endif /* _ASM_FB_H_ */
diff --git a/arch/arc/include/asm/video.h b/arch/arc/include/asm/video.h
new file mode 100644
index 0..8ff7263727fe7
--- /dev/null
+++ b/arch/arc/include/asm/video.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_VIDEO_H_
+#define _ASM_VIDEO_H_
+
+#include 
+
+#endif /* _ASM_VIDEO_H_ */


I wonder, since that file simply #includes the generic version,
wasn't there a possibility that kbuild could symlink
the generic version for us?
Does it need to be mandatory in include/asm-generic/Kbuild ?
Same applies to a few other files below.

Helge




diff --git a/arch/arm/include/asm/fb.h b/arch/arm/include/asm/fb.h
deleted file mode 100644
index ce20a43c30339..0
--- a/arch/arm/include/asm/fb.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef _ASM_FB_H_
-#define _ASM_FB_H_
-
-#include 
-
-#endif /* _ASM_FB_H_ */
diff --git a/arch/arm/include/asm/video.h b/arch/arm/include/asm/video.h
new file mode 100644
index 0..f570565366e67
--- /dev/null
+++ b/arch/arm/include/asm/video.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_VIDEO_H_
+#define _ASM_VIDEO_H_
+
+#include 
+
+#endif /* _ASM_VIDEO_H_ */
diff --git a/arch/a

Re: [PATCH v2 1/3] arch: Select fbdev helpers with CONFIG_VIDEO

2024-03-28 Thread Helge Deller

On 3/27/24 21:41, Thomas Zimmermann wrote:

Various Kconfig options selected the per-architecture helpers for
fbdev. But none of the contained code depends on fbdev. Standardize
on CONFIG_VIDEO, which will allow to add more general helpers for
video functionality.

CONFIG_VIDEO protects each architecture's video/ directory.


Your patch in general looks good.
But is renaming the config option from CONFIG_FB_CORE to CONFIG_VIDEO
the best choice?
CONFIG_VIDEO might be mixed up with multimedia/video-streaming.

Why not e.g. CONFIG_GRAPHICS_CORE?
I'm fine with CONFIG_VIDEO as well, but if someone has a better idea
we maybe should go with that instead now?

Helge


This
allows for the use of more fine-grained control for each directory's
files, such as the use of CONFIG_STI_CORE on parisc.

v2:
- sparc: rebased onto Makefile changes

Signed-off-by: Thomas Zimmermann 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: "David S. Miller" 
Cc: Andreas Larsson 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
---
  arch/parisc/Makefile  | 2 +-
  arch/sparc/Makefile   | 4 ++--
  arch/sparc/video/Makefile | 2 +-
  arch/x86/Makefile | 2 +-
  arch/x86/video/Makefile   | 3 ++-
  5 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index 316f84f1d15c8..21b8166a68839 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -119,7 +119,7 @@ export LIBGCC

  libs-y+= arch/parisc/lib/ $(LIBGCC)

-drivers-y += arch/parisc/video/
+drivers-$(CONFIG_VIDEO) += arch/parisc/video/

  boot  := arch/parisc/boot

diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
index 2a03daa68f285..757451c3ea1df 100644
--- a/arch/sparc/Makefile
+++ b/arch/sparc/Makefile
@@ -59,8 +59,8 @@ endif
  libs-y += arch/sparc/prom/
  libs-y += arch/sparc/lib/

-drivers-$(CONFIG_PM) += arch/sparc/power/
-drivers-$(CONFIG_FB_CORE) += arch/sparc/video/
+drivers-$(CONFIG_PM)+= arch/sparc/power/
+drivers-$(CONFIG_VIDEO) += arch/sparc/video/

  boot := arch/sparc/boot

diff --git a/arch/sparc/video/Makefile b/arch/sparc/video/Makefile
index d4d83f1702c61..9dd82880a027a 100644
--- a/arch/sparc/video/Makefile
+++ b/arch/sparc/video/Makefile
@@ -1,3 +1,3 @@
  # SPDX-License-Identifier: GPL-2.0-only

-obj-$(CONFIG_FB_CORE) += fbdev.o
+obj-y  += fbdev.o
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 15a5f4f2ff0aa..c0ea612c62ebe 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -265,7 +265,7 @@ drivers-$(CONFIG_PCI)+= arch/x86/pci/
  # suspend and hibernation support
  drivers-$(CONFIG_PM) += arch/x86/power/

-drivers-$(CONFIG_FB_CORE) += arch/x86/video/
+drivers-$(CONFIG_VIDEO) += arch/x86/video/

  
  # boot loader support. Several targets are kept for legacy purposes
diff --git a/arch/x86/video/Makefile b/arch/x86/video/Makefile
index 5ebe48752ffc4..9dd82880a027a 100644
--- a/arch/x86/video/Makefile
+++ b/arch/x86/video/Makefile
@@ -1,2 +1,3 @@
  # SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_FB_CORE)  += fbdev.o
+
+obj-y  += fbdev.o




Re: [PATCH v2 2/3] arch: Remove struct fb_info from video helpers

2024-03-28 Thread Helge Deller

On 3/27/24 21:41, Thomas Zimmermann wrote:

The per-architecture video helpers do not depend on struct fb_info
or anything else from fbdev. Remove it from the interface and replace
fb_is_primary_device() with video_is_primary_device(). The new helper


Since you rename this function, wouldn't something similar to

device_is_primary_display()
or
device_is_primary_console()
or
is_primary_graphics_device()
or
is_primary_display_device()

be a better name?

Helge


is similar in functionality, but can operate on non-fbdev devices.

Signed-off-by: Thomas Zimmermann 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: "David S. Miller" 
Cc: Andreas Larsson 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
---
  arch/parisc/include/asm/fb.h |  8 +---
  arch/parisc/video/fbdev.c|  9 +
  arch/sparc/include/asm/fb.h  |  7 ---
  arch/sparc/video/fbdev.c | 17 -
  arch/x86/include/asm/fb.h|  8 +---
  arch/x86/video/fbdev.c   | 18 +++---
  drivers/video/fbdev/core/fbcon.c |  2 +-
  include/asm-generic/fb.h | 11 ++-
  8 files changed, 41 insertions(+), 39 deletions(-)

diff --git a/arch/parisc/include/asm/fb.h b/arch/parisc/include/asm/fb.h
index 658a8a7dc5312..ed2a195a3e762 100644
--- a/arch/parisc/include/asm/fb.h
+++ b/arch/parisc/include/asm/fb.h
@@ -2,11 +2,13 @@
  #ifndef _ASM_FB_H_
  #define _ASM_FB_H_

-struct fb_info;
+#include 
+
+struct device;

  #if defined(CONFIG_STI_CORE)
-int fb_is_primary_device(struct fb_info *info);
-#define fb_is_primary_device fb_is_primary_device
+bool video_is_primary_device(struct device *dev);
+#define video_is_primary_device video_is_primary_device
  #endif

  #include 
diff --git a/arch/parisc/video/fbdev.c b/arch/parisc/video/fbdev.c
index e4f8ac99fc9e0..540fa0c919d59 100644
--- a/arch/parisc/video/fbdev.c
+++ b/arch/parisc/video/fbdev.c
@@ -5,12 +5,13 @@
   * Copyright (C) 2001-2002 Thomas Bogendoerfer 
   */

-#include 
  #include 

  #include 

-int fb_is_primary_device(struct fb_info *info)
+#include 
+
+bool video_is_primary_device(struct device *dev)
  {
struct sti_struct *sti;

@@ -21,6 +22,6 @@ int fb_is_primary_device(struct fb_info *info)
return true;

/* return true if it's the default built-in framebuffer driver */
-   return (sti->dev == info->device);
+   return (sti->dev == dev);
  }
-EXPORT_SYMBOL(fb_is_primary_device);
+EXPORT_SYMBOL(video_is_primary_device);
diff --git a/arch/sparc/include/asm/fb.h b/arch/sparc/include/asm/fb.h
index 24440c0fda490..07f0325d6921c 100644
--- a/arch/sparc/include/asm/fb.h
+++ b/arch/sparc/include/asm/fb.h
@@ -3,10 +3,11 @@
  #define _SPARC_FB_H_

  #include 
+#include 

  #include 

-struct fb_info;
+struct device;

  #ifdef CONFIG_SPARC32
  static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
@@ -18,8 +19,8 @@ static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
  #define pgprot_framebuffer pgprot_framebuffer
  #endif

-int fb_is_primary_device(struct fb_info *info);
-#define fb_is_primary_device fb_is_primary_device
+bool video_is_primary_device(struct device *dev);
+#define video_is_primary_device video_is_primary_device

  static inline void fb_memcpy_fromio(void *to, const volatile void __iomem 
*from, size_t n)
  {
diff --git a/arch/sparc/video/fbdev.c b/arch/sparc/video/fbdev.c
index bff66dd1909a4..e46f0499c2774 100644
--- a/arch/sparc/video/fbdev.c
+++ b/arch/sparc/video/fbdev.c
@@ -1,26 +1,25 @@
  // SPDX-License-Identifier: GPL-2.0

  #include 
-#include 
+#include 
  #include 

+#include 
  #include 

-int fb_is_primary_device(struct fb_info *info)
+bool video_is_primary_device(struct device *dev)
  {
-   struct device *dev = info->device;
-   struct device_node *node;
+   struct device_node *node = dev->of_node;

if (console_set_on_cmdline)
-   return 0;
+   return false;

-   node = dev->of_node;
if (node && node == of_console_device)
-   return 1;
+   return true;

-   return 0;
+   return false;
  }
-EXPORT_SYMBOL(fb_is_primary_device);
+EXPORT_SYMBOL(video_is_primary_device);

  MODULE_DESCRIPTION("Sparc fbdev helpers");
  MODULE_LICENSE("GPL");
diff --git a/arch/x86/include/asm/fb.h b/arch/x86/include/asm/fb.h
index c3b9582de7efd..999db33792869 100644
--- a/arch/x86/include/asm/fb.h
+++ b/arch/x86/include/asm/fb.h
@@ -2,17 +2,19 @@
  #ifndef _ASM_X86_FB_H
  #define _ASM_X86_FB_H

+#include 
+
  #include 

-struct fb_info;
+struct device;

  pgprot_t pgprot_framebuffer(pgprot_t prot,
unsigned long vm_start, unsigned long vm_end,
unsigned long offset);
  #define pgprot_framebuffer pgprot_framebuffer

-int fb_is_primary_device(struct fb_info *info);
-#de

Re: [PATCH 10/14] parisc: Add support for suppressing warning backtraces

2024-03-15 Thread Helge Deller

On 3/12/24 18:03, Guenter Roeck wrote:

Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.

To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_KUNIT and CONFIG_DEBUG_BUGVERBOSE
are enabled. Otherwise, the __func__ assembly parameter is replaced with a
(dummy) NULL parameter to avoid an image size increase due to unused
__func__ entries (this is necessary because __func__ is not a define but a
virtual variable).

While at it, declare assembler parameters as constants where possible.
Refine .blockz instructions to calculate the necessary padding instead
of using fixed values.

Signed-off-by: Guenter Roeck 



Acked-by: Helge Deller 

Helge



---
  arch/parisc/include/asm/bug.h | 29 +
  1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/arch/parisc/include/asm/bug.h b/arch/parisc/include/asm/bug.h
index 833555f74ffa..792dacc2a653 100644
--- a/arch/parisc/include/asm/bug.h
+++ b/arch/parisc/include/asm/bug.h
@@ -23,8 +23,17 @@
  # define __BUG_REL(val) ".word " __stringify(val)
  #endif

-
  #ifdef CONFIG_DEBUG_BUGVERBOSE
+
+#if IS_ENABLED(CONFIG_KUNIT)
+# define HAVE_BUG_FUNCTION
+# define __BUG_FUNC_PTR__BUG_REL(%c1)
+# define __BUG_FUNC__func__
+#else
+# define __BUG_FUNC_PTR
+# define __BUG_FUNCNULL
+#endif /* IS_ENABLED(CONFIG_KUNIT) */
+
  #define BUG() \
do {\
asm volatile("\n" \
@@ -33,10 +42,12 @@
 "\t.align 4\n"   \
 "2:\t" __BUG_REL(1b) "\n"  \
 "\t" __BUG_REL(%c0)  "\n"  \
-"\t.short %1, %2\n"  \
-"\t.blockz %3-2*4-2*2\n" \
+"\t" __BUG_FUNC_PTR  "\n"  \
+"\t.short %c2, %c3\n"\
+"\t.blockz %c4-(.-2b)\n" \
 "\t.popsection"  \
-: : "i" (__FILE__), "i" (__LINE__),\
+: : "i" (__FILE__), "i" (__BUG_FUNC),  \
+"i" (__LINE__),  \
 "i" (0), "i" (sizeof(struct bug_entry)) ); \
unreachable();  \
} while(0)
@@ -58,10 +69,12 @@
 "\t.align 4\n"   \
 "2:\t" __BUG_REL(1b) "\n"  \
 "\t" __BUG_REL(%c0)  "\n"  \
-"\t.short %1, %2\n"  \
-"\t.blockz %3-2*4-2*2\n" \
+"\t" __BUG_FUNC_PTR  "\n"  \
+"\t.short %c2, %3\n" \
+"\t.blockz %c4-(.-2b)\n" \
 "\t.popsection"  \
-: : "i" (__FILE__), "i" (__LINE__),\
+: : "i" (__FILE__), "i" (__BUG_FUNC),  \
+"i" (__LINE__),  \
 "i" (BUGFLAG_WARNING|(flags)),   \
 "i" (sizeof(struct bug_entry)) );\
} while(0)
@@ -74,7 +87,7 @@
 "\t.align 4\n"   \
 "2:\t" __BUG_REL(1b) "\n"  \
 "\t.short %0\n"  \
-"\t.blockz %1-4-2\n" \
+"\t.blockz %c1-(.-2b)\n" \
 "\t.popsection"  \
 : : "i" (BUGFLAG_WARNING|(flags)),   \
 "i" (sizeof(struct bug_entry)) );\




Re: [PATCH] fbdev/mb862xxfb: Fix defined but not used error

2024-03-15 Thread Helge Deller

On 2/29/24 12:50, Michael Ellerman wrote:

socrates_gc_mode is defined at the top-level but then only used inside
an #ifdef CONFIG_FB_MB862XX_LIME, leading to an error with some configs:

   drivers/video/fbdev/mb862xx/mb862xxfbdrv.c:36:31: error: ‘socrates_gc_mode’ 
defined but not used
  36 | static struct mb862xx_gc_mode socrates_gc_mode = {

Fix it by moving socrates_gc_mode inside that ifdef, immediately prior
to the only function where it's used.

Signed-off-by: Michael Ellerman 


applied.
Thanks!
Helge


---
  drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c 
b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
index 7c402e9fd7a9..baec312d7b33 100644
--- a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
+++ b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
@@ -32,15 +32,6 @@
  #define CARMINE_MEM_SIZE  0x800
  #define DRV_NAME  "mb862xxfb"

-#if defined(CONFIG_SOCRATES)
-static struct mb862xx_gc_mode socrates_gc_mode = {
-   /* Mode for Prime View PM070WL4 TFT LCD Panel */
-   { "800x480", 45, 800, 480, 4, 86, 42, 33, 10, 128, 2, 0, 0, 0 },
-   /* 16 bits/pixel, 16MB, 133MHz, SDRAM memory mode value */
-   16, 0x100, GC_CCF_COT_133, 0x4157ba63
-};
-#endif
-
  /* Helpers */
  static inline int h_total(struct fb_var_screeninfo *var)
  {
@@ -666,6 +657,15 @@ static int mb862xx_gdc_init(struct mb862xxfb_par *par)
return 0;
  }

+#if defined(CONFIG_SOCRATES)
+static struct mb862xx_gc_mode socrates_gc_mode = {
+   /* Mode for Prime View PM070WL4 TFT LCD Panel */
+   { "800x480", 45, 800, 480, 4, 86, 42, 33, 10, 128, 2, 0, 0, 0 },
+   /* 16 bits/pixel, 16MB, 133MHz, SDRAM memory mode value */
+   16, 0x100, GC_CCF_COT_133, 0x4157ba63
+};
+#endif
+
  static int of_platform_mb862xx_probe(struct platform_device *ofdev)
  {
struct device_node *np = ofdev->dev.of_node;




Re: [PATCH 2/4] arch: simplify architecture specific page size configuration

2024-02-27 Thread Helge Deller

On 2/26/24 17:14, Arnd Bergmann wrote:

From: Arnd Bergmann 

arc, arm64, parisc and powerpc all have their own Kconfig symbols
in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
so the common symbols are the ones that are actually used, while
leaving the arhcitecture specific ones as the user visible
place for configuring it, to avoid breaking user configs.

Signed-off-by: Arnd Bergmann 
---
  arch/arc/Kconfig  |  3 +++
  arch/arc/include/uapi/asm/page.h  |  6 ++
  arch/arm64/Kconfig| 29 +
  arch/arm64/include/asm/page-def.h |  2 +-
  arch/parisc/Kconfig   |  3 +++
  arch/parisc/include/asm/page.h| 10 +-


Acked-by: Helge Deller  # parisc

Thanks for the cleanups!

Helge



Re: [PATCH 2/9] parisc: Remove

2023-08-17 Thread Helge Deller

On 8/17/23 18:07, Geert Uytterhoeven wrote:

As of commit b7fb14d3ac63117e ("ide: remove the legacy ide driver") in
v5.14, there are no more generic users of .

Signed-off-by: Geert Uytterhoeven 


Acked-by: Helge Deller 

Thanks!
Helge


---
  arch/parisc/include/asm/ide.h | 54 ---
  1 file changed, 54 deletions(-)
  delete mode 100644 arch/parisc/include/asm/ide.h





Re: linux-next: Tree for Jul 13 (drivers/video/fbdev/ps3fb.c)

2023-07-31 Thread Helge Deller

On 7/18/23 13:48, Michael Ellerman wrote:

Bagas Sanjaya  writes:

On Thu, Jul 13, 2023 at 09:11:10AM -0700, Randy Dunlap wrote:

on ppc64:

In file included from ../include/linux/device.h:15,
  from ../arch/powerpc/include/asm/io.h:22,
  from ../include/linux/io.h:13,
  from ../include/linux/irq.h:20,
  from ../arch/powerpc/include/asm/hardirq.h:6,
  from ../include/linux/hardirq.h:11,
  from ../include/linux/interrupt.h:11,
  from ../drivers/video/fbdev/ps3fb.c:25:
../drivers/video/fbdev/ps3fb.c: In function 'ps3fb_probe':
../drivers/video/fbdev/ps3fb.c:1172:40: error: 'struct fb_info' has no member 
named 'dev'
  1172 |  dev_driver_string(info->dev), dev_name(info->dev),
   |^~
../include/linux/dev_printk.h:110:37: note: in definition of macro 
'dev_printk_index_wrap'
   110 | _p_func(dev, fmt, ##__VA_ARGS__);  
 \
   | ^~~
../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
  1171 | dev_info(info->device, "%s %s, using %u KiB of video memory\n",
   | ^~~~
../drivers/video/fbdev/ps3fb.c:1172:61: error: 'struct fb_info' has no member 
named 'dev'
  1172 |  dev_driver_string(info->dev), dev_name(info->dev),
   | ^~
../include/linux/dev_printk.h:110:37: note: in definition of macro 
'dev_printk_index_wrap'
   110 | _p_func(dev, fmt, ##__VA_ARGS__);  
 \
   | ^~~
../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
  1171 | dev_info(info->device, "%s %s, using %u KiB of video memory\n",
   | ^~~~




Hmm, there is no response from Thomas yet. I guess we should go with
reverting bdb616479eff419, right? Regardless, I'm adding this build regression
to regzbot so that parties involved are aware of it:

#regzbot ^introduced: bdb616479eff419
#regzbot title: build regression in PS3 framebuffer


Does regzbot track issues in linux-next?

They're not really regressions because they're not in a release yet.

Anyway I don't see where bdb616479eff419 comes from.

The issue was introduced by:

   701d2054fa31 fbdev: Make support for userspace interfaces configurable

The driver seems to only use info->dev in that one dev_info() line,
which seems purely cosmetic, so I think it could just be removed, eg:

diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
index d4abcf8aff75..a304a39d712b 100644
--- a/drivers/video/fbdev/ps3fb.c
+++ b/drivers/video/fbdev/ps3fb.c
@@ -1168,8 +1168,7 @@ static int ps3fb_probe(struct ps3_system_bus_device *dev)

ps3_system_bus_set_drvdata(dev, info);

-   dev_info(info->device, "%s %s, using %u KiB of video memory\n",
-dev_driver_string(info->dev), dev_name(info->dev),
+   dev_info(info->device, "using %u KiB of video memory\n",
 info->fix.smem_len >> 10);

task = kthread_run(ps3fbd, info, DEVICE_NAME);



Can you please resend this as proper patch to fbdev and/or drm-misc mailing 
lists?
As it is, it never showed up for me in patchwork...

Helge


Re: [PATCH v2 0/9] video: screen_info cleanups

2023-07-19 Thread Helge Deller

On 7/19/23 14:39, Arnd Bergmann wrote:

From: Arnd Bergmann 

I refreshed the first four patches that I sent before with very minor
updates, and then added some more to further disaggregate the use
of screen_info:

  - I found that powerpc wasn't using vga16fb any more

  - vgacon can be almost entirely separated from the global
screen_info, except on x86

  - similarly, the EFI framebuffer initialization can be
kept separate, except on x86.


Nice cleanup, Arnd!

You may add a
Acked-by: Helge Deller 
to the series.



I did extensive build testing on arm/arm64/x86 and the normal built bot
testing for the other architectures.



Which tree should this get merged through?


I suggest drm-misc or fbdev. Either is fine for me.

Since it applies cleanly onto git head, I can put it a few days into
the fbdev git tree to see if some builds break. Just let me know.

Helge


Re: [PATCH 00/17] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags

2023-07-11 Thread Helge Deller

On 7/11/23 16:47, Sam Ravnborg wrote:

Hi Thomas,

On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:

Hi Sam

Am 10.07.23 um 19:19 schrieb Sam Ravnborg:

Hi Thomas,

On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:

Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
useful when fbdev had special handling for driver modules. With
commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
and have no further effect.

Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
split this by the way the fb_info struct is being allocated. All flags
are cleared to zero during the allocation.

Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
an actual bug in how arch/sh uses the tokne for struct fb_videomode,
which is unrelated.

Patch 17 removes both flag constants from 


We have a few more flags that are unused - should they be nuked too?
FBINFO_HWACCEL_FILLRECT
FBINFO_HWACCEL_ROTATE
FBINFO_HWACCEL_XPAN


It seems those are there for completeness. Nothing sets _ROTATE,


I think some fbdev drivers had hardware acceleration for ROTATE in the
past. HWACCEL_XPAN is still in some drivers.


the others are simply never checked. According to the comments,
some are required, some are optional. I don't know what that
means.


I think it's OK if you remove those flags which aren't used anywhere,
e.g. FBINFO_HWACCEL_ROTATE.


IIRC there were complains about performance when Daniel tried to remove
fbcon acceleration, so not all _HWACCEL_ flags are unneeded.


Correct. I think COPYAREA and FILLRECT are the bare minimum to accelerate
fbcon, IMAGEBLIT is for showing the tux penguin (?),
XPAN/YPAN and YWRAP for some hardware screen panning needed by some drivers
(not sure if this is still used as I don't have such hardware, Geert?).


Leaving them in for reference/completeness might be an option; or not. I
have no strong feelings about those flags.


I'd say drop FBINFO_HWACCEL_ROTATE at least ?


Unused as in no references from fbdev/core/*

I would rather see one series nuke all unused FBINFO flags in one go.
Assuming my quick grep are right and the above can be dropped.


I would not want to extend this series. I'm removing _DEFAULT as it's
absolutely pointless and confusing.


Yes, Ok.

Helge


Re: [PATCH v2 08/23] parisc: add pte_unmap() to balance get_ptep()

2023-06-18 Thread Helge Deller

On 6/8/23 21:18, Hugh Dickins wrote:

To keep balance in future, remember to pte_unmap() after a successful
get_ptep().  And act as if flush_cache_pages() really needs a map there,
to read the pfn before "unmapping", to be sure page table is not removed.

Signed-off-by: Hugh Dickins 


For the parisc parts:

Acked-by: Helge Deller  # parisc

Helge



---
  arch/parisc/kernel/cache.c | 26 +-
  1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index ca4a302d4365..501160250bb7 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -426,10 +426,15 @@ void flush_dcache_page(struct page *page)
offset = (pgoff - mpnt->vm_pgoff) << PAGE_SHIFT;
addr = mpnt->vm_start + offset;
if (parisc_requires_coherency()) {
+   bool needs_flush = false;
pte_t *ptep;

ptep = get_ptep(mpnt->vm_mm, addr);
-   if (ptep && pte_needs_flush(*ptep))
+   if (ptep) {
+   needs_flush = pte_needs_flush(*ptep);
+   pte_unmap(ptep);
+   }
+   if (needs_flush)
flush_user_cache_page(mpnt, addr);
} else {
/*
@@ -561,14 +566,20 @@ EXPORT_SYMBOL(flush_kernel_dcache_page_addr);
  static void flush_cache_page_if_present(struct vm_area_struct *vma,
unsigned long vmaddr, unsigned long pfn)
  {
-   pte_t *ptep = get_ptep(vma->vm_mm, vmaddr);
+   bool needs_flush = false;
+   pte_t *ptep;

/*
 * The pte check is racy and sometimes the flush will trigger
 * a non-access TLB miss. Hopefully, the page has already been
 * flushed.
 */
-   if (ptep && pte_needs_flush(*ptep))
+   ptep = get_ptep(vma->vm_mm, vmaddr);
+   if (ptep) {
+   needs_flush = pte_needs_flush(*ptep);
+   pte_unmap(ptep);
+   }
+   if (needs_flush)
flush_cache_page(vma, vmaddr, pfn);
  }

@@ -635,17 +646,22 @@ static void flush_cache_pages(struct vm_area_struct *vma, 
unsigned long start, u
pte_t *ptep;

for (addr = start; addr < end; addr += PAGE_SIZE) {
+   bool needs_flush = false;
/*
 * The vma can contain pages that aren't present. Although
 * the pte search is expensive, we need the pte to find the
 * page pfn and to check whether the page should be flushed.
 */
ptep = get_ptep(vma->vm_mm, addr);
-   if (ptep && pte_needs_flush(*ptep)) {
+   if (ptep) {
+   needs_flush = pte_needs_flush(*ptep);
+   pfn = pte_pfn(*ptep);
+   pte_unmap(ptep);
+   }
+   if (needs_flush) {
if (parisc_requires_coherency()) {
flush_user_cache_page(vma, addr);
} else {
-   pfn = pte_pfn(*ptep);
if (WARN_ON(!pfn_valid(pfn)))
return;
__flush_cache_page(vma, addr, PFN_PHYS(pfn));




Re: [PATCH] mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED

2023-05-25 Thread Helge Deller

On 5/24/23 02:29, David Rientjes wrote:

On Tue, 23 May 2023, Vlastimil Babka wrote:


As discussed at LSF/MM [1] [2] and with no objections raised there,
deprecate the SLAB allocator. Rename the user-visible option so that
users with CONFIG_SLAB=y get a new prompt with explanation during make
oldconfig, while make olddefconfig will just switch to SLUB.

In all defconfigs with CONFIG_SLAB=y remove the line so those also
switch to SLUB. Regressions due to the switch should be reported to
linux-mm and slab maintainers.

[1] https://lore.kernel.org/all/4b9fc9c6-b48c-198f-5f80-811a44737...@suse.cz/
[2] https://lwn.net/Articles/932201/

Signed-off-by: Vlastimil Babka 


Acked-by: David Rientjes 


I did tested SLUB on parisc with 32- and 64-bit kernel, so you may add:

Acked-by: Helge Deller  # parisc

Helge


Re: [PATCH] procfs: consolidate arch_report_meminfo declaration

2023-05-17 Thread Helge Deller

On 5/16/23 21:57, Arnd Bergmann wrote:

From: Arnd Bergmann 

The arch_report_meminfo() function is provided by four architectures,
with a __weak fallback in procfs itself. On architectures that don't
have a custom version, the __weak version causes a warning because
of the missing prototype.

Remove the architecture specific prototypes and instead add one
in linux/proc_fs.h.

Signed-off-by: Arnd Bergmann 
---
  arch/parisc/include/asm/pgtable.h| 3 ---


Acked-by: Helge Deller  # parisc

Thanks!
Helge



  arch/powerpc/include/asm/pgtable.h   | 3 ---
  arch/s390/include/asm/pgtable.h  | 3 ---
  arch/s390/mm/pageattr.c  | 1 +
  arch/x86/include/asm/pgtable.h   | 1 +
  arch/x86/include/asm/pgtable_types.h | 3 ---
  arch/x86/mm/pat/set_memory.c | 1 +
  include/linux/proc_fs.h  | 2 ++
  8 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/arch/parisc/include/asm/pgtable.h 
b/arch/parisc/include/asm/pgtable.h
index e715df5385d6..5656395c95ee 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -472,9 +472,6 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, 
unsigned long addr,

  #define pte_same(A,B) (pte_val(A) == pte_val(B))

-struct seq_file;
-extern void arch_report_meminfo(struct seq_file *m);
-
  #endif /* !__ASSEMBLY__ */


diff --git a/arch/powerpc/include/asm/pgtable.h 
b/arch/powerpc/include/asm/pgtable.h
index 9972626ddaf6..6a88bfdaa69b 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -165,9 +165,6 @@ static inline bool is_ioremap_addr(const void *x)

return addr >= IOREMAP_BASE && addr < IOREMAP_END;
  }
-
-struct seq_file;
-void arch_report_meminfo(struct seq_file *m);
  #endif /* CONFIG_PPC64 */

  #endif /* __ASSEMBLY__ */
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 6822a11c2c8a..c55f3c3365af 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -42,9 +42,6 @@ static inline void update_page_count(int level, long count)
atomic_long_add(count, _pages_count[level]);
  }

-struct seq_file;
-void arch_report_meminfo(struct seq_file *m);
-
  /*
   * The S390 doesn't have any external MMU info: the kernel page
   * tables contain all the necessary information.
diff --git a/arch/s390/mm/pageattr.c b/arch/s390/mm/pageattr.c
index 5ba3bd8a7b12..ca5a418c58a8 100644
--- a/arch/s390/mm/pageattr.c
+++ b/arch/s390/mm/pageattr.c
@@ -4,6 +4,7 @@
   * Author(s): Jan Glauber 
   */
  #include 
+#include 
  #include 
  #include 
  #include 
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 15ae4d6ba476..5700bb337987 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -27,6 +27,7 @@
  extern pgd_t early_top_pgt[PTRS_PER_PGD];
  bool __init __early_make_pgtable(unsigned long address, pmdval_t pmd);

+struct seq_file;
  void ptdump_walk_pgd_level(struct seq_file *m, struct mm_struct *mm);
  void ptdump_walk_pgd_level_debugfs(struct seq_file *m, struct mm_struct *mm,
   bool user);
diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index 447d4bee25c4..ba3e2554799a 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -513,9 +513,6 @@ extern void native_pagetable_init(void);
  #define native_pagetable_initpaging_init
  #endif

-struct seq_file;
-extern void arch_report_meminfo(struct seq_file *m);
-
  enum pg_level {
PG_LEVEL_NONE,
PG_LEVEL_4K,
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 7159cf787613..d1515756e369 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index 0260f5ea98fe..e981ef830252 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -158,6 +158,8 @@ int proc_pid_arch_status(struct seq_file *m, struct 
pid_namespace *ns,
struct pid *pid, struct task_struct *task);
  #endif /* CONFIG_PROC_PID_ARCH_STATUS */

+extern void arch_report_meminfo(struct seq_file *m);
+
  #else /* CONFIG_PROC_FS */

  static inline void proc_root_init(void)




Re: [PATCH 08/23] parisc: add pte_unmap() to balance get_ptep()

2023-05-13 Thread Helge Deller

Hi Hugh,

On 5/10/23 06:52, Hugh Dickins wrote:

To keep balance in future, remember to pte_unmap() after a successful
get_ptep().  And (we might as well) pretend that flush_cache_pages()
really needed a map there, to read the pfn before "unmapping".

Signed-off-by: Hugh Dickins 
---
  arch/parisc/kernel/cache.c | 26 +-
  1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index 1d3b8bc8a623..b0c969b3a300 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -425,10 +425,15 @@ void flush_dcache_page(struct page *page)
offset = (pgoff - mpnt->vm_pgoff) << PAGE_SHIFT;
addr = mpnt->vm_start + offset;
if (parisc_requires_coherency()) {
+   bool needs_flush = false;
pte_t *ptep;

ptep = get_ptep(mpnt->vm_mm, addr);
-   if (ptep && pte_needs_flush(*ptep))
+   if (ptep) {
+   needs_flush = pte_needs_flush(*ptep);
+   pte_unmap(ptep);
+   }
+   if (needs_flush)
flush_user_cache_page(mpnt, addr);
} else {
/*
@@ -560,14 +565,20 @@ EXPORT_SYMBOL(flush_kernel_dcache_page_addr);
  static void flush_cache_page_if_present(struct vm_area_struct *vma,
unsigned long vmaddr, unsigned long pfn)
  {
-   pte_t *ptep = get_ptep(vma->vm_mm, vmaddr);
+   bool needs_flush = false;
+   pte_t *ptep;

/*
 * The pte check is racy and sometimes the flush will trigger
 * a non-access TLB miss. Hopefully, the page has already been
 * flushed.
 */
-   if (ptep && pte_needs_flush(*ptep))
+   ptep = get_ptep(vma->vm_mm, vmaddr);
+   if (ptep) {
+   needs_flush = pte_needs_flush(*ptep))


^
One ")" too much and lacks a trailing ";"
Should be:
needs_flush = pte_needs_flush(*ptep);

With that fixed the kernel compiles and boots sucessfully on parisc.

Helge


Re: [PATCH 0/3] fbdev: Set missing owner fields in fb_ops

2023-04-24 Thread Helge Deller

On 4/24/23 10:58, Thomas Zimmermann wrote:

Set the owner field of various drivers' fb_ops instance. The
setting is required by fbcon, which acquires a reference on the
fbdev driver's module. Otherwise, users could attempt to unload
the module while it's still in use.

Thomas Zimmermann (3):
   fbdev/68328fb: Init owner field of struct fb_ops
   fbdev/ps3fb: Init owner field of struct fb_ops
   fbdev/vfb: Init owner field of struct fb_ops

  drivers/video/fbdev/68328fb.c | 1 +
  drivers/video/fbdev/ps3fb.c   | 1 +
  drivers/video/fbdev/vfb.c | 1 +
  3 files changed, 3 insertions(+)



Series applied.

Thank you!
Helge


Re: [PATCH v3 00/19] arch: Consolidate

2023-04-19 Thread Helge Deller

Hi Thomas,


Am 17.04.23 um 16:12 schrieb Arnd Bergmann:>> On Mon, Apr 17, 2023, at 14:56, 
Thomas Zimmermann wrote:

Various architectures provide  with helpers for fbdev
framebuffer devices. Share the contained code where possible. There
is already , which implements generic (as in
'empty') functions of the fbdev helpers. The header was added in
commit aafe4dbed0bf ("asm-generic: add generic versions of common
headers"), but never used.

Each per-architecture header file declares and/or implements fbdev
helpers and defines a preprocessor token for each. The generic
header then provides the remaining helpers. It works like the I/O
helpers in .


Looks all good to me,

Acked-by: Arnd Bergmann 


Thanks a lot. I know that Helge wants to test the PARISC changes, so
I'll keep this series pending for a bit longer. I'd like to merge the
patches through the DRM tree, if no one objects.


Yes, patch is good and I've tested it on parisc. Thanks!

You may add:
Acked-by: Helge Deller 
to the series and take it through the drm tree.

Helge


Re: [PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures

2023-03-10 Thread Helge Deller

On 3/10/23 02:45, Baoquan He wrote:

On 03/09/23 at 03:36pm, Thomas Bogendoerfer wrote:

On Wed, Mar 08, 2023 at 09:07:09PM +0800, Baoquan He wrote:

ioremap_uc() is only meaningful on old x86-32 systems with the PAT
extension, and on ia64 with its slightly unconventional ioremap()
behavior. So remove the ioremap_uc() definition in architecutures
other than x86 and ia64. These architectures all have asm-generic/io.h
included and will have the default ioremap_uc() definition which
returns NULL.

This changes the existing behaviour, while no need to worry about
any breakage because in the only callsite of ioremap_uc(), code
has been adjusted to eliminate the impact. Please see
atyfb_setup_generic() of drivers/video/fbdev/aty/atyfb_base.c.

If any new invocation of ioremap_uc() need be added, please consider
using ioremap() intead or adding a ARCH specific version if necessary.

Acked-by: Geert Uytterhoeven 
Signed-off-by: Baoquan He 
Cc: linux-al...@vger.kernel.org
Cc: linux-hexa...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-m...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
---
  Documentation/driver-api/device-io.rst | 9 +
  arch/alpha/include/asm/io.h| 1 -
  arch/hexagon/include/asm/io.h  | 3 ---
  arch/m68k/include/asm/kmap.h   | 1 -
  arch/mips/include/asm/io.h | 1 -
  arch/parisc/include/asm/io.h   | 2 --
  arch/powerpc/include/asm/io.h  | 1 -
  arch/sh/include/asm/io.h   | 2 --
  arch/sparc/include/asm/io_64.h | 1 -
  9 files changed, 5 insertions(+), 16 deletions(-)


this doesn't apply to v6.3-rc1... what tree is this based on ?


Sorry, I forgot mentioning this in cover letter. This series is
followup of below patchset, so it's on top of below patchset and based
on v6.3-rc1.

https://lore.kernel.org/all/20230301034247.136007-1-...@redhat.com/T/#u
[PATCH v5 00/17] mm: ioremap:  Convert architectures to take GENERIC_IOREMAP way


I've applied both patch series on top of v6.3-rc1 and
tested it with success on the parisc platform (32- and 64-bit kernel).

You may add to both patch series:

Acked-by: Helge Deller   # parisc

Thank you!
Helge


Re: [PATCH v3 19/24] parisc: Remove empty

2023-02-14 Thread Helge Deller

On 2/14/23 10:08, Philippe Mathieu-Daudé wrote:

On 14/2/23 08:49, Alexandre Ghiti wrote:

From: Palmer Dabbelt 

Signed-off-by: Palmer Dabbelt 
---
  arch/parisc/include/uapi/asm/setup.h | 5 -
  1 file changed, 5 deletions(-)
  delete mode 100644 arch/parisc/include/uapi/asm/setup.h


Reviewed-by: Philippe Mathieu-Daudé 


Acked-by: Helge Deller 




Re: [PATCH v3 08/24] parisc: Remove COMMAND_LINE_SIZE from uapi

2023-02-14 Thread Helge Deller

On 2/14/23 10:08, Philippe Mathieu-Daudé wrote:

On 14/2/23 08:49, Alexandre Ghiti wrote:

From: Palmer Dabbelt 

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Palmer Dabbelt 
---
  arch/parisc/include/asm/setup.h  | 7 +++
  arch/parisc/include/uapi/asm/setup.h | 2 --
  2 files changed, 7 insertions(+), 2 deletions(-)
  create mode 100644 arch/parisc/include/asm/setup.h


Reviewed-by: Philippe Mathieu-Daudé 


Acked-by: Helge Deller 





Re: [PATCH 01/15] video: fbdev: atmel_lcdfb: Rework backlight handling

2023-01-09 Thread Helge Deller

On 1/9/23 21:18, Stephen Kitt wrote:

On Sun, 8 Jan 2023 18:26:12 +0100, Helge Deller  wrote:


On 1/7/23 21:53, Sam Ravnborg wrote:

Hi Stephen.

On Sat, Jan 07, 2023 at 09:36:47PM +0100, Stephen Kitt wrote:

On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint
 wrote:

From: Sam Ravnborg 

The atmel_lcdfb had code to save/restore power state.
This is not needed so drop it.

Introduce backlight_is_brightness() to make logic simpler.

Signed-off-by: Sam Ravnborg 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Ludovic Desroches 
Cc: linux-fb...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/video/fbdev/atmel_lcdfb.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)

...


Hi Sam,

I’d submitted quite a few more of these previously (and you’d reviewed
them), see e.g. the thread starting at
https://lkml.org/lkml/2022/6/7/4365, and yesterday,
https://lkml.org/lkml/2023/1/6/520, https://lkml.org/lkml/2023/1/6/656,
https://lkml.org/lkml/2023/1/6/970, https://lkml.org/lkml/2023/1/6/643,
and https://lkml.org/lkml/2023/1/6/680. There are a few more, I can find
them if it’s any use.


The patches from yesterday was what triggered me to resurrect an old
branch of mine where I had done something similar. I had lost all
memory of reviewing similar patches from you.


Helge - could you pick the reviewed patches from:
https://lore.kernel.org/all/20220607192335.1137249-1-st...@sk2.org/
[This is the same mail as Stephen refer to above - looked up via lore].


I just pulled those 7 patches into fbdev/for-next.
If you need more, please let me know,


Please pull
https://lore.kernel.org/lkml/20230109200239.1850611-1-st...@sk2.org/ too, it
completes the fbdev set. (It’s a re-send of
https://lore.kernel.org/lkml/20220609180440.3138625-1-st...@sk2.org/).


Done.

Thanks!
Helge



Re: [PATCH 01/15] video: fbdev: atmel_lcdfb: Rework backlight handling

2023-01-08 Thread Helge Deller

On 1/7/23 21:53, Sam Ravnborg wrote:

Hi Stephen.

On Sat, Jan 07, 2023 at 09:36:47PM +0100, Stephen Kitt wrote:

On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint 
 wrote:

From: Sam Ravnborg 

The atmel_lcdfb had code to save/restore power state.
This is not needed so drop it.

Introduce backlight_is_brightness() to make logic simpler.

Signed-off-by: Sam Ravnborg 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Ludovic Desroches 
Cc: linux-fb...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/video/fbdev/atmel_lcdfb.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)

...


Hi Sam,

I’d submitted quite a few more of these previously (and you’d reviewed them), 
see e.g. the thread starting at https://lkml.org/lkml/2022/6/7/4365, and 
yesterday, https://lkml.org/lkml/2023/1/6/520, 
https://lkml.org/lkml/2023/1/6/656, https://lkml.org/lkml/2023/1/6/970, 
https://lkml.org/lkml/2023/1/6/643, and https://lkml.org/lkml/2023/1/6/680. 
There are a few more, I can find them if it’s any use.


The patches from yesterday was what triggered me to resurrect an old
branch of mine where I had done something similar. I had lost all
memory of reviewing similar patches from you.


Helge - could you pick the reviewed patches from:
https://lore.kernel.org/all/20220607192335.1137249-1-st...@sk2.org/
[This is the same mail as Stephen refer to above - looked up via lore].


I just pulled those 7 patches into fbdev/for-next.
If you need more, please let me know,

Thanks!
Helge




Stephen - I expect Daniel/Lee to take care of the patches from yesterday.
If you can look up other pending patches from you please do so, so we
can have them applied.
Preferably with links to lore - as this makes it easier to apply them.

Review of what is unique in this set would be appreciated.

Sam




Re: [PATCH] fbdev: make offb driver tristate

2022-12-27 Thread Helge Deller

On 12/27/22 19:48, Nathan Chancellor wrote:

On Sat, Dec 10, 2022 at 05:35:06PM +0100, Helge Deller wrote:

On 11/26/22 14:40, Thomas Zimmermann wrote:

Am 26.11.22 um 01:04 schrieb Randy Dunlap:

Make the offb (Open Firmware frame buffer) driver tristate,
i.e., so that it can be built as a loadable module.

However, it still depends on the setting of DRM_OFDRM
so that both of these drivers cannot be builtin at the same time
nor can one be builtin and the other one a loadable module.

Build-tested successfully with all combination of DRM_OFDRM and FB_OF.

This fixes a build issue that Michal reported when FB_OF=y and
DRM_OFDRM=m:

powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x58): undefined 
reference to `cfb_fillrect'
powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x60): undefined 
reference to `cfb_copyarea'
powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x68): undefined 
reference to `cfb_imageblit'

Signed-off-by: Randy Dunlap 
Suggested-by: Arnd Bergmann 
Cc: Masahiro Yamada 
Cc: Thomas Zimmermann 
Cc: Michal Suchánek 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org


Acked-by: Thomas Zimmermann 


applied.


Is this going to make it to Linus soon? We are now seeing this error in
our CI, which has the configuration describe in this commit.

https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/3785609002/jobs/6437398666#step:5:149

https://storage.tuxsuite.com/public/clangbuiltlinux/continuous-integration2/builds/2JUMSmjAoSJoKfl6PPjfU66JGit/build.log



It didn't applied cleanly earlier.
I've now added it to the fbdev for-next branch, and if no problems
show up in the next few days I'll push it before next weekend.
https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/log/?h=for-next

Helge



Cheers,
Nathan


---
   drivers/video/fbdev/Kconfig |    4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff -- a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -456,8 +456,8 @@ config FB_ATARI
     chipset found in Ataris.
   config FB_OF
-    bool "Open Firmware frame buffer device support"
-    depends on (FB = y) && PPC && (!PPC_PSERIES || PCI)
+    tristate "Open Firmware frame buffer device support"
+    depends on FB && PPC && (!PPC_PSERIES || PCI)
   depends on !DRM_OFDRM
   select APERTURE_HELPERS
   select FB_CFB_FILLRECT









Re: [PATCH] fbdev: make offb driver tristate

2022-12-10 Thread Helge Deller

On 11/26/22 14:40, Thomas Zimmermann wrote:

Am 26.11.22 um 01:04 schrieb Randy Dunlap:

Make the offb (Open Firmware frame buffer) driver tristate,
i.e., so that it can be built as a loadable module.

However, it still depends on the setting of DRM_OFDRM
so that both of these drivers cannot be builtin at the same time
nor can one be builtin and the other one a loadable module.

Build-tested successfully with all combination of DRM_OFDRM and FB_OF.

This fixes a build issue that Michal reported when FB_OF=y and
DRM_OFDRM=m:

powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x58): undefined 
reference to `cfb_fillrect'
powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x60): undefined 
reference to `cfb_copyarea'
powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x68): undefined 
reference to `cfb_imageblit'

Signed-off-by: Randy Dunlap 
Suggested-by: Arnd Bergmann 
Cc: Masahiro Yamada 
Cc: Thomas Zimmermann 
Cc: Michal Suchánek 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org


Acked-by: Thomas Zimmermann 


applied.

Thanks!
Helge





---
  drivers/video/fbdev/Kconfig |    4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff -- a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -456,8 +456,8 @@ config FB_ATARI
    chipset found in Ataris.
  config FB_OF
-    bool "Open Firmware frame buffer device support"
-    depends on (FB = y) && PPC && (!PPC_PSERIES || PCI)
+    tristate "Open Firmware frame buffer device support"
+    depends on FB && PPC && (!PPC_PSERIES || PCI)
  depends on !DRM_OFDRM
  select APERTURE_HELPERS
  select FB_CFB_FILLRECT






Re: [PATCH] mm: remove kern_addr_valid() completely

2022-10-18 Thread Helge Deller

On 10/18/22 09:40, Kefeng Wang wrote:

Most architectures(except arm64/x86/sparc) simply return 1 for
kern_addr_valid(), which is only used in read_kcore(), and it
calls copy_from_kernel_nofault() which could check whether the
address is a valid kernel address, so no need kern_addr_valid(),
let's remove unneeded kern_addr_valid() completely.

Signed-off-by: Kefeng Wang 


Acked-by: Helge Deller   # parisc

Thanks!
Helge


---
  arch/alpha/include/asm/pgtable.h  |  2 -
  arch/arc/include/asm/pgtable-bits-arcv2.h |  2 -
  arch/arm/include/asm/pgtable-nommu.h  |  2 -
  arch/arm/include/asm/pgtable.h|  4 --
  arch/arm64/include/asm/pgtable.h  |  2 -
  arch/arm64/mm/mmu.c   | 47 ---
  arch/arm64/mm/pageattr.c  |  3 +-
  arch/csky/include/asm/pgtable.h   |  3 --
  arch/hexagon/include/asm/page.h   |  7 
  arch/ia64/include/asm/pgtable.h   | 16 
  arch/loongarch/include/asm/pgtable.h  |  2 -
  arch/m68k/include/asm/pgtable_mm.h|  2 -
  arch/m68k/include/asm/pgtable_no.h|  1 -
  arch/microblaze/include/asm/pgtable.h |  3 --
  arch/mips/include/asm/pgtable.h   |  2 -
  arch/nios2/include/asm/pgtable.h  |  2 -
  arch/openrisc/include/asm/pgtable.h   |  2 -
  arch/parisc/include/asm/pgtable.h | 15 
  arch/powerpc/include/asm/pgtable.h|  7 
  arch/riscv/include/asm/pgtable.h  |  2 -
  arch/s390/include/asm/pgtable.h   |  2 -
  arch/sh/include/asm/pgtable.h |  2 -
  arch/sparc/include/asm/pgtable_32.h   |  6 ---
  arch/sparc/mm/init_32.c   |  3 +-
  arch/sparc/mm/init_64.c   |  1 -
  arch/um/include/asm/pgtable.h |  2 -
  arch/x86/include/asm/pgtable_32.h |  9 -
  arch/x86/include/asm/pgtable_64.h |  1 -
  arch/x86/mm/init_64.c | 41 
  arch/xtensa/include/asm/pgtable.h |  2 -
  fs/proc/kcore.c   | 26 +
  31 files changed, 11 insertions(+), 210 deletions(-)

diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
index 3ea9661c09ff..9e45f6735d5d 100644
--- a/arch/alpha/include/asm/pgtable.h
+++ b/arch/alpha/include/asm/pgtable.h
@@ -313,8 +313,6 @@ extern inline pte_t mk_swap_pte(unsigned long type, 
unsigned long offset)
  #define __pte_to_swp_entry(pte)   ((swp_entry_t) { pte_val(pte) })
  #define __swp_entry_to_pte(x) ((pte_t) { (x).val })

-#define kern_addr_valid(addr)  (1)
-
  #define pte_ERROR(e) \
printk("%s:%d: bad pte %016lx.\n", __FILE__, __LINE__, pte_val(e))
  #define pmd_ERROR(e) \
diff --git a/arch/arc/include/asm/pgtable-bits-arcv2.h 
b/arch/arc/include/asm/pgtable-bits-arcv2.h
index b23be557403e..515e82db519f 100644
--- a/arch/arc/include/asm/pgtable-bits-arcv2.h
+++ b/arch/arc/include/asm/pgtable-bits-arcv2.h
@@ -120,8 +120,6 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned 
long address,
  #define __pte_to_swp_entry(pte)   ((swp_entry_t) { pte_val(pte) })
  #define __swp_entry_to_pte(x) ((pte_t) { (x).val })

-#define kern_addr_valid(addr)  (1)
-
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
  #include 
  #endif
diff --git a/arch/arm/include/asm/pgtable-nommu.h 
b/arch/arm/include/asm/pgtable-nommu.h
index d16aba48fa0a..25d8c7bb07e0 100644
--- a/arch/arm/include/asm/pgtable-nommu.h
+++ b/arch/arm/include/asm/pgtable-nommu.h
@@ -21,8 +21,6 @@
  #define pgd_none(pgd) (0)
  #define pgd_bad(pgd)  (0)
  #define pgd_clear(pgdp)
-#define kern_addr_valid(addr)  (1)
-/* FIXME */
  /*
   * PMD_SHIFT determines the size of the area a second-level page table can map
   * PGDIR_SHIFT determines what a third-level page table entry can map
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 78a532068fec..00954ab1a039 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -298,10 +298,6 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
   */
  #define MAX_SWAPFILES_CHECK() BUILD_BUG_ON(MAX_SWAPFILES_SHIFT > 
__SWP_TYPE_BITS)

-/* Needs to be defined here and not in linux/mm.h, as it is arch dependent */
-/* FIXME: this is not correct */
-#define kern_addr_valid(addr)  (1)
-
  /*
   * We provide our own arch_get_unmapped_area to cope with VIPT caches.
   */
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 71a1af42f0e8..4873c1d6e7d0 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -1021,8 +1021,6 @@ static inline pmd_t pmdp_establish(struct vm_area_struct 
*vma,
   */
  #define MAX_SWAPFILES_CHECK() BUILD_BUG_ON(MAX_SWAPFILES_SHIFT > 
__SWP_TYPE_BITS)

-extern int kern_addr_valid(unsigned long addr);
-
  #ifdef CONFIG_ARM64_MTE

  #define __HAVE_ARCH_PREPARE_TO_SWAP
diff --git a/arch/arm64/mm/mmu.c b/arch/arm6

Re: [PATCH v3 4/4] arc: Use generic dump_stack_print_cmdline() implementation

2022-10-10 Thread Helge Deller

On 10/10/22 07:18, Vineet Gupta wrote:

On 8/8/22 06:09, Helge Deller wrote:

The process program name and command line is now shown in generic code
in dump_stack_print_info(), so drop the arc-specific implementation.

Signed-off-by: Helge Deller 


But that info printing was added back in 2018 by e36df28f532f882.
I don't think arc is using show_regs_print_info -> dump_stack_print_info yet.
Or is there a different code path now which calls here ?


Right.
See patches #1 and #2 of this series which added this
info to dump_stack_print_info().



---
  arch/arc/kernel/troubleshoot.c | 24 
  1 file changed, 24 deletions(-)

diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c
index 7654c2e42dc0..9807e590ee55 100644
--- a/arch/arc/kernel/troubleshoot.c
+++ b/arch/arc/kernel/troubleshoot.c
@@ -51,29 +51,6 @@ static void print_regs_callee(struct callee_regs *regs)
  regs->r24, regs->r25);
  }

-static void print_task_path_n_nm(struct task_struct *tsk)
-{
-    char *path_nm = NULL;
-    struct mm_struct *mm;
-    struct file *exe_file;
-    char buf[ARC_PATH_MAX];
-
-    mm = get_task_mm(tsk);
-    if (!mm)
-    goto done;
-
-    exe_file = get_mm_exe_file(mm);
-    mmput(mm);
-
-    if (exe_file) {
-    path_nm = file_path(exe_file, buf, ARC_PATH_MAX-1);
-    fput(exe_file);
-    }
-
-done:
-    pr_info("Path: %s\n", !IS_ERR(path_nm) ? path_nm : "?");
-}
-
  static void show_faulting_vma(unsigned long address)
  {
  struct vm_area_struct *vma;
@@ -176,7 +153,6 @@ void show_regs(struct pt_regs *regs)
   */
  preempt_enable();


Maybe we remove preempt* as well now (perhaps as a follow up patch)
since that was added by f731a8e89f8c78 "ARC: show_regs: lockdep:
re-enable preemption" where show_regs -> print_task_path_n_nm ->
mmput was triggering lockdep splat which is supposedly removed.


The patch series was dropped from Andrew's queue, because the kernel
test robot showed some issues:
https://lore.kernel.org/lkml/Yu59QdVpPgnXUnQC@xsang-OptiPlex-9020/
Maybe adding preempt_enable() in my patches would fix that -
sadly I haven't had time to follow up on this yet ...

Helge





-    print_task_path_n_nm(tsk);
  show_regs_print_info(KERN_INFO);

  show_ecr_verbose(regs);




[PATCH v3 1/4] proc: Add get_task_cmdline_kernel() function

2022-08-08 Thread Helge Deller
Add a new function get_task_cmdline_kernel() which reads the command
line of a process into a kernel buffer. This command line can then be
dumped by arch code to give additional debug info via the parameters
with which a faulting process was started.

The new function re-uses the existing code which provides the cmdline
for the procfs. For that the existing functions were modified so that
the buffer page is allocated outside of get_mm_proctitle() and
get_mm_cmdline() and instead provided as parameter.

Signed-off-by: Helge Deller 

--
Changes in v3:
- add parameter names in header files, noticed by: kernel test robot
- require task to be locked by caller
---
 fs/proc/base.c  | 74 -
 include/linux/proc_fs.h |  5 +++
 2 files changed, 56 insertions(+), 23 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 8dfa36a99c74..e2d4152aed34 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -217,20 +217,17 @@ static int proc_root_link(struct dentry *dentry, struct 
path *path)
  */
 static ssize_t get_mm_proctitle(struct mm_struct *mm, char __user *buf,
size_t count, unsigned long pos,
-   unsigned long arg_start)
+   unsigned long arg_start, char *page)
 {
-   char *page;
int ret, got;
+   size_t size;

-   if (pos >= PAGE_SIZE)
+   size = min_t(size_t, PAGE_SIZE, count);
+   if (pos >= size)
return 0;

-   page = (char *)__get_free_page(GFP_KERNEL);
-   if (!page)
-   return -ENOMEM;
-
ret = 0;
-   got = access_remote_vm(mm, arg_start, page, PAGE_SIZE, FOLL_ANON);
+   got = access_remote_vm(mm, arg_start, page, size, FOLL_ANON);
if (got > 0) {
int len = strnlen(page, got);

@@ -238,7 +235,9 @@ static ssize_t get_mm_proctitle(struct mm_struct *mm, char 
__user *buf,
if (len < got)
len++;

-   if (len > pos) {
+   if (!buf)
+   ret = len;
+   else if (len > pos) {
len -= pos;
if (len > count)
len = count;
@@ -248,16 +247,15 @@ static ssize_t get_mm_proctitle(struct mm_struct *mm, 
char __user *buf,
ret = len;
}
}
-   free_page((unsigned long)page);
return ret;
 }

 static ssize_t get_mm_cmdline(struct mm_struct *mm, char __user *buf,
- size_t count, loff_t *ppos)
+ size_t count, loff_t *ppos, char *page)
 {
unsigned long arg_start, arg_end, env_start, env_end;
unsigned long pos, len;
-   char *page, c;
+   char c;

/* Check if process spawned far enough to have cmdline. */
if (!mm->env_end)
@@ -283,7 +281,7 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char 
__user *buf,
len = env_end - arg_start;

/* We're not going to care if "*ppos" has high bits set */
-   pos = *ppos;
+   pos = ppos ? *ppos : 0;
if (pos >= len)
return 0;
if (count > len - pos)
@@ -299,7 +297,7 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char 
__user *buf,
 * pos is 0, and set a flag in the 'struct file'.
 */
if (access_remote_vm(mm, arg_end-1, , 1, FOLL_ANON) == 1 && c)
-   return get_mm_proctitle(mm, buf, count, pos, arg_start);
+   return get_mm_proctitle(mm, buf, count, pos, arg_start, page);

/*
 * For the non-setproctitle() case we limit things strictly
@@ -311,10 +309,6 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char 
__user *buf,
if (count > arg_end - pos)
count = arg_end - pos;

-   page = (char *)__get_free_page(GFP_KERNEL);
-   if (!page)
-   return -ENOMEM;
-
len = 0;
while (count) {
int got;
@@ -323,7 +317,8 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char 
__user *buf,
got = access_remote_vm(mm, pos, page, size, FOLL_ANON);
if (got <= 0)
break;
-   got -= copy_to_user(buf, page, got);
+   if (buf)
+   got -= copy_to_user(buf, page, got);
if (unlikely(!got)) {
if (!len)
len = -EFAULT;
@@ -335,12 +330,11 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char 
__user *buf,
count -= got;
}

-   free_page((unsigned long)page);
return len;
 }

 static ssize_t get_task_cmdline(struct task_struct *tsk, char __user *buf,
-   size_t count, loff_t *pos)
+   size_t count, loff_t *pos, char *page)
 {
struct 

[PATCH v3 0/4] Dump command line of faulting process to syslog

2022-08-08 Thread Helge Deller
This patch series dumps the command line (including the program parameters) of
a faulting process to the syslog.

The motivation for this patch is that it's sometimes quite hard to find out and
annoying to not know which program *exactly* faulted when looking at the syslog.

For example, a dump on parisc shows:
   do_page_fault() command='cc1' type=15 address=0x in 
libc-2.33.so[f6abb000+184000]

-> We see the "cc1" compiler crashed, but it would be useful to know which file 
was compiled.
With this patch you will see that cc1 crashed while compiling some haskell code:

   cc1[13472] cmdline: /usr/lib/gcc/hppa-linux-gnu/12/cc1 -quiet @/tmp/ccRkFSfY 
-imultilib . -imultiarch hppa-linux-gnu -D USE_MINIINTERPRETER -D NO_REGS -D 
_HPUX_SOURCE -D NOSMP -D THREADED_RTS -include 
/build/ghc/ghc-9.0.2/includes/dist-install/build/ghcversion.h -iquote 
compiler/GHC/Iface -quiet -dumpdir /tmp/ghc13413_0/ -dumpbase ghc_5.hc 
-dumpbase-ext .hc -O -Wimplicit -fno-PIC -fwrapv -fno-builtin 
-fno-strict-aliasing -o /tmp/ghc13413_0/ghc_5.s

Another example are the glibc testcases which always segfault in "ld.so.1" with 
no other info:

   do_page_fault() command='ld.so.1' type=15 address=0x565921d8 in 
libc.so[f7339000+1bb000]

-> With the patch you can see it was the "tst-safe-linking-malloc-hugetlb1" 
testcase:

   ld.so.1[1151] cmdline: /home/gnu/glibc/objdir/elf/ld.so.1 --library-path 
/home/gnu/glibc/objdir:/home/gnu/glibc/objdir/math:/home/gnu/
/home/gnu/glibc/objdir/malloc/tst-safe-linking-malloc-hugetlb1

An example of a typical x86 fault shows up as:
   crash[2326]: segfault at 0 ip 561a7969c12e sp 7ffe97a05630 error 6 
in crash[561a7969c000+1000]
   Code: 68 ff ff ff c6 05 19 2f 00 00 01 5d c3 0f 1f 80 00 00 00 00 c3 0f 1f 
80 00 00 ...

-> with this patch you now see the whole command line:
   crash[2326] cmdline: ./crash test_write_to_page_0

The patches are relatively small, and reuse functions which are used
to create the output for the /proc//cmdline files.

The relevant changes are in patches #1 and #2.
Patch #3 adds the cmdline dump on x86.
Patch #4 drops code from arc which now becomes unnecessary as this is done by 
generic code.

Helge

---

Changes in v3:
- require task to be locked by caller, noticed by kernel test robot
- add parameter names in header files, noticed by kernel test robot

Changes in v2:
- Don't dump all or parts of the commandline depending on the
  kptr_restrict sysctl value (suggested by Josh Triplett).
- Patch sent to more arch mailing lists

Helge Deller (4):
  proc: Add get_task_cmdline_kernel() function
  lib/dump_stack: Add dump_stack_print_cmdline() and wire up in
dump_stack_print_info()
  x86/fault: Dump command line of faulting process to syslog
  arc: Use generic dump_stack_print_cmdline() implementation

 arch/arc/kernel/troubleshoot.c | 24 ---
 arch/x86/mm/fault.c|  2 +
 fs/proc/base.c | 74 +++---
 include/linux/printk.h |  5 +++
 include/linux/proc_fs.h|  5 +++
 lib/dump_stack.c   | 34 
 6 files changed, 97 insertions(+), 47 deletions(-)

--
2.37.1



[PATCH v3 2/4] lib/dump_stack: Add dump_stack_print_cmdline() and wire up in dump_stack_print_info()

2022-08-08 Thread Helge Deller
Add the function dump_stack_print_cmdline() which can be used by arch
code to print the command line of the current processs.  This function
is useful in arch code when dumping information for a faulting process.

Wire this function up in the dump_stack_print_info() function to include
the dumping of the command line for architectures which use
dump_stack_print_info().

As an example, with this patch a failing glibc testcase (which uses
ld.so.1 as starting program) up to now reported just "ld.so.1" failing:

 do_page_fault() command='ld.so.1' type=15 address=0x565921d8 in 
libc.so[f7339000+1bb000]
 trap #15: Data TLB miss fault, vm_start = 0x0001a000, vm_end = 0x0001b000

and now it reports in addition:

 ld.so.1[1151] cmdline: /home/gnu/glibc/objdir/elf/ld.so.1 --library-path 
/home/gnu/glibc/objdir:/home/gnu/glibc/objdir/math:/home/gnu/
/home/gnu/glibc/objdir/malloc/tst-safe-linking-malloc-hugetlb1

Josh Triplett noted that dumping such command line parameters into
syslog may theoretically lead to information disclosure.
That's why this patch checks the value of the kptr_restrict sysctl
variable and will not print any information if kptr_restrict==2, and
will not show the program parameters if kptr_restrict==1.

Signed-off-by: Helge Deller 
---
 include/linux/printk.h |  5 +
 lib/dump_stack.c   | 34 ++
 2 files changed, 39 insertions(+)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index cf7d666ab1f8..5290a32a197d 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -191,6 +191,7 @@ u32 log_buf_len_get(void);
 void log_buf_vmcoreinfo_setup(void);
 void __init setup_log_buf(int early);
 __printf(1, 2) void dump_stack_set_arch_desc(const char *fmt, ...);
+void dump_stack_print_cmdline(const char *log_lvl);
 void dump_stack_print_info(const char *log_lvl);
 void show_regs_print_info(const char *log_lvl);
 extern asmlinkage void dump_stack_lvl(const char *log_lvl) __cold;
@@ -262,6 +263,10 @@ static inline __printf(1, 2) void 
dump_stack_set_arch_desc(const char *fmt, ...)
 {
 }

+static inline void dump_stack_print_cmdline(const char *log_lvl)
+{
+}
+
 static inline void dump_stack_print_info(const char *log_lvl)
 {
 }
diff --git a/lib/dump_stack.c b/lib/dump_stack.c
index 83471e81501a..38ef1067c7eb 100644
--- a/lib/dump_stack.c
+++ b/lib/dump_stack.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 

 static char dump_stack_arch_desc_str[128];

@@ -45,6 +46,37 @@ void __init dump_stack_set_arch_desc(const char *fmt, ...)
 #define BUILD_ID_VAL ""
 #endif

+/**
+ * dump_stack_print_cmdline - print the command line of current process
+ * @log_lvl: log level
+ */
+void dump_stack_print_cmdline(const char *log_lvl)
+{
+   char cmdline[256];
+
+   if (kptr_restrict >= 2)
+   return; /* never show command line */
+
+   /* get command line */
+   get_task_cmdline_kernel(current, cmdline, sizeof(cmdline));
+
+   if (kptr_restrict == 1) {
+   char *p;
+
+   /* if restricted show program path only */
+   p = strchr(cmdline, ' ');
+   if (p) {
+   *p = 0;
+   strlcat(cmdline,
+   " ... [parameters hidden due to kptr_restrict]",
+   sizeof(cmdline));
+   }
+   }
+
+   printk("%s%s[%d] cmdline: %s\n", log_lvl, current->comm,
+   current->pid, cmdline);
+}
+
 /**
  * dump_stack_print_info - print generic debug info for dump_stack()
  * @log_lvl: log level
@@ -62,6 +94,8 @@ void dump_stack_print_info(const char *log_lvl)
   (int)strcspn(init_utsname()->version, " "),
   init_utsname()->version, BUILD_ID_VAL);

+   dump_stack_print_cmdline(log_lvl);
+
if (dump_stack_arch_desc_str[0] != '\0')
printk("%sHardware name: %s\n",
   log_lvl, dump_stack_arch_desc_str);
--
2.37.1



[PATCH v3 3/4] x86/fault: Dump command line of faulting process to syslog

2022-08-08 Thread Helge Deller
If a process segfaults, include the command line of the faulting process
in the syslog.

In the example below, the "crash" program (which simply writes zero to address 
0)
was called with the parameters "this is a test":

 crash[2326]: segfault at 0 ip 561a7969c12e sp 7ffe97a05630 error 6 in 
crash[561a7969c000+1000]
 crash[2326] cmdline: ./crash this is a test
 Code: 68 ff ff ff c6 05 19 2f 00 00 01 5d c3 0f 1f 80 00 00 00 00 c3 0f 1f ...

Signed-off-by: Helge Deller 
---
 arch/x86/mm/fault.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index fad8faa29d04..d4e21c402e29 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -784,6 +784,8 @@ show_signal_msg(struct pt_regs *regs, unsigned long 
error_code,

printk(KERN_CONT "\n");

+   dump_stack_print_cmdline(loglvl);
+
show_opcodes(regs, loglvl);
 }

--
2.37.1



[PATCH v3 4/4] arc: Use generic dump_stack_print_cmdline() implementation

2022-08-08 Thread Helge Deller
The process program name and command line is now shown in generic code
in dump_stack_print_info(), so drop the arc-specific implementation.

Signed-off-by: Helge Deller 
---
 arch/arc/kernel/troubleshoot.c | 24 
 1 file changed, 24 deletions(-)

diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c
index 7654c2e42dc0..9807e590ee55 100644
--- a/arch/arc/kernel/troubleshoot.c
+++ b/arch/arc/kernel/troubleshoot.c
@@ -51,29 +51,6 @@ static void print_regs_callee(struct callee_regs *regs)
regs->r24, regs->r25);
 }

-static void print_task_path_n_nm(struct task_struct *tsk)
-{
-   char *path_nm = NULL;
-   struct mm_struct *mm;
-   struct file *exe_file;
-   char buf[ARC_PATH_MAX];
-
-   mm = get_task_mm(tsk);
-   if (!mm)
-   goto done;
-
-   exe_file = get_mm_exe_file(mm);
-   mmput(mm);
-
-   if (exe_file) {
-   path_nm = file_path(exe_file, buf, ARC_PATH_MAX-1);
-   fput(exe_file);
-   }
-
-done:
-   pr_info("Path: %s\n", !IS_ERR(path_nm) ? path_nm : "?");
-}
-
 static void show_faulting_vma(unsigned long address)
 {
struct vm_area_struct *vma;
@@ -176,7 +153,6 @@ void show_regs(struct pt_regs *regs)
 */
preempt_enable();

-   print_task_path_n_nm(tsk);
show_regs_print_info(KERN_INFO);

show_ecr_verbose(regs);
--
2.37.1



[PATCH v2 0/3] Dump command line of faulting process to syslog

2022-08-06 Thread Helge Deller
This patch series allows the arch-specific kernel fault handlers to dump
the command line parameters of the faulting process.

The motivation for this patch is that it's sometimes quite hard to find out and
annoying to not know which program *exactly* faulted when looking at the syslog.

Some examples from the syslog are:

On parisc:
   do_page_fault() command='cc1' type=15 address=0x in 
libc-2.33.so[f6abb000+184000]
   CPU: 1 PID: 13472 Comm: cc1 Tainted: GE 5.10.133+ #45
   Hardware name: 9000/785/C8000

-> We see the "cc1" compiler crashed, but it would be useful to know which file 
was compiled.

With this patch series, the kernel now prints in addition:
   cc1[13472] cmdline: /usr/lib/gcc/hppa-linux-gnu/12/cc1 -quiet @/tmp/ccRkFSfY 
-imultilib . -imultiarch hppa-linux-gnu -D USE_MINIINTERPRETER -D NO_REGS -D 
_HPUX_SOURCE -D NOSMP -D THREADED_RTS -include 
/build/ghc/ghc-9.0.2/includes/dist-install/build/ghcversion.h -iquote 
compiler/GHC/Iface -quiet -dumpdir /tmp/ghc13413_0/ -dumpbase ghc_5.hc 
-dumpbase-ext .hc -O -Wimplicit -fno-PIC -fwrapv -fno-builtin 
-fno-strict-aliasing -o /tmp/ghc13413_0/ghc_5.s

-> now we know that cc1 crashed while compiling some haskell code.

Another parisc example:
   do_page_fault() command='ld.so.1' type=15 address=0x565921d8 in 
libc.so[f7339000+1bb000]
   CPU: 1 PID: 1151 Comm: cc1 Tainted: GE 5.10.133+ #45
   Hardware name: 9000/785/C8000

-> apparently here a program from the glibc testsuite segfaulted.

With this patch we now additionally get:
   ld.so.1[1151] cmdline: /home/gnu/glibc/objdir/elf/ld.so.1 --library-path 
/home/gnu/glibc/objdir:/home/gnu/glibc/objdir/math:/home/gnu/
/home/gnu/glibc/objdir/malloc/tst-safe-linking-malloc-hugetlb1

-> it was the tst-safe-linking-malloc-hugetlb1 testcase which faulted.

An example of a typical x86 fault shows up as:
   crash[2326]: segfault at 0 ip 561a7969c12e sp 7ffe97a05630 error 6 
in crash[561a7969c000+1000]
   Code: 68 ff ff ff c6 05 19 2f 00 00 01 5d c3 0f 1f 80 00 00 00 00 c3 0f 1f 
80 00 00 00 00 e9 7b ff ff ff 55 48 89 e5 b8 00 00 00 00  00 01 00 00 00 b8 
00 00 00 00 5d c3 0f 1f 44 00 00 41 57 4c 8d

-> with this patch we now will see the whole command line:
   crash[2326] cmdline: ./crash test_write_to_page_0

The patches are relatively small, and reuses functions which are used
to create the output for the /proc//cmdline files.

In this version 2 of the patch set, all or parts of the command line isn't
shown if the value of the kptr_restrict sysctl >= 1.

Thanks!
Helge

---

Changes compared to v1 of this patchset:

- Don't dump all or parts of the commandline depending on the
  kptr_restrict sysctl value (suggested by Josh Triplett).
- Patch sent to more arch mailing lists

Helge Deller (3):
  proc: Add get_task_cmdline_kernel() function
  lib/dump_stack: Add dump_stack_print_cmdline() and wire up in
dump_stack_print_info()
  x86/fault: Dump command line of faulting process to syslog

 arch/x86/mm/fault.c |  2 ++
 fs/proc/base.c  | 68 +++--
 include/linux/printk.h  |  5 +++
 include/linux/proc_fs.h |  5 +++
 lib/dump_stack.c| 34 +
 5 files changed, 91 insertions(+), 23 deletions(-)

--
2.37.1



[PATCH v2 1/3] proc: Add get_task_cmdline_kernel() function

2022-08-06 Thread Helge Deller
Add a new function get_task_cmdline_kernel() which reads the command
line of a process into a kernel buffer. This command line can then be
dumped by arch code to give additional debug info via the parameters
with which a faulting process was started.

The new function re-uses the existing code which provides the cmdline
for the procfs. For that the existing functions were modified so that
the buffer page is allocated outside of get_mm_proctitle() and
get_mm_cmdline() and instead provided as parameter.

Signed-off-by: Helge Deller 
---
 fs/proc/base.c  | 68 +++--
 include/linux/proc_fs.h |  5 +++
 2 files changed, 50 insertions(+), 23 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 8dfa36a99c74..4da9a8b3c7d1 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -217,20 +217,17 @@ static int proc_root_link(struct dentry *dentry, struct 
path *path)
  */
 static ssize_t get_mm_proctitle(struct mm_struct *mm, char __user *buf,
size_t count, unsigned long pos,
-   unsigned long arg_start)
+   unsigned long arg_start, char *page)
 {
-   char *page;
int ret, got;
+   size_t size;

-   if (pos >= PAGE_SIZE)
+   size = min_t(size_t, PAGE_SIZE, count);
+   if (pos >= size)
return 0;

-   page = (char *)__get_free_page(GFP_KERNEL);
-   if (!page)
-   return -ENOMEM;
-
ret = 0;
-   got = access_remote_vm(mm, arg_start, page, PAGE_SIZE, FOLL_ANON);
+   got = access_remote_vm(mm, arg_start, page, size, FOLL_ANON);
if (got > 0) {
int len = strnlen(page, got);

@@ -238,7 +235,9 @@ static ssize_t get_mm_proctitle(struct mm_struct *mm, char 
__user *buf,
if (len < got)
len++;

-   if (len > pos) {
+   if (!buf)
+   ret = len;
+   else if (len > pos) {
len -= pos;
if (len > count)
len = count;
@@ -248,16 +247,15 @@ static ssize_t get_mm_proctitle(struct mm_struct *mm, 
char __user *buf,
ret = len;
}
}
-   free_page((unsigned long)page);
return ret;
 }

 static ssize_t get_mm_cmdline(struct mm_struct *mm, char __user *buf,
- size_t count, loff_t *ppos)
+ size_t count, loff_t *ppos, char *page)
 {
unsigned long arg_start, arg_end, env_start, env_end;
unsigned long pos, len;
-   char *page, c;
+   char c;

/* Check if process spawned far enough to have cmdline. */
if (!mm->env_end)
@@ -283,7 +281,7 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char 
__user *buf,
len = env_end - arg_start;

/* We're not going to care if "*ppos" has high bits set */
-   pos = *ppos;
+   pos = ppos ? *ppos : 0;
if (pos >= len)
return 0;
if (count > len - pos)
@@ -299,7 +297,7 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char 
__user *buf,
 * pos is 0, and set a flag in the 'struct file'.
 */
if (access_remote_vm(mm, arg_end-1, , 1, FOLL_ANON) == 1 && c)
-   return get_mm_proctitle(mm, buf, count, pos, arg_start);
+   return get_mm_proctitle(mm, buf, count, pos, arg_start, page);

/*
 * For the non-setproctitle() case we limit things strictly
@@ -311,10 +309,6 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char 
__user *buf,
if (count > arg_end - pos)
count = arg_end - pos;

-   page = (char *)__get_free_page(GFP_KERNEL);
-   if (!page)
-   return -ENOMEM;
-
len = 0;
while (count) {
int got;
@@ -323,7 +317,8 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char 
__user *buf,
got = access_remote_vm(mm, pos, page, size, FOLL_ANON);
if (got <= 0)
break;
-   got -= copy_to_user(buf, page, got);
+   if (buf)
+   got -= copy_to_user(buf, page, got);
if (unlikely(!got)) {
if (!len)
len = -EFAULT;
@@ -335,12 +330,11 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char 
__user *buf,
count -= got;
}

-   free_page((unsigned long)page);
return len;
 }

 static ssize_t get_task_cmdline(struct task_struct *tsk, char __user *buf,
-   size_t count, loff_t *pos)
+   size_t count, loff_t *pos, char *page)
 {
struct mm_struct *mm;
ssize_t ret;
@@ -349,23 +343,51 @@ static ssize_t get_task_cmdline(struct task_struct *tsk, 
char 

[PATCH v2 3/3] x86/fault: Dump command line of faulting process to syslog

2022-08-06 Thread Helge Deller
If a process segfaults, include the command line of the faulting process
in the syslog.

In the example below, the "crash" program (which simply writes zero to address 
0)
was called with the parameters "this is a test":

 crash[2326]: segfault at 0 ip 561a7969c12e sp 7ffe97a05630 error 6 in 
crash[561a7969c000+1000]
 crash[2326] cmdline: ./crash this is a test
 Code: 68 ff ff ff c6 05 19 2f 00 00 01 5d c3 0f 1f 80 00 00 00 00 c3 0f 1f 80 
00 00 00 00 e9 7b ff ff ff 55 48 89 e5 b8 00 00 00 00  00 01 00 00 00 b8 00 
00 00 00 5d c3 0f 1f 44 00 00 41 57 4c 8d

Signed-off-by: Helge Deller 
---
 arch/x86/mm/fault.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index fad8faa29d04..d4e21c402e29 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -784,6 +784,8 @@ show_signal_msg(struct pt_regs *regs, unsigned long 
error_code,

printk(KERN_CONT "\n");

+   dump_stack_print_cmdline(loglvl);
+
show_opcodes(regs, loglvl);
 }

--
2.37.1



[PATCH v2 2/3] lib/dump_stack: Add dump_stack_print_cmdline() and wire up in dump_stack_print_info()

2022-08-06 Thread Helge Deller
Add the function dump_stack_print_cmdline() which can be used by arch
code to print the command line of the current processs.  This function
is useful in arch code when dumping information for a faulting process.

Wire this function up in the dump_stack_print_info() function to include
the dumping of the command line for architectures which use
dump_stack_print_info().

As an example, with this patch a failing glibc testcase (which uses
ld.so.1 as starting program) up to now reported just "ld.so.1" failing:

 do_page_fault() command='ld.so.1' type=15 address=0x565921d8 in 
libc.so[f7339000+1bb000]
 trap #15: Data TLB miss fault, vm_start = 0x0001a000, vm_end = 0x0001b000

and now it reports in addition:

 ld.so.1[1151] cmdline: /home/gnu/glibc/objdir/elf/ld.so.1 --library-path 
/home/gnu/glibc/objdir:/home/gnu/glibc/objdir/math:/home/gnu/
/home/gnu/glibc/objdir/malloc/tst-safe-linking-malloc-hugetlb1

Josh Triplett noted that dumping such command line parameters into
syslog may theoretically lead to information disclosure.
That's why this patch checks the value of the kptr_restrict sysctl
variable and will not print any information if kptr_restrict==2, and
will not show the program parameters if kptr_restrict==1.

Signed-off-by: Helge Deller 
---
 include/linux/printk.h |  5 +
 lib/dump_stack.c   | 34 ++
 2 files changed, 39 insertions(+)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index cf7d666ab1f8..5290a32a197d 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -191,6 +191,7 @@ u32 log_buf_len_get(void);
 void log_buf_vmcoreinfo_setup(void);
 void __init setup_log_buf(int early);
 __printf(1, 2) void dump_stack_set_arch_desc(const char *fmt, ...);
+void dump_stack_print_cmdline(const char *log_lvl);
 void dump_stack_print_info(const char *log_lvl);
 void show_regs_print_info(const char *log_lvl);
 extern asmlinkage void dump_stack_lvl(const char *log_lvl) __cold;
@@ -262,6 +263,10 @@ static inline __printf(1, 2) void 
dump_stack_set_arch_desc(const char *fmt, ...)
 {
 }

+static inline void dump_stack_print_cmdline(const char *log_lvl)
+{
+}
+
 static inline void dump_stack_print_info(const char *log_lvl)
 {
 }
diff --git a/lib/dump_stack.c b/lib/dump_stack.c
index 83471e81501a..38ef1067c7eb 100644
--- a/lib/dump_stack.c
+++ b/lib/dump_stack.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 

 static char dump_stack_arch_desc_str[128];

@@ -45,6 +46,37 @@ void __init dump_stack_set_arch_desc(const char *fmt, ...)
 #define BUILD_ID_VAL ""
 #endif

+/**
+ * dump_stack_print_cmdline - print the command line of current process
+ * @log_lvl: log level
+ */
+void dump_stack_print_cmdline(const char *log_lvl)
+{
+   char cmdline[256];
+
+   if (kptr_restrict >= 2)
+   return; /* never show command line */
+
+   /* get command line */
+   get_task_cmdline_kernel(current, cmdline, sizeof(cmdline));
+
+   if (kptr_restrict == 1) {
+   char *p;
+
+   /* if restricted show program path only */
+   p = strchr(cmdline, ' ');
+   if (p) {
+   *p = 0;
+   strlcat(cmdline,
+   " ... [parameters hidden due to kptr_restrict]",
+   sizeof(cmdline));
+   }
+   }
+
+   printk("%s%s[%d] cmdline: %s\n", log_lvl, current->comm,
+   current->pid, cmdline);
+}
+
 /**
  * dump_stack_print_info - print generic debug info for dump_stack()
  * @log_lvl: log level
@@ -62,6 +94,8 @@ void dump_stack_print_info(const char *log_lvl)
   (int)strcspn(init_utsname()->version, " "),
   init_utsname()->version, BUILD_ID_VAL);

+   dump_stack_print_cmdline(log_lvl);
+
if (dump_stack_arch_desc_str[0] != '\0')
printk("%sHardware name: %s\n",
   log_lvl, dump_stack_arch_desc_str);
--
2.37.1



Re: [PATCH 1/4] video: fbdev: offb: Include missing linux/platform_device.h

2022-06-20 Thread Helge Deller
On 6/11/22 18:50, Christophe Leroy wrote:
> A lot of drivers were getting platform and of headers
> indirectly via headers like asm/pci.h or asm/prom.h
>
> Most of them were fixed during 5.19 cycle but a newissue was
> introduced by commit 52b1b46c39ae ("of: Create platform devices
> for OF framebuffers")
>
> Include missing platform_device.h to allow cleaning asm/pci.h
>
> Cc: Thomas Zimmermann 
> Fixes: 52b1b46c39ae ("of: Create platform devices for OF framebuffers")
> Signed-off-by: Christophe Leroy 

Acked-by: Helge Deller 

I assume you take this through the linuxppc git tree?

Helge

> ---
>  drivers/video/fbdev/offb.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
> index b1acb1ebebe9..91001990e351 100644
> --- a/drivers/video/fbdev/offb.c
> +++ b/drivers/video/fbdev/offb.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #ifdef CONFIG_PPC32



Re: [PATCH 1/3] termbits.h: create termbits-common.h for identical bits

2022-05-09 Thread Helge Deller
Hello Ilpo,

On 5/9/22 11:34, Ilpo Järvinen wrote:
> Some defines are the same across all archs. Move the most obvious
> intersection to termbits-common.h.

I like your cleanup patches, but in this specific one, does it makes sense
to split up together-belonging constants, e.g.

> diff --git a/arch/parisc/include/uapi/asm/termbits.h 
> b/arch/parisc/include/uapi/asm/termbits.h
> index 6017ee08f099..7f74a822b7ea 100644
> --- a/arch/parisc/include/uapi/asm/termbits.h
> +++ b/arch/parisc/include/uapi/asm/termbits.h
> @@ -61,31 +61,15 @@ struct ktermios {
>
>
>  /* c_iflag bits */
> -#define IGNBRK   0x1
> -#define BRKINT   0x2
> -#define IGNPAR   0x4
> -#define PARMRK   0x8
> -#define INPCK0x00010
> -#define ISTRIP   0x00020
> -#define INLCR0x00040
> -#define IGNCR0x00080
> -#define ICRNL0x00100
>  #define IUCLC0x00200
>  #define IXON 0x00400
> -#define IXANY0x00800
>  #define IXOFF0x01000
>  #define IMAXBEL  0x04000
>  #define IUTF80x08000

In the hunk above you leave IUCLC, IXON, IXOFF... because they seem unique to 
parisc.
The other defines are then taken from generic header.
Although this is correct, it leaves single values alone, which make it hard to 
verify
because you don't see the full list of values in one place.

> @@ -112,24 +96,6 @@ struct ktermios {
>
>  /* c_cflag bit meaning */
>  #define CBAUD0x100f
> -#define  B0  0x  /* hang up */
> -#define  B50 0x0001
> -#define  B75 0x0002
> -#define  B1100x0003
> -#define  B1340x0004
> -#define  B1500x0005
> -#define  B2000x0006
> -#define  B3000x0007
> -#define  B6000x0008
> -#define  B1200   0x0009
> -#define  B1800   0x000a
> -#define  B2400   0x000b
> -#define  B4800   0x000c
> -#define  B9600   0x000d
> -#define  B19200  0x000e
> -#define  B38400  0x000f
> -#define EXTA B19200
> -#define EXTB B38400

Here all baud values are dropped and will be taken from generic header, which 
is good.

That said, I think it's good to move away the second hunk,
but maybe we should keep the first as is?

It's just a thought. Either way, I'm fine your patch if that's the
way which is decided to go for all platforms.

Helge


Re: [PATCH 12/30] parisc: Replace regular spinlock with spin_trylock on panic path

2022-04-28 Thread Helge Deller
On 4/28/22 00:49, Guilherme G. Piccoli wrote:
> The panic notifiers' callbacks execute in an atomic context, with
> interrupts/preemption disabled, and all CPUs not running the panic
> function are off, so it's very dangerous to wait on a regular
> spinlock, there's a risk of deadlock.
>
> This patch refactors the panic notifier of parisc/power driver
> to make use of spin_trylock - for that, we've added a second
> version of the soft-power function. Also, some comments were
> reorganized and trailing white spaces, useless header inclusion
> and blank lines were removed.
>
> Cc: Helge Deller 
> Cc: "James E.J. Bottomley" 
> Signed-off-by: Guilherme G. Piccoli 

You may add:
Acked-by: Helge Deller  # parisc

Helge


> ---
>  arch/parisc/include/asm/pdc.h |  1 +
>  arch/parisc/kernel/firmware.c | 27 +++
>  drivers/parisc/power.c| 17 ++---
>  3 files changed, 34 insertions(+), 11 deletions(-)
>
> diff --git a/arch/parisc/include/asm/pdc.h b/arch/parisc/include/asm/pdc.h
> index b643092d4b98..7a106008e258 100644
> --- a/arch/parisc/include/asm/pdc.h
> +++ b/arch/parisc/include/asm/pdc.h
> @@ -83,6 +83,7 @@ int pdc_do_firm_test_reset(unsigned long ftc_bitmap);
>  int pdc_do_reset(void);
>  int pdc_soft_power_info(unsigned long *power_reg);
>  int pdc_soft_power_button(int sw_control);
> +int pdc_soft_power_button_panic(int sw_control);
>  void pdc_io_reset(void);
>  void pdc_io_reset_devices(void);
>  int pdc_iodc_getc(void);
> diff --git a/arch/parisc/kernel/firmware.c b/arch/parisc/kernel/firmware.c
> index 6a7e315bcc2e..0e2f70b592f4 100644
> --- a/arch/parisc/kernel/firmware.c
> +++ b/arch/parisc/kernel/firmware.c
> @@ -1232,15 +1232,18 @@ int __init pdc_soft_power_info(unsigned long 
> *power_reg)
>  }
>
>  /*
> - * pdc_soft_power_button - Control the soft power button behaviour
> - * @sw_control: 0 for hardware control, 1 for software control
> + * pdc_soft_power_button{_panic} - Control the soft power button behaviour
> + * @sw_control: 0 for hardware control, 1 for software control
>   *
>   *
>   * This PDC function places the soft power button under software or
>   * hardware control.
> - * Under software control the OS may control to when to allow to shut
> - * down the system. Under hardware control pressing the power button
> + * Under software control the OS may control to when to allow to shut
> + * down the system. Under hardware control pressing the power button
>   * powers off the system immediately.
> + *
> + * The _panic version relies in spin_trylock to prevent deadlock
> + * on panic path.
>   */
>  int pdc_soft_power_button(int sw_control)
>  {
> @@ -1254,6 +1257,22 @@ int pdc_soft_power_button(int sw_control)
>   return retval;
>  }
>
> +int pdc_soft_power_button_panic(int sw_control)
> +{
> + int retval;
> + unsigned long flags;
> +
> + if (!spin_trylock_irqsave(_lock, flags)) {
> + pr_emerg("Couldn't enable soft power button\n");
> + return -EBUSY; /* ignored by the panic notifier */
> + }
> +
> + retval = mem_pdc_call(PDC_SOFT_POWER, PDC_SOFT_POWER_ENABLE, 
> __pa(pdc_result), sw_control);
> + spin_unlock_irqrestore(_lock, flags);
> +
> + return retval;
> +}
> +
>  /*
>   * pdc_io_reset - Hack to avoid overlapping range registers of Bridges 
> devices.
>   * Primarily a problem on T600 (which parisc-linux doesn't support) but
> diff --git a/drivers/parisc/power.c b/drivers/parisc/power.c
> index 456776bd8ee6..8512884de2cf 100644
> --- a/drivers/parisc/power.c
> +++ b/drivers/parisc/power.c
> @@ -37,7 +37,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -175,16 +174,21 @@ static void powerfail_interrupt(int code, void *x)
>
>
>
> -/* parisc_panic_event() is called by the panic handler.
> - * As soon as a panic occurs, our tasklets above will not be
> - * executed any longer. This function then re-enables the
> - * soft-power switch and allows the user to switch off the system
> +/*
> + * parisc_panic_event() is called by the panic handler.
> + *
> + * As soon as a panic occurs, our tasklets above will not
> + * be executed any longer. This function then re-enables
> + * the soft-power switch and allows the user to switch off
> + * the system. We rely in pdc_soft_power_button_panic()
> + * since this version spin_trylocks (instead of regular
> + * spinlock), preventing deadlocks on panic path.
>   */
>  static int parisc_panic_event(struct notifier_block *this,
>   unsigned long event, void *ptr)
>  {
>   /* re-enable the soft-power switch */
> - pdc_soft_power_button(0);
> + pdc_soft_power_button_panic(0);
>   return NOTIFY_DONE;
>  }
>
> @@ -193,7 +197,6 @@ static struct notifier_block parisc_panic_block = {
>   .priority   = INT_MAX,
>  };
>
> -
>  static int __init power_init(void)
>  {
>   unsigned long ret;



Re: [PATCH v4 00/13] Fix LKDTM for PPC64/IA64/PARISC v4

2022-02-16 Thread Helge Deller
On 2/15/22 17:07, Kees Cook wrote:
> On Tue, Feb 15, 2022 at 01:40:55PM +0100, Christophe Leroy wrote:
>> PPC64/IA64/PARISC have function descriptors. LKDTM doesn't work
>> on those three architectures because LKDTM messes up function
>> descriptors with functions.
>>
>> This series does some cleanup in the three architectures and
>> refactors function descriptors so that it can then easily use it
>> in a generic way in LKDTM.
>
> Thanks for doing this! It looks good to me. :)

I endorse that.
Thank you, Christophe!

Acked-by: Helge Deller 

Helge

> -Kees
>
>>
>> Changes in v4:
>> - Added patch 1 which Fixes 'sparse' for powerpc64le after wrong report on 
>> previous series, refer 
>> https://github.com/ruscur/linux-ci/actions/runs/1351427671
>> - Exported dereference_function_descriptor() to modules
>> - Addressed other received comments
>> - Rebased on latest powerpc/next (5a72345e6a78120368fcc841b570331b6c5a50da)
>>
>> Changes in v3:
>> - Addressed received comments
>> - Swapped some of the powerpc patches to keep func_descr_t renamed as struct 
>> func_desc and remove 'struct ppc64_opd_entry'
>> - Changed HAVE_FUNCTION_DESCRIPTORS macro to a config item 
>> CONFIG_HAVE_FUNCTION_DESCRIPTORS
>> - Dropped patch 11 ("Fix lkdtm_EXEC_RODATA()")
>>
>> Changes in v2:
>> - Addressed received comments
>> - Moved dereference_[kernel]_function_descriptor() out of line
>> - Added patches to remove func_descr_t and func_desc_t in powerpc
>> - Using func_desc_t instead of funct_descr_t
>> - Renamed HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR to HAVE_FUNCTION_DESCRIPTORS
>> - Added a new lkdtm test to check protection of function descriptors
>>
>> Christophe Leroy (13):
>>   powerpc: Fix 'sparse' checking on PPC64le
>>   powerpc: Move and rename func_descr_t
>>   powerpc: Use 'struct func_desc' instead of 'struct ppc64_opd_entry'
>>   powerpc: Remove 'struct ppc64_opd_entry'
>>   powerpc: Prepare func_desc_t for refactorisation
>>   ia64: Rename 'ip' to 'addr' in 'struct fdesc'
>>   asm-generic: Define CONFIG_HAVE_FUNCTION_DESCRIPTORS
>>   asm-generic: Define 'func_desc_t' to commonly describe function
>> descriptors
>>   asm-generic: Refactor dereference_[kernel]_function_descriptor()
>>   lkdtm: Force do_nothing() out of line
>>   lkdtm: Really write into kernel text in WRITE_KERN
>>   lkdtm: Fix execute_[user]_location()
>>   lkdtm: Add a test for function descriptors protection
>>
>>  arch/Kconfig |  3 +
>>  arch/ia64/Kconfig|  1 +
>>  arch/ia64/include/asm/elf.h  |  2 +-
>>  arch/ia64/include/asm/sections.h | 24 +---
>>  arch/ia64/kernel/module.c|  6 +-
>>  arch/parisc/Kconfig  |  1 +
>>  arch/parisc/include/asm/sections.h   | 16 ++
>>  arch/parisc/kernel/process.c | 21 ---
>>  arch/powerpc/Kconfig |  1 +
>>  arch/powerpc/Makefile|  2 +-
>>  arch/powerpc/include/asm/code-patching.h |  2 +-
>>  arch/powerpc/include/asm/elf.h   |  6 ++
>>  arch/powerpc/include/asm/sections.h  | 29 ++
>>  arch/powerpc/include/asm/types.h |  6 --
>>  arch/powerpc/include/uapi/asm/elf.h  |  8 ---
>>  arch/powerpc/kernel/module_64.c  | 42 ++
>>  arch/powerpc/kernel/ptrace/ptrace.c  |  6 ++
>>  arch/powerpc/kernel/signal_64.c  |  8 +--
>>  drivers/misc/lkdtm/core.c|  1 +
>>  drivers/misc/lkdtm/lkdtm.h   |  1 +
>>  drivers/misc/lkdtm/perms.c   | 71 +++-
>>  include/asm-generic/sections.h   | 15 -
>>  include/linux/kallsyms.h |  2 +-
>>  kernel/extable.c | 24 +++-
>>  tools/testing/selftests/lkdtm/tests.txt  |  1 +
>>  25 files changed, 155 insertions(+), 144 deletions(-)
>>
>> --
>> 2.34.1
>>
>



Re: [PATCH 14/14] uaccess: drop set_fs leftovers

2022-02-14 Thread Helge Deller
On 2/15/22 04:03, Al Viro wrote:
> On Mon, Feb 14, 2022 at 05:34:52PM +0100, Arnd Bergmann wrote:
>> diff --git a/arch/parisc/include/asm/futex.h 
>> b/arch/parisc/include/asm/futex.h
>> index b5835325d44b..2f4a1b1ef387 100644
>> --- a/arch/parisc/include/asm/futex.h
>> +++ b/arch/parisc/include/asm/futex.h
>> @@ -99,7 +99,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
>>  /* futex.c wants to do a cmpxchg_inatomic on kernel NULL, which is
>>   * our gateway page, and causes no end of trouble...
>>   */
>> -if (uaccess_kernel() && !uaddr)
>> +if (!uaddr)
>>  return -EFAULT;
>
>   Huh?  uaccess_kernel() is removed since it becomes always false now,
> so this looks odd.
>
>   AFAICS, the comment above that check refers to futex_detect_cmpxchg()
> -> cmpxchg_futex_value_locked() -> futex_atomic_cmpxchg_inatomic() call chain.
> Which had been gone since commit 3297481d688a (futex: Remove futex_cmpxchg
> detection).  The comment *and* the check should've been killed off back
> then.
>   Let's make sure to get both now...

Right. Arnd, can you drop this if() and the comment above it?

Thanks,
Helge


Re: [PATCH v3 11/12] lkdtm: Fix execute_[user]_location()

2021-12-17 Thread Helge Deller
On 12/17/21 12:49, Christophe Leroy wrote:
> Hi Kees,
>
> Le 17/10/2021 à 14:38, Christophe Leroy a écrit :
>> execute_location() and execute_user_location() intent
>> to copy do_nothing() text and execute it at a new location.
>> However, at the time being it doesn't copy do_nothing() function
>> but do_nothing() function descriptor which still points to the
>> original text. So at the end it still executes do_nothing() at
>> its original location allthough using a copied function descriptor.
>>
>> So, fix that by really copying do_nothing() text and build a new
>> function descriptor by copying do_nothing() function descriptor and
>> updating the target address with the new location.
>>
>> Also fix the displayed addresses by dereferencing do_nothing()
>> function descriptor.
>>
>> Signed-off-by: Christophe Leroy 
>
> Do you have any comment to this patch and to patch 12 ?
>
> If not, is it ok to get your acked-by ?


Hi Christophe,

I think this whole series is a nice cleanup and harmonization
of how function descriptors are used.

At least for the PA-RISC parts you may add:
Acked-by: Helge Deller 

Thanks!
Helge

>
>> ---
>>   drivers/misc/lkdtm/perms.c | 37 -
>>   1 file changed, 28 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/misc/lkdtm/perms.c b/drivers/misc/lkdtm/perms.c
>> index 035fcca441f0..1cf24c4a79e9 100644
>> --- a/drivers/misc/lkdtm/perms.c
>> +++ b/drivers/misc/lkdtm/perms.c
>> @@ -44,19 +44,34 @@ static noinline void do_overwritten(void)
>>  return;
>>   }
>>
>> +static void *setup_function_descriptor(func_desc_t *fdesc, void *dst)
>> +{
>> +if (!have_function_descriptors())
>> +return dst;
>> +
>> +memcpy(fdesc, do_nothing, sizeof(*fdesc));
>> +fdesc->addr = (unsigned long)dst;
>> +barrier();
>> +
>> +return fdesc;
>> +}
>> +
>>   static noinline void execute_location(void *dst, bool write)
>>   {
>> -void (*func)(void) = dst;
>> +void (*func)(void);
>> +func_desc_t fdesc;
>> +void *do_nothing_text = dereference_function_descriptor(do_nothing);
>>
>> -pr_info("attempting ok execution at %px\n", do_nothing);
>> +pr_info("attempting ok execution at %px\n", do_nothing_text);
>>  do_nothing();
>>
>>  if (write == CODE_WRITE) {
>> -memcpy(dst, do_nothing, EXEC_SIZE);
>> +memcpy(dst, do_nothing_text, EXEC_SIZE);
>>  flush_icache_range((unsigned long)dst,
>> (unsigned long)dst + EXEC_SIZE);
>>  }
>> -pr_info("attempting bad execution at %px\n", func);
>> +pr_info("attempting bad execution at %px\n", dst);
>> +func = setup_function_descriptor(, dst);
>>  func();
>>  pr_err("FAIL: func returned\n");
>>   }
>> @@ -66,16 +81,19 @@ static void execute_user_location(void *dst)
>>  int copied;
>>
>>  /* Intentionally crossing kernel/user memory boundary. */
>> -void (*func)(void) = dst;
>> +void (*func)(void);
>> +func_desc_t fdesc;
>> +void *do_nothing_text = dereference_function_descriptor(do_nothing);
>>
>> -pr_info("attempting ok execution at %px\n", do_nothing);
>> +pr_info("attempting ok execution at %px\n", do_nothing_text);
>>  do_nothing();
>>
>> -copied = access_process_vm(current, (unsigned long)dst, do_nothing,
>> +copied = access_process_vm(current, (unsigned long)dst, do_nothing_text,
>> EXEC_SIZE, FOLL_WRITE);
>>  if (copied < EXEC_SIZE)
>>  return;
>> -pr_info("attempting bad execution at %px\n", func);
>> +pr_info("attempting bad execution at %px\n", dst);
>> +func = setup_function_descriptor(, dst);
>>  func();
>>  pr_err("FAIL: func returned\n");
>>   }
>> @@ -153,7 +171,8 @@ void lkdtm_EXEC_VMALLOC(void)
>>
>>   void lkdtm_EXEC_RODATA(void)
>>   {
>> -execute_location(lkdtm_rodata_do_nothing, CODE_AS_IS);
>> +
>> execute_location(dereference_function_descriptor(lkdtm_rodata_do_nothing),
>> + CODE_AS_IS);
>>   }
>>
>>   void lkdtm_EXEC_USERSPACE(void)



Re: Build regressions/improvements in v5.16-rc1

2021-11-17 Thread Helge Deller
On 11/17/21 03:19, Nick Terrell wrote:
>
>
>> On Nov 16, 2021, at 6:05 PM, Randy Dunlap  wrote:
>>
>> On 11/16/21 5:59 PM, Nick Terrell wrote:
>>>> On Nov 15, 2021, at 8:44 AM, Helge Deller  wrote:
>>>>
>>>> On 11/15/21 17:12, Geert Uytterhoeven wrote:
>>>>> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven  
>>>>> wrote:
>>>>>> Below is the list of build error/warning regressions/improvements in
>>>>>> v5.16-rc1[1] compared to v5.15[2].
>>>>>>
>>>>>> Summarized:
>>>>>>  - build errors: +20/-13
>>>>>>  - build warnings: +3/-28
>>>>>>
>>>>>> Happy fixing! ;-)
>>>>>>
>>>>>> Thanks to the linux-next team for providing the build service.
>>>>>>
>>>>>> [1] 
>>>>>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf/
>>>>>>(all 90 configs)
>>>>>> [2] 
>>>>>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8bb7eca972ad531c9b149c0a51ab43a417385813/
>>>>>>(all 90 configs)
>>>>>>
>>>>>>
>>>>>> *** ERRORS ***
>>>>>>
>>>>>> 20 error regressions:
>>>>>>  + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: expected ':' 
>>>>>> before '__stringify':  => 33:4, 18:4
>>>>>>  + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: label 
>>>>>> 'l_yes' defined but not used [-Werror=unused-label]:  => 38:1, 23:1
>>>>>
>>>>>due to static_branch_likely() in crypto/api.c
>>>>>
>>>>> parisc-allmodconfig
>>>>
>>>> fixed now in the parisc for-next git tree.
>>>>
>>>>
>>>>>>  + /kisskb/src/drivers/gpu/drm/msm/msm_drv.h: error: "COND" redefined 
>>>>>> [-Werror]:  => 531
>>>>>>  + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame 
>>>>>> size of 3252 bytes is larger than 1536 bytes 
>>>>>> [-Werror=frame-larger-than=]:  => 47:1
>>>>>>  + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame 
>>>>>> size of 3360 bytes is larger than 1536 bytes 
>>>>>> [-Werror=frame-larger-than=]:  => 499:1
>>>>>>  + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame 
>>>>>> size of 5344 bytes is larger than 1536 bytes 
>>>>>> [-Werror=frame-larger-than=]:  => 334:1
>>>>>>  + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame 
>>>>>> size of 5380 bytes is larger than 1536 bytes 
>>>>>> [-Werror=frame-larger-than=]:  => 354:1
>>>>>>  + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 
>>>>>> 1824 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]:  => 
>>>>>> 372:1
>>>>>>  + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 
>>>>>> 2224 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]:  => 
>>>>>> 204:1
>>>>>>  + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 
>>>>>> 3800 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]:  => 
>>>>>> 476:1
>>>>>
>>>>> parisc-allmodconfig
>>>>
>>>> parisc needs much bigger frame sizes, so I'm not astonished here.
>>>> During the v5.15 cycl I increased it to 1536 (from 1280), so I'm simply 
>>>> tempted to
>>>> increase it this time to 4096, unless someone has a better idea
>>> This patch set should fix the zstd stack size warnings [0]. I’ve
>>> verified the fix using the same tooling: gcc-8-hppa-linux-gnu.
>>> I’ll send the PR to Linus tomorrow. I’ve been informed that it
>>> isn't strictly necessary to send the patches to the mailing list
>>> for bug fixes, but its already done, so I’ll wait and see if there
>>> is any feedback.
>>
>> IMO several (or many more) people would disagree with that.
>>
>> "strictly?"  OK, it's probably possible that almost any patch
>> could be merged without being on a mailing list, but it's not
>> desirable (except in the case of "security" patches).
>
> Good to know! Thanks for the advice, I wasn’t really sure what
> the best practice is for sending patches to your own tree, as I
> didn't see anything about it in the maintainer guide.

Nick, thanks a lot for your efforts to get the frame size usage down!

I've applied your patch series to the parisc for-next tree [1], so that it
gets some testing in the upstream for-next tree.
My tests so far are good, although I'm only using gcc-11.

If you don't mind, and if it doesn't generate issues for other
platforms & architectures I could submit them upstream to Linus when
I send the next pull request.

Helge

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/log/?h=for-next


Re: Build regressions/improvements in v5.16-rc1

2021-11-15 Thread Helge Deller
On 11/15/21 17:12, Geert Uytterhoeven wrote:
> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven  
> wrote:
>> Below is the list of build error/warning regressions/improvements in
>> v5.16-rc1[1] compared to v5.15[2].
>>
>> Summarized:
>>   - build errors: +20/-13
>>   - build warnings: +3/-28
>>
>> Happy fixing! ;-)
>>
>> Thanks to the linux-next team for providing the build service.
>>
>> [1] 
>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf/
>>  (all 90 configs)
>> [2] 
>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8bb7eca972ad531c9b149c0a51ab43a417385813/
>>  (all 90 configs)
>>
>>
>> *** ERRORS ***
>>
>> 20 error regressions:
>>   + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: expected ':' 
>> before '__stringify':  => 33:4, 18:4
>>   + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: label 'l_yes' 
>> defined but not used [-Werror=unused-label]:  => 38:1, 23:1
>
> due to static_branch_likely() in crypto/api.c
>
> parisc-allmodconfig

fixed now in the parisc for-next git tree.


>>   + /kisskb/src/drivers/gpu/drm/msm/msm_drv.h: error: "COND" redefined 
>> [-Werror]:  => 531
>>   + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size 
>> of 3252 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]:  => 
>> 47:1
>>   + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size 
>> of 3360 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]:  => 
>> 499:1
>>   + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size 
>> of 5344 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]:  => 
>> 334:1
>>   + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size 
>> of 5380 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]:  => 
>> 354:1
>>   + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 1824 
>> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]:  => 372:1
>>   + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 2224 
>> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]:  => 204:1
>>   + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 3800 
>> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]:  => 476:1
>
> parisc-allmodconfig

parisc needs much bigger frame sizes, so I'm not astonished here.
During the v5.15 cycl I increased it to 1536 (from 1280), so I'm simply tempted 
to
increase it this time to 4096, unless someone has a better idea

>>   + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2240 bytes is 
>> larger than 2048 bytes [-Werror=frame-larger-than=]:  => 1311:1
>>   + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2304 bytes is 
>> larger than 2048 bytes [-Werror=frame-larger-than=]:  => 1311:1
>>   + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2320 bytes is 
>> larger than 2048 bytes [-Werror=frame-larger-than=]:  => 1311:1
>
> powerpc-allmodconfig
>
>>   + /kisskb/src/include/linux/compiler_types.h: error: call to 
>> '__compiletime_assert_366' declared with attribute error: FIELD_PREP: value 
>> too large for the field:  => 335:38
>
> in drivers/pinctrl/pinctrl-apple-gpio.c
>
> arm64-allmodconfig (gcc8)
>
>>   + /kisskb/src/include/linux/fortify-string.h: error: call to 
>> '__read_overflow' declared with attribute error: detected read beyond size 
>> of object (1st parameter):  => 263:25, 277:17
>
> in lib/test_kasan.c
>
> s390-all{mod,yes}config
> arm64-allmodconfig (gcc11)
>
>>   + error: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko] 
>> undefined!:  => N/A
>>   + error: modpost: "mips_cm_lock_other" 
>> [drivers/pci/controller/pcie-mt7621.ko] undefined!:  => N/A
>>   + error: modpost: "mips_cm_unlock_other" 
>> [drivers/pci/controller/pcie-mt7621.ko] undefined!:  => N/A
>>   + error: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko] 
>> undefined!:  => N/A
>>   + error: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko] 
>> undefined!:  => N/A
>
> mips-allmodconfig
>
>> 3 warning regressions:
>>   + : warning: #warning syscall futex_waitv not implemented [-Wcpp]:  
>> => 1559:2
>
> powerpc, m68k, mips, s390, parisc (and probably more)

Will someone update all of them at once?




Helge


>>   + arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for 
>> MCTP:  => 322
>>   + arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for 
>> MCTP:  => 295
>
> Yeah, that happens when symbols are changed from tristate to bool...
> Will be fixed in 5.17-rc1, with the next defconfig refresh.
>
> 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.
> 

Re: [PATCH v2 16/45] parisc: Use do_kernel_power_off()

2021-10-28 Thread Helge Deller
On 10/27/21 23:16, Dmitry Osipenko wrote:
> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
> that invokes chained power-off handlers. It also invokes legacy
> pm_power_off() for now, which will be removed once all drivers will
> be converted to the new power-off API.
>
> Signed-off-by: Dmitry Osipenko 

Acked-by: Helge Deller  # parisc



> ---
>  arch/parisc/kernel/process.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
> index ea3d83b6fb62..928201b1f58f 100644
> --- a/arch/parisc/kernel/process.c
> +++ b/arch/parisc/kernel/process.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -114,8 +115,7 @@ void machine_power_off(void)
>   pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN);
>
>   /* ipmi_poweroff may have been installed. */
> - if (pm_power_off)
> - pm_power_off();
> + do_kernel_power_off();
>
>   /* It seems we have no way to power the system off via
>* software. The user has to press the button himself. */
>



Re: [PATCH] locking: remove spin_lock_flags() etc

2021-10-22 Thread Helge Deller
On 10/22/21 13:59, Arnd Bergmann wrote:
> From: Arnd Bergmann 
>
> parisc, ia64 and powerpc32 are the only remaining architectures that
> provide custom arch_{spin,read,write}_lock_flags() functions, which are
> meant to re-enable interrupts while waiting for a spinlock.
>
> However, none of these can actually run into this codepath, because
> it is only called on architectures without CONFIG_GENERIC_LOCKBREAK,
> or when CONFIG_DEBUG_LOCK_ALLOC is set without CONFIG_LOCKDEP, and none
> of those combinations are possible on the three architectures.
>
> Going back in the git history, it appears that arch/mn10300 may have
> been able to run into this code path, but there is a good chance that
> it never worked. On the architectures that still exist, it was
> already impossible to hit back in 2008 after the introduction of
> CONFIG_GENERIC_LOCKBREAK, and possibly earlier.
>
> As this is all dead code, just remove it and the helper functions built
> around it. For arch/ia64, the inline asm could be cleaned up, but
> it seems safer to leave it untouched.
>
> Signed-off-by: Arnd Bergmann 

Acked-by: Helge Deller   # parisc

Helge

> ---
>  arch/ia64/include/asm/spinlock.h   | 23 ++
>  arch/openrisc/include/asm/spinlock.h   |  3 ---
>  arch/parisc/include/asm/spinlock.h | 15 --
>  arch/powerpc/include/asm/simple_spinlock.h | 21 
>  arch/s390/include/asm/spinlock.h   |  8 
>  include/linux/lockdep.h| 17 
>  include/linux/rwlock.h | 15 --
>  include/linux/rwlock_api_smp.h |  6 ++
>  include/linux/spinlock.h   | 13 
>  include/linux/spinlock_api_smp.h   |  9 -
>  include/linux/spinlock_up.h|  1 -
>  kernel/locking/spinlock.c  |  3 +--
>  12 files changed, 9 insertions(+), 125 deletions(-)
>
> diff --git a/arch/ia64/include/asm/spinlock.h 
> b/arch/ia64/include/asm/spinlock.h
> index 864775970c50..0e5c1ad3239c 100644
> --- a/arch/ia64/include/asm/spinlock.h
> +++ b/arch/ia64/include/asm/spinlock.h
> @@ -124,18 +124,13 @@ static __always_inline void 
> arch_spin_unlock(arch_spinlock_t *lock)
>   __ticket_spin_unlock(lock);
>  }
>
> -static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock,
> -   unsigned long flags)
> -{
> - arch_spin_lock(lock);
> -}
> -#define arch_spin_lock_flags arch_spin_lock_flags
> -
>  #ifdef ASM_SUPPORTED
>
>  static __always_inline void
> -arch_read_lock_flags(arch_rwlock_t *lock, unsigned long flags)
> +arch_read_lock(arch_rwlock_t *lock)
>  {
> + unsigned long flags = 0;
> +
>   __asm__ __volatile__ (
>   "tbit.nz p6, p0 = %1,%2\n"
>   "br.few 3f\n"
> @@ -157,13 +152,8 @@ arch_read_lock_flags(arch_rwlock_t *lock, unsigned long 
> flags)
>   : "p6", "p7", "r2", "memory");
>  }
>
> -#define arch_read_lock_flags arch_read_lock_flags
> -#define arch_read_lock(lock) arch_read_lock_flags(lock, 0)
> -
>  #else /* !ASM_SUPPORTED */
>
> -#define arch_read_lock_flags(rw, flags) arch_read_lock(rw)
> -
>  #define arch_read_lock(rw)   
> \
>  do { 
> \
>   arch_rwlock_t *__read_lock_ptr = (rw);  
> \
> @@ -186,8 +176,10 @@ do { 
> \
>  #ifdef ASM_SUPPORTED
>
>  static __always_inline void
> -arch_write_lock_flags(arch_rwlock_t *lock, unsigned long flags)
> +arch_write_lock(arch_rwlock_t *lock)
>  {
> + unsigned long flags = 0;
> +
>   __asm__ __volatile__ (
>   "tbit.nz p6, p0 = %1, %2\n"
>   "mov ar.ccv = r0\n"
> @@ -210,9 +202,6 @@ arch_write_lock_flags(arch_rwlock_t *lock, unsigned long 
> flags)
>   : "ar.ccv", "p6", "p7", "r2", "r29", "memory");
>  }
>
> -#define arch_write_lock_flags arch_write_lock_flags
> -#define arch_write_lock(rw) arch_write_lock_flags(rw, 0)
> -
>  #define arch_write_trylock(rw)   
> \
>  ({   
> \
>   register long result;   
> \
> diff --git a/arch/openrisc/include/asm/spinlock.h 
> b/arch

Re: [PATCH v1 04/10] asm-generic: Use HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR to define associated stubs

2021-10-12 Thread Helge Deller
* Christophe Leroy :
>
>
> Le 12/10/2021 à 08:02, Helge Deller a écrit :
> > On 10/11/21 17:25, Christophe Leroy wrote:
> > > Use HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR instead of 
> > > 'dereference_function_descriptor'
> > > to know whether arch has function descriptors.
> > >
> > > Signed-off-by: Christophe Leroy 
> > > ---
> > >   arch/ia64/include/asm/sections.h| 4 ++--
> > >   arch/parisc/include/asm/sections.h  | 6 --
> > >   arch/powerpc/include/asm/sections.h | 6 --
> > >   include/asm-generic/sections.h  | 3 ++-
> > >   4 files changed, 12 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/ia64/include/asm/sections.h 
> > > b/arch/ia64/include/asm/sections.h
> > > index 35f24e52149a..80f5868afb06 100644
> > > --- a/arch/ia64/include/asm/sections.h
> > > +++ b/arch/ia64/include/asm/sections.h
> > > @@ -7,6 +7,8 @@
> > >*  David Mosberger-Tang 
> > >*/
> > >
> > > +#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> > > +
> > >   #include 
> > >   #include 
> > >   #include 
> > > @@ -27,8 +29,6 @@ extern char 
> > > __start_gate_brl_fsys_bubble_down_patchlist[], __end_gate_brl_fsys_b
> > >   extern char __start_unwind[], __end_unwind[];
> > >   extern char __start_ivt_text[], __end_ivt_text[];
> > >
> > > -#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> > > -
> > >   #undef dereference_function_descriptor
> > >   static inline void *dereference_function_descriptor(void *ptr)
> > >   {
> > > diff --git a/arch/parisc/include/asm/sections.h 
> > > b/arch/parisc/include/asm/sections.h
> > > index bb52aea0cb21..2e781ee19b66 100644
> > > --- a/arch/parisc/include/asm/sections.h
> > > +++ b/arch/parisc/include/asm/sections.h
> > > @@ -2,6 +2,10 @@
> > >   #ifndef _PARISC_SECTIONS_H
> > >   #define _PARISC_SECTIONS_H
> > >
> > > +#ifdef CONFIG_64BIT
> > > +#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> > > +#endif
> > > +
> > >   /* nothing to see, move along */
> > >   #include 
> > >
> > > @@ -9,8 +13,6 @@ extern char __alt_instructions[], 
> > > __alt_instructions_end[];
> > >
> > >   #ifdef CONFIG_64BIT
> > >
> > > -#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> > > -
> > >   #undef dereference_function_descriptor
> > >   void *dereference_function_descriptor(void *);
> > >
> > > diff --git a/arch/powerpc/include/asm/sections.h 
> > > b/arch/powerpc/include/asm/sections.h
> > > index 32e7035863ac..b7f1ba04e756 100644
> > > --- a/arch/powerpc/include/asm/sections.h
> > > +++ b/arch/powerpc/include/asm/sections.h
> > > @@ -8,6 +8,10 @@
> > >
> > >   #define arch_is_kernel_initmem_freed arch_is_kernel_initmem_freed
> > >
> > > +#ifdef PPC64_ELF_ABI_v1
> > > +#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> > > +#endif
> > > +
> > >   #include 
> > >
> > >   extern bool init_mem_is_free;
> > > @@ -69,8 +73,6 @@ static inline int overlaps_kernel_text(unsigned long 
> > > start, unsigned long end)
> > >
> > >   #ifdef PPC64_ELF_ABI_v1
> > >
> > > -#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> > > -
> > >   #undef dereference_function_descriptor
> > >   static inline void *dereference_function_descriptor(void *ptr)
> > >   {
> > > diff --git a/include/asm-generic/sections.h 
> > > b/include/asm-generic/sections.h
> > > index d16302d3eb59..1db5cfd69817 100644
> > > --- a/include/asm-generic/sections.h
> > > +++ b/include/asm-generic/sections.h
> > > @@ -59,7 +59,8 @@ extern char __noinstr_text_start[], 
> > > __noinstr_text_end[];
> > >   extern __visible const void __nosave_begin, __nosave_end;
> > >
> > >   /* Function descriptor handling (if any).  Override in asm/sections.h */
> > > -#ifndef dereference_function_descriptor
> > > +#ifdef HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR
> > > +#else
> >
> > why not
> > #ifndef HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR
> > instead of #if/#else ?
>
> To avoid changing it again in patch 6, or getting an ugly #ifndef/#else at
> the end.

Ok.

Building on parisc fails at multiple files like this:
  CC  mm/filemap.o
In file included from 
/home/cvs/parisc/git-kernel/linus-linux-2.6/include/linux/i

Re: [PATCH v1 04/10] asm-generic: Use HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR to define associated stubs

2021-10-12 Thread Helge Deller
On 10/11/21 17:25, Christophe Leroy wrote:
> Use HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR instead of 
> 'dereference_function_descriptor'
> to know whether arch has function descriptors.
>
> Signed-off-by: Christophe Leroy 
> ---
>  arch/ia64/include/asm/sections.h| 4 ++--
>  arch/parisc/include/asm/sections.h  | 6 --
>  arch/powerpc/include/asm/sections.h | 6 --
>  include/asm-generic/sections.h  | 3 ++-
>  4 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/arch/ia64/include/asm/sections.h 
> b/arch/ia64/include/asm/sections.h
> index 35f24e52149a..80f5868afb06 100644
> --- a/arch/ia64/include/asm/sections.h
> +++ b/arch/ia64/include/asm/sections.h
> @@ -7,6 +7,8 @@
>   *   David Mosberger-Tang 
>   */
>
> +#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> +
>  #include 
>  #include 
>  #include 
> @@ -27,8 +29,6 @@ extern char __start_gate_brl_fsys_bubble_down_patchlist[], 
> __end_gate_brl_fsys_b
>  extern char __start_unwind[], __end_unwind[];
>  extern char __start_ivt_text[], __end_ivt_text[];
>
> -#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> -
>  #undef dereference_function_descriptor
>  static inline void *dereference_function_descriptor(void *ptr)
>  {
> diff --git a/arch/parisc/include/asm/sections.h 
> b/arch/parisc/include/asm/sections.h
> index bb52aea0cb21..2e781ee19b66 100644
> --- a/arch/parisc/include/asm/sections.h
> +++ b/arch/parisc/include/asm/sections.h
> @@ -2,6 +2,10 @@
>  #ifndef _PARISC_SECTIONS_H
>  #define _PARISC_SECTIONS_H
>
> +#ifdef CONFIG_64BIT
> +#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> +#endif
> +
>  /* nothing to see, move along */
>  #include 
>
> @@ -9,8 +13,6 @@ extern char __alt_instructions[], __alt_instructions_end[];
>
>  #ifdef CONFIG_64BIT
>
> -#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> -
>  #undef dereference_function_descriptor
>  void *dereference_function_descriptor(void *);
>
> diff --git a/arch/powerpc/include/asm/sections.h 
> b/arch/powerpc/include/asm/sections.h
> index 32e7035863ac..b7f1ba04e756 100644
> --- a/arch/powerpc/include/asm/sections.h
> +++ b/arch/powerpc/include/asm/sections.h
> @@ -8,6 +8,10 @@
>
>  #define arch_is_kernel_initmem_freed arch_is_kernel_initmem_freed
>
> +#ifdef PPC64_ELF_ABI_v1
> +#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> +#endif
> +
>  #include 
>
>  extern bool init_mem_is_free;
> @@ -69,8 +73,6 @@ static inline int overlaps_kernel_text(unsigned long start, 
> unsigned long end)
>
>  #ifdef PPC64_ELF_ABI_v1
>
> -#define HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR 1
> -
>  #undef dereference_function_descriptor
>  static inline void *dereference_function_descriptor(void *ptr)
>  {
> diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
> index d16302d3eb59..1db5cfd69817 100644
> --- a/include/asm-generic/sections.h
> +++ b/include/asm-generic/sections.h
> @@ -59,7 +59,8 @@ extern char __noinstr_text_start[], __noinstr_text_end[];
>  extern __visible const void __nosave_begin, __nosave_end;
>
>  /* Function descriptor handling (if any).  Override in asm/sections.h */
> -#ifndef dereference_function_descriptor
> +#ifdef HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR
> +#else

why not
#ifndef HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR
instead of #if/#else ?

>  #define dereference_function_descriptor(p) ((void *)(p))
>  #define dereference_kernel_function_descriptor(p) ((void *)(p))
>  #endif
>



Re: [PATCH] agp: define proper stubs for empty helpers

2021-09-20 Thread Helge Deller

On 9/20/21 2:17 PM, Arnd Bergmann wrote:

From: Arnd Bergmann 

The empty unmap_page_from_agp() macro causes a warning when
building with 'make W=1' on a couple of architectures:

drivers/char/agp/generic.c: In function 'agp_generic_destroy_page':
drivers/char/agp/generic.c:1265:28: error: suggest braces around empty body in 
an 'if' statement [-Werror=empty-body]
  1265 |   unmap_page_from_agp(page);

Change the definitions to a 'do { } while (0)' construct to
make these more reliable.

Signed-off-by: Arnd Bergmann 


Acked-by: Helge Deller  # parisc

Thanks,
Helge


---
  arch/parisc/include/asm/agp.h  | 4 ++--
  arch/powerpc/include/asm/agp.h | 4 ++--
  arch/sparc/include/asm/agp.h   | 6 +++---
  3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/parisc/include/asm/agp.h b/arch/parisc/include/asm/agp.h
index cb04470e63d0..14ae54cfd368 100644
--- a/arch/parisc/include/asm/agp.h
+++ b/arch/parisc/include/asm/agp.h
@@ -8,8 +8,8 @@
   *
   */

-#define map_page_into_agp(page)/* nothing */
-#define unmap_page_from_agp(page)  /* nothing */
+#define map_page_into_agp(page)do { } while (0)
+#define unmap_page_from_agp(page)  do { } while (0)
  #define flush_agp_cache() mb()

  /* GATT allocation. Returns/accepts GATT kernel virtual address. */
diff --git a/arch/powerpc/include/asm/agp.h b/arch/powerpc/include/asm/agp.h
index b29b1186f819..6b6485c988dd 100644
--- a/arch/powerpc/include/asm/agp.h
+++ b/arch/powerpc/include/asm/agp.h
@@ -5,8 +5,8 @@

  #include 

-#define map_page_into_agp(page)
-#define unmap_page_from_agp(page)
+#define map_page_into_agp(page) do {} while (0)
+#define unmap_page_from_agp(page) do {} while (0)
  #define flush_agp_cache() mb()

  /* GATT allocation. Returns/accepts GATT kernel virtual address. */
diff --git a/arch/sparc/include/asm/agp.h b/arch/sparc/include/asm/agp.h
index efe0d6a12e5a..2d0ff84cee3f 100644
--- a/arch/sparc/include/asm/agp.h
+++ b/arch/sparc/include/asm/agp.h
@@ -4,9 +4,9 @@

  /* dummy for now */

-#define map_page_into_agp(page)
-#define unmap_page_from_agp(page)
-#define flush_agp_cache() mb()
+#define map_page_into_agp(page)do { } while (0)
+#define unmap_page_from_agp(page)  do { } while (0)
+#define flush_agp_cache()  mb()

  /* GATT allocation. Returns/accepts GATT kernel virtual address. */
  #define alloc_gatt_pages(order)   \





Re: [PATCH v2] ftrace: Cleanup ftrace_dyn_arch_init()

2021-09-06 Thread Helge Deller

On 9/6/21 1:16 PM, Weizhao Ouyang wrote:

Most of ARCHs use empty ftrace_dyn_arch_init(), introduce a weak common
ftrace_dyn_arch_init() to cleanup them.

Signed-off-by: Weizhao Ouyang 
Acked-by: Heiko Carstens  (s390)


Acked-by: Helge Deller  # parisc

Thanks,
Helge



---

Changes in v2:
-- correct CONFIG_DYNAMIC_FTRACE on PowerPC
-- add Acked-by tag

---
  arch/arm/kernel/ftrace.c  | 5 -
  arch/arm64/kernel/ftrace.c| 5 -
  arch/csky/kernel/ftrace.c | 5 -
  arch/ia64/kernel/ftrace.c | 6 --
  arch/microblaze/kernel/ftrace.c   | 5 -
  arch/mips/include/asm/ftrace.h| 2 ++
  arch/nds32/kernel/ftrace.c| 5 -
  arch/parisc/kernel/ftrace.c   | 5 -
  arch/powerpc/include/asm/ftrace.h | 4 
  arch/riscv/kernel/ftrace.c| 5 -
  arch/s390/kernel/ftrace.c | 5 -
  arch/sh/kernel/ftrace.c   | 5 -
  arch/sparc/kernel/ftrace.c| 5 -
  arch/x86/kernel/ftrace.c  | 5 -
  include/linux/ftrace.h| 1 -
  kernel/trace/ftrace.c | 5 +
  16 files changed, 11 insertions(+), 62 deletions(-)

diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
index 3c83b5d29697..a006585e1c09 100644
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -193,11 +193,6 @@ int ftrace_make_nop(struct module *mod,

return ret;
  }
-
-int __init ftrace_dyn_arch_init(void)
-{
-   return 0;
-}
  #endif /* CONFIG_DYNAMIC_FTRACE */

  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 7f467bd9db7a..fc62dfe73f93 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -236,11 +236,6 @@ void arch_ftrace_update_code(int command)
command |= FTRACE_MAY_SLEEP;
ftrace_modify_all_code(command);
  }
-
-int __init ftrace_dyn_arch_init(void)
-{
-   return 0;
-}
  #endif /* CONFIG_DYNAMIC_FTRACE */

  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
diff --git a/arch/csky/kernel/ftrace.c b/arch/csky/kernel/ftrace.c
index b4a7ec1517ff..50bfcf129078 100644
--- a/arch/csky/kernel/ftrace.c
+++ b/arch/csky/kernel/ftrace.c
@@ -133,11 +133,6 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
(unsigned long)func, true, true);
return ret;
  }
-
-int __init ftrace_dyn_arch_init(void)
-{
-   return 0;
-}
  #endif /* CONFIG_DYNAMIC_FTRACE */

  #ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
diff --git a/arch/ia64/kernel/ftrace.c b/arch/ia64/kernel/ftrace.c
index b2ab2d58fb30..d6360fd404ab 100644
--- a/arch/ia64/kernel/ftrace.c
+++ b/arch/ia64/kernel/ftrace.c
@@ -194,9 +194,3 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
flush_icache_range(addr, addr + 16);
return 0;
  }
-
-/* run from kstop_machine */
-int __init ftrace_dyn_arch_init(void)
-{
-   return 0;
-}
diff --git a/arch/microblaze/kernel/ftrace.c b/arch/microblaze/kernel/ftrace.c
index 224eea40e1ee..188749d62709 100644
--- a/arch/microblaze/kernel/ftrace.c
+++ b/arch/microblaze/kernel/ftrace.c
@@ -163,11 +163,6 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long 
addr)
return ret;
  }

-int __init ftrace_dyn_arch_init(void)
-{
-   return 0;
-}
-
  int ftrace_update_ftrace_func(ftrace_func_t func)
  {
unsigned long ip = (unsigned long)(_call);
diff --git a/arch/mips/include/asm/ftrace.h b/arch/mips/include/asm/ftrace.h
index b463f2aa5a61..ed013e767390 100644
--- a/arch/mips/include/asm/ftrace.h
+++ b/arch/mips/include/asm/ftrace.h
@@ -76,6 +76,8 @@ do {  \


  #ifdef CONFIG_DYNAMIC_FTRACE
+int __init ftrace_dyn_arch_init(void);
+
  static inline unsigned long ftrace_call_adjust(unsigned long addr)
  {
return addr;
diff --git a/arch/nds32/kernel/ftrace.c b/arch/nds32/kernel/ftrace.c
index 0e23e3a8df6b..f0ef4842d191 100644
--- a/arch/nds32/kernel/ftrace.c
+++ b/arch/nds32/kernel/ftrace.c
@@ -84,11 +84,6 @@ void _ftrace_caller(unsigned long parent_ip)
/* restore all state needed by the compiler epilogue */
  }

-int __init ftrace_dyn_arch_init(void)
-{
-   return 0;
-}
-
  static unsigned long gen_sethi_insn(unsigned long addr)
  {
unsigned long opcode = 0x4600;
diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c
index 0a1e75af5382..01581f715737 100644
--- a/arch/parisc/kernel/ftrace.c
+++ b/arch/parisc/kernel/ftrace.c
@@ -94,11 +94,6 @@ int ftrace_disable_ftrace_graph_caller(void)
  #endif

  #ifdef CONFIG_DYNAMIC_FTRACE
-
-int __init ftrace_dyn_arch_init(void)
-{
-   return 0;
-}
  int ftrace_update_ftrace_func(ftrace_func_t func)
  {
return 0;
diff --git a/arch/powerpc/include/asm/ftrace.h 
b/arch/powerpc/include/asm/ftrace.h
index debe8c4f7062..d59f67c0225f 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -61,6 +61,10 @@ struct dyn_arch_ftrace {
  };
  #endif /* __ASSEMBLY__ */

+#ifdef CONFIG_DYNAMIC_FTRACE

Re: [PATCH v2] init: consolidate trap_init()

2021-08-22 Thread Helge Deller

On 4/14/21 12:00 PM, Jisheng Zhang wrote:

Many architectures implement the trap_init() as NOP, since there is
no such default for trap_init(), this empty stub is duplicated among
these architectures. Provide a generic but weak NOP implementation
to drop the empty stubs of trap_init() in these architectures.

The alpha, microblaze and sparc32 have real trap_init() implementation
but the __init marker is missing, so add it to these three platforms.

Signed-off-by: Jisheng Zhang 
---
Since v1:
  - add __init marker to trap_init() for alpha, microblaze and sparc32
  - adjust the generic weak NOP trap_init() location to make it sits with
other NOP implementations together

  arch/alpha/kernel/traps.c  |  2 +-
  arch/arc/kernel/traps.c|  5 -
  arch/arm/kernel/traps.c|  5 -
  arch/h8300/kernel/traps.c  | 13 -
  arch/hexagon/kernel/traps.c|  4 
  arch/microblaze/kernel/traps.c |  2 +-
  arch/nds32/kernel/traps.c  |  5 -
  arch/nios2/kernel/traps.c  |  5 -
  arch/openrisc/kernel/traps.c   |  5 -
  arch/parisc/kernel/traps.c |  4 
  arch/powerpc/kernel/traps.c|  5 -
  arch/riscv/kernel/traps.c  |  5 -
  arch/sparc/kernel/traps_32.c   |  2 +-
  arch/um/kernel/trap.c  |  4 
  init/main.c|  2 ++
  15 files changed, 5 insertions(+), 63 deletions(-)



For parisc:

Acked-by: Helge Deller  # parisc

Thanks!
Helge



diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
index 921d4b6e4d95..96b203199c6c 100644
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -973,7 +973,7 @@ do_entUnaUser(void __user * va, unsigned long opcode,
return;
  }

-void
+void __init
  trap_init(void)
  {
/* Tell PAL-code what global pointer we want in the kernel.  */
diff --git a/arch/arc/kernel/traps.c b/arch/arc/kernel/traps.c
index 57235e5c0cea..6b83e3f2b41c 100644
--- a/arch/arc/kernel/traps.c
+++ b/arch/arc/kernel/traps.c
@@ -20,11 +20,6 @@
  #include 
  #include 

-void __init trap_init(void)
-{
-   return;
-}
-
  void die(const char *str, struct pt_regs *regs, unsigned long address)
  {
show_kernel_fault_diag(str, regs, address);
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 17d5a785df28..9baccef20392 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -780,11 +780,6 @@ void abort(void)
panic("Oops failed to kill thread");
  }

-void __init trap_init(void)
-{
-   return;
-}
-
  #ifdef CONFIG_KUSER_HELPERS
  static void __init kuser_init(void *vectors)
  {
diff --git a/arch/h8300/kernel/traps.c b/arch/h8300/kernel/traps.c
index 5d8b969cd8f3..c3a3ebf77fbb 100644
--- a/arch/h8300/kernel/traps.c
+++ b/arch/h8300/kernel/traps.c
@@ -30,19 +30,6 @@

  static DEFINE_SPINLOCK(die_lock);

-/*
- * this must be called very early as the kernel might
- * use some instruction that are emulated on the 060
- */
-
-void __init base_trap_init(void)
-{
-}
-
-void __init trap_init(void)
-{
-}
-
  asmlinkage void set_esp0(unsigned long ssp)
  {
current->thread.esp0 = ssp;
diff --git a/arch/hexagon/kernel/traps.c b/arch/hexagon/kernel/traps.c
index 904134b37232..edfc35dafeb1 100644
--- a/arch/hexagon/kernel/traps.c
+++ b/arch/hexagon/kernel/traps.c
@@ -28,10 +28,6 @@
  #define TRAP_SYSCALL  1
  #define TRAP_DEBUG0xdb

-void __init trap_init(void)
-{
-}
-
  #ifdef CONFIG_GENERIC_BUG
  /* Maybe should resemble arch/sh/kernel/traps.c ?? */
  int is_valid_bugaddr(unsigned long addr)
diff --git a/arch/microblaze/kernel/traps.c b/arch/microblaze/kernel/traps.c
index 94b6fe93147d..7c15704fe56e 100644
--- a/arch/microblaze/kernel/traps.c
+++ b/arch/microblaze/kernel/traps.c
@@ -18,7 +18,7 @@
  #include 
  #include 

-void trap_init(void)
+void __init trap_init(void)
  {
__enable_hw_exceptions();
  }
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index ee0d9ae192a5..f06421c645af 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -183,11 +183,6 @@ void __pgd_error(const char *file, int line, unsigned long 
val)
  }

  extern char *exception_vector, *exception_vector_end;
-void __init trap_init(void)
-{
-   return;
-}
-
  void __init early_trap_init(void)
  {
unsigned long ivb = 0;
diff --git a/arch/nios2/kernel/traps.c b/arch/nios2/kernel/traps.c
index b172da4eb1a9..596986a74a26 100644
--- a/arch/nios2/kernel/traps.c
+++ b/arch/nios2/kernel/traps.c
@@ -105,11 +105,6 @@ void show_stack(struct task_struct *task, unsigned long 
*stack,
printk("%s\n", loglvl);
  }

-void __init trap_init(void)
-{
-   /* Nothing to do here */
-}
-
  /* Breakpoint handler */
  asmlinkage void breakpoint_c(struct pt_regs *fp)
  {
diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c
index 4d61333c2623..aa1e709405ac 100644
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -231,11 +231,6 @@ void unhandled_e

Re: [PATCH v2 1/1] kernel.h: Split out panic and oops helpers

2021-04-09 Thread Helge Deller

On 4/9/21 12:02 PM, Andy Shevchenko wrote:

kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.

There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop by moving out panic_notifier.h
- unload kernel.h from something which has its own domain

At the same time convert users tree-wide to use new headers, although
for the time being include new header back to kernel.h to avoid twisted
indirected includes for existing users.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Bjorn Andersson 
Acked-by: Mike Rapoport 
Acked-by: Corey Minyard 
Acked-by: Christian Brauner 
Acked-by: Arnd Bergmann 
Acked-by: Kees Cook 
Acked-by: Wei Liu 
Acked-by: Rasmus Villemoes 
Signed-off-by: Andrew Morton 


Acked-by: Helge Deller  # parisc

Helge


Re: [PATCH 18/27] parisc: syscalls: switch to generic syscalltbl.sh

2021-01-28 Thread Helge Deller
On 1/28/21 1:51 AM, Masahiro Yamada wrote:
> As of v5.11-rc1, 12 architectures duplicate similar shell scripts in
> order to generate syscall table headers. My goal is to unify them into
> the single scripts/syscalltbl.sh.
>
> This commit converts parisc to use scripts/syscalltbl.sh. This also
> unifies syscall_table_64.h and syscall_table_c32.h.
>
> Signed-off-by: Masahiro Yamada 

Thanks for the cleanup!

You may add:
Acked-by: Helge Deller  # parisc

Helge

> ---
>
>  arch/parisc/include/asm/Kbuild|  1 -
>  arch/parisc/kernel/syscall.S  | 16 +-
>  arch/parisc/kernel/syscalls/Makefile  | 19 
>  arch/parisc/kernel/syscalls/syscalltbl.sh | 36 ---
>  4 files changed, 12 insertions(+), 60 deletions(-)
>  delete mode 100644 arch/parisc/kernel/syscalls/syscalltbl.sh
>
> diff --git a/arch/parisc/include/asm/Kbuild b/arch/parisc/include/asm/Kbuild
> index 4406475a2304..e6e7f74c8ac9 100644
> --- a/arch/parisc/include/asm/Kbuild
> +++ b/arch/parisc/include/asm/Kbuild
> @@ -1,7 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  generated-y += syscall_table_32.h
>  generated-y += syscall_table_64.h
> -generated-y += syscall_table_c32.h
>  generic-y += kvm_para.h
>  generic-y += mcs_spinlock.h
>  generic-y += user.h
> diff --git a/arch/parisc/kernel/syscall.S b/arch/parisc/kernel/syscall.S
> index 322503780db6..3f24a0af1e04 100644
> --- a/arch/parisc/kernel/syscall.S
> +++ b/arch/parisc/kernel/syscall.S
> @@ -919,24 +919,24 @@ ENTRY(lws_table)
>  END(lws_table)
>   /* End of lws table */
>
> +#ifdef CONFIG_64BIT
> +#define __SYSCALL_WITH_COMPAT(nr, native, compat)__SYSCALL(nr, compat)
> +#else
> +#define __SYSCALL_WITH_COMPAT(nr, native, compat)__SYSCALL(nr, native)
> +#endif
>  #define __SYSCALL(nr, entry) ASM_ULONG_INSN entry
>   .align 8
>  ENTRY(sys_call_table)
>   .export sys_call_table,data
> -#ifdef CONFIG_64BIT
> -#include/* Compat syscalls */
> -#else
> -#include /* 32-bit native syscalls */
> -#endif
> +#include /* 32-bit syscalls */
>  END(sys_call_table)
>
>  #ifdef CONFIG_64BIT
>   .align 8
>  ENTRY(sys_call_table64)
> -#include /* 64-bit native syscalls */
> +#include /* 64-bit syscalls */
>  END(sys_call_table64)
>  #endif
> -#undef __SYSCALL
>
>   /*
>   All light-weight-syscall atomic operations
> @@ -961,5 +961,3 @@ END(lws_lock_start)
>   .previous
>
>  .end
> -
> -
> diff --git a/arch/parisc/kernel/syscalls/Makefile 
> b/arch/parisc/kernel/syscalls/Makefile
> index 556fe30a6c8f..77fea5beb9be 100644
> --- a/arch/parisc/kernel/syscalls/Makefile
> +++ b/arch/parisc/kernel/syscalls/Makefile
> @@ -7,7 +7,7 @@ _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') 
> \
>
>  syscall := $(srctree)/$(src)/syscall.tbl
>  syshdr := $(srctree)/$(src)/syscallhdr.sh
> -systbl := $(srctree)/$(src)/syscalltbl.sh
> +systbl := $(srctree)/scripts/syscalltbl.sh
>
>  quiet_cmd_syshdr = SYSHDR  $@
>cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@' \
> @@ -16,10 +16,7 @@ quiet_cmd_syshdr = SYSHDR  $@
>  '$(syshdr_offset_$(basetarget))'
>
>  quiet_cmd_systbl = SYSTBL  $@
> -  cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@' \
> -'$(systbl_abis_$(basetarget))'   \
> -'$(systbl_abi_$(basetarget))'\
> -'$(systbl_offset_$(basetarget))'
> +  cmd_systbl = $(CONFIG_SHELL) $(systbl) $< $@ $(abis)
>
>  syshdr_abis_unistd_32 := common,32
>  $(uapi)/unistd_32.h: $(syscall) $(syshdr) FORCE
> @@ -29,23 +26,17 @@ syshdr_abis_unistd_64 := common,64
>  $(uapi)/unistd_64.h: $(syscall) $(syshdr) FORCE
>   $(call if_changed,syshdr)
>
> -systbl_abis_syscall_table_32 := common,32
> +$(kapi)/syscall_table_32.h: abis := common,32
>  $(kapi)/syscall_table_32.h: $(syscall) $(systbl) FORCE
>   $(call if_changed,systbl)
>
> -systbl_abis_syscall_table_64 := common,64
> +$(kapi)/syscall_table_64.h: abis := common,64
>  $(kapi)/syscall_table_64.h: $(syscall) $(systbl) FORCE
>   $(call if_changed,systbl)
>
> -systbl_abis_syscall_table_c32 := common,32
> -systbl_abi_syscall_table_c32 := c32
> -$(kapi)/syscall_table_c32.h: $(syscall) $(systbl) FORCE
> - $(call if_changed,systbl)
> -
>  uapisyshdr-y += unistd_32.h unistd_64.h
>  kapisyshdr-y += syscall_table_32.h   \
> -syscall_table_64.h   \
> -syscall_table_c32.h
> +syscall_table_64.h
>
>  uapisyshdr-y := $(addprefix $(uapi)/, $(uapisyshdr-y))
>

Re: [PATCH] arch: fix 'unexpected IRQ trap at vector' warnings

2020-12-08 Thread Helge Deller
On 12/8/20 3:11 AM, Michael Ellerman wrote:
> "Enrico Weigelt, metux IT consult"  writes:
>> All archs, except Alpha, print out the irq number in hex, but the message
>> looks like it was a decimal number, which is quite confusing. Fixing this
>> by adding "0x" prefix.
>
> Arguably decimal would be better, /proc/interrupts and /proc/irq/ both
> use decimal.

I agree.

> The whole message is very dated IMO, these days the number it prints is
> (possibly) virtualised via IRQ domains, ie. it's not necessarily a
> "vector" if that even makes sense on all arches). Arguably "trap" is the
> wrong term on some arches too.
>
> So it would be better reworded entirely IMO, and also switched to
> decimal to match other sources of information on interrupts.
>
> Perhaps:
>   "Unexpected Linux IRQ %d."

Yes.

and while cleaning it up, introducing a default weak implementation of 
ack_bad_irq()
which adds and increases irq_err_count for all platforms would be a nice 
cleanup.

Helge

> If anyone else is having deja vu like me, yes this has come up before:
>   
> https://lore.kernel.org/lkml/20150712220211.7166.42035.st...@bhelgaas-glaptop2.roam.corp.google.com/
>
> cheers
>
>
>
>> diff --git a/arch/arm/include/asm/hw_irq.h b/arch/arm/include/asm/hw_irq.h
>> index cecc13214ef1..2749f19271d9 100644
>> --- a/arch/arm/include/asm/hw_irq.h
>> +++ b/arch/arm/include/asm/hw_irq.h
>> @@ -9,7 +9,7 @@ static inline void ack_bad_irq(int irq)
>>  {
>>  extern unsigned long irq_err_count;
>>  irq_err_count++;
>> -pr_crit("unexpected IRQ trap at vector %02x\n", irq);
>> +pr_crit("unexpected IRQ trap at vector 0x%02x\n", irq);
>>  }
>>
>>  #define ARCH_IRQ_INIT_FLAGS (IRQ_NOREQUEST | IRQ_NOPROBE)
>> diff --git a/arch/parisc/include/asm/hardirq.h 
>> b/arch/parisc/include/asm/hardirq.h
>> index 7f7039516e53..c3348af88d3f 100644
>> --- a/arch/parisc/include/asm/hardirq.h
>> +++ b/arch/parisc/include/asm/hardirq.h
>> @@ -35,6 +35,6 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
>>  #define __IRQ_STAT(cpu, member) (irq_stat[cpu].member)
>>  #define inc_irq_stat(member)this_cpu_inc(irq_stat.member)
>>  #define __inc_irq_stat(member)  __this_cpu_inc(irq_stat.member)
>> -#define ack_bad_irq(irq) WARN(1, "unexpected IRQ trap at vector %02x\n", 
>> irq)
>> +#define ack_bad_irq(irq) WARN(1, "unexpected IRQ trap at vector 0x%02x\n", 
>> irq)
>>
>>  #endif /* _PARISC_HARDIRQ_H */
>> diff --git a/arch/powerpc/include/asm/hardirq.h 
>> b/arch/powerpc/include/asm/hardirq.h
>> index f133b5930ae1..ec8cf3cf6e49 100644
>> --- a/arch/powerpc/include/asm/hardirq.h
>> +++ b/arch/powerpc/include/asm/hardirq.h
>> @@ -29,7 +29,7 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
>>
>>  static inline void ack_bad_irq(unsigned int irq)
>>  {
>> -printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
>> +printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
>>  }
>>
>>  extern u64 arch_irq_stat_cpu(unsigned int cpu);
>> diff --git a/arch/s390/include/asm/hardirq.h 
>> b/arch/s390/include/asm/hardirq.h
>> index dfbc3c6c0674..aaaec5cdd4fe 100644
>> --- a/arch/s390/include/asm/hardirq.h
>> +++ b/arch/s390/include/asm/hardirq.h
>> @@ -23,7 +23,7 @@
>>
>>  static inline void ack_bad_irq(unsigned int irq)
>>  {
>> -printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
>> +printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
>>  }
>>
>>  #endif /* __ASM_HARDIRQ_H */
>> diff --git a/arch/um/include/asm/hardirq.h b/arch/um/include/asm/hardirq.h
>> index b426796d26fd..2a2e6eae034b 100644
>> --- a/arch/um/include/asm/hardirq.h
>> +++ b/arch/um/include/asm/hardirq.h
>> @@ -15,7 +15,7 @@ typedef struct {
>>  #ifndef ack_bad_irq
>>  static inline void ack_bad_irq(unsigned int irq)
>>  {
>> -printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
>> +printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
>>  }
>>  #endif
>>
>> diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
>> index c5dd50369e2f..957c716f2df7 100644
>> --- a/arch/x86/kernel/irq.c
>> +++ b/arch/x86/kernel/irq.c
>> @@ -37,7 +37,7 @@ atomic_t irq_err_count;
>>  void ack_bad_irq(unsigned int irq)
>>  {
>>  if (printk_ratelimit())
>> -pr_err("unexpected IRQ trap at vector %02x\n", irq);
>> +pr_err("unexpected IRQ trap at vector 0x%02x\n", irq);
>>
>>  /*
>>   * Currently unexpected vectors happen only on SMP and APIC.
>> --
>> 2.11.0



Re: [PATCH seccomp 2/8] parisc: Enable seccomp architecture tracking

2020-11-05 Thread Helge Deller
On 11/3/20 2:42 PM, YiFei Zhu wrote:
> From: YiFei Zhu 
>
> To enable seccomp constant action bitmaps, we need to have a static
> mapping to the audit architecture and system call table size. Add these
> for parisc.
> > Signed-off-by: YiFei Zhu 

I did compile- and boot-tested it, works on 32- and 64-bit parisc kernel.
I don't know how to test it actually, but anyway:

Acked-by: Helge Deller 

Thanks!
Helge

> ---
>  arch/parisc/include/asm/Kbuild|  1 -
>  arch/parisc/include/asm/seccomp.h | 22 ++
>  2 files changed, 22 insertions(+), 1 deletion(-)
>  create mode 100644 arch/parisc/include/asm/seccomp.h
>
> diff --git a/arch/parisc/include/asm/Kbuild b/arch/parisc/include/asm/Kbuild
> index e3ee5c0bfe80..f16c4db80116 100644
> --- a/arch/parisc/include/asm/Kbuild
> +++ b/arch/parisc/include/asm/Kbuild
> @@ -5,5 +5,4 @@ generated-y += syscall_table_c32.h
>  generic-y += kvm_para.h
>  generic-y += local64.h
>  generic-y += mcs_spinlock.h
> -generic-y += seccomp.h
>  generic-y += user.h
> diff --git a/arch/parisc/include/asm/seccomp.h 
> b/arch/parisc/include/asm/seccomp.h
> new file mode 100644
> index ..b058b2220322
> --- /dev/null
> +++ b/arch/parisc/include/asm/seccomp.h
> @@ -0,0 +1,22 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef _ASM_SECCOMP_H
> +#define _ASM_SECCOMP_H
> +
> +#include 
> +
> +#ifdef CONFIG_64BIT
> +# define SECCOMP_ARCH_NATIVE AUDIT_ARCH_PARISC64
> +# define SECCOMP_ARCH_NATIVE_NR  NR_syscalls
> +# define SECCOMP_ARCH_NATIVE_NAME"parisc64"
> +# ifdef CONFIG_COMPAT
> +#  define SECCOMP_ARCH_COMPATAUDIT_ARCH_PARISC
> +#  define SECCOMP_ARCH_COMPAT_NR NR_syscalls
> +#  define SECCOMP_ARCH_COMPAT_NAME   "parisc"
> +# endif
> +#else /* !CONFIG_64BIT */
> +# define SECCOMP_ARCH_NATIVE AUDIT_ARCH_PARISC
> +# define SECCOMP_ARCH_NATIVE_NR  NR_syscalls
> +# define SECCOMP_ARCH_NATIVE_NAME"parisc"
> +#endif
> +
> +#endif /* _ASM_SECCOMP_H */
>



Re: rename probe_kernel_* and probe_user_*

2020-06-18 Thread Helge Deller
On 18.06.20 21:48, Linus Torvalds wrote:
> [ Explicitly added architecture lists and developers to the cc to make
> this more visible ]
>
> On Wed, Jun 17, 2020 at 12:38 AM Christoph Hellwig  wrote:
>>
>> Andrew and I decided to drop the patches implementing your suggested
>> rename of the probe_kernel_* and probe_user_* helpers from -mm as there
>> were way to many conflicts.  After -rc1 might be a good time for this as
>> all the conflicts are resolved now.
>
> So I've merged this renaming now, together with my changes to make
> 'get_kernel_nofault()' look and act a lot more like 'get_user()'.
>
> It just felt wrong (and potentially dangerous) to me to have a
> 'get_kernel_nofault()' naming that implied semantics that we're all
> familiar with from 'get_user()', but acting very differently.
>
> But part of the fixups I made for the type checking are for
> architectures where I didn't even compile-test the end result. I
> looked at every case individually, and the patch looks sane, but I
> could have screwed something up.
>
> Basically, 'get_kernel_nofault()' doesn't do the same automagic type
> munging from the pointer to the target that 'get_user()' does, but at
> least now it checks that the types are superficially compatible.
> There should be build failures if they aren't, but I hopefully fixed
> everything up properly for all architectures.
>
> This email is partly to ask people to double-check, but partly just as
> a heads-up so that _if_ I screwed something up, you'll have the
> background and it won't take you by surprise.

Linus. thanks for the heads-up!
With your change it compiles cleanly on 32- and 64-bit parisc.

Helge


Re: [PATCH v4 7/9] parisc/perf: open access for CAP_SYS_PERFMON privileged process

2020-01-27 Thread Helge Deller
On 18.12.19 10:29, Alexey Budankov wrote:
>
> Open access to monitoring for CAP_SYS_PERFMON privileged processes.
> For backward compatibility reasons access to the monitoring remains open
> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
> monitoring is discouraged with respect to CAP_SYS_PERFMON capability.
>
> Signed-off-by: Alexey Budankov 

Acked-by: Helge Deller 

> ---
>  arch/parisc/kernel/perf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/parisc/kernel/perf.c b/arch/parisc/kernel/perf.c
> index 676683641d00..c4208d027794 100644
> --- a/arch/parisc/kernel/perf.c
> +++ b/arch/parisc/kernel/perf.c
> @@ -300,7 +300,7 @@ static ssize_t perf_write(struct file *file, const char 
> __user *buf,
>   else
>   return -EFAULT;
>
> - if (!capable(CAP_SYS_ADMIN))
> + if (!perfmon_capable())
>   return -EACCES;
>
>   if (count != sizeof(uint32_t))
>



Re: [PATCH v2 23/29] parisc: Move EXCEPTION_TABLE to RO_DATA segment

2019-10-12 Thread Helge Deller

On 11.10.19 02:06, Kees Cook wrote:

Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.

Signed-off-by: Kees Cook 
---
  arch/parisc/kernel/vmlinux.lds.S | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)



Acked-by: Helge Deller   # parisc

Helge



diff --git a/arch/parisc/kernel/vmlinux.lds.S b/arch/parisc/kernel/vmlinux.lds.S
index 12b3d7d5e9e4..53e29d88f99c 100644
--- a/arch/parisc/kernel/vmlinux.lds.S
+++ b/arch/parisc/kernel/vmlinux.lds.S
@@ -19,6 +19,7 @@
*(.data..vm0.pte)

  #define CC_USING_PATCHABLE_FUNCTION_ENTRY
+#define RO_EXCEPTION_TABLE_ALIGN   8

  #include 

@@ -129,9 +130,6 @@ SECTIONS

RO_DATA(8)

-   /* RO because of BUILDTIME_EXTABLE_SORT */
-   EXCEPTION_TABLE(8)
-
/* unwind info */
.PARISC.unwind : {
__start___unwind = .;





Re: [PATCH v5 0/7] kexec: add generic support for elf kernel images

2019-09-06 Thread Helge Deller
On 06.09.19 23:47, Thiago Jung Bauermann wrote:
> Helge Deller  writes:
>> This kexec patch series is the groundwork for kexec on the parisc 
>> architecture.
>> Since we want kexec on parisc, I've applied it to my for-next-kexec tree [1],
>> and can push it to Linus in the next merge window through the parisc tree 
>> [2].
>
> I just had a look at this version and it looks fine to me. Identical to
> the version I reviewed before except for the changes I suggested.
> Thanks, Sven!
>
>> If someone has any objections, or if you prefer to take it through
>> a kexec or powerpc tree, please let me know.
>>
>> Helge
>>
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/log/?h=for-next-kexec
>> [2] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/log/?h=for-next
>
> I noticed that the first patch is the only one that doesn't have my
> Reviewed-by. If you want, you can add it:
>
> Reviewed-by: Thiago Jung Bauermann 

Thanks for reviewing again!
I added your Reviewed-by to the patches in the for-next tree.

Helge

>
>> On 23.08.19 21:49, Sven Schnelle wrote:
>>> Changes to v4:
>>>  - rebase on current powerpc/merge tree
>>>  - fix syscall name in commit message
>>>  - remove a few unused #defines in arch/powerpc/kernel/kexec_elf_64.c
>>> ...
>>>  arch/Kconfig  |   3 +
>>>  arch/powerpc/Kconfig  |   1 +
>>>  arch/powerpc/kernel/kexec_elf_64.c| 545 +-
>>>  include/linux/kexec.h |  23 +
>>>  kernel/Makefile   |   1 +
>>>  .../kexec_elf_64.c => kernel/kexec_elf.c  | 394 +++--
>>>  6 files changed, 115 insertions(+), 852 deletions(-)
>>>  copy arch/powerpc/kernel/kexec_elf_64.c => kernel/kexec_elf.c (50%)
>
>



Re: [PATCH v5 0/7] kexec: add generic support for elf kernel images

2019-09-06 Thread Helge Deller
Hi all,

This kexec patch series is the groundwork for kexec on the parisc architecture.
Since we want kexec on parisc, I've applied it to my for-next-kexec tree [1],
and can push it to Linus in the next merge window through the parisc tree [2].

If someone has any objections, or if you prefer to take it through
a kexec or powerpc tree, please let me know.

Helge

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/log/?h=for-next-kexec
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/log/?h=for-next

On 23.08.19 21:49, Sven Schnelle wrote:
> Changes to v4:
>  - rebase on current powerpc/merge tree
>  - fix syscall name in commit message
>  - remove a few unused #defines in arch/powerpc/kernel/kexec_elf_64.c
>...
>  arch/Kconfig  |   3 +
>  arch/powerpc/Kconfig  |   1 +
>  arch/powerpc/kernel/kexec_elf_64.c| 545 +-
>  include/linux/kexec.h |  23 +
>  kernel/Makefile   |   1 +
>  .../kexec_elf_64.c => kernel/kexec_elf.c  | 394 +++--
>  6 files changed, 115 insertions(+), 852 deletions(-)
>  copy arch/powerpc/kernel/kexec_elf_64.c => kernel/kexec_elf.c (50%)


Re: Build regressions/improvements in v5.3-rc1

2019-07-23 Thread Helge Deller

On 23.07.19 17:39, Geert Uytterhoeven wrote:

On Tue, Jul 23, 2019 at 5:22 PM Geert Uytterhoeven  wrote:

Below is the list of build error/warning regressions/improvements in
v5.3-rc1[1] compared to v5.2[2].



[1] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/5f9e832c137075045d15cd6899ab0505cfb2ca4b/
 (241 out of 242 configs)
[2] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/0ecfebd2b52404ae0c54a878c872bb93363ada36/
 (all 242 configs)


*** ERRORS ***
...
   + /kisskb/src/include/linux/kprobes.h: error: implicit declaration of function 
'kprobe_fault_handler'; did you mean 'kprobe_page_fault'? 
[-Werror=implicit-function-declaration]:  => 477:9


parisc-allmodconfig


I've a patch queued up for the next pull request (in the parisc git tree) to 
fix this:

https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/commit/?h=for-next=f5e03d3a04978d2866f82cb11cc7a6b808c8ce07

Helge


Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

2019-07-16 Thread Helge Deller

On 16.07.19 20:55, Christian Brauner wrote:

On Tue, Jul 16, 2019 at 08:53:10PM +0200, Sven Schnelle wrote:

Hi,

[Adding Helge to CC list]

On Tue, Jul 16, 2019 at 03:06:33PM +0200, Christian Brauner wrote:

On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote:

I think Vasily already has a clone3 patch for s390x with 435.


A quick follow-up on this. Helge and Michael have asked whether there
are any tests for clone3. Yes, there will be and I try to have them
ready by the end of the this or next week for review. In the meantime I
hope the following minimalistic test program that just verifies very
very basic functionality (It's not pretty.) will help you test:
[..]


On PA-RISC this seems to work fine with Helge's patch to wire up the
clone3 syscall.


[...]
In any case, I saw Helge's patch and I think I might've missed to add an
Acked-by but feel free to add it.


Thanks!
I've added the patch to the parisc-linux for-next tree.

Helge


Re: [PATCH] treewide: remove current_text_addr

2018-08-26 Thread Helge Deller
On 21.08.2018 22:28, Nick Desaulniers wrote:
> Prefer _THIS_IP_ defined in linux/kernel.h.
> 
> Most definitions of current_text_addr were the same as _THIS_IP_, but
> a few archs had inline assembly instead.
> 
> This patch removes the final call site of current_text_addr, making all
> of the definitions dead code.
> 
> Signed-off-by: Nick Desaulniers 
> ---
> I suspect that current_text_addr predated GNU C extensions for statement
> expressions and/or taking the address of a label, then the macro was
> reimplemented for every new archs include/asm/processor.h, even though
> there were very few call sites, and none required an assembly
> implementation vs the C implementation.
> 
> I am sad to see a few neat arch specific ways of getting the ip/pc, but
> we should prefer the higher level C in cases where assembly is not
> required. And the definitions can always be found again in git history.

Currently alpha, s390, sparc, sh, c6x, ia64 and parisc provide an
inline assembly function to get the current instruction pointer. 
As mentioned in an earlier thread, I personally would *prefer* if 
_THIS_IP_ would use those inline assembly instructions on those
architectures instead of the (currently used) higher C-level
implementation.

Helge


>  arch/alpha/include/asm/processor.h  |  6 --
>  arch/arc/include/asm/processor.h|  8 
>  arch/arm/include/asm/processor.h|  6 --
>  arch/arm64/include/asm/processor.h  |  7 ---
>  arch/c6x/include/asm/processor.h| 11 ---
>  arch/h8300/include/asm/processor.h  |  6 --
>  arch/hexagon/include/asm/processor.h|  3 ---
>  arch/ia64/include/asm/processor.h   |  6 --
>  arch/m68k/include/asm/processor.h   |  6 --
>  arch/microblaze/include/asm/processor.h | 12 
>  arch/mips/include/asm/processor.h   |  5 -
>  arch/nds32/include/asm/processor.h  |  6 --
>  arch/nios2/include/asm/processor.h  |  6 --
>  arch/openrisc/include/asm/processor.h   |  5 -
>  arch/parisc/include/asm/processor.h | 11 ---
>  arch/powerpc/include/asm/processor.h|  6 --
>  arch/riscv/include/asm/processor.h  |  6 --
>  arch/s390/include/asm/processor.h   |  6 --
>  arch/sh/include/asm/processor_32.h  |  6 --
>  arch/sh/include/asm/processor_64.h  | 15 ---
>  arch/sparc/include/asm/processor_32.h   |  6 --
>  arch/sparc/include/asm/processor_64.h   |  6 --
>  arch/unicore32/include/asm/processor.h  |  6 --
>  arch/x86/include/asm/kexec.h|  3 ++-
>  arch/x86/include/asm/processor.h| 12 
>  arch/x86/um/asm/processor_32.h  |  8 
>  arch/x86/um/asm/processor_64.h  |  3 ---
>  arch/xtensa/include/asm/processor.h |  8 
>  28 files changed, 2 insertions(+), 193 deletions(-)
> 
> diff --git a/arch/alpha/include/asm/processor.h 
> b/arch/alpha/include/asm/processor.h
> index cb05d045efe3..6100431da07a 100644
> --- a/arch/alpha/include/asm/processor.h
> +++ b/arch/alpha/include/asm/processor.h
> @@ -10,12 +10,6 @@
>  
>  #include/* for ADDR_LIMIT_32BIT */
>  
> -/*
> - * Returns current instruction pointer ("program counter").
> - */
> -#define current_text_addr() \
> -  ({ void *__pc; __asm__ ("br %0,.+4" : "=r"(__pc)); __pc; })
> -
>  /*
>   * We have a 42-bit user address space: 4TB user VM...
>   */
> diff --git a/arch/arc/include/asm/processor.h 
> b/arch/arc/include/asm/processor.h
> index 8ee41e988169..10346d6cf926 100644
> --- a/arch/arc/include/asm/processor.h
> +++ b/arch/arc/include/asm/processor.h
> @@ -98,14 +98,6 @@ extern void start_thread(struct pt_regs * regs, unsigned 
> long pc,
>  
>  extern unsigned int get_wchan(struct task_struct *p);
>  
> -/*
> - * Default implementation of macro that returns current
> - * instruction pointer ("program counter").
> - * Should the PC register be read instead ? This macro does not seem to
> - * be used in many places so this wont be all that bad.
> - */
> -#define current_text_addr() ({ __label__ _l; _l: &&_l; })
> -
>  #endif /* !__ASSEMBLY__ */
>  
>  /*
> diff --git a/arch/arm/include/asm/processor.h 
> b/arch/arm/include/asm/processor.h
> index 1bf65b47808a..120f4c9bbfde 100644
> --- a/arch/arm/include/asm/processor.h
> +++ b/arch/arm/include/asm/processor.h
> @@ -11,12 +11,6 @@
>  #ifndef __ASM_ARM_PROCESSOR_H
>  #define __ASM_ARM_PROCESSOR_H
>  
> -/*
> - * Default implementation of macro that returns current
> - * instruction pointer ("program counter").
> - */
> -#define current_text_addr() ({ __label__ _l; _l: &&_l;})
> -
>  #ifdef __KERNEL__
>  
>  #include 
> diff --git a/arch/arm64/include/asm/processor.h 
> b/arch/arm64/include/asm/processor.h
> index 79657ad91397..966214f473b4 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -25,13 +25,6 @@
>  #define USER_DS  (TASK_SIZE_64 - 1)
>  
>  #ifndef __ASSEMBLY__
> -
> -/*
> 

Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives

2018-07-26 Thread Helge Deller
Hi Alex,

On 26.07.2018 21:13, Alex Ghiti wrote:
> $ make ARCH=parisc O=build_parisc generic-64bit_defconfig
> $ PATH=/home/alex/wip/toolchain/gcc-8.1.0-nolibc/hppa64-linux/bin:$PATH make 
> ARCH=parisc CROSS_COMPILE=hppa64-linux-
> 
>> ...
>>  LD  vmlinux.o
>>  MODPOST vmlinux.o
>> hppa64-linux-ld: init/main.o(.text+0x98): cannot reach strreplace
>> init/main.o: In function `initcall_blacklisted':
>> init/.tmp_main.o:(.text+0x98): relocation truncated to fit: 
>> R_PARISC_PCREL22F against symbol `strreplace' defined in .text section in 
>> lib/string.o
>> hppa64-linux-ld: init/main.o(.text+0xbc): cannot reach strcmp

In order to be able to link vmlinux, we need to enable 
CONFIG_MLONGCALLS=y in the defconfig.

Nevertheless, I see some modversion issues too which I still need 
to analyze (but that's a completely off-topic issue here).

Helge


Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives

2018-07-26 Thread Helge Deller
* Alex Ghiti :
> This is the result of the build for all arches tackled in this series
> rebased on 4.18-rc6:
> ...
> parisc:
>     generic-64bit_defconfig: with huge page does not link
>     generic-64bit_defconfig: without huge page does not link
>     BUT not because of this series, any feedback welcome.
Strange, but I will check that later

Anyway, I applied your v4-patch to my parisc64 tree, built the kernel,
started it and ran some hugetlb LTP testcases sucessfully.
So, please add:

Tested-by: Helge Deller  # parisc

Helge


Re: [PATCH v3 02/10] include: Move compat_timespec/ timeval to compat_time.h

2018-03-04 Thread Helge Deller
On 16.01.2018 03:18, Deepa Dinamani wrote:
> All the current architecture specific defines for these
> are the same. Refactor these common defines to a common
> header file.
> 
> The new common linux/compat_time.h is also useful as it
> will eventually be used to hold all the defines that
> are needed for compat time types that support non y2038
> safe types. New architectures need not have to define these
> new types as they will only use new y2038 safe syscalls.
> This file can be deleted after y2038 when we stop supporting
> non y2038 safe syscalls.

For parisc:

Acked-by: Helge Deller <del...@gmx.de> # parisc


Re: [PATCHv4 0/6] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-11-13 Thread Helge Deller

On 10.11.2017 00:48, Sergey Senozhatsky wrote:

All Ack-s/Tested-by-s were dropped, since the patch set has been
reworked. I'm kindly asking arch-s maintainers and developers to test it
once again. Sorry for any inconveniences and thanks for your help in
advance.


I tested it successfully on parisc64.
You can add back the
Tested-by: Helge Deller <del...@gmx.de> #parisc64

Thanks!
Helge


Re: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-09-25 Thread Helge Deller

On 25.09.2017 18:29, Luck, Tony wrote:

speaking of upstream, any objections if this patch set will go through
the printk tree, in one piece?


Fine with me too.

Helge


Re: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-09-20 Thread Helge Deller

On 20.09.2017 18:29, Sergey Senozhatsky wrote:

 This patch set attempts to move ia64/ppc64/parisc64 C function
pointer ABI details out of printk() to arch code. Function dereference
code now checks if a pointer belongs to a .opd ELF section and dereferences
that pointer only if it does. The kernel and modules have their own .opd
sections that's why I use two different ARCH functions: for kernel and
for module pointer dereference.
...> *** A BIG NOTE ***
 I don't own ia64/ppc64/parisc64 hardware, so the patches are not
 tested. Sorry about that!



I just now tested your patch series successfully on parisc64.

You may add to the whole series:
Tested-by: Helge Deller <del...@gmx.de> # parisc64

 

Another note:
 I need to check what is BPF symbol lookup and do we need to
 do any dereference there.


Not relevant for parisc, since we don't support it yet.

Helge


Re: [RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

2017-09-20 Thread Helge Deller

On 20.09.2017 19:38, Joe Perches wrote:

On Thu, 2017-09-21 at 01:29 +0900, Sergey Senozhatsky wrote:

We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart
enough to handle function pointer dereference on platforms where such
dereference is required.

checkpatch warning example:

WARNING: Use '%pS/%ps' instead. This pointer extension was deprecated: '%pF'


If this series is accepted,  I think this message
is unclear and would prefer something like:


Is it worth to mention, that it's still needed in older kernels?
Just in case some patch get's backported.

Helge


Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-09-20 Thread Helge Deller

On 20.09.2017 10:41, David Laight wrote:

From: Helge Deller

Sent: 19 September 2017 21:08

...

Using 'unsigned long' for any kind of pointer is an accident
waiting do happen.
It also makes it difficult to typecheck the function calls.
Using 'void *' isn't any better.
Either a pointer to an undefined struct, or a struct containing
a single 'char' member, is likely to be safest.


David, you might be right in most cases, but in this case I'd prefer
unsigned long too. I think this will create the least amount of
typecasts here.


I've not looked at the specifics case...

Another option is using a struct with a single member and
passing it by value.


Actually, we do already have correct structs which could be referenced:
parisc: struct Elf64_Fdesc
ia64:   struct fdesc
ppc64:  struct ppc64_opd_entry

One could "#define platform_opd_entry" to each of those depending on the 
platform and use it.
It might be misleading though, because the pointer which is handed over to
dereference_function_descriptor() can be such a pointer but isn't necessary.
I'll leave it up to Sergey to decide.

Helge


Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-09-19 Thread Helge Deller

On 19.09.2017 15:38, David Laight wrote:

From: Sergey Senozhatsky

Sent: 19 September 2017 03:06

...

I'll simply convert everything to `unsigned long'. including the
dereference_function_descriptor() function [I believe there are
still some casts happening when we pass addr from kernel/module
dereference functions to dereference_function_descriptor(), or
when we return `void *' back to symbol resolution code, etc.)
besides, it seems that everything that uses
dereference_function_descriptor() wants `unsigned long' anyway:


Using 'unsigned long' for any kind of pointer is an accident
waiting do happen.
It also makes it difficult to typecheck the function calls.
Using 'void *' isn't any better.
Either a pointer to an undefined struct, or a struct containing
a single 'char' member, is likely to be safest.


David, you might be right in most cases, but in this case I'd prefer
unsigned long too. I think this will create the least amount of
typecasts here.

Helge


Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-09-19 Thread Helge Deller
* Helge Deller <del...@gmx.de>:
> On 19.09.2017 04:05, Sergey Senozhatsky wrote:
> >On (09/18/17 20:39), Helge Deller wrote:
> >>I did tried your testcases [on parisc] too.
> ...
> >>and here is "modprobe zram":
> >>  printk#7 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
> >>  printk#8 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
> >>  printk#9 do_one_initcall+0x194/0x290
> >>  printk#10 do_one_initcall+0x194/0x290
> >>  printk#11 do_one_initcall+0x194/0x290
> >>  printk#12 do_one_initcall+0x194/0x290
> >>  printk#13 zram_init+0x22c/0x2a0 [zram]
> >>  printk#14 zram_init+0x22c/0x2a0 [zram]
> >>  printk#15 zram_init+0x22c/0x2a0 [zram]
> >>  printk#16 zram_init+0x22c/0x2a0 [zram]
> >>
> >>I wonder why printk#7 and printk#8 don't show "zram_init"...
> >
> >interesting... what does the unpatched kernel show?
> 
> Really strange.
> The unpatched kernel shows __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 too.
> The symbol should be known, because later on in printk13 it shows correctly 
> zram_init.
> I'll need to dig deeper into it, but at least the regression is not due
> to your patch.

Sergey, I was wrong with this assumption.

Your implementation of dereference_module_function_descriptor() in
arch/parisc/kernel/module.c is faulty.
mod->arch.fdesc_offset is relative to the base address of the module,
so you need to add to mod->core_layout.base.

Here is the relevant patch to fix this issue (against mainline).
Additionally I compare against mod->arch.fdesc_count instead of
mod->arch.fdesc_max.
Can you please fold it into your patch
[PATCH 4/5] parisc64: Add .opd based function descriptor dereference
for the next round?

Thanks,
Helge

Signed-off-by: Helge Deller <del...@gmx.de>

diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index f1a7693..ae3e6c5 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -66,6 +66,7 @@
 
 #include 
 #include 
+#include 
 
 #if 0
 #define DEBUGP printk
@@ -954,3 +955,19 @@ void module_arch_cleanup(struct module *mod)
 {
deregister_unwind_table(mod);
 }
+
+#ifdef CONFIG_64BIT
+unsigned long dereference_module_function_descriptor(struct module *mod,
+unsigned long addr)
+{
+   unsigned long opd_start = (Elf64_Addr) mod->core_layout.base
+   + mod->arch.fdesc_offset;
+   unsigned long opd_end = opd_start
+   + mod->arch.fdesc_count * sizeof(Elf64_Fdesc);
+
+   if (addr < opd_start || addr >= opd_end)
+   return addr;
+
+   return (unsigned long) dereference_function_descriptor((void *) addr);
+}
+#endif


Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-09-19 Thread Helge Deller

On 19.09.2017 04:05, Sergey Senozhatsky wrote:

On (09/18/17 20:39), Helge Deller wrote:

I did tried your testcases [on parisc] too.

...

and here is "modprobe zram":
  printk#7 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
  printk#8 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
  printk#9 do_one_initcall+0x194/0x290
  printk#10 do_one_initcall+0x194/0x290
  printk#11 do_one_initcall+0x194/0x290
  printk#12 do_one_initcall+0x194/0x290
  printk#13 zram_init+0x22c/0x2a0 [zram]
  printk#14 zram_init+0x22c/0x2a0 [zram]
  printk#15 zram_init+0x22c/0x2a0 [zram]
  printk#16 zram_init+0x22c/0x2a0 [zram]

I wonder why printk#7 and printk#8 don't show "zram_init"...


interesting... what does the unpatched kernel show?


Really strange.
The unpatched kernel shows __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 too.
The symbol should be known, because later on in printk13 it shows correctly 
zram_init.
I'll need to dig deeper into it, but at least the regression is not due
to your patch.

Helge


Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

2017-09-18 Thread Helge Deller
* Luck, Tony :
> On Sat, Sep 16, 2017 at 12:53:42PM +0900, Sergey Senozhatsky wrote:
> > Hello
> > 
> > RFC
> > 
> > On some arches C function pointers are indirect and point to
> > a function descriptor, which contains the actual pointer to the code.
> > This mostly doesn't matter, except for cases when people want to print
> > out function pointers in symbolic format, because the usual '%pS/%ps'
> > does not work on those arches as expected. That's the reason why we
> > have '%pF/%pf', but since it's here because of a subtle ABI detail
> > specific to some arches (ppc64/ia64/parisc64) it's easy to misuse
> > '%pF/%pf' and '%pS/%ps' (see [1], for example).
> 
> A few new warnings when building on ia64:
> 
> arch/ia64/kernel/module.c:931: warning: passing argument 1 of 
> 'dereference_function_descriptor' makes pointer from integer without a cast
> arch/ia64/kernel/module.c:931: warning: return makes integer from pointer 
> without a cast
> kernel/kallsyms.c:325: warning: assignment makes integer from pointer without 
> a cast
> kernel/kallsyms.c:325: warning: passing argument 1 of 
> 'dereference_kernel_function_descriptor' makes pointer from integer without a 
> cast


I got similiar warnings on parisc.
This patch on top of yours fixed those:

diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index bc2eae8..4f34b46 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -66,6 +66,7 @@
 
 #include 
 #include 
+#include 
 
 #if 0
 #define DEBUGP printk
@@ -959,12 +960,12 @@ void module_arch_cleanup(struct module *mod)
 unsigned long dereference_module_function_descriptor(struct module *mod,
 unsigned long addr)
 {
-   void *opd_sz = mod->arch.fdesc_offset +
+   unsigned long opd_sz = mod->arch.fdesc_offset +
   mod->arch.fdesc_max * sizeof(Elf64_Fdesc);
 
if (addr < mod->arch.fdesc_offset || opd_sz < addr)
return addr;
 
-   return dereference_function_descriptor(addr);
+   return (unsigned long) dereference_function_descriptor((void *) addr);
 }
 #endif
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index e2fc09e..76f4de6 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -322,7 +322,7 @@ const char *kallsyms_lookup(unsigned long addr,
if (is_ksym_addr(addr)) {
unsigned long pos;
 
-   addr = dereference_kernel_function_descriptor(addr);
+   addr = dereference_kernel_function_descriptor((void *) addr);
pos = get_symbol_pos(addr, symbolsize, offset);
/* Grab name */
kallsyms_expand_symbol(get_symbol_offset(pos),


I did tried your testcases too.

"echo 1 > /proc/sys/vm/drop_caches" gave correct output:
 printk#1 schedule_timeout+0x0/0x4a8
 printk#2 schedule_timeout+0x0/0x4a8
 printk#3 proc_sys_call_handler+0x120/0x180
 printk#4 proc_sys_call_handler+0x120/0x180
 printk#5 proc_sys_call_handler+0x120/0x180
 printk#6 proc_sys_call_handler+0x120/0x180

and here is "modprobe zram":
 printk#7 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
 printk#8 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
 printk#9 do_one_initcall+0x194/0x290
 printk#10 do_one_initcall+0x194/0x290
 printk#11 do_one_initcall+0x194/0x290
 printk#12 do_one_initcall+0x194/0x290
 printk#13 zram_init+0x22c/0x2a0 [zram]
 printk#14 zram_init+0x22c/0x2a0 [zram]
 printk#15 zram_init+0x22c/0x2a0 [zram]
 printk#16 zram_init+0x22c/0x2a0 [zram]

I wonder why printk#7 and printk#8 don't show "zram_init"...


Regarding your patches:

In arch/parisc/kernel/process.c:
+void *dereference_kernel_function_descriptor(void *ptr)
+{
+   if (ptr < (void *)__start_opd || (void *)__end_opd < ptr)

This needs to be (__end_opd is outside):
+   if (ptr < (void *)__start_opd || (void *)__end_opd <= ptr)

The same is true for the checks in the other arches.


I'd suggest to move the various
extern char __start_opd[], __end_opd[];
out of arch//include/asm/sections.h and into 


I'll continue to test.

Helge


Re: [PATCH 1/4] panic: Allow warnings to set different taint flags

2010-04-05 Thread Helge Deller
On 04/03/2010 08:34 PM, Ben Hutchings wrote:
 WARN() is used in some places to report firmware or hardware bugs that
 are then worked-around.  These bugs do not affect the stability of the
 kernel and should not set the flag for TAINT_WARN.  To allow for this,
 add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint number
 as argument.
 
 Architectures that implement warnings using trap instructions instead
 of calls to warn_slowpath_*() now implement __WARN_TAINT(taint)
 instead of __WARN().
 
 Signed-off-by: Ben Hutchings b...@decadent.org.uk

Builds and works on the parisc architecture.
Acked-by: Helge Deller del...@gmx.de


 ---
 Changes since the previous version:
 - Added note to Documentation/oops-tracing.txt
 - Changed the commit message to distinguish taint numbers from taint
   flags
 - Removed 'must' from last sentence of commit message; this patch
   converts all mainline architectures
 
 Ben.
 
  Documentation/oops-tracing.txt |1 +
  arch/parisc/include/asm/bug.h  |8 
  arch/powerpc/include/asm/bug.h |6 +++---
  arch/s390/include/asm/bug.h|8 
  arch/sh/include/asm/bug.h  |4 ++--
  include/asm-generic/bug.h  |   34 --
  kernel/panic.c |   24 
  lib/bug.c  |2 +-
  8 files changed, 67 insertions(+), 20 deletions(-)
 
 diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt
 index c10c022..069fab3 100644
 --- a/Documentation/oops-tracing.txt
 +++ b/Documentation/oops-tracing.txt
 @@ -256,6 +256,7 @@ characters, each representing a particular tainted value.
9: 'A' if the ACPI table has been overridden.
  
   10: 'W' if a warning has previously been issued by the kernel.
 + (Though some warnings may set more specific taint flags.)
  
   11: 'C' if a staging driver has been loaded.
  
 diff --git a/arch/parisc/include/asm/bug.h b/arch/parisc/include/asm/bug.h
 index 75e46c5..72cfdb0 100644
 --- a/arch/parisc/include/asm/bug.h
 +++ b/arch/parisc/include/asm/bug.h
 @@ -44,7 +44,7 @@
  #endif
  
  #ifdef CONFIG_DEBUG_BUGVERBOSE
 -#define __WARN() \
 +#define __WARN_TAINT(taint)  \
   do {\
   asm volatile(\n   \
1:\t PARISC_BUG_BREAK_ASM \n   \
 @@ -54,11 +54,11 @@
\t.org 2b+%c3\n  \
\t.popsection\
: : i (__FILE__), i (__LINE__),\
 -  i (BUGFLAG_WARNING), \
 +  i (BUGFLAG_TAINT(taint)),\
i (sizeof(struct bug_entry)) );  \
   } while(0)
  #else
 -#define __WARN() \
 +#define __WARN_TAINT(taint)  \
   do {\
   asm volatile(\n   \
1:\t PARISC_BUG_BREAK_ASM \n   \
 @@ -67,7 +67,7 @@
\t.short %c0\n   \
\t.org 2b+%c1\n  \
\t.popsection\
 -  : : i (BUGFLAG_WARNING), \
 +  : : i (BUGFLAG_TAINT(taint)),\
i (sizeof(struct bug_entry)) );  \
   } while(0)
  #endif
 diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
 index 2c15212..065c590 100644
 --- a/arch/powerpc/include/asm/bug.h
 +++ b/arch/powerpc/include/asm/bug.h
 @@ -85,12 +85,12 @@
   }   \
  } while (0)
  
 -#define __WARN() do {\
 +#define __WARN_TAINT(taint) do { \
   __asm__ __volatile__(   \
   1: twi 31,0,0\n   \
   _EMIT_BUG_ENTRY \
   : : i (__FILE__), i (__LINE__), \
 -   i (BUGFLAG_WARNING),\
 +   i (BUGFLAG_TAINT(taint)),   \
 i (sizeof(struct bug_entry)));  \
  } while (0)
  
 @@ -104,7 +104,7 @@
   1: PPC_TLNEI %4,0\n \
   _EMIT_BUG_ENTRY \
   : : i (__FILE__), i (__LINE__), \
 -   i (BUGFLAG_WARNING),\
 +   i (BUGFLAG_TAINT

Re: [PATCH] Restrict initial stack space expansion to rlimit

2010-02-11 Thread Helge Deller

On 02/10/2010 06:31 AM, Michael Neuling wrote:

In message20100210141016.4d18.a69d9...@jp.fujitsu.com  you wrote:

On 02/09/2010 10:51 PM, Michael Neuling wrote:

I'd still like someone with a CONFIG_STACK_GROWSUP arch to test/ACK it
as well.


There's only one CONFIG_GROWSUP arch - parisc.
Could someone please test it on parisc?


I did.


How about doing:
'ulimit -s 15; ls'
before and after the patch is applied.  Before it's applied, 'ls' should
be killed.  After the patch is applied, 'ls' should no longer be killed.

I'm suggesting a stack limit of 15KB since it's small enough to trigger
20*PAGE_SIZE.  Also 15KB not a multiple of PAGE_SIZE, which is a trickier
case to handle correctly with this code.

4K pages on parisc should be fine to test with.


Mikey, thanks for the suggested test plan.

I'm not sure if your patch does it correct for parisc/stack-grows-up-case.

I tested your patch on  a 4k pages kernel:
r...@c3000:~# uname -a
Linux c3000 2.6.33-rc7-32bit #221 Tue Feb 9 23:17:06 CET 2010 parisc GNU/Li

nux


Without your patch:
r...@c3000:~# ulimit -s 15; ls
Killed
-  correct.

With your patch:
r...@c3000:~# ulimit -s 15; ls
Killed
_or_:
r...@c3000:~# ulimit -s 15; ls
Segmentation fault
-  ??

Any idea?


My x86_64 box also makes segmentation fault. I think ulimit -s 15 is too sm

all stack for ls.

ulimit -s 27; ls   wroks perfectly fine.


Arrh.  I asked Helge offline earlier to check what use to work on parisc
on 2.6.31.

I guess PPC has a nice clean non-bloated ABI :-D


Hi Mikey,

I tested again, and it works for me with ulimit -s 27 as well (on a 4k, 32bit 
kernel).
Still, I'm not 100%  sure if your patch is correct.
Anyway, it seems to work.

But what makes me wonder is, why EXTRA_STACK_VM_PAGES is defined in pages at 
all.
You wrote in your patch description:

This bug means that when limiting the stack to less the 20*PAGE_SIZE (eg.
80K on 4K pages or 'ulimit -s 79') all processes will be killed before
they start.  This is particularly bad with 64K pages, where a ulimit below
1280K will kill every process.


Wouldn't it make sense to define and use EXTRA_STACK_VM_SIZE instead (e.g. as 
20*4096 = 80k)?
This extra stack reservation should IMHO be independend of the actual kernel 
page size.

Helge
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] Restrict initial stack space expansion to rlimit

2010-02-09 Thread Helge Deller

On 02/09/2010 10:51 PM, Michael Neuling wrote:

I'd still like someone with a CONFIG_STACK_GROWSUP arch to test/ACK it
as well.


There's only one CONFIG_GROWSUP arch - parisc.
Could someone please test it on parisc?


I did.


How about doing:
   'ulimit -s 15; ls'
before and after the patch is applied.  Before it's applied, 'ls' should
be killed.  After the patch is applied, 'ls' should no longer be killed.

I'm suggesting a stack limit of 15KB since it's small enough to trigger
20*PAGE_SIZE.  Also 15KB not a multiple of PAGE_SIZE, which is a trickier
case to handle correctly with this code.

4K pages on parisc should be fine to test with.


Mikey, thanks for the suggested test plan.

I'm not sure if your patch does it correct for parisc/stack-grows-up-case.

I tested your patch on  a 4k pages kernel:
r...@c3000:~# uname -a
Linux c3000 2.6.33-rc7-32bit #221 Tue Feb 9 23:17:06 CET 2010 parisc GNU/Linux

Without your patch:
r...@c3000:~# ulimit -s 15; ls
Killed
- correct.

With your patch:
r...@c3000:~# ulimit -s 15; ls
Killed
_or_:
r...@c3000:~# ulimit -s 15; ls
Segmentation fault
- ??

Any idea?

Helge



From: Michael Neulingmi...@neuling.org

When reserving stack space for a new process, make sure we're not
attempting to expand the stack by more than rlimit allows.

This fixes a bug caused by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba (mm:
variable length argument support) and unmasked by
fc63cf237078c86214abcb2ee9926d8ad289da9b (exec: setup_arg_pages() fails
to return errors).

This bug means that when limiting the stack to less the 20*PAGE_SIZE (eg.
80K on 4K pages or 'ulimit -s 79') all processes will be killed before
they start.  This is particularly bad with 64K pages, where a ulimit below
1280K will kill every process.

Signed-off-by: Michael Neulingmi...@neuling.org
Cc: KOSAKI Motohirokosaki.motoh...@jp.fujitsu.com
Cc: Americo Wangxiyou.wangc...@gmail.com
Cc: Anton Blanchardan...@samba.org
Cc: Oleg Nesterovo...@redhat.com
Cc: James Morrisjmor...@namei.org
Cc: Ingo Molnarmi...@elte.hu
Cc: Serge Hallynse...@us.ibm.com
Cc: Benjamin Herrenschmidtb...@kernel.crashing.org
Cc:sta...@kernel.org

  fs/exec.c |   21 +++--
  1 file changed, 19 insertions(+), 2 deletions(-)

diff -puN fs/exec.c~fs-execc-restrict-initial-stack-space-expansion-to-rlimit

  fs/exec.c

--- a/fs/exec.c~fs-execc-restrict-initial-stack-space-expansion-to-rlimit
+++ a/fs/exec.c
@@ -571,6 +571,9 @@ int setup_arg_pages(struct linux_binprm
struct vm_area_struct *prev = NULL;
unsigned long vm_flags;
unsigned long stack_base;
+   unsigned long stack_size;
+   unsigned long stack_expand;
+   unsigned long rlim_stack;

  #ifdef CONFIG_STACK_GROWSUP
/* Limit stack size to 1GB */
@@ -627,10 +630,24 @@ int setup_arg_pages(struct linux_binprm
goto out_unlock;
}

+   stack_expand = EXTRA_STACK_VM_PAGES * PAGE_SIZE;
+   stack_size = vma-vm_end - vma-vm_start;
+   /*
+* Align this down to a page boundary as expand_stack
+* will align it up.
+*/
+   rlim_stack = rlimit(RLIMIT_STACK)  PAGE_MASK;
+   rlim_stack = min(rlim_stack, stack_size);
  #ifdef CONFIG_STACK_GROWSUP
-   stack_base = vma-vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
+   if (stack_size + stack_expand  rlim_stack)
+   stack_base = vma-vm_start + rlim_stack;
+   else
+   stack_base = vma-vm_end + stack_expand;
  #else
-   stack_base = vma-vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
+   if (stack_size + stack_expand  rlim_stack)
+   stack_base = vma-vm_end - rlim_stack;
+   else
+   stack_base = vma-vm_start - stack_expand;
  #endif
ret = expand_stack(vma, stack_base);
if (ret)

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH/RFC 0/5] Generic RTC class driver

2009-02-24 Thread Helge Deller
Geert Uytterhoeven wrote:
 I've been looking into problems with auto-loading the RTC driver on PPC (more
 specifically on PS3):
   - The recent rtc-ppc RTC class driver is not autoloaded by udev because
 it's an old style platform driver that contains its own platform device.
   - The alternative old genrtc driver is autoloaded on non-udev systems only
 because it contains the module alias char-major-10-135. However, it's not
 a new-style RTC class driver.
 
 Fortunately there already exists a generic RTC class driver: rtc-parisc.
 Despite it's name, it's platform-independent, as it's build on top of the RTC
 abstraction used by genrtc.
 
 This patch series
   - adds a missing module alias to rtc-parisc,
   - renames rtc-parisc to rtc-generic,
   - converts the architectures that currently have CONFIG_GEN_RTC enabled in
 their defconfig (m68k, parisc, powerpc) to rtc-generic,
   - removes the obsolete rtc-ppc driver,
   - removes the old genrtc driver.
   
 Note that genrtc may be used on other archictectures as well: at least alpha
 has the required infrastructure ([gs]et_rtc_time()). The Kconfig rules allow
 genrtc to be enabled on several others (cris, h8300, mn10300, um, x86, 
 xtensa).
 
 Furthermore genrtc and rtc-generic are not 100% userspace compatible:
   - /dev/rtc provided by genrtc uses a misc character device (10:135),
   - /dev/rtc provided by rtc-generic uses a dynamic character device.
   
 So perhaps we don't want to kill gen-rtc yet?
 
 Any comments are welcomed!

Hi Geert,
FYI, I didn't followed any discussions or changes around the RTC drivers for 
parisc,
but Dann Frazier did some work on the parisc RTC driver as well.
His patches were merged (not upstream yet!) in Kyle's rtc-parisc branch at:
http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=shortlog;h=rtc-parisc

Not sure if they conflict (or are in sync) with your patches...

Helge
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev