On Tue, Jan 23, 2007 at 09:59:26PM -0800, David Miller wrote: > From: Neil Horman <[EMAIL PROTECTED]> > Date: Tue, 16 Jan 2007 15:13:32 -0500 > > > As it is currently written, sys_select checks its return code to convert > > ERESTARTNOHAND to EINTR. However, the check is within an if (tvp) clause, > > and > > so if select is called from userspace with a NULL timeval, then it is > > possible > > for the ERESTARTNOHAND errno to leak into userspace, which is incorrect. > > This > > patch moves that check outside of the conditional, and prevents the errno > > leak. > > > > Signed-Off-By: Neil Horman <[EMAIL PROTECTED]> > > As has been probably mentioned, this change is bogus. > > core_sys_select() returns -ERESTARTNOHAND in exactly the > case where that return value is legal, when a signal is > pending, so that the signal dispatch code (on return from > the system call) will "fixup" the -ERESTARTNOHAND return > value so that userspace does not see it. > > What could be happening is that, somehow, we see the signal > pending in core_sys_select(), but for some reason by the time > the signal dispatch code would run, the signal is cleared. > > I always found this scheme a little fishy, relying on signal > pending state to guarentee the fixup of the syscall restart > error return values. > > For example, I see nothing that prevents another thread sharing > this signal state from clearing the signal between the syscall > checking in the other thread and the signal dispatch check running > in that other thread. > > cpu 1 cpu 2 > check sigpending > clear signal > syscall return > no signal panding > get -ERESTARTNOHAND > > Perhaps something makes this no happen, but I don't see it :) This is exactly the theory that I've been tossing around with the person that reported it to me. We're still witing on a reproduer, but I'm currently working on a multithreaded test case to try and trigger user space leaks of ERESTARTNOHAND to user space.
Neil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
