These three patches address tlb_flush_pending issues. The first one address
a race when accessing tlb_flush_pending and is the important one.
The next two patch addresses Andrew Morton question regarding the barriers.
These patches are not really related to the first one: the atomic
operations atomic_read() and atomic_inc() do not act as a memory barrier,
and replacing existing barriers with smp_mb__after_atomic() did not seem
beneficial. Yet, while reviewing the memory barriers around the use of
tlb_flush_pending, few issues were identified.
v3 -> v4:
- Change function names to indicate they inc/dec and not set/clear
(Sergey)
- Avoid additional barriers, and instead revert the patch that accessed
mm_tlb_flush_pending without a lock (Mel)
v2 -> v3:
- Do not init tlb_flush_pending if it is not defined without (Sergey)
- Internalize memory barriers to mm_tlb_flush_pending (Minchan)
v1 -> v2:
- Explain the implications of the implications of the race (Andrew)
- Mark the patch that address the race as stable (Andrew)
- Add another patch to clean the use of barriers (Andrew)
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Cc: Minchan Kim <minchan@xxxxxxxxxx>
Cc: Sergey Senozhatsky <sergey.senozhatsky@xxxxxxxxx>
Cc: Andy Lutomirski <luto@xxxxxxxxxx>
Cc: Mel Gorman <mgorman@xxxxxxx>
Cc: Rik van Riel <riel@xxxxxxxxxx>
Nadav Amit (3):
mm: migrate: prevent racy access to tlb_flush_pending
mm: migrate: fix barriers around tlb_flush_pending
Revert "mm: numa: defer TLB flush for THP migration as long as
possible"
include/linux/mm_types.h | 45 ++++++++++++++++++++++++++++++++-------------
kernel/fork.c | 2 +-
mm/debug.c | 2 +-
mm/huge_memory.c | 7 +++++++
mm/migrate.c | 6 ------
mm/mprotect.c | 4 ++--
6 files changed, 43 insertions(+), 23 deletions(-)
--
2.11.0
--
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>
