Justin,
> > > Tags: upstream
> >
> > Any time you open a report like this you better make sure
> > that whatever you say holds against the latest upstream release.
> Do you mean of manpages?
Yes. I mean, if you open a report and immedaitely tag it
upstream like this, my assumption would be that you have
checked that report also applies against the latest
upstream release.
> > > It seems that the clone manpage is out of sync with the libc/kernel
> > > reality.
> > >
> > > In particular, the following succeeds,
> >
> > The preceding is nearly meaningless, because so vague. Succeeds
> > where?
> I write a program that called clone() and it didn't return -1 when the
> manpage suggested that it should have. If glibc passed it on to the
> kernel (which it apparently did, since it succeeded), then the kernel
> didn't return -1; otherwise glibc did.
>
> > What kernel?
> Linux andromeda 2.6.15-1-686 #2 Mon Mar 6 15:27:08 UTC 2006 i686
> GNU/Linux
>
> > > but the annotation says that it
> > > should not:
> > >
> > > CLONE_NEWNS|CLONE_FS
> This still seems to succeed when I do a syscall (without libc).
>
> > > CLONE_THREAD (because CLONE_SIGHAND is not set)
> > > CLONE_SIGHAND (because CLONE_VM is not set)
> But these now return -1 (when using the "syscall" mechanism; see
> below).
>
> > And how did you test or verify this? If it was with a program,
> > show me the complete clone() call.
>
> Originally, I was doing it the "libc" way:
>
> #include <sched.h>
> // #include <syscall.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <assert.h>
>
> int f(void *v)
> {
> assert(v==NULL);
> fprintf(stderr, "%s\n", __PRETTY_FUNCTION__);
> return 0;
> }
>
> int main()
> {
> char buf[1<<10];
> const int flags=CLONE_NEWNS|CLONE_FS;
>
> fprintf(stderr, "%s\n", __PRETTY_FUNCTION__);
> if (-1==clone(f, buf, flags, NULL)) {
> perror("clone");
> }
>
> exit(EXIT_SUCCESS);
> }
>
> But I finally got the "syscall" way to work, with the above updated
> results:
>
> #include <syscall.h>
> #include <asm/ldt.h>
> // bits/sched.h or linux/sched.h
> #include <errno.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <assert.h>
>
> int f(void *v)
> {
> assert(v==NULL);
> fprintf(stderr, "%s\n", __PRETTY_FUNCTION__);
> return 0;
> }
>
> _syscall5(int, clone, int, flags, void *, child_stack, int *,
> parent_tidptr, struct user_desc *, newtls, int *, child_tidptr);
>
> int main()
> {
> const int flags=0x0001ffff|0x00000200; /* CLONE_NEWNS|CLONE_FS; */
> // 0x00000800; /* CLONE_SIGHAND */
> // 0x00010000; /* CLONE_THREAD */
Why are you hard coding these constants? They are in sched.h.
If you had done that you would not have made the following blunder:
/usr/include/bits/sched.h:# define CLONE_NEWNS 0x00020000
> if (-1==clone(flags,0,0,0,0)) {
> perror("clone");
> }
>
> fprintf(stderr, "%s\n", __PRETTY_FUNCTION__);
> exit(EXIT_SUCCESS);
> }
>
> > > There is also mention of a "CLONE_DETACHED" flag which is not
> > > otherwise mentioned; (the header files indicate that it is ignored).
> >
> > Mention where? Please be precise.
> I'm terribly sorry but, although I had updated to manpages 2.25-3, the
> manpage was already opened with 2.22 or so; CLONE_DETACHED is no
> longer mentioned.
And as I say above, Id expect this report to apply against 2.29.
> > > Also, I can't follow the description of sys_clone, mostly because the
> > > prototype doesn't make sense. Instead of being a prototype of clone,
> > > it looks like it is just copied from the definition (somewhere).
> > > Doesn't it make more sense to include something like:
> > >
> > > clone(int flags, void *child_stack, int *parent_tidptr,
> > > struct user_desc *newtls, int *child_tidptr);
> >
> > No, because it is not prototyped in header files.
> > Thus either _syscall5() or syscall() is required.
> Okay.
>
> > > Instead of the stuff that some scary-looking macro in a burried
> > > header file that generates the definition? :)
> >
> > The people who find it scary probably don't need clone().
> >
> > Justin -- vague bug reports like this waste my time.
> Not my intent, of course.
It is not my aim to discourage you. Obviously you do quite a lot
of good work in man-pages...
> > (I may be wrong, but this bug report sounds "speculative" -- that
> > is, you don't really have much experience with clone().)
> This is true, I do not.
... but I don't want to spend time processing bug report which
are really about someone's learning process.
Best regards,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
