From: Casey Dahlin <cdahlin@redhat.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
Scott James Remnant <scott@netsplit.com>
Subject: Re: [RFC PATCH] waitfd: file descriptor to wait on child processes
Date: Tue, 09 Dec 2008 15:09:41 -0500 [thread overview]
Message-ID: <493ED085.9010701@redhat.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0812091127160.17144@alien.or.mcafeemobile.com>
Davide Libenzi wrote:
> On Tue, 9 Dec 2008, Casey Dahlin wrote:
>
>
>> This is essentially my first kernel patch, so be nice :)
>>
>> Linux already has signalfd, timerfd, and eventfd to expose signals, timers,
>> and events via a file descriptor. This patch is a working prototype for a
>> fourth: waitfd. It pretty much does what the name suggests: reading from it
>> yields a series of status ints (as would be written into the second argument
>> of waitpid) for child processes that have changed state. It takes essentially
>> the same arguments as waitpid (for now) and supports the same set of features.
>>
>> This is far from ready for merge. Some things that are wrong with it:
>> * Waitpid's argument scheme probably isn't the best for this. By default it
>> makes it easiest to wait on a single child, which is not often useful in this
>> case. Waiting on all children or children in a particular process group is
>> possible, but not a particular, explicit set of children, which we probably
>> want (and which will complicate the implementation significantly).
>> * The prototype for peek_waitpid is obviously in the wrong place, but I
>> haven't found a good home for it.
>> * Waitid's semantics have slightly altered: passing NULL as the pointer to
>> siginfo_t with WNOWAIT will now return successfully instead of throwing
>> EFAULT. I don't know if that means I broke it or fixed it :)
>> * peek_waitpid may not be required at all now. I can probably trick sys_wait4
>> or sys_waitid into giving me what I want (or I could always just make do_wait
>> non-static).
>>
>> Please provide thoughts.
>>
>
> What's wrong in having a signalfd on SIGCHLD, than doing waitpid() once
> you get the signal? Do you have cases where this wouldn't be OK?
>
When the child doesn't send SIGCHLD (clone() lets you do evil things :)
Seriously though, that may be an option. Scott (CC'd ) is primarily the
consumer of this, so he can better comment.
> About the code, eventually, you really want to report the PID of the
> exited child, together with the status. So maybe a non-compat-requiring
> struct would be better to be returned by read(2).
> Also ...
>
>
>
>
>
>> +static unsigned int waitfd_poll(struct file *file, poll_table *wait)
>> +{
>> + struct waitfd_ctx *ctx = file->private_data;
>> + long value;
>> +
>> + poll_wait(file, ¤t->signal->wait_chldexit, wait);
>> +
>> + value = peek_waitpid(ctx->upid, ctx->ops);
>> + if (value > 0) {
>> + return POLLIN;
>> + } if (value == -ECHILD) {
>> + return POLLIN;
>> + }
>>
>
> Trust the compiler, it's pretty good in not having you to add Perl-like
> extra brackets ;)
> This also looks wierd:
>
> } if (value == -ECHILD) {
>
> So maybe:
>
> return value > 0 || value == -ECHILD ? POLLIN: 0;
>
>
>
Yeah, I ripped this up because during debugging poll was behaving oddly,
and I had been instrumenting the code with printks. It can go back to
being 1 line now.
>
>
>
>> +/*
>> + * Returns a multiple of the size of a "struct waitfd_siginfo", or a negative
>> + * error code. The "count" parameter must be at least the size of a
>> + * "struct waitfd_siginfo".
>> + */
>>
>
> Really? ...
>
>
>
Wow... and I read this patch before I sent it, too *facepalm*
The function did briefly return a siginfo_t (I implemented on top of
waitid first).
>
>> +static ssize_t waitfd_read(struct file *file, char __user *buf, size_t count,
>> + loff_t *ppos)
>> +{
>> + struct waitfd_ctx *ctx = file->private_data;
>> + int __user *stat_addr = (int *)buf;
>> + int nonblock = file->f_flags & O_NONBLOCK ? WNOHANG: 0;
>> + ssize_t ret, total = 0;
>> +
>> + count /= sizeof(int);
>> + if (!count)
>> + return -EINVAL;
>> +
>> + do {
>> + ret = sys_wait4(ctx->upid, stat_addr, ctx->ops | nonblock,
>> + NULL);
>> + if (ret == 0)
>> + ret = -EAGAIN;
>> + if (ret == -ECHILD)
>> + ret = 0;
>> + if (ret <= 0)
>> + break;
>> +
>> + stat_addr++;
>> + total += sizeof(struct siginfo);
>> + nonblock = WNOHANG;
>> + } while (--count);
>> +
>> + return total ? total: ret;
>> +}
>>
>
> ... looks like you're returning a sequence of status ints, with wrong data
> size returned by read(2).
>
>
>
More leftovers from above.
>
>
>> +
>> +static const struct file_operations waitfd_fops = {
>> + .release = waitfd_release,
>> + .poll = waitfd_poll,
>> + .read = waitfd_read,
>> +};
>> +
>> +asmlinkage long sys_waitfd(pid_t upid, int ops)
>>
>
> Please leave space for extra flags for fds, otherwise Uli will have to
> make another sys_waitfd3().
>
>
>
ack'd.
>
>> +long peek_waitpid(pid_t upid, int options)
>> +{
>> + struct pid *pid = NULL;
>> + enum pid_type type;
>> + long ret;
>> +
>> + if (options & ~(WNOHANG|WUNTRACED|WCONTINUED|
>> + __WNOTHREAD|__WCLONE|__WALL))
>> + return -EINVAL;
>> +
>> + options |= WNOHANG | WNOWAIT;
>> +
>> + if (upid == -1)
>> + type = PIDTYPE_MAX;
>> + else if (upid < 0) {
>> + type = PIDTYPE_PGID;
>> + pid = find_get_pid(-upid);
>> + } else if (upid == 0) {
>> + type = PIDTYPE_PGID;
>> + pid = get_pid(task_pgrp(current));
>> + } else /* upid > 0 */ {
>> + type = PIDTYPE_PID;
>> + pid = find_get_pid(upid);
>> + }
>> +
>> + ret = do_wait(type, pid, options | WEXITED, NULL, NULL, NULL);
>> + put_pid(pid);
>> +
>> + /* avoid REGPARM breakage on x86: */
>> + asmlinkage_protect(4, ret, upid, options);
>> + return ret;
>> +}
>>
>
> Given that you blinded copied this from sys_wait4(), you may want to at
> least try to make sys_wait4() to re-use the new function.
>
Good idea.
> Also, your patch does not apply to latest Linus tree. Which one was the
> base?
>
>
This is the last commit before mine in my git repo:
commit f7a8db89c1f42e504bb12d2ae399cd96f755a7db
Merge: 6f84b4d... c49b9f2...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon Dec 8 19:52:43 2008 -0800
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
tproxy: fixe a possible read from an invalid location in the
socket match
zd1211rw: use unaligned safe memcmp() in-place of compare_ether_addr()
(...lots and lots of changes snipped...)
--CJD
next prev parent reply other threads:[~2008-12-09 20:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-09 17:00 [RFC PATCH] waitfd: file descriptor to wait on child processes Casey Dahlin
2008-12-09 17:05 ` Alan Cox
2008-12-09 17:12 ` Scott James Remnant
2008-12-09 18:46 ` Casey Dahlin
2008-12-09 19:04 ` Alan Cox
2008-12-09 19:21 ` Casey Dahlin
2008-12-09 19:41 ` Davide Libenzi
2008-12-09 20:09 ` Casey Dahlin [this message]
2008-12-12 23:28 ` Scott James Remnant
2008-12-13 4:29 ` Davide Libenzi
2008-12-13 8:43 ` Scott James Remnant
2008-12-13 18:39 ` Davide Libenzi
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=493ED085.9010701@redhat.com \
--to=cdahlin@redhat.com \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=scott@netsplit.com \
/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