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: <0445de39-15a4-f645-b380-39f20abb6524@bytedance.com>
Date:   Wed, 16 Nov 2022 17:38:09 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: [External] Re: [PATCH v2] mm: add new syscall
 pidfd_set_mempolicy().
To:     "Huang, Ying" <ying.huang@intel.com>
Cc:     corbet@lwn.net, mhocko@suse.com, akpm@linux-foundation.org,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        linux-api@vger.kernel.org, linux-doc@vger.kernel.org
References: <20221111084051.2121029-1-hezhongkun.hzk@bytedance.com>
 <87zgcrwfac.fsf@yhuang6-desk2.ccr.corp.intel.com>
From:   Zhongkun He <hezhongkun.hzk@bytedance.com>
In-Reply-To: <87zgcrwfac.fsf@yhuang6-desk2.ccr.corp.intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Ying, thanks for your replay and suggestions.

> 
> I suggest to move the flags in "mode" parameter (MPOL_F_STATIC_NODES,
> MPOL_F_RELATIVE_NODES, MPOL_F_NUMA_BALANCING, etc.) to "flags"
> parameter, otherwise, why add it?

The "flags" is used for future extension if any, just like
process_madvise() and set_mempolicy_home_node().
Maybe it should be removed.

> 
> And, how about add a "home_node" parameter?  I don't think that it's a
> good idea to add another new syscall for pidfd_set_mempolicy_home_node()
> in the future.
> 

Good idea, but "home_node" is used for vma policy, not task policy.
It is possible to use it in pidfd_mbind() in the future.

> 
> IMHO, "The first four APIS" and "The last one" isn't easy to be
> understood.  How about
> 
> "sys_pidfd_set_mempolicy sets the mempolicy of task specified in the
> pidfd, the others affect only the calling task, ...".
> 

Got it.

> 
> Why add "sys_"?  I fount that there's no "sys_" before set_mempolicy()/mbind() etc.
> 

Got it.

>> +void mpol_put_async(struct task_struct *task, struct mempolicy *p)
> 
> How about change __mpol_put() directly?

> 
> Why can we fall back to freeing directly if task_work_add() failed?
> Should we check the return code and fall back only if -ESRCH and WARN
> for other cases?
> 

A task_work based solution has not been accepted yet, it will be 
considered later if needed.


>> +	}
> 
> Why do we need to write lock mmap_sem?  IIUC, we don't touch vma.
> 

Yes, it should be removed.

>>   /*
> 
> Because we will change task_struct->mempolicy in another task, we need
> to use kind of "load acquire" / "store release" memory order.  For
> example, rcu_dereference() / rcu_assign_pointer(), etc.
> 
Thanks again for your suggestion.

Best Regards,
Zhongkun