linux-kernel - Re: ERESTARTSYS escaping from sem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Oct 2009 19:59:06 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Blaise Gassend <blaise@...lowgarage.com>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Jeremy Leibs <leibs@...lowgarage.com>,
	Darren Hart <dvhltc@...ibm.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: ERESTARTSYS escaping from sem_wait with RTLinux patch

Blaise,

On Sat, 10 Oct 2009, Blaise Gassend wrote:
> 1) Where is the ERESTARTSYS being prevented from getting to user space? 
> 
> The only likely place I see for preventing ERESTARTSYS from escaping to
> user space is in arch/*/kernel/signal*.c. However, I don't see how the
> code there is being called if there no signal pending. Is that a path
> for ERESTARTSYS to escape from the kernel?
> 
> The following comment in kernel/futex.h in futex_wait makes me wonder if
> two threads are getting marked as ERESTARTSYS. The first one to leave
> the kernel processes the signal and restarts. The second one doesn't
> have a signal to handle, so it returns to user space without getting
> into signal*.c and wreaks havoc.
> 
>     (...)
>         /*
>          * We expect signal_pending(current), but another thread may
>          * have handled it for us already.
>          */
>         if (!abs_time)
>                 return -ERESTARTSYS;
>     (...)

If the task is woken by a signal, then the task private flag
TIF_SIGPENDING is set, but in case of a process wide signal the signal
might have been handled by another thread of the same process before
that thread reaches the signal handling code, but then ERESTARTSYS is
handled gracefully. So you seem to trigger a code path which does not
go through do_signal.

> 2) Why would this be happening only with RT kernels?

Slightly different timing and locking semantics.

> 3) Any suggestions on the best place to patch/workaround this? 
> 
> My understanding is that if I was to treat ERESTARTSYS as an EAGAIN,
> most applications would be perfectly happy. Would bad things happen if I
> replaced the ERESTARTSYS in futex_wait with an EAGAIN?

No workarounds please. We really want to know what's wrong.

Two things to look at:

1) Does that happen with 2.6.31.2-rt13 as well ?

2) Add a check to the code path where ERESTARTSYS is returned:

   if (!signal_pending(current))
      printk(KERN_ERR "....."); 

If you can see that message then we'll look further. I'll give your
script a test ride on my systems as well.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/