On Tue, May 06, 2014 at 05:30:53PM +0200, Vlastimil Babka wrote: > On 05/01/2014 10:44 AM, Mel Gorman wrote: > >When adding pages to the LRU we clear the active bit unconditionally. As the > >page could be reachable from other paths we cannot use unlocked operations > >without risk of corruption such as a parallel mark_page_accessed. This > >patch test if is necessary to clear the atomic flag before using an atomic > > active > Thanks. Clearly I had atomic on the brain. > >operation. In the unlikely even this races with mark_page_accesssed the > >consequences are simply that the page may be promoted to the active list > >that might have been left on the inactive list before the patch. This is > >a marginal consequence. > > Well if this is racy, then even before the patch, mark_page_accessed > might have come right after ClearPageActive(page) anyway? > Or is the > changelog saying that this change only extended the race window that > already existed? If yes it could be more explicit, as now it might > sound as if the race was introduced. > When adding pages to the LRU we clear the active bit unconditionally. As the page could be reachable from other paths we cannot use unlocked operations without risk of corruption such as a parallel mark_page_accessed. This patch tests if is necessary to clear the active flag before using an atomic operation. This potentially opens a tiny race when PageActive is checked as mark_page_accessed could be called after PageActive was checked. The race already exists but this patch changes it slightly. The consequence is that that the page may be promoted to the active list that might have been left on the inactive list before the patch. It's too tiny a race and too marginal a consequence to always use atomic operations for. ? -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>