Helge Deller | 21 Oct 21:46 2014

[PATCH] parisc: fix out-of-register compiler error in ldcw inline assembler function

Sometimes we face this compiler error:

arch/parisc/include/asm/ldcw.h:39:2: error: can't find a register in class 'R1_REGS' while reloading 'asm'
	__asm__ __volatile__(__LDCW " 0(%2),%0"...
	note: in expansion of macro '__ldcw'
	error: 'asm' operand has impossible constraints

Dave suggested:
Likely the problem can be fixed by making __ldcw a static inline function and
forcing the argument 'a' to a specific register before using in ldcw.

Since it's not easy to reproduce this bug, this patch now tries to still let
the compiler decide on which register should be used. If it doesn't work, we'll
have to assign a specific register as suggested by Dave.

Signed-off-by: Helge Deller <deller <at> gmx.de>
Cc: John David Anglin <dave.anglin <at> bell.net>

diff --git a/arch/parisc/include/asm/ldcw.h b/arch/parisc/include/asm/ldcw.h
index d2d11b7..b951e01 100644
--- a/arch/parisc/include/asm/ldcw.h
+++ b/arch/parisc/include/asm/ldcw.h
 <at>  <at>  -34,12 +34,14  <at>  <at> 
 #endif /*!CONFIG_PA20*/

 /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*.  */
-#define __ldcw(a) ({						\
-	unsigned __ret;						\
-	__asm__ __volatile__(__LDCW " 0(%2),%0"			\
-		: "=r" (__ret), "+m" (*(a)) : "r" (a));		\
(Continue reading)

Helge Deller | 21 Oct 21:29 2014

[PATCH] parisc: use BUILD_BUG() instead of undefined functions

Signed-off-by: Helge Deller <deller <at> gmx.de>

diff --git a/arch/parisc/include/asm/uaccess.h b/arch/parisc/include/asm/uaccess.h
index 4006964..a5cb070 100644
--- a/arch/parisc/include/asm/uaccess.h
+++ b/arch/parisc/include/asm/uaccess.h
 <at>  <at>  -9,6 +9,8  <at>  <at> 
 #include <asm/errno.h>
 #include <asm-generic/uaccess-unaligned.h>

+#include <linux/bug.h>
 #define VERIFY_READ 0
 #define VERIFY_WRITE 1

 <at>  <at>  -28,11 +30,6  <at>  <at> 
  * that put_user is the same as __put_user, etc.

-extern int __get_kernel_bad(void);
-extern int __get_user_bad(void);
-extern int __put_kernel_bad(void);
-extern int __put_user_bad(void);
 static inline long access_ok(int type, const void __user * addr,
 		unsigned long size)
 <at>  <at>  -43,8 +40,8  <at>  <at>  static inline long access_ok(int type, const void __user * addr,
 #define get_user __get_user

(Continue reading)

Helge Deller | 21 Oct 21:27 2014

[PATCH] parisc: Wire up bpf syscall

Signed-off-by: Helge Deller <deller <at> gmx.de>

diff --git a/arch/parisc/include/uapi/asm/unistd.h b/arch/parisc/include/uapi/asm/unistd.h
index 8667f18..5f5c037 100644
--- a/arch/parisc/include/uapi/asm/unistd.h
+++ b/arch/parisc/include/uapi/asm/unistd.h
 <at>  <at>  -833,8 +833,9  <at>  <at> 
 #define __NR_seccomp		(__NR_Linux + 338)
 #define __NR_getrandom		(__NR_Linux + 339)
 #define __NR_memfd_create	(__NR_Linux + 340)
+#define __NR_bpf		(__NR_Linux + 341)

-#define __NR_Linux_syscalls	(__NR_memfd_create + 1)
+#define __NR_Linux_syscalls	(__NR_bpf + 1)

 #define __IGNORE_select		/* newselect */
diff --git a/arch/parisc/kernel/syscall_table.S b/arch/parisc/kernel/syscall_table.S
index b563d9c..d65c50a 100644
--- a/arch/parisc/kernel/syscall_table.S
+++ b/arch/parisc/kernel/syscall_table.S
 <at>  <at>  -436,6 +436,7  <at>  <at> 
 	ENTRY_SAME(memfd_create)	/* 340 */

 	/* Nothing yet */

(Continue reading)

Helge Deller | 12 Oct 12:08 2014

[GIT PULL] parisc architecture patch for v3.18

Hi Linus,

please pull one patch for the parisc architecture for kernel 3.18 from 
  git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-3.18-1

This patch intentionally breaks the ABI on PARISC Linux!

It assigns new numbers to SIGSTKFLT, SIGXCPU, SIGXFSZ and SIGSYS so that
those are below 32 and thus leaves us with 32 RT signals like other
Linux architectures (SIGRTMIN now becomes 32 instead of 37).

Even if it breaks the ABI, it doesn't seem to have any visible impact on
existing userspace applications. I was able to mix new kernel and/or
glibc without impacting normal bootup.  So, even if it breaks the ABI,
the benefits (e.g. being able to use systemd on PARISC Linux)
outperforms the minimal (if any) impact it gives.

The patch has been discussed on the parisc kernel mailing list and the
coresponding glibc patch will be committed by the parisc glibc
maintainer after this patch went into 3.18.

Some more background information about this patch is in the commit


Helge Deller (1):
      parisc: Reduce SIGRTMIN from 37 to 32 to behave like other Linux architectures
(Continue reading)

Helge Deller | 10 Oct 22:20 2014

[PATCH] parisc: Reduce SIGRTMIN from 37 to 32 to behave like other Linux architectures

This patch reduces the value of SIGRTMIN on PARISC from 37 to 32, thus
increasing the number of available RT signals and bring it in sync with other
Linux architectures.

Historically we wanted to natively support HP-UX 32bit binaries with the
PA-RISC Linux port.  Because of that we carried the various available signals
from HP-UX (e.g. SIGEMT and SIGLOST) and folded them in between the native
Linux signals.  Although this was the right decision at that time, this
required us to increase SIGRTMIN to at least 37 which left us with 27 (64-37)
RT signals.

Those 27 RT signals haven't been a problem in the past, but with the upcoming
importance of systemd we now got the problem that systemd alloctes (hardcoded)
signals up to SIGRTMIN+29 which is beyond our NSIG of 64. Because of that we
have not been able to use systemd on the PARISC Linux port yet.

Of course we could ask the systemd developers to not use those hardcoded
values, but this change is very unlikely, esp. with PA-RISC being a niche

The other possibility would be to increase NSIG to e.g. 128, but this would
mean to duplicate most of the existing Linux signal handling code into the
parisc specific Linux kernel tree which would most likely introduce lots of new
bugs beside the code duplication.

The third option is to drop some HP-UX signals and shuffle some other signals
around to bring SIGRTMIN to 32.  This is of course an ABI change, but testing
has shown that existing Linux installations are not visibly affected by this
change - most likely because we move those signals around which are rarely used
and move them to slots which haven't been used in Linux yet. In an existing
(Continue reading)

Helge Deller | 7 Oct 21:39 2014

systemd on hppa and number of free RT signals

Hello everyone,

I've just had a successful boot on hppa with systemd :-)
The bootlog is attached.

As already discussed here:
we don't have enough RT signals for systemd, which requests "SIGRTMIN+29" which is > 64 (SIGRTMAX).
Since systemd gets more and more important (e.g. KDE now seems to require systemd) we should try to find a solution.

The attached patches to Linux kernel and glibc shuffles around some signals, so that we end up with
#define __SIGRTMIN	32
instead of
#define __SIGRTMIN	37

I do know that this changes the ABI and introduces a binary incompatibly.
Nevertheless, my testing with the new kernel and glibc didn't showed any obvious problems, which means
that I could install either of those and the system didn't showed problems even after reboots.
Additionally, given the fact that we have very little users and live in debian/gentoo unstable would IMHO
justify such an incompatible change. Even HP-UX support was dropped a few months back...
And we could easily rebuild packages like strace, gdb and such...

The other option would be to increase NSIG in kernel from 64 to 128 or higher.
I did tried to come up with kernel patches for this now for a few weeks, but ended up with the recognition, that
this would require to duplicate nearly all of Linux kernel signal handling and which would most likely
introduce new bugs.

What's your opinion on this?
I will provide prebuilt debian packages with those patches for kernel and glibc tomorrow for download, so
that people may test themselves...
(Continue reading)

Helge Deller | 1 Oct 22:11 2014

[PATCH] parisc: Fix serial console for machines with serial port on superio chip

Fix the serial console on machines where the serial port is located on
the SuperIO chip.

Signed-off-by: Helge Deller <deller <at> gmx.de>
CC: Peter Hurley <peter <at> hurleysoftware.com>
diff --git a/drivers/parisc/superio.c b/drivers/parisc/superio.c
index a042d06..8be2096 100644
--- a/drivers/parisc/superio.c
+++ b/drivers/parisc/superio.c
 <at>  <at>  -395,7 +395,8  <at>  <at>  static void __init superio_serial_init(void)
 	serial_port.iotype	= UPIO_PORT;
 	serial_port.type	= PORT_16550A;
 	serial_port.uartclk	= 115200*16;
-	serial_port.fifosize	= 16;
+	serial_port.flags	= UPF_FIXED_PORT | UPF_FIXED_TYPE |

 	/* serial port #1 */
 	serial_port.iobase	= sio_dev.sp1_base;
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Guenter Roeck | 30 Sep 20:00 2014

[RFC PATCH 00/16] kernel: Add support for poweroff handler call chain

Various drivers implement architecture and/or device specific means to
remove power from the system.  For the most part, those drivers set the
global variable pm_power_off to point to a function within the driver.

This mechanism has a number of drawbacks.  Typically only one scheme
to remove power is supported (at least if pm_power_off is used).
At least in theory there can be multiple means remove power, some of
which may be less desirable.  For example, some mechanisms may only
power off the CPU or the CPU card, while another may power off the
entire system.  Others may really just execute a restart sequence
or drop into the ROM monitor.  Using pm_power_off can also be racy
if the function pointer is set from a driver built as module, as the
driver may be in the process of being unloaded when pm_power_off is
called.  If there are multiple poweroff handlers in the system, removing
a module with such a handler may inadvertently reset the pointer to
pm_power_off to NULL, leaving the system with no means to remove power.

Introduce a system poweroff handler call chain to solve the described
problems.  This call chain is expected to be executed from the
architecture specific machine_power_off() function.  Drivers providing
system poweroff functionality are expected to register with this call chain.
By using the priority field in the notifier block, callers can control
poweroff handler execution sequence and thus ensure that the poweroff
handler with the optimal capabilities to remove power for a given system
is called first.

The poweroff handler is introduced in multiple steps

1) Implement poweroff handler API.
   Patch 01/16.
(Continue reading)

Nicholas Krause | 24 Sep 03:49 2014

[PATCH] parisc:Remove unnecessary FIXMES in init.c

This removes the two fixmes in the file, init.c for compiler hints
for comments related to compiler hints in linux_gateway_page_addr
and map_hpux_gateway_page to change from FIXME to HINT in order
for people reading this code to understand that these are compiler

Signed-off-by: Nicholas Krause <yocto6 <at> gmail.com>
 arch/parisc/mm/init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 0bef864..668102e 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
 <at>  <at>  -733,7 +733,7  <at>  <at>  static void __init pagetable_init(void)
 static void __init gateway_init(void)
 	unsigned long linux_gateway_page_addr;
-	/* FIXME: This is 'const' in order to trick the compiler
+	/* HINT: This is 'const' in order to trick the compiler
 	   into not treating it as DP-relative data. */
 	extern void * const linux_gateway_page;

 <at>  <at>  -761,7 +761,7  <at>  <at>  map_hpux_gateway_page(struct task_struct *tsk, struct mm_struct *mm)
 	unsigned long start_pte;
 	unsigned long address;
 	unsigned long hpux_gw_page_addr;
-	/* FIXME: This is 'const' in order to trick the compiler
+	/* HINT: This is 'const' in order to trick the compiler
(Continue reading)

Helge Deller | 23 Sep 21:43 2014

[GIT PULL] parisc fixes for v3.17

Hi Linus,

please pull a few late fixes for the parisc architecture for kernel 3.17 from 
  git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-3.17-7

We avoid using -mfast-indirect-calls for 64bit kernel builds to prevent
building an unbootable kernel due to latest gcc changes. In the
pdc_stable/firmware-access driver we fix a few possible stack overflows
and we now call secure_computing_strict() instead of secure_computing()
which fixes upcoming SECCOMP patches in the for-next trees.


Helge Deller (2):
      parisc: ptrace: use secure_computing_strict()
      parisc: pdc_stable.c: Avoid potential stack overflows

John David Anglin (1):
      parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds

Rickard Strandqvist (1):
      parisc: pdc_stable.c: Cleaning up unnecessary use of memset in conjunction with strncpy

 arch/parisc/Makefile        |  7 ++++++-
 arch/parisc/kernel/ptrace.c |  6 ++----
 drivers/parisc/pdc_stable.c | 15 +++++++++------
 3 files changed, 17 insertions(+), 11 deletions(-)
(Continue reading)

小孔 | 23 Sep 16:32 2014

用这个平台发短信,这就对了 x5fw3uum


(Continue reading)