From: Dave Hansen <haveblue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Cc: Linux Containers
<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH] An attempt to have an unlimitedly extendable sys_clone
Date: Tue, 15 Jan 2008 09:54:20 -0800 [thread overview]
Message-ID: <1200419660.22674.68.camel@localhost> (raw)
In-Reply-To: <478CAC32.4080809-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
On Tue, 2008-01-15 at 15:50 +0300, Pavel Emelyanov wrote:
> +static struct long_clone_arg *get_long_clone_arg(int __user
> *child_tidptr)
> +{
> + int size;
> + struct long_clone_arg *carg;
> +
> + if (get_user(size, child_tidptr))
> + return ERR_PTR(-EFAULT);
> +
> + if (size > sizeof(struct long_clone_arg))
> + return ERR_PTR(-EINVAL);
This little bit means that any newer app (with a large
long_clone_arg->size) trying to run on an older kernel (with a smaller
struct) would simply fail to run clone(). Perhaps it shouldn't be _so_
generic as to allow anything in the struct and should stick to bits.
That way, we can actually go look to see whether there are any _unknown_
bits set just like we do now with clone flags.
The more I think about this, the more nervous I get about it. It is
really neat, but has a bit of the stink of ioctl()s on it. I'd
personally rather see a new system call.
But, this seems like a good Linus question. Want to keep us on cc, but
run it by him (and the rest of LKML)?
-- Dave
next prev parent reply other threads:[~2008-01-15 17:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-15 12:50 [PATCH] An attempt to have an unlimitedly extendable sys_clone Pavel Emelyanov
[not found] ` <478CAC32.4080809-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-01-15 13:38 ` Cedric Le Goater
[not found] ` <478CB73E.30603-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-01-15 14:48 ` Cedric Le Goater
[not found] ` <478CC7AD.7060908-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-01-15 21:40 ` Serge E. Hallyn
2008-01-16 7:39 ` Pavel Emelyanov
[not found] ` <478DB4CC.1090102-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-01-16 8:15 ` Cedric Le Goater
2008-01-21 10:36 ` Cedric Le Goater
2008-01-15 13:52 ` Cedric Le Goater
2008-01-15 14:34 ` Daniel Hokka Zakrisson
2008-01-15 21:46 ` Serge E. Hallyn
2008-01-16 7:26 ` Pavel Emelyanov
[not found] ` <478DB1AC.6050508-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-01-16 7:58 ` Daniel Hokka Zakrisson
2008-01-16 8:07 ` Daniel Hokka Zakrisson
2008-01-16 8:09 ` Pavel Emelyanov
2008-01-16 17:52 ` Dave Hansen
2008-01-15 15:17 ` Oren Laadan
[not found] ` <478CCE81.5090605-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-01-15 15:56 ` Cedric Le Goater
2008-01-16 7:37 ` Pavel Emelyanov
2008-01-15 17:54 ` Dave Hansen [this message]
2008-01-15 21:32 ` Serge E. Hallyn
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=1200419660.22674.68.camel@localhost \
--to=haveblue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
/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