Hello,
Here 4 more minor patches that are incremental against -mm.
In short:
1/4) updates vm_page_prot atomically as it's updated outside the
rmap_locks. It's always better to use READ_ONCE/WRITE_ONCE if the
access is concurrent from multiple CPUs, even if there wouldn't
be risk of reading intermediate values... like in this case there
is too.
Not critical, theoretical issue only so far, it might be possible
that gcc emits right asm code already, but this is safer and
forces gcc to emit the right asm code.
2/4) comment correction
Not critical, noop change.
3/4) adapts CONFIG_DEBUG_VM_RB=y to cope with the case of
next->vm_start reduced. Earlier that could never happen and
vma->vm_end was always increased instead. validate_mm() is always
called before returning from vma_adjust() and the argumented
rbtree is always consistent while exercising a flood of case8.
Not critical if CONFIG_DEBUG_VM_RB=n as there's no functional
change in such case. Critical if you set CONFIG_DEBUG_VM_RB=y, in
which case without the patch false positives are emitted.
4/4) cleanup a line that is superfluous and in turns it can confuse
the reader if the reader assumes it's not superfluous.
Not critical, noop change.
Andrea Arcangeli (4):
mm: vm_page_prot: update with WRITE_ONCE/READ_ONCE
mm: vma_adjust: minor comment correction
mm: vma_merge: correct false positive from
__vma_unlink->validate_mm_rb
mm: vma_adjust: remove superfluous confusing update in remove_next ==
1 case
mm/huge_memory.c | 2 +-
mm/migrate.c | 2 +-
mm/mmap.c | 94 +++++++++++++++++++++++++++++++++++++++++---------------
3 files changed, 72 insertions(+), 26 deletions(-)
--
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>