Re: [PATCH 2/2] signals: eventpoll: set ->saved_sigmask at thestart

[Oleg Nesterov]

On 06/25, Al Viro wrote:
>
> On Tue, Jun 25, 2013 at 09:57:59PM +0200, Oleg Nesterov wrote:
> > +		current->saved_sigmask = current->blocked;
> >  		set_current_blocked(&ksigmask);
> >  	}
> >  
> >  	error = sys_epoll_wait(epfd, events, maxevents, timeout);
> > -
> >  	/*
> >  	 * If we changed the signal mask, we need to restore the original one.
> >  	 * In case we've got a signal while waiting, we do not restore the
> > @@ -1988,12 +1988,10 @@ SYSCALL_DEFINE6(epoll_pwait, int, epfd, struct epoll_event __user *, events,
> >  	 * the way back to userspace, before the signal mask is restored.
> >  	 */
> >  	if (sigmask) {
> > -		if (error == -EINTR) {
> > -			memcpy(&current->saved_sigmask, &sigsaved,
> > -			       sizeof(sigsaved));
> > +		if (error == -EINTR)
> >  			set_restore_sigmask();
> > -		} else
> > -			set_current_blocked(&sigsaved);
> > +		else
> > +			__set_current_blocked(&current->saved_sigmask);
> 
> I don't like that.  If anything, we have
> static inline void restore_saved_sigmask(void)
> {
>         if (test_and_clear_restore_sigmask())
>                 __set_current_blocked(&current->saved_sigmask);
> }
> which means that the last part can be turned into
> 		set_restore_sigmask();
> 		if (error != -EINTR)
> 			restore_saved_sigmask();

set_restore_sigmask() does WARN_ON(!TIF_SIGPENDING).

> and I'd pulled set_restore_sigmask() call next to setting the sucker.

Sorry, can't understand...

Anyway, I agree we can make this more clean. From 0/2

	Perhaps it also makes sense to add the new helper which does
	copy_from_user + set saved_sigmask + set_current_blocked() ?

and perhaps we can add another helper which does set_restore_sigmask()
_or_ set_current_blocked(saved_sigmask), this can simplify more callers.
I think we can do this on top of this change.

Or I misunderstood and you dislike the very fact we rely on the already
initialized ->saved_sigmask ?

Oleg.

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