On Thu, Nov 30, 2023 at 05:34:04PM +0800, Zhongkun He wrote: > Hi Gregory, sorry for the late reply. > > I tried pidfd_set_mempolicy(suggested by michal) about a year ago. > There is a problem here that may need attention. > > A mempolicy can be either associated with a process or with a VMA. > All vma manipulation is somewhat protected by a down_read on > mmap_lock.In process context(in alloc_pages()) there is no locking > because only the process accesses its own state. > > Now we need to change the process context mempolicy specified > in pidfd. the mempolicy may about to be freed by > pidfd_set_mempolicy() while alloc_pages() is using it, > The race condition appears. > > Say something like the following： > > pidfd_set_mempolicy() target task stack: > alloc_pages: > mpol = p->mempolicy; > task_lock(task); > old = task->mempolicy; > task->mempolicy = new; > task_unlock(task); > mpol_put(old); > /*old mpol has been freed.*/ > policy_node(...., mpol) > __alloc_pages(); > > To reduce the use of locks and atomic operations(mpol_get/put) > in the hot path, there are no references or lock protections here > for task mempolicy. > > It would be great if your refactoring has a good solution. > > Thanks. > Hi ZhongKun! I actually just sent out a more general RFC to mempolicy updates that discuss this more completely: https://lore.kernel.org/linux-mm/ZWezcQk+BYEq%2FWiI@xxxxxxxxxxxx/ and another post on even more issues with pidfd modifications to vma mempolicies: https://lore.kernel.org/linux-mm/ZWYsth2CtC4Ilvoz@xxxxxxxxxxxx/ We may have to slow-walk the changes to vma policies due to there being many more hidden accesses to (current) than expected. It's a rather nasty rats nest of mempolicy-vma-cpusets-shmem callbacks that obscure these current-task accesses, it will take time to work through. As for hot-path reference counting - we may need to change the way mempolicy is managed, possibly we could leverage RCU to manage mempolicy references in the hot path, rather than using locks. In this scenario, we would likely need to change the way the default policy is applied (maybe not, I haven't fully explored it). Do you have thoughts on this? Would very much like additional comments before I go through the refactor work. Regards, Gregory
