mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: "David Wang 王标" <wangbiao3@xiaomi.com>,
	"Peter Zijlstra" <peterz@infradead.org>
Cc: "mingo@redhat.com" <mingo@redhat.com>,
	"juri.lelli@redhat.com" <juri.lelli@redhat.com>,
	"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
	"brauner@kernel.org" <brauner@kernel.org>,
	"bsegall@google.com" <bsegall@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"wenjieli@qti.qualcomm.com" <wenjieli@qti.qualcomm.com>,
	陈冠有 <chenguanyou@xiaomi.com>, "Will Deacon" <will@kernel.org>,
	"Ting11 Wang 王婷" <wangting11@xiaomi.com>
Subject: Re: 答复: [External Mail]Re: [PATCH 1/1] sched: fix user_mask double free
Date: Wed, 23 Nov 2022 22:59:38 -0500	[thread overview]
Message-ID: <0b50b719-b8df-decb-b6ed-12be8f623ad0@redhat.com> (raw)
In-Reply-To: <9cc51697705f472e99a620eee8569a32@xiaomi.com>

On 11/23/22 21:37, David Wang 王标 wrote:
>
> Dear Waiman,
>
> Yes, we have read 
> https://lore.kernel.org/lkml/20221123131612.914906-1-longman@redhat.com/ 
>  and checked it  carefully.
>
> We mean dup_user_cpus_ptr should not judge if the src->user_cpus_ptr 
> is null at the entry of the
> Function dup_user_cpus_ptr.
> If do this when user_cpus_ptr is freed by othe thread, but the parent 
> task copy the user_cpus_ptr
> data for new task through dup_task_struct 
> <https://opengrok.qualcomm.com/source/s?refs=dup_task_struct&project=KERNEL.PLATFORM.2.0> 
> -> arch_dup_task_struct 
> <https://opengrok.qualcomm.com/source/xref/KERNEL.PLATFORM.2.0/kernel_platform/common/kernel/fork.c#arch_dup_task_struct>(tsk 
> <https://opengrok.qualcomm.com/source/s?defs=tsk&project=KERNEL.PLATFORM.2.0>, 
> orig 
> <https://opengrok.qualcomm.com/source/s?defs=orig&project=KERNEL.PLATFORM.2.0>) 
> before the user_cpus_ptr
> ,
> is freed, ,next , when dup_task_struct 
> <https://opengrok.qualcomm.com/source/s?refs=dup_task_struct&project=KERNEL.PLATFORM.2.0> 
> call dup_user_cpus_ptr 
> <https://opengrok.qualcomm.com/source/s?defs=dup_user_cpus_ptr&project=KERNEL.PLATFORM.2.0>(tsk 
> <https://opengrok.qualcomm.com/source/s?defs=tsk&project=KERNEL.PLATFORM.2.0>, 
> orig 
> <https://opengrok.qualcomm.com/source/s?defs=orig&project=KERNEL.PLATFORM.2.0>, 
> node 
> <https://opengrok.qualcomm.com/source/s?defs=node&project=KERNEL.PLATFORM.2.0>),it 
> will return directly
> without doing nothing.  When wake up new task , then call 
> select_fallback_rqàdo_set_cpus_allowed,
> it will meet slub double free issue.  Then new path can not fix issue 
> in this scenario.
> void do_set_cpus_allowed(struct task_struct *p, const struct cpumask 
> *new_mask)
> {
>         struct affinity_context ac = {
>                .new_mask  = new_mask,
>                .user_mask = NULL,
>                .flags     = SCA_USER,      /* clear the user requested 
> mask */
>         };
>         __do_set_cpus_allowed(p, &ac);
>         kfree(ac.user_mask);
> }
> Kfree kfree(ac.user_mask) cause double free issue. New patch just 
> cover the user_cpus_ptr is freed
> after  code running into raw_spin_lock_irqsave, if it can not enter 
> into pi_lock critical section,
> what will happen.
>
> Maybe should delte following code at the entry of fuction . Please 
> help check it.
>
> -       if (!src->user_cpus_ptr)     //delete this
>
> -              return 0;            //delete  this
>
> We think maybe path needs a little more modification like following :
>
> kernel/sched/core.c 
> <https://lore.kernel.org/lkml/20221123131612.914906-1-longman@redhat.com/#Z31kernel:sched:core.c> 
> | 23 +++++++++++++++++++++--
>
> 1 file changed 
> <https://lore.kernel.org/lkml/20221123131612.914906-1-longman@redhat.com/#related>, 
> 21 insertions(+), 2 deletions(-)
>
> diff 
> <https://lore.kernel.org/lkml/20221123131612.914906-1-longman@redhat.com/#iZ31kernel:sched:core.c> 
> --git a/kernel/sched/core.c b/kernel/sched/core.c
>
> index 8df51b08bb38..6b259d9e127a 100644
>
> --- a/kernel/sched/core.c
>
> +++ b/kernel/sched/core.c
>
> @@ -2624,8 +2624,14 @@ void do_set_cpus_allowed(struct task_struct *p, 
> const struct cpumask *new_mask)
>
> int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src,
>
>       int node)
>
> {
>
> + cpumask_t *user_mask = NULL;
>
>        unsigned long flags;
>
> + /*
>
> + * This check is racy and losing the race is a valid situation.
>
> + * It is not worth the extra overhead of taking the pi_lock on
>
> + * every fork/clone.
>
> + */
>
> -       if (!src->user_cpus_ptr) //delete this
>
> -              return 0;            //delete this
>
The clearing of user_cpus_ptr is protected by pi_lock. IOW, racing 
between dup_user_cpus_ptr() and do_set_cpus_allowed is not possible and 
double free like what you have suggested should not happen. Yes, the 
user_cpus_ptr check here is racy. The worst case result is that a 
user_cpus_ptr has just been set in the task to be cloned, but it fail to 
copy over the user mask. With or without the check, the race can happen. 
The check is an optimization. Its effect is just make one outcome more 
likely than the other.

Cheers,
Longman


  parent reply	other threads:[~2022-11-24  4:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 10:04 [PATCH 0/1] " wangbiao3
2022-11-21 10:04 ` [PATCH 1/1] " wangbiao3
2022-11-22 13:18   ` Quentin Perret
2022-11-22 14:05   ` Peter Zijlstra
2022-11-22 14:06     ` Peter Zijlstra
2022-11-22 15:39     ` Waiman Long
2022-11-22 18:13       ` Waiman Long
     [not found]         ` <1fe9abbdd12b41fc87c92b60550fc909@xiaomi.com>
     [not found]           ` <9a6b10cd-855d-ca15-01e9-2c95a8b692be@redhat.com>
     [not found]             ` <9cc51697705f472e99a620eee8569a32@xiaomi.com>
2022-11-24  3:59               ` Waiman Long [this message]
2022-11-24 12:04                 ` 答复: [External Mail]Re: " Wenjie Li (Evan)
2022-11-25  2:08                   ` Waiman Long

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=0b50b719-b8df-decb-b6ed-12be8f623ad0@redhat.com \
    --to=longman@redhat.com \
    --cc=brauner@kernel.org \
    --cc=bsegall@google.com \
    --cc=chenguanyou@xiaomi.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=vincent.guittot@linaro.org \
    --cc=wangbiao3@xiaomi.com \
    --cc=wangting11@xiaomi.com \
    --cc=wenjieli@qti.qualcomm.com \
    --cc=will@kernel.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

all inboxes | Powered by JetHome®