On Sun, Jan 12, 2020 at 10:28:58AM +0800, Wei Yang wrote: > On Sat, Jan 11, 2020 at 03:03:52AM +0300, Kirill A. Shutemov wrote: > >On Thu, Jan 09, 2020 at 10:30:54PM +0800, Wei Yang wrote: > >> As all the other places, we grab the lock before manipulate the defer list. > >> Current implementation may face a race condition. > >> > >> For example, the potential race would be: > >> > >> CPU1 CPU2 > >> mem_cgroup_move_account split_huge_page_to_list > >> !list_empty > >> lock > >> !list_empty > >> list_del > >> unlock > >> lock > >> # !list_empty might not hold anymore > >> list_del_init > >> unlock > > > >I don't think this particular race is possible. Both parties take page > >lock before messing with deferred queue, but anytway: > > I am afraid not. Page lock is per page, while defer queue is per pgdate or > memcg. > > It is possible two page in the same pgdate or memcg grab page lock > respectively and then access the same defer queue concurrently. Look closer on the list_empty() argument. It's list_head local to the page. Too different pages can be handled in parallel without any problem in this particular scenario. As long as we as we modify it under the lock. Said that, page lock here was somewhat accidential and I still belive we need to move the check under the lock anyway. -- Kirill A. Shutemov
