All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gang <gang.chen@asianux.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kernel/pid.c: check pid whether be NULL in __change_pid()
Date: Wed, 09 Oct 2013 09:03:54 +0800	[thread overview]
Message-ID: <5254AB7A.4030204@asianux.com> (raw)
In-Reply-To: <20131008175625.GA32220@redhat.com>

On 10/09/2013 01:56 AM, Oleg Nesterov wrote:
> On 10/08, Chen Gang wrote:
>>
>> On 10/07/2013 08:43 PM, Oleg Nesterov wrote:
>>>
>>>> but still recommend to check it
>>>> in __change_pid() to let itself consistency.
>>>
>>> Why?
>>>
>>> Contrary, I think we should not hide the problem. If __change_pid() is
>>> called when task->pids[type].pid is already NULL there is something
>>> seriously wrong.
>>>
>>
>> Hmm... In my opinion, it means need BUG_ON() for original 'link->pid'.
>>
>> --------------------------------patch begin-----------------------------
>>
>> [PATCH] kernel/pid.c: add BUG_ON() for "!pid" in __change_pid()
>>
>>   Within __change_pid(), 'new' may be NULL if it comes from detach_pid(),
> 
> Yes, this is fine,
> 
>>   and 'link->pid' also may be NULL ("link->pid = new"),
>> ...
>>   the original 'link->pid' may be NULL, too.
> 
> Too? You mean, it becomes NULL after detach_pid().
> 
>>   But in real world, all related extern functions always assume "if
>>   'link->pid' is already NULL, there must be something seriously wrong",
>>   although __change_pid() can accept parameter 'new' as NULL.
> 
> I simply can't understand why you mix "new == NULL" and "link->pid == NULL".
> 
>>   So in __change_pid(), need add BUG_ON() for it: "it should not happen,
>>   when it really happen, OS must be continuing blindly,
> 
> OS will crash a couple of lines below trying to dereference this pointer.
> 
>> --- a/kernel/pid.c
>> +++ b/kernel/pid.c
>> @@ -396,6 +396,12 @@ static void __change_pid(struct task_struct *task, enum pid_type type,
>>  	link = &task->pids[type];
>>  	pid = link->pid;
>>
>> +	/*
>> +	 * If task->pids[type].pid is already NULL, there must be something
>> +	 * seriously wrong
>> +	 */
>> +	BUG_ON(!pid);
> 
> Following this logic you should also add
> 
> 	BUG_ON(!task);
> 	BUG_ON(!link->node.next);
> 	BUG_ON(!link->node.prev || link->node.prev == LIST_POISON2);
> 	...
> 
> Seriously, I do not understand the point. Yes, detach_pid() should not
> be called twice. And it has a single caller. And this caller will crash
> too if it is called twice. So you can also add BUG_ON() into
> __unhash_process(). And so on.
> 

In my opinion, for using BUG_ON(), it has 3 requirements:

 - OS is just continuing blindly.

 - next, will cause real issue (or need use WARN_ON instead of).

 - Can let the related code self consitency (or will add many wastes).


Your demo are match 2 requrements, but not match the 3rd one: "it is
reasonable to assume 'task', 'link', and 'link->node' are valid in
__change_pid()".

But for link->pid, the function name '__change_pid' tells us it is only
for changing pid, if 'new' can be NULL, 'link->pid' also can be NULL,
so the original 'link-pid' can be NULL, too.

So for self consistency, we also can change the function name from
'__change_pid' to another one (e.g. 'change_orig_valid_pid'), to let
itself consistency (so don't need BUG_ON)


The related patch is below, please check, thanks.

--------------------------------patch begin-----------------------------

kernel/pid.c: use 'change_orig_valid_pid' instead of '__change_pid' for function name

  For function name '__change_pid' is only for changing pid. In fact, it
  always assumes the original pid is valid, but new pid can be NULL, so
  recommend to use 'change_orig_valid_pid' instead of.

Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 kernel/pid.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/pid.c b/kernel/pid.c
index 9b9a266..408a3b5 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -386,7 +386,7 @@ void attach_pid(struct task_struct *task, enum pid_type type)
 	hlist_add_head_rcu(&link->node, &link->pid->tasks[type]);
 }
 
-static void __change_pid(struct task_struct *task, enum pid_type type,
+static void change_orig_valid_pid(struct task_struct *task, enum pid_type type,
 			struct pid *new)
 {
 	struct pid_link *link;
@@ -408,13 +408,13 @@ static void __change_pid(struct task_struct *task, enum pid_type type,
 
 void detach_pid(struct task_struct *task, enum pid_type type)
 {
-	__change_pid(task, type, NULL);
+	change_orig_valid_pid(task, type, NULL);
 }
 
 void change_pid(struct task_struct *task, enum pid_type type,
 		struct pid *pid)
 {
-	__change_pid(task, type, pid);
+	change_orig_valid_pid(task, type, pid);
 	attach_pid(task, type);
 }
 
-- 
1.7.7.6

--------------------------------patch end-------------------------------

Thanks.
-- 
Chen Gang

      reply	other threads:[~2013-10-09  1:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-07 10:29 [PATCH] kernel/pid.c: check pid whether be NULL in __change_pid() Chen Gang
2013-10-07 12:43 ` Oleg Nesterov
2013-10-07 21:53   ` Chen Gang
2013-10-08 17:56     ` Oleg Nesterov
2013-10-09  1:03       ` Chen Gang [this message]

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=5254AB7A.4030204@asianux.com \
    --to=gang.chen@asianux.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=serge.hallyn@canonical.com \
    --cc=serge@hallyn.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.