summaryrefslogtreecommitdiff
path: root/firmware/README.AddingFirmware
diff options
context:
space:
mode:
authorOleg Nesterov <oleg@redhat.com>2012-07-29 20:22:16 +0200
committerIngo Molnar <mingo@kernel.org>2012-07-30 11:27:19 +0200
commitc517ee744b96e441d9c731e245f83c6d08dc0a19 (patch)
tree8d7f7b86767ba2d5c62c2d421f388949f0483c85 /firmware/README.AddingFirmware
parentf403072c6108e15f319a4a5036b650c77760522c (diff)
uprobes: __replace_page() should not use page_address_in_vma()
page_address_in_vma(old_page) in __replace_page() is ugly and wrong. The caller already knows the correct virtual address, this page was found by get_user_pages(vaddr). However, page_address_in_vma() can actually fail if page->mapping was cleared by __delete_from_page_cache() after get_user_pages() returns. But this means the race with page reclaim, write_opcode() should not fail, it should retry and read this page again. Probably the race with remove_mapping() is not possible due to page_freeze_refs() logic, but afaics at least shmem_writepage()->shmem_delete_from_page_cache() can clear ->mapping. We could change __replace_page() to return -EAGAIN in this case, but it would be better to simply use the caller's vaddr and rely on page_check_address(). Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Srikar Dronamraju <srikar.vnet.ibm.com> Cc: Anton Arapov <anton@redhat.com> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/20120729182216.GA20311@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'firmware/README.AddingFirmware')
0 files changed, 0 insertions, 0 deletions