Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Thu, 23 Nov 2023 16:42:32 -0500
From:   Gregory Price <gregory.price@memverge.com>
To:     Zhongkun He <hezhongkun.hzk@bytedance.com>
Cc:     Vinicius Petrucci <vpetrucci@gmail.com>, akpm@linux-foundation.org,
        linux-mm@vger.kernel.org, linux-cxl@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
        linux-api@vger.kernel.org, minchan@kernel.org,
        dave.hansen@linux.intel.com, x86@kernel.org,
        Jonathan.Cameron@huawei.com, aneesh.kumar@linux.ibm.com,
        ying.huang@intel.com, dan.j.williams@intel.com, fvdl@google.com,
        surenb@google.com, rientjes@google.com, hannes@cmpxchg.org,
        mhocko@suse.com, Hasan.Maruf@amd.com, jgroves@micron.com,
        ravis.opensrc@micron.com, sthanneeru@micron.com,
        emirakhur@micron.com, vtavarespetr@micron.com
Subject: Re: [RFC PATCH] mm/mbind: Introduce process_mbind() syscall for
 external memory binding
Message-ID: <ZV/HSFMmv3xwkNPL@memverge.com>
References: <ZV5zGROLefrsEcHJ@r13-u19.micron.com>
 <CACSyD1OFjROw26+2ojG37eDBParVg721x1HCROMiF2pW2aHj8A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACSyD1OFjROw26+2ojG37eDBParVg721x1HCROMiF2pW2aHj8A@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VWR6ZC93T1ltN2ZheVZkenNXNlQwNXZSNDRWN2xGMm9IUHdSWVBKTXZCcnph?=
 =?utf-8?B?TDV2VzR0ZGJaZlF2OE15Z2hTdlovZnhsREpaUE80dWVWMWRnV0dGT0QwdnRj?=
 =?utf-8?B?am90ZHFtRDU2TWcvK1Q4amxLeHdjaFlFQzRybFZFclBrMjVPZGVvblcwR2xq?=
 =?utf-8?B?eHR1L1FmckFXN2krdGVWRkVpVERpUXRxYklWZFk0bWYxWGJwMmJRZlBWWHp1?=
 =?utf-8?B?UGxKL0g1TnFTNUVNVE41MVRkaVF0VVQwaU1NTU9UUE8vNDgzMGowaE40UnFL?=
 =?utf-8?B?VWJlSHJ5MkxHZmF4NzFrS1hTcytNclFlbFI3UWhZV2dVd0RuRnVrSkJoRS9v?=
 =?utf-8?B?cHh4NTJrREE1UE80WlMyT2tSM2xTSWR6R2dXZkJINURJUCsvaXd6RkpiZEFS?=
 =?utf-8?B?YUE2TTNTS1ZrY1dSeVJ5YWd2YmluaVFhaDFYcWZnemd2Z3ptM3NnNHU1bW05?=
 =?utf-8?B?QkpDZGh4UFZGUVROWXRVd3pjNy9nUXNLazhzTkV0c21paTVUK2FiRlZhNXVX?=
 =?utf-8?B?VjJHQXJwemlSTGx6WmUrSDU1Mm1nTEtsVmxxMmJ4K1FvUERTRFRRMDFrbnlE?=
 =?utf-8?B?K3FoZUpQNWNQU2hnQk0zTlJJV0RuSTFYa080NmVWeDcvZUttb2l3MHJoOEJO?=
 =?utf-8?B?eTRVbEhGU3E5cGwxaWZGVUJYZmphMkRtdjZuWS9OVTA2aWpuWlJ6OUhxVkph?=
 =?utf-8?B?bXoyVEtsTjNJVEFjdWpaY0Z5S0l2U2RzRmFIaXkydG54c213NkFWWlRBTitN?=
 =?utf-8?B?K2FLSjdQMDlJQjREUlB5TlB4OTVidjcvUWFnNndOZVgyWVNwVTFpY05RN2Y1?=
 =?utf-8?B?Z01qcVBaclkyOUxZc25CNExYSGF0WDlxK1BQOXNDWjF5Rm5xQkNDRHQ0T1l2?=
 =?utf-8?B?RkRMUGVVbjJxYVNqeXJ0SCtkRmxyakRicjRrTWJ4K0tnNytRb0ZsRDdiVzI4?=
 =?utf-8?B?ZExiMk16bk5HVXdBMFB2cFhYTUJEc1NaVDV5OHIvdUd0MjROT1R5WEg0TElK?=
 =?utf-8?B?cUhPYngwVkpOaVBqS2RVc1NxODFyVmNJYktkM2dJTWNrMWRBV1ZyU2hPNjh0?=
 =?utf-8?B?OEcwOTRLUExHMW1KaUJJV1ZrN3NDZ2pVY0tjSHBiYzFrWmlER1Ixb0xWSGZN?=
 =?utf-8?B?RS9Nc0htVkNHcTNXSUN5RzJ5WEZQRm5VUTk1MXFVSCtzczl0QUVFZ3lXTWtm?=
 =?utf-8?B?NUtUakZMUzVKVkk4NVdhcGo1YlA4d3d4OXBHODJwMm1NeDBRNkM0WWNwTXph?=
 =?utf-8?B?YkhUWnRVTHkyWWU5aDVBK1ZzVkkzZjUyTmF0c25JYWhaN2hXUkt5Qzh2OEht?=
 =?utf-8?B?a2RTdjJiZlhXL2IwdzBJL3RibEpUWEtWT0dFVlNLTWlDQkQyYjFmZzRpSUhM?=
 =?utf-8?B?bGZaZmRob0xpREVCZmxMTGQ4MGhtWTVpZkp4ZjFzV04xL2tjelZlV3RHZ1Zz?=
 =?utf-8?B?OVJCbWk2elgxNEc1YUZ0cTBTOFJZenlGVjRnd0RDT0ZLcXVUc1JzMlprdXN6?=
 =?utf-8?B?bEU5S3dldHNLK3dwcTE3dHd2NTZGc0VVSmZmSWE5UjA0N1ZpeDFWaThEeUt1?=
 =?utf-8?B?OUloODlOVE16UnA2TTdpajlDeHBQcmNGWnRNS1ZZYnZreG4vUGt6OHB3R1Ex?=
 =?utf-8?B?SzVtcGFRdjZKem8zZWFycEZHV2VqK1FpdTFTK1YrTDlRMUFNbTNFZzQ1bWdT?=
 =?utf-8?B?RHlTaEcwdnpxeE9yZnV2aU5hUGNFSDZCa2dmSStCMDhUVGNGTkVFcHprai85?=
 =?utf-8?B?d0hScGtQMmZEVUdsa0VZRnM3M0tncVZVSm1yYnhmdURkVmw2ZFJZUHVTWHZQ?=
 =?utf-8?B?TDMxV0IrbnA0YUcwV05kbmtZYjYvYmllMGgrbmV0Q3AyRzltREg3ajdHTjJI?=
 =?utf-8?B?M0h4S3JzeWtJZ0MrMFMxVmxBZnA0VXFJaGtTL3VZbzhxNkJnU2FHR2gzUXBI?=
 =?utf-8?B?LzJoUGZxWnlxeGZlMFIvUFh4NVJpSmgyNEZxekRmeCs4aWJsc29aQ2RxZGpl?=
 =?utf-8?B?bTJVZlpYV0dWdUlsUVB4NFdMSERLeWJGSGtxVW5XNHNPMjE0OTUranVZaFNk?=
 =?utf-8?B?ZTlVZ1lramMxVmQ1R2VCNkJZNUNpNno1WGJ1a29zS2ZqbnFRNTAyL2daODlv?=
 =?utf-8?B?Qi9KMkFhdDEyUEw1T2cwTXdYL3o0KytqYW1PMGM0VG1md2dFUUlKTkFDN1Bt?=
 =?utf-8?B?L0E9PQ==?=
