From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756641AbbCSOdy (ORCPT ); Thu, 19 Mar 2015 10:33:54 -0400 Received: from mx2.parallels.com ([199.115.105.18]:50884 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752725AbbCSOdv (ORCPT ); Thu, 19 Mar 2015 10:33:51 -0400 Date: Thu, 19 Mar 2015 17:33:41 +0300 From: Vladimir Davydov To: Oleg Nesterov CC: , Andrew Morton , Richard Weinberger , "Paul E. McKenney" Subject: Re: [PATCH] signal: improve warning about using SI_TKILL in rt_[tg]sigqueueinfo Message-ID: <20150319143341.GG29416@esperanza> References: <1426758781-11746-1-git-send-email-vdavydov@parallels.com> <20150319130045.GA7201@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20150319130045.GA7201@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 19, 2015 at 02:00:46PM +0100, Oleg Nesterov wrote: > On 03/19, Vladimir Davydov wrote: > > > > Sending SI_TKILL from rt_[tg]sigqueueinfo was deprecated, so now we > > issue a warning on the first attempt of doing it. We use WARN_ON_ONCE, > > which is not informative and, what is worse, taints the kernel, making > > the trinity syscall fuzzer complain false-positively from time to time. > > > > This patch therefore substitutes the WARN_ON_ONCE with a pr_warn_once. > > Agreed. > > but perhaps we can simply remove this warning at all? We can, I suppose. Personally, I do not have any strong preference. The patch removing the warning is attached. --- From: Vladimir Davydov Subject: [PATCH] signal: remove warning about using SI_TKILL in rt_[tg]sigqueueinfo Sending SI_TKILL from rt_[tg]sigqueueinfo was deprecated, so now we issue a warning on the first attempt of doing it. We use WARN_ON_ONCE, which is not informative and, what is worse, taints the kernel, making the trinity syscall fuzzer complain false-positively from time to time. It does not look like we need this warning at all, because the behaviour changed quite a long time ago (2.6.39), and if an application relies on the old API, it gets EPERM anyway and can issue a warning by itself. So let us zap the warning in kernel. Signed-off-by: Vladimir Davydov diff --git a/kernel/signal.c b/kernel/signal.c index a390499943e4..d51c5ddd855c 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -2992,11 +2992,9 @@ static int do_rt_sigqueueinfo(pid_t pid, int sig, siginfo_t *info) * Nor can they impersonate a kill()/tgkill(), which adds source info. */ if ((info->si_code >= 0 || info->si_code == SI_TKILL) && - (task_pid_vnr(current) != pid)) { - /* We used to allow any < 0 si_code */ - WARN_ON_ONCE(info->si_code < 0); + (task_pid_vnr(current) != pid)) return -EPERM; - } + info->si_signo = sig; /* POSIX.1b doesn't mention process groups. */ @@ -3041,12 +3039,10 @@ static int do_rt_tgsigqueueinfo(pid_t tgid, pid_t pid, int sig, siginfo_t *info) /* Not even root can pretend to send signals from the kernel. * Nor can they impersonate a kill()/tgkill(), which adds source info. */ - if (((info->si_code >= 0 || info->si_code == SI_TKILL)) && - (task_pid_vnr(current) != pid)) { - /* We used to allow any < 0 si_code */ - WARN_ON_ONCE(info->si_code < 0); + if ((info->si_code >= 0 || info->si_code == SI_TKILL) && + (task_pid_vnr(current) != pid)) return -EPERM; - } + info->si_signo = sig; return do_send_specific(tgid, pid, sig, info);