From: Christian Brauner <christian@brauner.io>
To: Oleg Nesterov <oleg@redhat.com>
Cc: linux-kernel@vger.kernel.org, ebiederm@xmission.com,
gregkh@linuxfoundation.org, mingo@kernel.org,
james.morris@microsoft.com, keescook@chromium.org,
peterz@infradead.org, sds@tycho.nsa.gov, viro@zeniv.linux.org.uk,
akpm@linux-foundation.org
Subject: Re: [PATCH v1 06/20] signal: drop else branch in do_signal_stop()
Date: Tue, 29 May 2018 17:06:59 +0200 [thread overview]
Message-ID: <20180529150658.GA28029@gmail.com> (raw)
In-Reply-To: <20180529143039.GA1802@redhat.com>
On Tue, May 29, 2018 at 04:30:40PM +0200, Oleg Nesterov wrote:
> I am busy now, can't review, just picked a random patch from this series...
>
> On 05/28, Christian Brauner wrote:
> > do_signal_stop() already returns in the if branch so there's no need to
> > keep the else branch around.
>
> OK, but for what???
Yes to both.
>
> Do you think this change makes the code more readable? more clean? or what?
>
> I do not really care but to me these "if/else" branches make this code more
> symmetrical, so I don't understand the purpose.
The pattern where both the if and the else branch return is fairly
uncommon even in this file. Otherwise you would need to also argue that
functions like:
int send_sig_info(int sig, struct siginfo *info, struct task_struct *p)
{
/*
* Make sure legacy kernel users don't send in bad values
* (normal paths check this in check_kill_permission).
*/
if (!valid_signal(sig))
return -EINVAL;
return do_send_sig_info(sig, info, p, false);
}
should really be:
int send_sig_info(int sig, struct siginfo *info, struct task_struct *p)
{
/*
* Make sure legacy kernel users don't send in bad values
* (normal paths check this in check_kill_permission).
*/
if (!valid_signal(sig))
return -EINVAL;
else
return do_send_sig_info(sig, info, p, false);
}
Which I find very uneasy on the eye. Even more so when there are
multiple lines in the else that returns.
Christian
>
>
>
> > Signed-off-by: Christian Brauner <christian@brauner.io>
> > ---
> > v0->v1:
> > * patch unchanged
> > ---
> > kernel/signal.c | 14 +++++++-------
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/signal.c b/kernel/signal.c
> > index a628b56415e6..d1914439f144 100644
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -2214,14 +2214,14 @@ static bool do_signal_stop(int signr)
> > /* Now we don't run again until woken by SIGCONT or SIGKILL */
> > freezable_schedule();
> > return true;
> > - } else {
> > - /*
> > - * While ptraced, group stop is handled by STOP trap.
> > - * Schedule it and let the caller deal with it.
> > - */
> > - task_set_jobctl_pending(current, JOBCTL_TRAP_STOP);
> > - return false;
> > }
> > +
> > + /*
> > + * While ptraced, group stop is handled by STOP trap.
> > + * Schedule it and let the caller deal with it.
> > + */
> > + task_set_jobctl_pending(current, JOBCTL_TRAP_STOP);
> > + return false;
> > }
> >
> > /**
> > --
> > 2.17.0
> >
>
next prev parent reply other threads:[~2018-05-29 15:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-28 21:53 [PATCH v1 00/20] signal: refactor some functions Christian Brauner
2018-05-28 21:53 ` [PATCH v1 01/20] signal: make force_sigsegv() void Christian Brauner
2018-05-28 21:53 ` [PATCH v1 02/20] signal: make kill_as_cred_perm() return bool Christian Brauner
2018-05-28 21:53 ` [PATCH v1 03/20] signal: make may_ptrace_stop() " Christian Brauner
2018-05-28 21:53 ` [PATCH v1 04/20] signal: add copy_pending() helper Christian Brauner
2018-05-29 12:24 ` Eric W. Biederman
2018-05-29 12:41 ` Christian Brauner
2018-05-29 13:44 ` Eric W. Biederman
2018-05-29 13:55 ` Christian Brauner
2018-05-28 21:53 ` [PATCH v1 05/20] signal: flatten do_send_sig_info() Christian Brauner
2018-05-29 12:28 ` Eric W. Biederman
2018-05-29 12:38 ` Christian Brauner
2018-05-30 20:31 ` Eric W. Biederman
2018-05-28 21:53 ` [PATCH v1 06/20] signal: drop else branch in do_signal_stop() Christian Brauner
2018-05-29 14:30 ` Oleg Nesterov
2018-05-29 15:06 ` Christian Brauner [this message]
2018-05-28 21:53 ` [PATCH v1 07/20] signal: make do_sigpending() void Christian Brauner
2018-05-28 21:53 ` [PATCH v1 08/20] signal: simplify rt_sigaction() Christian Brauner
2018-05-28 21:53 ` [PATCH v1 09/20] signal: make kill_ok_by_cred() return bool Christian Brauner
2018-05-28 21:53 ` [PATCH v1 10/20] signal: make sig_handler_ignored() " Christian Brauner
2018-05-28 21:53 ` [PATCH v1 11/20] signal: make sig_task_ignored() " Christian Brauner
2018-05-28 21:53 ` [PATCH v1 12/20] signal: make sig_ignored() " Christian Brauner
2018-05-28 21:53 ` [PATCH v1 13/20] signal: make has_pending_signals() " Christian Brauner
2018-05-28 21:53 ` [PATCH v1 14/20] signal: make recalc_sigpending_tsk() " Christian Brauner
2018-05-28 21:53 ` [PATCH v1 15/20] signal: make unhandled_signal() " Christian Brauner
2018-05-28 21:53 ` [PATCH v1 16/20] signal: make flush_sigqueue_mask() void Christian Brauner
2018-05-28 21:53 ` [PATCH v1 17/20] signal: make wants_signal() return bool Christian Brauner
2018-05-28 21:53 ` [PATCH v1 18/20] signal: make legacy_queue() " Christian Brauner
2018-05-28 21:53 ` [PATCH v1 19/20] signal: make security_task_kill() " Christian Brauner
2018-05-28 21:53 ` [PATCH v1 20/20] signal: make get_signal() " Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180529150658.GA28029@gmail.com \
--to=christian@brauner.io \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=james.morris@microsoft.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=sds@tycho.nsa.gov \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox