wait4/waitpid/waitid oddness

wait4/waitpid/waitid oddness

[Albert Cahalan]

The kernel prohibits:

1. WNOHANG on waitpid/wait4
2. __WALL on waitid

Why? I need both at once.

Re: wait4/waitpid/waitid oddness

[Joshua Hudson]

On 4/5/06, Albert Cahalan <acahalan@gmail.com> wrote:
> The kernel prohibits:
>
> 1. WNOHANG on waitpid/wait4
> 2. __WALL on waitid
>
> Why? I need both at once.

Why don't you try removing the checks and see if anything breaks. My instinct
says that waitid is less likely to break.

I'm the guy who removed the check in link() about source is a directory, found
out what broke, and am working on a patch to fix all the resulting breakage.
Your task is apt to be a lot simpler.

Re: wait4/waitpid/waitid oddness

[Kyle Moffett]

On Apr 6, 2006, at 22:09:48, Joshua Hudson wrote:
> I'm the guy who removed the check in link() about source is a  
> directory, found out what broke, and am working on a patch to fix  
> all the resulting breakage.  Your task is apt to be a lot simpler.

I seem to recall the reason why hardlinking directories was  
prohibited had something more to do with some unfixable races and  
deadlocks in the kernel; not to mention creating self-referential  
directory trees that are never freed and chew up disk space.

Cheers,
Kyle Moffett

Re: wait4/waitpid/waitid oddness

[Joshua Hudson]

On 4/6/06, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> On Apr 6, 2006, at 22:09:48, Joshua Hudson wrote:
> > I'm the guy who removed the check in link() about source is a
> > directory, found out what broke, and am working on a patch to fix
> > all the resulting breakage.  Your task is apt to be a lot simpler.
>
> I seem to recall the reason why hardlinking directories was
> prohibited had something more to do with some unfixable races and
> deadlocks in the kernel; not to mention creating self-referential
> directory trees that are never freed and chew up disk space.

You recall correctly. I have fixed the self-referrential problem, and I
am testing a fix for the races and deadlocks. Desk proof is not good
enough for me.

Re: wait4/waitpid/waitid oddness

[Neil Brown]

On Thursday April 6, joshudson@gmail.com wrote:
> On 4/6/06, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> > On Apr 6, 2006, at 22:09:48, Joshua Hudson wrote:
> > > I'm the guy who removed the check in link() about source is a
> > > directory, found out what broke, and am working on a patch to fix
> > > all the resulting breakage.  Your task is apt to be a lot simpler.
> >
> > I seem to recall the reason why hardlinking directories was
> > prohibited had something more to do with some unfixable races and
> > deadlocks in the kernel; not to mention creating self-referential
> > directory trees that are never freed and chew up disk space.
> 
> You recall correctly. I have fixed the self-referrential problem, and I
> am testing a fix for the races and deadlocks. Desk proof is not good
> enough for me.

I wonder what you are doing about the conceptual problem of 
  What does ".." mean now?

NeilBrown

Re: wait4/waitpid/waitid oddness

[Joshua Hudson]

> I wonder what you are doing about the conceptual problem of
>   What does ".." mean now?
>
> NeilBrown
dnode->d_parent.

Re: wait4/waitpid/waitid oddness

[Eric W. Biederman]

"Albert Cahalan" <acahalan@gmail.com> writes:

> The kernel prohibits:
>
> 1. WNOHANG on waitpid/wait4

Not 2.6.17-rc1, and not for a lot of earlier kernels.
At least not on ingress, and just skimming the code
I can't see any deeper checks that would prevent this.

> 2. __WALL on waitid
>
> Why? I need both at once.

Which kernel is failing, and how?

Eric

Re: wait4/waitpid/waitid oddness

[Joshua Hudson]

On 4/7/06, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Albert Cahalan" <acahalan@gmail.com> writes:
>
> > The kernel prohibits:
> >
> > 1. WNOHANG on waitpid/wait4
>
> Not 2.6.17-rc1, and not for a lot of earlier kernels.
> At least not on ingress, and just skimming the code
> I can't see any deeper checks that would prevent this.
>
> > 2. __WALL on waitid
> >
> > Why? I need both at once.
>
> Which kernel is failing, and how?

LKNL 2.6.16.1 has this check. Haven't checked any others.

Re: wait4/waitpid/waitid oddness

[Eric W. Biederman]

"Joshua Hudson" <joshudson@gmail.com> writes:

> On 4/7/06, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> "Albert Cahalan" <acahalan@gmail.com> writes:
>>
>> > The kernel prohibits:
>> >
>> > 1. WNOHANG on waitpid/wait4
>>
>> Not 2.6.17-rc1, and not for a lot of earlier kernels.
>> At least not on ingress, and just skimming the code
>> I can't see any deeper checks that would prevent this.
>>
>> > 2. __WALL on waitid
>> >
>> > Why? I need both at once.
>>
>> Which kernel is failing, and how?
>
> LKNL 2.6.16.1 has this check. Haven't checked any others.

So what I see current in wait4 is:
> asmlinkage long sys_wait4(pid_t pid, int __user *stat_addr,
> 			  int options, struct rusage __user *ru)
> {
> 	long ret;
> 
> 	if (options & ~(WNOHANG|WUNTRACED|WCONTINUED|
> 			__WNOTHREAD|__WCLONE|__WALL))
> 		return -EINVAL;

This denies access if you use other flags but it should allow
__WALL and WNOHANG together.  I didn't see anything in do_wait,
that would prohibit this.

> 	ret = do_wait(pid, options | WEXITED, NULL, stat_addr, ru);
> 
> 	/* avoid REGPARM breakage on x86: */
> 	prevent_tail_call(ret);
> 	return ret;
> }

So where are you seeing the check in 2.6.16.1?

Eric

Re: wait4/waitpid/waitid oddness

[Joshua Hudson]

> So what I see current in wait4 is:
> > asmlinkage long sys_wait4(pid_t pid, int __user *stat_addr,
> >                         int options, struct rusage __user *ru)
> > {
> >       long ret;
> >
> >       if (options & ~(WNOHANG|WUNTRACED|WCONTINUED|
> >                       __WNOTHREAD|__WCLONE|__WALL))
> >               return -EINVAL;
>
> So where are you seeing the check in 2.6.16.1?
>
> Eric
Stupid me. I read that w/o the tilde.