Richard Weinberger | 12 Jan 21:36 2016

[GIT PULL] UML updates for 4.5


the following changes since commit 74bf8efb5fa6e958d2d7c7917b8bb672085ec0c6:

  Linux 4.4-rc7 (2015-12-27 18:17:37 -0800)

are available in the git repository at:

  git:// for-linus-4.5-rc1

for you to fetch changes up to 3e46b25376321db119bc8507ce8c8841c580e736:

  um: Use race-free temporary file creation (2016-01-10 21:49:50 +0100)

Anton Ivanov (3):
      um: Prevent IRQ handler reentrancy
      um: Do not change hard IRQ flags in soft IRQ processing
      um: Update UBD to use pread/pwrite family of functions

Mickaël Salaün (7):
      um: Fix ptrace GETREGS/SETREGS bugs
      selftests/seccomp: Remove the need for HAVE_ARCH_TRACEHOOK
      um: Add full asm/syscall.h support
      um: Add seccomp support
      um: Fix build error and kconfig for i386
      um: Do not set unsecure permission for temporary file
      um: Use race-free temporary file creation

Vegard Nossum (3):
(Continue reading)

Richard Weinberger | 10 Jan 23:37 2016

Stuff for v4.5


I've pushed everything I'd like to see in 4.5 merged.
Please speak up now if I forgot something!



Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
Anton Ivanov | 21 Dec 19:54 2015

[PATCH 1/2] Update UBD to use pread/pwrite family of functions

This decreases the number of syscalls per read/write by half.

Signed-off-by: Anton Ivanov <aivanov <at>>
 arch/um/drivers/ubd_kern.c  | 27 +++++----------------------
 arch/um/include/shared/os.h |  2 ++
 arch/um/os-Linux/file.c     | 19 +++++++++++++++++++
 3 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
index e8ab93c..39ba207 100644
--- a/arch/um/drivers/ubd_kern.c
+++ b/arch/um/drivers/ubd_kern.c
 <at>  <at>  -535,11 +535,7  <at>  <at>  static int read_cow_bitmap(int fd, void *buf, int offset, int len)
 	int err;

-	err = os_seek_file(fd, offset);
-	if (err < 0)
-		return err;
-	err = os_read_file(fd, buf, len);
+	err = os_pread_file(fd, buf, len, offset);
 	if (err < 0)
 		return err;

 <at>  <at>  -1377,14 +1373,8  <at>  <at>  static int update_bitmap(struct io_thread_req *req)
 	if(req->cow_offset == -1)
 		return 0;

(Continue reading)

Anton Ivanov | 21 Dec 12:28 2015

[PATCH 1/2] Prevent IRQ handler reentrancy

The existing IRQ handler design in UML does not prevent reentrancy

This is mitigated by fd-enable/fd-disable semantics for the IO
portion of the UML subsystem. The timer, however, can and is
re-entered resulting in very deep stack usage and occasional
stack exhaustion.

This patch prevents this by checking if there is a timer
interrupt in-flight before processing any pending timer interrupts.

Signed-off-by: Anton Ivanov <aivanov <at>>
 arch/um/os-Linux/signal.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/um/os-Linux/signal.c b/arch/um/os-Linux/signal.c
index c211153..7801666 100644
--- a/arch/um/os-Linux/signal.c
+++ b/arch/um/os-Linux/signal.c
 <at>  <at>  -62,6 +62,7  <at>  <at>  static void sig_handler_common(int sig, struct siginfo *si, mcontext_t *mc)

 static int signals_enabled;
 static unsigned int signals_pending;
+static unsigned int signals_active = 0;

 void sig_handler(int sig, struct siginfo *si, mcontext_t *mc)
 <at>  <at>  -101,7 +102,12  <at>  <at>  void timer_alarm_handler(int sig, struct siginfo *unused_si, mcontext_t *mc)

(Continue reading)

Vegard Nossum | 6 Dec 16:34 2015

uml instance crashes when started from script


I've been running into some odd crashes when starting my UML instance 
from Python. This is my script:

import subprocess
subprocess.check_call(['path/to/vmlinux', 'mem=2048M', 
'rootfstype=hostfs', 'rw', 'init=/bin/bash'])

This will crash 9 out of 10 times with various strange messages on the 

