Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <8a48c522-afbc-f18f-5080-4c915f87e2bc@redhat.com>
Date:   Thu, 24 Nov 2022 21:08:25 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.0
Subject: =?UTF-8?B?UmU6IOetlOWkjTogW0V4dGVybmFsIE1haWxdUmU6IFtQQVRDSCAxLzFd?=
 =?UTF-8?Q?_sched=3a_fix_user=5fmask_double_free?=
Content-Language: en-US
To:     "Wenjie Li (Evan)" <wenjieli@qti.qualcomm.com>,
        =?UTF-8?B?RGF2aWQgV2FuZyDnjovmoIc=?= <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>,
        =?UTF-8?B?6ZmI5Yag5pyJ?= <chenguanyou@xiaomi.com>,
        Will Deacon <will@kernel.org>,
        =?UTF-8?B?VGluZzExIFdhbmcg546L5am3?= <wangting11@xiaomi.com>
References: <cover.1669020858.git.wangbiao3@xiaomi.com>
 <b8970a530d420109ee9fe0b268e097fb839211b0.1669020858.git.wangbiao3@xiaomi.com>
 <Y3zXDZeTUgDz2hJ8@hirez.programming.kicks-ass.net>
 <a7fb3cac-176f-3928-f3a3-23c25ab9677e@redhat.com>
 <1c3ce8c4-354d-2f00-1dc6-e13cbe389828@redhat.com>
 <1fe9abbdd12b41fc87c92b60550fc909@xiaomi.com>
 <9a6b10cd-855d-ca15-01e9-2c95a8b692be@redhat.com>
 <9cc51697705f472e99a620eee8569a32@xiaomi.com>
 <0b50b719-b8df-decb-b6ed-12be8f623ad0@redhat.com>
 <DM8PR02MB80559373BC22C4051AE30073ED0F9@DM8PR02MB8055.namprd02.prod.outlook.com>
From:   Waiman Long <longman@redhat.com>
In-Reply-To: <DM8PR02MB80559373BC22C4051AE30073ED0F9@DM8PR02MB8055.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 11/24/22 07:04, Wenjie Li (Evan) wrote:
> Hi, Waiman.
>
> "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." We still can understand why it is impossible to happen. Because we indeed met this issue. Following is we got from ftrace.
>
> 1. Task  A  pid 27961 run on core6 and is forking/cloning task pid 28051, and task B  pid 28051 will copy task struct data from task A pid 27961. So task A p->user_cpus_ptr = ffffff884fbf9200 is equal to task B p->user_cpus_ptr=ffffff884fbf9200 through arch_dup_task_struct.

You are right. I forgot the fact that the value of dst->user_cpus_ptr is 
a copy of src. I have posted a v3 patch to address that. Thanks for the 
spotting that.

Cheers,
Longman