linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: christofferdall@christofferdall.dk (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [C/R ARM][PATCH 2/3] ARM: Add the eclone system call
Date: Wed, 24 Mar 2010 20:42:41 +0100	[thread overview]
Message-ID: <7d08b87d1003241242k62cd125ex4b0fa0e24879fddb@mail.gmail.com> (raw)
In-Reply-To: <20100323210616.GB19572@n2100.arm.linux.org.uk>

On Tue, Mar 23, 2010 at 10:06 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sun, Mar 21, 2010 at 09:06:04PM -0400, Christoffer Dall wrote:
>> In addition to doing everything that clone() system call does, the
>> eclone() system call:
>
> Some comments...
>
>> +sys_eclone_wrapper:
>> + ? ? ? ? ? ? add ? ? ip, sp, #S_OFF
>> + ? ? ? ? ? ? str ? ? ip, [sp, #0]
>> + ? ? ? ? ? ? b ? ? ? sys_eclone
>> +ENDPROC(sys_eclone_wrapper)
>
> I'm curious why, if you want the entire set of registers, you don't just
> do:
> ? ? ? ? ? ? ? ?add ? ? r0, sp, #S_OFF
> ? ? ? ? ? ? ? ?b ? ? ? sys_eclone
>
> and load the syscall arguments out of regs->ARM_foo. ?This avoids the need
> for additional stores.
>

I simply copied the code from sys_clone. Do you prefer that I change
it in both places?

>> +
>> ?sys_sigreturn_wrapper:
>> ? ? ? ? ? ? ? add ? ? r0, sp, #S_OFF
>> ? ? ? ? ? ? ? b ? ? ? sys_sigreturn
>> diff --git a/arch/arm/kernel/sys_arm.c b/arch/arm/kernel/sys_arm.c
>> index ae4027b..fd8199d 100644
>> --- a/arch/arm/kernel/sys_arm.c
>> +++ b/arch/arm/kernel/sys_arm.c
>> @@ -183,6 +183,45 @@ asmlinkage int sys_clone(unsigned long clone_flags, unsigned long newsp,
>> ? ? ? return do_fork(clone_flags, newsp, regs, 0, parent_tidptr, child_tidptr);
>> ?}
>>
>> +asmlinkage int sys_eclone(unsigned flags_low, struct clone_args __user *uca,
>> + ? ? ? ? ? ? ? ? ? ? ? int args_size, pid_t __user *pids,
>> + ? ? ? ? ? ? ? ? ? ? ? struct pt_regs *regs)
>> +{
>> + ? ? int rc;
>> + ? ? struct clone_args kca;
>> + ? ? unsigned long flags;
>> + ? ? int __user *parent_tidp;
>> + ? ? int __user *child_tidp;
>> + ? ? unsigned long __user stack;
>
> __user on an integer type doesn't make any sense; integer types do not
> have address spaces.
>

thanks, will follow Sukadev's changes...

>> + ? ? unsigned long stack_size;
>> +
>> + ? ? rc = fetch_clone_args_from_user(uca, args_size, &kca);
>> + ? ? if (rc)
>> + ? ? ? ? ? ? return rc;
>> +
>> + ? ? /*
>> + ? ? ?* TODO: Convert 'clone-flags' to 64-bits on all architectures.
>> + ? ? ?* TODO: When ->clone_flags_high is non-zero, copy it in to the
>> + ? ? ?* ? ? ? higher word(s) of 'flags':
>> + ? ? ?*
>> + ? ? ?* ? ? ? ? ? ? ?flags = (kca.clone_flags_high << 32) | flags_low;
>> + ? ? ?*/
>> + ? ? flags = flags_low;
>> + ? ? parent_tidp = (int *)(unsigned long)kca.parent_tid_ptr;
>> + ? ? child_tidp = (int *)(unsigned long)kca.child_tid_ptr;
>
> This will produce sparse errors. ?Is there a reason why 'clone_args'
> tid pointers aren't already pointers marked with __user ?
>
>> +
>> + ? ? stack_size = (unsigned long)kca.child_stack_size;
>
> Shouldn't this already be of integer type?
>
>> + ? ? if (stack_size)
>> + ? ? ? ? ? ? return -EINVAL;
>
> So the stack must have a zero size? ?Is this missing a '!' ?
>
>> +
>> + ? ? stack = (unsigned long)kca.child_stack;
>> + ? ? if (!stack)
>> + ? ? ? ? ? ? stack = regs->ARM_sp;
>> +
>> + ? ? return do_fork_with_pids(flags, stack, regs, stack_size, parent_tidp,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? child_tidp, kca.nr_pids, pids);
>
> Hmm, so let me get this syscall interface right. ?We have some arguments
> passed in registers and others via a (variable sized?) structure. ?It seems
> really weird to have, eg, a pointer to the pids and the number of pids
> passed in two separate ways.
>
> The grouping between what's passed in registers and via this clone_args
> structure seems to be random. ?Can it be sanitized?
>

Thanks for you feedback. I will let the people behind eclone deal with
the eclone specifics.

  parent reply	other threads:[~2010-03-24 19:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-22  1:06 [C/R ARM][PATCH 0/3] Linux Checkpoint-Restart - ARM port Christoffer Dall
2010-03-22  1:06 ` [C/R ARM][PATCH 1/3] ARM: Rudimentary syscall interfaces Christoffer Dall
2010-03-23 20:53   ` Russell King - ARM Linux
2010-03-24  2:03     ` Matt Helsley
2010-03-24  4:57       ` Oren Laadan
2010-03-24 14:02         ` Matt Helsley
2010-03-24 15:53           ` Oren Laadan
2010-03-24 19:36             ` Christoffer Dall
2010-03-25  1:11               ` Matt Helsley
2010-03-25  1:17                 ` Matt Helsley
2010-03-25 10:29                   ` Christoffer Dall
2010-03-25  1:35                 ` Oren Laadan
2010-03-25 10:34                   ` Christoffer Dall
2010-03-22  1:06 ` [C/R ARM][PATCH 2/3] ARM: Add the eclone system call Christoffer Dall
2010-03-23 21:06   ` Russell King - ARM Linux
2010-03-24 18:19     ` Sukadev Bhattiprolu
2010-03-24 19:42     ` Christoffer Dall [this message]
2010-03-22  1:06 ` [C/R ARM][PATCH 3/3] c/r: ARM implementation of checkpoint/restart Christoffer Dall
2010-03-23 16:09   ` Serge E. Hallyn
2010-03-24 19:46     ` Christoffer Dall
2010-03-23 21:18   ` Russell King - ARM Linux
2010-03-24  1:53     ` Matt Helsley
2010-03-24 20:48     ` Christoffer Dall
2010-03-26  2:47       ` Jamie Lokier
2010-03-26  3:02         ` Paul Mundt
2010-03-26  3:55           ` Jamie Lokier
2010-03-28 22:55           ` Christoffer Dall

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=7d08b87d1003241242k62cd125ex4b0fa0e24879fddb@mail.gmail.com \
    --to=christofferdall@christofferdall.dk \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).