On 04/24, Hugh Dickins wrote:
On Thu, 24 Apr 2014, Oleg Nesterov wrote:
So, what do you think about the patch below? It is probably fine in any
case,
but is there any strong reason to follow the gup's behaviour and forbid
the
anon page in VM_MAYSHARE !VM_MAYWRITE vma?
I don't
On Fri, 25 Apr 2014, Oleg Nesterov wrote:
And I forgot to mention, there is another reason why I would like to
change uprobes to follow the same convention. I still think it would
be better to kill __replace_page() and use gup(FOLL_WRITE | FORCE)
in uprobe_write_opcode().
Oh, please please
Hi Hugh,
Sorry for late reply. First of all, to avoid the confusion, I think the
patch is fine.
When I saw this patch I decided that uprobes should be updated accordingly,
but I just realized that I do not understand what should I write in the
changelog.
On 04/04, Hugh Dickins wrote:
+
On Thu, 24 Apr 2014, Oleg Nesterov wrote:
Hi Hugh,
Sorry for late reply. First of all, to avoid the confusion, I think the
patch is fine.
When I saw this patch I decided that uprobes should be updated accordingly,
but I just realized that I do not understand what should I write in the
get_user_pages(write=1, force=1) has always had odd behaviour on write-
protected shared mappings: although it demands FMODE_WRITE-access to the
underlying object (do_mmap_pgoff sets neither VM_SHARED nor VM_MAYWRITE
without that), it ends up with do_wp_page substituting private anonymous
On Fri, Apr 04, 2014 at 01:28:22AM -0700, Hugh Dickins wrote:
get_user_pages(write=1, force=1) has always had odd behaviour on write-
protected shared mappings: although it demands FMODE_WRITE-access to the
underlying object (do_mmap_pgoff sets neither VM_SHARED nor VM_MAYWRITE
without that),
On Fri, 4 Apr 2014, Kirill A. Shutemov wrote:
There's comment in do_wp_page() which is not true anymore with patch
applied. It should be fixed.
The * Only catch write-faults on shared writable pages,
* read-only shared pages can get COWed by
* get_user_pages(.write=1, .force=1).
Yes,