X-OriginatorOrg: memverge.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d933315-8f19-4ee8-a74f-08dbed294245
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR17MB5512.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2023 20:09:26.5672
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5c90cb59-37e7-4c81-9c07-00473d5fb682
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: wTm1IpVKJ+T0B1fNeGvqvhF2V/c2gJfirj0rIfVbueRWTmiVGMBeKaPFIUXfTfOhy/AIys6eMnIuzSG0dV5GZV6tJsbSqgW0gJQjZ/a3gBI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR17MB4275
X-Spam-Status: No, score=-0.1 required=5.0 tests=DATE_IN_PAST_12_24,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Fri, 24 Nov 2023 12:09:42 -0800 (PST)

On Fri, Nov 24, 2023 at 04:13:41PM +0800, Zhongkun He wrote:
> 
> Per my understanding,  the process_mbind() is implementable without
> many difficult challenges，
> since it is always protected by mm->mmap_lock. But task mempolicy does
> not acquire any lock
> in alloc_pages().

per-vma policies are protected by the mmap lock, while the task
mempolicy is protected by the task lock on replacement, and
task->mems_allowed (protected by task_lock).

There is an update in my refactor tickets that enforces the acquisition
of task_lock on mpol_set_nodemask, which prevents the need for
alloc_pages to do anything else.  That's not present in this patch.

Basically mems_allowed deals with the majority of situations, and
mmap_lock deals with per-vma mempolicy changes and migrations.

~Gregory