All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Dowad <alexinbeijing@gmail.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, Rik van Riel <riel@redhat.com>,
	Vladimir Davydov <vdavydov@parallels.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Kees Cook <keescook@chromium.org>,
	Aaron Tomlin <atomlin@redhat.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] do_fork(): Rename 'stack_size' argument to reflect actual use
Date: Thu, 05 Mar 2015 13:18:25 +0200	[thread overview]
Message-ID: <54F83B81.5060003@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1503041505550.25790@chino.kir.corp.google.com>


On 05/03/15 01:07, David Rientjes wrote:
> On Wed, 4 Mar 2015, Alex Dowad wrote:
>
>> The 'stack_size' argument is never used to pass a stack size. It's only used when
>> forking a kernel thread, in which case it is an argument which should be passed
>> to the 'main' function which the kernel thread executes. Hence, rename it to
>> 'kthread_arg'.
>>
>> Signed-off-by: Alex Dowad <alexinbeijing@gmail.com>
>> ---
>>
>> Hi,
>>
>> Please have a look at this patch. If this is accepted, I have a series of patches
>> ready for a similar cleanup to all the arch-specific implementations of copy_thread()
>> (as suggested by Andrew Morton in a private e-mail).
>>
>> Thank you,
>> Alex Dowad
>>
>>   kernel/fork.c | 14 ++++++++------
>>   1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index cf65139..b38a2ae 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -1186,10 +1186,12 @@ init_task_pid(struct task_struct *task, enum pid_type type, struct pid *pid)
>>    * It copies the registers, and all the appropriate
>>    * parts of the process environment (as per the clone
>>    * flags). The actual kick-off is left to the caller.
>> + *
>> + * When copying a kernel thread, 'stack_start' is the function to run.
>>    */
>>   static struct task_struct *copy_process(unsigned long clone_flags,
>>   					unsigned long stack_start,
>> -					unsigned long stack_size,
>> +					unsigned long kthread_arg,
>>   					int __user *child_tidptr,
>>   					struct pid *pid,
>>   					int trace)
>> @@ -1401,7 +1403,7 @@ static struct task_struct *copy_process(unsigned long clone_flags,
>>   	retval = copy_io(clone_flags, p);
>>   	if (retval)
>>   		goto bad_fork_cleanup_namespaces;
>> -	retval = copy_thread(clone_flags, stack_start, stack_size, p);
>> +	retval = copy_thread(clone_flags, stack_start, kthread_arg, p);
>>   	if (retval)
>>   		goto bad_fork_cleanup_io;
>>   
>> @@ -1629,8 +1631,8 @@ struct task_struct *fork_idle(int cpu)
>>    * it and waits for it to finish using the VM if required.
>>    */
>>   long do_fork(unsigned long clone_flags,
>> -	      unsigned long stack_start,
>> -	      unsigned long stack_size,
>> +	      unsigned long stack_start, /* or function for kthread to run */
>> +	      unsigned long kthread_arg,
>>   	      int __user *parent_tidptr,
>>   	      int __user *child_tidptr)
>>   {
> Looks fine, but I'm not sure about commenting functional formals.  Since
> copy_process() and do_fork() can have formals with different meanings,
> then why not just rename them "arg1" and "arg2" respectively and then
> define in the comment above the function what the possible combinations
> are?

The second argument is *only* ever used for one thing: an argument 
passed to a kernel thread. That's why I would like to rename it to 
"kthread_arg". The previous argument (currently named "stack_start") is 
indeed used for 2 different things: a new stack pointer for a user 
thread, or a function to be executed by a kernel thread. Rather than 
"arg1", what would you think of something like "sp_or_fn", or "usp_or_fn"?

Thanks for your feedback!

>
>> @@ -1656,7 +1658,7 @@ long do_fork(unsigned long clone_flags,
>>   			trace = 0;
>>   	}
>>   
>> -	p = copy_process(clone_flags, stack_start, stack_size,
>> +	p = copy_process(clone_flags, stack_start, kthread_arg,
>>   			 child_tidptr, NULL, trace);
>>   	/*
>>   	 * Do this prior waking up the new thread - the thread pointer
>> @@ -1740,7 +1742,7 @@ SYSCALL_DEFINE5(clone, unsigned long, newsp, unsigned long, clone_flags,
>>   		 int, tls_val)
>>   #elif defined(CONFIG_CLONE_BACKWARDS3)
>>   SYSCALL_DEFINE6(clone, unsigned long, clone_flags, unsigned long, newsp,
>> -		int, stack_size,
>> +		int, ignored,
>>   		int __user *, parent_tidptr,
>>   		int __user *, child_tidptr,
>>   		int, tls_val)


  reply	other threads:[~2015-03-05 11:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04 12:40 [PATCH] do_fork(): Rename 'stack_size' argument to reflect actual use Alex Dowad
2015-03-04 20:45 ` Kees Cook
2015-03-04 23:07 ` David Rientjes
2015-03-05 11:18   ` Alex Dowad [this message]
2015-03-05 20:29     ` David Rientjes
2015-03-06  6:07       ` Alex Dowad

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=54F83B81.5060003@gmail.com \
    --to=alexinbeijing@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=atomlin@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=vdavydov@parallels.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.