[    1.890000] devtmpfs: mounted
[    1.960000] mount (947) used greatest stack depth: 5592 bytes left
[    1.990000] mount (948) used greatest stack depth: 5496 bytes left
#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#��+J <at> ��o��#7%����2Z����.�j
��h� -^(�l0�w8�\ <at> �}P�)o`o-�p)CS�-!���8��,��Ҋ8�>)DV9 � 
�9�����$��#�#�#�#[    6.870000]
[    6.870000] Pid: 1, comm: init Not tainted 4.4.0-rc3
[    6.870000] RIP: 0033:[<00000000018d4848>]
[    6.870000] RSP: 00000000dff3efa8  EFLAGS: 00010216
[    6.870000] RAX: 0000000000000001 RBX: 00000000600748c0 RCX: 
[    6.870000] RDX: ffffffffffffffff RSI: 0000000000000001 RDI: 
[    6.870000] RBP: 00000000dff3efe8 R08: 00000000dff3ee38 R09: 
[    6.870000] R10: 0000000000000000 R11: 0000000000000246 R12: 
(Continue reading)

Richard Weinberger | 29 Nov 21:13 2015

[PATCH] um: Fix fpstate handling

The x86 FPU cleanup changed fpstate to a plain integer.
UML on x86 has to deal with that too.

Signed-off-by: Richard Weinberger <richard <at>>

diff --git a/arch/x86/um/signal.c b/arch/x86/um/signal.c
index 06934a8..e5f854c 100644
--- a/arch/x86/um/signal.c
+++ b/arch/x86/um/signal.c
 <at>  <at>  -211,7 +211,7  <at>  <at>  static int copy_sc_from_user(struct pt_regs *regs,
 		if (err)
 			return 1;

-		err = convert_fxsr_from_user(&fpx, sc.fpstate);
+		err = convert_fxsr_from_user(&fpx, (void *)sc.fpstate);
 		if (err)
 			return 1;

 <at>  <at>  -227,7 +227,7  <at>  <at>  static int copy_sc_from_user(struct pt_regs *regs,
 		struct user_i387_struct fp;

-		err = copy_from_user(&fp, sc.fpstate,
+		err = copy_from_user(&fp, (void *)sc.fpstate,
 				     sizeof(struct user_i387_struct));
 		if (err)
 			return 1;
 <at>  <at>  -291,7 +291,7  <at>  <at>  static int copy_sc_to_user(struct sigcontext __user *to,
 #undef PUTREG
(Continue reading)

Anton Ivanov | 26 Nov 10:49 2015

Old process in D state bug

Hi List, hi Richard,

While working on the EPOLL I managed to consistently reproduce and get 
down to the bottom of the process in D state bug which you occasionally 
see with UML. I recall asking Richard's help on this for the first time 
nearly 5 years ago ;-).

It is extremely rare with the POLL based controller, timers and the 
stock UBD drivers. As you make things go faster (anywhere in UML) it 
rares its ugly head. So improving the IRQs, improving UBD itself, etc - 
all make it easier to trigger.

It looks like it is possible to end up in a state where the restart list 
is not empty (an earlier transaction to the disk io thread failed with 
EAGAIN), but with no pending IO on the UBD IPC thread fd. So the restart 
list is never re-triggered and the UBD device ends up with a non-empty 
queue. The process that requested the IO ends up in D state. Any other 
processes trying IO to the same disk join it. As the requests to the 
same UBD queue up, ultimately, UML goes belly up.

Pinging the UML process with SIGIO does not help as there is no IO 
pending on the fd. So it is not a lost interrupt. It somehow manages to 
race forming the restart queue.

If, however, you have more than one UBD device IO to the other one 
unstucks it by re-running the restart queue out of the ubd interrupt 

Once again - this is extremely rare at present, but possible (I have 
seen it a few times over the last 5 years).
(Continue reading)

Anton Ivanov | 20 Nov 17:45 2015

[PATCH 1/3] IRQ Reentrancy guard

Fixes: IRQ Reentrancy

The code in signal.c used in irq controller emulation does not
prevent IRQ reentrancy which can result in all types of issues
as IRQs including ones on the same device can be executed in
a nested manner

Signed-off-by: Anton Ivanov <aivanov <at>>
 arch/um/kernel/irq.c      |  8 ++++++++
 arch/um/os-Linux/signal.c | 15 ++++++++++++++-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/um/kernel/irq.c b/arch/um/kernel/irq.c
index 23cb935..4813263 100644
--- a/arch/um/kernel/irq.c
+++ b/arch/um/kernel/irq.c
 <at>  <at>  -30,11 +30,17  <at>  <at>  static struct irq_fd **last_irq_ptr = &active_fds;

 extern void free_irqs(void);

+static int in_poll_handler = 0;
 void sigio_handler(int sig, struct siginfo *unused_si, struct uml_pt_regs *regs)
 	struct irq_fd *irq_fd;
 	int n;

+	WARN_ON_ONCE(in_poll_handler == 1);
(Continue reading)

Anton Ivanov | 20 Nov 13:05 2015

IRQ handler reentrancy

I have gotten to the bottom of this.

1. The IRQ handler re-entrancy issue predates the timer patch. Adding a 
simple guard with a WARN_ON_ONCE around the device loop in the 
sig_io_handler catches it in plain 4.3

diff --git a/arch/um/kernel/irq.c b/arch/um/kernel/irq.c
index 23cb935..ac0bbce 100644
--- a/arch/um/kernel/irq.c
+++ b/arch/um/kernel/irq.c
 <at>  <at>  -30,12 +30,17  <at>  <at>  static struct irq_fd **last_irq_ptr = &active_fds;

  extern void free_irqs(void);

+static int in_poll_handler = 0;
  void sigio_handler(int sig, struct siginfo *unused_si, struct 
uml_pt_regs *regs)
         struct irq_fd *irq_fd;
         int n;

+    WARN_ON_ONCE(in_poll_handler == 1);
         while (1) {
+        in_poll_handler = 1;
                 n = os_waiting_for_events(active_fds);
                 if (n <= 0) {
                         if (n == -EINTR)
 <at>  <at>  -51,6 +56,7  <at>  <at>  void sigio_handler(int sig, struct siginfo *unused_si, 
(Continue reading)

Lorenzo Colitti | 18 Nov 15:12 2015

[PATCH] arch: um: fix error when linking vmlinux.

On gcc Ubuntu 4.8.4-2ubuntu1~14.04, linking vmlinux fails with:

arch/um/os-Linux/built-in.o: In function `os_timer_create':
/android/kernel/android/arch/um/os-Linux/time.c:51: undefined reference to `timer_create'
arch/um/os-Linux/built-in.o: In function `os_timer_set_interval':
/android/kernel/android/arch/um/os-Linux/time.c:84: undefined reference to `timer_settime'
arch/um/os-Linux/built-in.o: In function `os_timer_remain':
/android/kernel/android/arch/um/os-Linux/time.c:109: undefined reference to `timer_gettime'
arch/um/os-Linux/built-in.o: In function `os_timer_one_shot':
/android/kernel/android/arch/um/os-Linux/time.c:132: undefined reference to `timer_settime'
arch/um/os-Linux/built-in.o: In function `os_timer_disable':
/android/kernel/android/arch/um/os-Linux/time.c:145: undefined reference to `timer_settime'

This is because -lrt appears in the generated link commandline
after arch/um/os-Linux/built-in.o. Fix this by removing -lrt from
arch/um/Makefile and adding it to the UM-specific section of

Signed-off-by: Lorenzo Colitti <lorenzo <at>>
 arch/um/Makefile        | 2 +-
 scripts/ | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/um/Makefile b/arch/um/Makefile
index 25ed409..e3abe6f 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
 <at>  <at>  -131,7 +131,7  <at>  <at>  export LDS_ELF_FORMAT := $(ELF_FORMAT)
 # The wrappers will select whether using "malloc" or the kernel allocator.
(Continue reading)

Anton Ivanov | 18 Nov 09:33 2015

Re: [PATCH v2] EPOLL Interrupt Controller V2.0

Hi all,

I have looked through this and I still have not figured it out 
completely. Moving from the old poll controller to the new epoll one 
triggers deep recursive invocations of the interrupt handlers. I still 
do not understand why it does it so I will park it for now and come back 
to it next week.

I did, however, find a number of small issues. Namely, various patches 
and fixes over the years have used calls to block/unblock signals and 
block/unblock irqs in a few places where these can create a recursion 
race (even with the old controller).

If I understand os-Linux/irq.c correctly, block/unblock in UML does not 
block or unblock the signals. It blocks/unblocks the processing of them 
and unblock can (and will) result in the immediate processing any 
pending signals. So in most places, that should not be block/unblock 
(and respectively local_irq_enable/local_irq_disable which invoke that). 
It should be save+block and restore. Otherwise you recurse by invoking 
the IRQ handler the moment you unblock_signals().

Additionally, if you want just to wait and be interrupted by a signal, 
you do not need to enable/disable IRQs - signals are always received at 
present. If I understand the situation correctly, irq on/off only 
changes if they are processed or not.

I am going to roll my tree back to the timer patch now and go through 
the ones I found so far one by one and submit them separately. Once that 
is out of the way we can look again at the epoll controller patch. It 
has potential, but it makes all gremlins come out of the woodwork so we 
(Continue reading)