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 ple
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 vm
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
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 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).
Ye
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
6 matches
Mail list logo
