From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753968AbbKQOFn (ORCPT ); Tue, 17 Nov 2015 09:05:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44366 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754049AbbKQOEh (ORCPT ); Tue, 17 Nov 2015 09:04:37 -0500 Date: Tue, 17 Nov 2015 16:00:35 +0100 From: Oleg Nesterov To: Richard Weinberger Cc: linux-kernel@vger.kernel.org, vegard.nossum@oracle.com, akpm@linux-foundation.org, amanieu@gmail.com, dave@stgolabs.net, qiaowei.ren@intel.com, luto@amacapital.net, palmer@dabbelt.com, vdavydov@parallels.com Subject: Re: [PATCH] signal: Unexport sigsuspend() Message-ID: <20151117150035.GB5489@redhat.com> References: <1447697901-28918-1-git-send-email-richard@nod.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1447697901-28918-1-git-send-email-richard@nod.at> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/16, Richard Weinberger wrote: > > sigsuspend() is nowhere used except in signal.c itself, > so we can mark it static do not pollute the global namespace. > > But this patch is more than a boring cleanup patch, > it fixes a real issue on UserModeLinux. > UML has a special console driver to display ttys using xterm, > or other terminal emulators, on the host side. > Vegard reported that sometimes UML is unable to spawn a xterm > and he's facing the following warning: > WARNING: CPU: 0 PID: 908 at include/linux/thread_info.h:128 sigsuspend+0xab/0xc0() > It turned out that this warning makes absolutely no sense as > the UML xterm code calls sigsuspend() on the host side, at least it tries. > But as the kernel itself offers a sigsuspend() symbol the linker choose > this one instead of the glibc wrapper. Interestingly this code used to > work since ever but always blocked signals on the wrong side. > Some recent kernel change made the WARN_ON() trigger and uncovered the bug. > > It is a wonderful example of how much works by chance on computers. :-) You know, initially I didn't bother to read the changelog, I was going to nack this change because git-grep reports that sigsuspend() is called by arch/um/drivers/chan_user.c ;) > Reported-and-tested-by: Vegard Nossum > Signed-off-by: Richard Weinberger Acked-by: Oleg Nesterov > --- > include/linux/signal.h | 1 - > kernel/signal.c | 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/include/linux/signal.h b/include/linux/signal.h > index ab1e039..92557bb 100644 > --- a/include/linux/signal.h > +++ b/include/linux/signal.h > @@ -239,7 +239,6 @@ extern int sigprocmask(int, sigset_t *, sigset_t *); > extern void set_current_blocked(sigset_t *); > extern void __set_current_blocked(const sigset_t *); > extern int show_unhandled_signals; > -extern int sigsuspend(sigset_t *); > > struct sigaction { > #ifndef __ARCH_HAS_IRIX_SIGACTION > diff --git a/kernel/signal.c b/kernel/signal.c > index c0b01fe..f3f1f7a 100644 > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -3503,7 +3503,7 @@ SYSCALL_DEFINE0(pause) > > #endif > > -int sigsuspend(sigset_t *set) > +static int sigsuspend(sigset_t *set) > { > current->saved_sigmask = current->blocked; > set_current_blocked(set); > -- > 2.5.0 >