Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH] m68k: flat one memory region works with small kernel patch
@ 2016-08-17  5:49 Waldemar Brodkorb
  2016-08-17  5:57 ` Baruch Siach
  0 siblings, 1 reply; 2+ messages in thread
From: Waldemar Brodkorb @ 2016-08-17  5:49 UTC (permalink / raw)
  To: buildroot

Greg Ungerer fixed recently a bug in the Linux kernel, which
allows to use one memory region again.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
---
 arch/Config.in                                     |  2 +-
 .../patches/linux/m68knommu-fix-signal.patch       | 45 ++++++++++++++++++++++
 configs/qemu_m68k_mcf5208_defconfig                |  2 +
 3 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 board/qemu/m68k-mcf5208/patches/linux/m68knommu-fix-signal.patch

diff --git a/arch/Config.in b/arch/Config.in
index b980e05..73d240f 100644
--- a/arch/Config.in
+++ b/arch/Config.in
@@ -331,7 +331,7 @@ choice
 
 config BR2_BINFMT_FLAT_ONE
 	bool "One memory region"
-	depends on !BR2_m68k
+	depends on BR2_m68k || BR2_bfin
 	help
 	  All segments are linked into one memory region.
 
diff --git a/board/qemu/m68k-mcf5208/patches/linux/m68knommu-fix-signal.patch b/board/qemu/m68k-mcf5208/patches/linux/m68knommu-fix-signal.patch
new file mode 100644
index 0000000..b56994b
--- /dev/null
+++ b/board/qemu/m68k-mcf5208/patches/linux/m68knommu-fix-signal.patch
@@ -0,0 +1,45 @@
+m68knommu: fix user a5 register being overwritten
+
+On no-MMU systems the application a5 register can be overwitten with the
+address of the process data segment when processing application signals.
+For flat format applications compiled with full absolute relocation this
+effectively corrupts the a5 register on signal processing - and this very
+quickly leads to process crash and often takes out the whole system with
+a panic as well.
+
+This has no effect on flat format applications compiled with the more
+common PIC methods (such as -msep-data). These format applications reserve
+a5 for the pointer to the data segment anyway - so it doesn't change it.
+
+A long time ago the a5 register was used in the code packed into the user
+stack to enable signal return processing. And so it had to be restored on
+end of signal cleanup processing back to the original a5 user value. This
+was historically done by saving away a5 in the sigcontext structure. At
+some point (a long time back it seems) the a5 restore process was changed
+and it was hard coded to put the user data segment address directly into a5.
+Which is ok for the common PIC compiled application case, but breaks the
+full relocation application code.
+
+We no longer use this type of signal handling mechanism and so we don't
+need to do anything special to save and restore a5 at all now. So remove the
+code that hard codes a5 to the address of the user data segment.
+
+Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
+---
+ arch/m68k/kernel/signal.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
+index 2dcee3a..9202f82 100644
+--- a/arch/m68k/kernel/signal.c
++++ b/arch/m68k/kernel/signal.c
+@@ -213,7 +213,6 @@ static inline int frame_extra_sizes(int f)
+ 
+ static inline void adjustformat(struct pt_regs *regs)
+ {
+-	((struct switch_stack *)regs - 1)->a5 = current->mm->start_data;
+ 	/*
+ 	 * set format byte to make stack appear modulo 4, which it will
+ 	 * be when doing the rte
+-- 
+1.9.1
diff --git a/configs/qemu_m68k_mcf5208_defconfig b/configs/qemu_m68k_mcf5208_defconfig
index f911467..659ae3d 100644
--- a/configs/qemu_m68k_mcf5208_defconfig
+++ b/configs/qemu_m68k_mcf5208_defconfig
@@ -9,6 +9,8 @@ BR2_SYSTEM_DHCP="eth0"
 BR2_TARGET_ROOTFS_INITRAMFS=y
 # BR2_TARGET_ROOTFS_TAR is not set
 
+BR2_GLOBAL_PATCH_DIR="board/qemu/m68k-mcf5208/patches"
+
 # Linux headers same as kernel, a 4.7 series
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_7=y
 
-- 
2.1.4

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* [Buildroot] [PATCH] m68k: flat one memory region works with small kernel patch
  2016-08-17  5:49 [Buildroot] [PATCH] m68k: flat one memory region works with small kernel patch Waldemar Brodkorb
@ 2016-08-17  5:57 ` Baruch Siach
  0 siblings, 0 replies; 2+ messages in thread
From: Baruch Siach @ 2016-08-17  5:57 UTC (permalink / raw)
  To: buildroot

Hi Waldemar,

On Wed, Aug 17, 2016 at 07:49:59AM +0200, Waldemar Brodkorb wrote:
> Greg Ungerer fixed recently a bug in the Linux kernel, which
> allows to use one memory region again.
> 
> Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
> ---
>  arch/Config.in                                     |  2 +-
>  .../patches/linux/m68knommu-fix-signal.patch       | 45 ++++++++++++++++++++++
>  configs/qemu_m68k_mcf5208_defconfig                |  2 +
>  3 files changed, 48 insertions(+), 1 deletion(-)
>  create mode 100644 board/qemu/m68k-mcf5208/patches/linux/m68knommu-fix-signal.patch
> 
> diff --git a/arch/Config.in b/arch/Config.in
> index b980e05..73d240f 100644
> --- a/arch/Config.in
> +++ b/arch/Config.in
> @@ -331,7 +331,7 @@ choice
>  
>  config BR2_BINFMT_FLAT_ONE
>  	bool "One memory region"
> -	depends on !BR2_m68k
> +	depends on BR2_m68k || BR2_bfin

This change excludes other noMMU arches (e.g. ARM). Is that intended?

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-08-17  5:57 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-08-17  5:49 [Buildroot] [PATCH] m68k: flat one memory region works with small kernel patch Waldemar Brodkorb
2016-08-17  5:57 ` Baruch Siach

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox