[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fs4ig23p.fsf@email.froward.int.ebiederm.org>
Date: Wed, 16 Aug 2023 15:32:26 -0500
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: David Laight <David.Laight@...LAB.COM>,
Petr Skocik <pskocik@...il.com>,
Kees Cook <keescook@...omium.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Marco Elver <elver@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] signal: Fix the error return of kill -1
Oleg Nesterov <oleg@...hat.com> writes:
> On 08/15, David Laight wrote:
>>
>> or maybe even:
>> } else {
>> struct task_struct * p;
>> int err;
>> ret = -ESRCH;
>>
>> for_each_process(p) {
>> if (task_pid_vnr(p) > 1 &&
>> !same_thread_group(p, current)) {
>> err = group_send_sig_info(sig, info, p,
>> PIDTYPE_MAX);
>> if (ret)
>> ret = err;
>
> Hmm, indeed ;)
>
> and "err" can be declared inside the loop.
We can't remove the success case, from my posted patch.
A signal is considered as successfully delivered if at least
one process receives it.
That is something the current code for kill -1 actually gets
wrong (but hides because it ignores -EPERM).
Otherwise yes I expect we can simplify the use of variables as
suggested.
Eric
Powered by blists - more mailing lists