From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9939C433FE for ; Wed, 16 Nov 2022 09:38:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A1FE6B0071; Wed, 16 Nov 2022 04:38:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3518E8E0001; Wed, 16 Nov 2022 04:38:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 219816B0073; Wed, 16 Nov 2022 04:38:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 11A496B0071 for ; Wed, 16 Nov 2022 04:38:18 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D53641C6166 for ; Wed, 16 Nov 2022 09:38:17 +0000 (UTC) X-FDA: 80138804634.02.F6EF054 Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by imf10.hostedemail.com (Postfix) with ESMTP id 745E0C000D for ; Wed, 16 Nov 2022 09:38:16 +0000 (UTC) Received: by mail-pj1-f50.google.com with SMTP id o7so16048479pjj.1 for ; Wed, 16 Nov 2022 01:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=ED3dVZVhTXurH9uVn9Km9+qzSuteSy+hO2CW2MEdWTU=; b=I/7hBPwo37uWwdiPvScqp5Wub/IybcuswDPzUWm8rPIFGRsJNEuTVzrGQec8Ow/l/d aKnmhZEjWitb73ekE3JC0wqz1Oep1X0J2fzqil9JzjWCl3ue1ogO8l8x0Nrp0Y3vebvA HFfs+KKvymqM4vfSpUHJQ/C8Ga7T3aTpHhqukRCmkCDrYDZFBuCnjK0du8NuQRg+alzJ i5tjHe9Y5bMNOUAwOjs+QWG+c2OtcYzs4E09M+1P90Lg3JgRx2+/lIppdhPFqVVL/HLg hiOawDrc9p4LqIRHMEKakCa77RJmZq5YG8kly2mNrLV/9e74LnZ6CGCWYdbcJoyX0ZsG BzDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=ED3dVZVhTXurH9uVn9Km9+qzSuteSy+hO2CW2MEdWTU=; b=LkBhYSz9zfh6gq0XWj8Kt3NAe6lI79+1PqotUyLk3XBTY4Ir5YknARTyE95d/+DIiF bE0NiO/bDZyQQuO0qUfb884iBZacJmaxfM70mjY8itZrkiyWN1z3bPhI5wTyE2weTULo P+3szjdBRmTabnXOghT7HUmpiQOWYvg06WwG43ECUKYEJRvXK04xRLvsdeAwh5cA2AhF anZNffJbHlZYk6X+vUYqLfJ+3lLjihZ0csJagrodd0jR3oLxW6vvxMFtZwcvLR+G2Vqj Vn8Tnf0oBZ5pT5jZ3EegLemj9tKrXuWzcu18/bMSd3CdCDzUs8FBk3MnFIGcfqHkXE97 bX+g== X-Gm-Message-State: ANoB5pkC5c+H5sjuz16KjoqKBJYXYw82GfKztBXatS4TYpN1wqMWKesj 8sKYoBqRU31HR/rtEYpAZ2mAqA== X-Google-Smtp-Source: AA0mqf6mO/o9kgca96vOeZ6qwUazWfcWU/RyXDHE4Gy+8A40ZFbYqCJCwRW5uzjdX4dDB5SHOuDr3A== X-Received: by 2002:a17:902:b694:b0:187:337a:b2a1 with SMTP id c20-20020a170902b69400b00187337ab2a1mr8336586pls.96.1668591495172; Wed, 16 Nov 2022 01:38:15 -0800 (PST) Received: from [10.68.76.92] ([139.177.225.229]) by smtp.gmail.com with ESMTPSA id e24-20020a63f558000000b00470275c8d6dsm9012484pgk.10.2022.11.16.01.38.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Nov 2022 01:38:14 -0800 (PST) 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" 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 In-Reply-To: <87zgcrwfac.fsf@yhuang6-desk2.ccr.corp.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668591497; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ED3dVZVhTXurH9uVn9Km9+qzSuteSy+hO2CW2MEdWTU=; b=YCUjXPWgHwSVJKxM884tFBrbQxUi6kLsPRaDO/DaJqxHXuz6gxxcHprwO4sr1MeOwDZa8N xBAmVqhb/8nkOoTq8RnBbp6I+XVGNtw2le3RRssPYxiHlds/Ql7SJUHeENqbiOETbkT+4V VLW6U8MlVi4F1LFGg1TR/OekBKb7ouo= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b="I/7hBPwo"; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf10.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.216.50 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668591497; a=rsa-sha256; cv=none; b=wssOVWtXguOp24VkoUqvtWu31VwvHoN425xJJoTE378k6Xe9+srK53f1BVch4jXVhr+sWG jfMX+JyiA3i34K7g+nUxMsvJhT8srk0Tac+a32JQyI8xVBzo5vpyw+5iVGg5vGop2BL3Cr jiylQbc/OP4/MsUoB0jFE9Bk+LO9WPg= X-Rspam-User: X-Stat-Signature: 9tqkr4goz4gk55e4pn3cy6f49d7gpqmt X-Rspamd-Queue-Id: 745E0C000D Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b="I/7hBPwo"; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf10.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.216.50 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com X-Rspamd-Server: rspam07 X-HE-Tag: 1668591496-413371 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000646, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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