On 2022/5/6 11:23, ying.huang@xxxxxxxxx wrote: > On Mon, 2022-04-25 at 21:27 +0800, Miaohe Lin wrote: >> rcu_read_lock is required by grabbing the task refcount but it's not >> needed for ptrace_may_access. So we could release the rcu lock after >> task refcount is successfully grabbed to reduce the rcu holding time. >> >> Reviewed-by: Muchun Song <songmuchun@xxxxxxxxxxxxx> >> Reviewed-by: Christoph Hellwig <hch@xxxxxx> >> Signed-off-by: Miaohe Lin <linmiaohe@xxxxxxxxxx> >> Cc: Huang Ying <ying.huang@xxxxxxxxx> >> Cc: David Howells <dhowells@xxxxxxxxxx> >> Cc: Christoph Lameter <cl@xxxxxxxxx> >> --- >> mm/migrate.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/mm/migrate.c b/mm/migrate.c >> index b2678279eb43..b779646665fe 100644 >> --- a/mm/migrate.c >> +++ b/mm/migrate.c >> @@ -1902,17 +1902,16 @@ static struct mm_struct *find_mm_struct(pid_t pid, nodemask_t *mem_nodes) >> return ERR_PTR(-ESRCH); >> } >> get_task_struct(task); >> + rcu_read_unlock(); >> >> >> /* >> * Check if this process has the right to modify the specified >> * process. Use the regular "ptrace_may_access()" checks. >> */ >> if (!ptrace_may_access(task, PTRACE_MODE_READ_REALCREDS)) { >> - rcu_read_unlock(); >> mm = ERR_PTR(-EPERM); >> goto out; >> } >> - rcu_read_unlock(); >> >> >> mm = ERR_PTR(security_task_movememory(task)); >> if (IS_ERR(mm)) > > Hi, Miaohe, > > Please check the previous discussion and verify whether the original > reported race condition is stll valid by yourself before resending this > patch again. If you find that the original race condition isn't > possible now, please add the analysis in your change log. > Sorry for late respond. It's a pity that this change is still not verified by the relevant experts. I will try to give my analysis in my change log instead if the original race condition is invalid now. Many thanks! > Best Regards, > Huang, Ying > > . >