From: ebiederm@xmission.com (Eric W. Biederman)
To: Christoph Hellwig <hch@infradead.org>
Cc: Oleg Nesterov <oleg@tv-sign.ru>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] kill_something_info: misc cleanups
Date: Sun, 17 Dec 2006 04:22:48 -0700 [thread overview]
Message-ID: <m18xh6u5pz.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20061217101856.GA1285@infradead.org> (Christoph Hellwig's message of "Sun, 17 Dec 2006 10:18:56 +0000")
Christoph Hellwig <hch@infradead.org> writes:
> On Sat, Dec 16, 2006 at 11:05:10PM +0300, Oleg Nesterov wrote:
>> static int kill_something_info(int sig, struct siginfo *info, int pid)
>> {
>> int ret;
>> +
>> + rcu_read_lock();
>> + if (pid > 0) {
>> + ret = kill_pid_info(sig, info, find_pid(pid));
>> + } else if (pid == -1) {
>> + struct task_struct *p;
>> + int found = 0;
>> +
>> + ret = 0;
>> + read_lock(&tasklist_lock);
>> + for_each_process(p)
>> + if (!is_init(p) && p != current->group_leader) {
>> + int err = group_send_sig_info(sig, info, p);
>> + if (err != -EPERM)
>> + ret = err;
>> + found = 1;
>> + }
>> + read_unlock(&tasklist_lock);
>> + if (!found)
>> + ret = -ESRCH;
>
> This branch should probably be factored out into a helper of it's own:
The proper name would be something like kill_all_info(). As we are
talking about the group of all processes.
I am sitting here wondering why we bother to ignore init, as init
is protected from all signals it doesn't explicitly setup a signal
handler for. It is probably worth taking a quick look at the common
shutdown scripts and sysv init and see if anything actually cares if
we simply remove the is_init check.
The only two signals I know that are commonly handled this way
are kill(-1, SIGTERM) and kill(-1, SIGKILL);
And a very quick look at sysvinit-2.86 shows that it doesn't setup a
handler for SIGTERM. So I believe we can delete we can delete
the is_init check entirely without changing anything and with a less
surprising if anyone ever cares.
>> + } else {
>> + struct pid *grp = task_pgrp(current);
>> + if (pid != 0)
>> + grp = find_pid(-pid);
>> + ret = kill_pgrp_info(sig, info, grp);
>> + }
>
> This also looks rather unreadable, an
>
> } else if (pid) {
> ret = kill_pgrp_info(sig, info, find_pid(-pid));
> } else {
> ret = kill_pgrp_info(sig, info, task_pgrp(current));
> }
>
> might be slightly more code, but also a lot more readable.
And that part is basically what we have now, just reshuffled.
Eric
next prev parent reply other threads:[~2006-12-17 11:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-16 20:05 Oleg Nesterov
2006-12-16 23:10 ` Eric W. Biederman
2006-12-17 0:37 ` Oleg Nesterov
2006-12-17 1:09 ` Eric W. Biederman
2006-12-17 10:18 ` Christoph Hellwig
2006-12-17 11:22 ` Eric W. Biederman [this message]
2006-12-17 14:40 ` Oleg Nesterov
2006-12-18 13:09 ` Eric W. Biederman
2006-12-18 21:24 ` Oleg Nesterov
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=m18xh6u5pz.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
/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
all inboxes | Powered by JetHome®