From: Oleg Nesterov <oleg@redhat.com>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Dave Hansen <dave@sr71.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
dave.hansen@linux.intel.com, akpm@linux-foundation.org,
kirill.shutemov@linux.intel.com, aarcange@redhat.com,
n-horiguchi@ah.jp.nec.com, vbabka@suse.cz, jack@suse.cz
Subject: Re: [PATCH] mm, gup: introduce concept of "foreign" get_user_pages()
Date: Mon, 25 Jan 2016 19:18:12 +0100 [thread overview]
Message-ID: <20160125181812.GA9050@redhat.com> (raw)
In-Reply-To: <20160125131723.GB17206@linux.vnet.ibm.com>
On 01/25, Srikar Dronamraju wrote:
>
> > The uprobes is_trap_at_addr() location holds mmap_sem and
> > calls get_user_pages(current->mm) on an instruction address. This
> > makes it a pretty unique gup caller.
Yes, in particular is_trap_at_addr() doesn't look really nice. But we need
to read the insn under mmap_sem to avoid the race with unregister + register
at the same address, so that we won't send the wrong SIGTRAP in this case.
> Changes for uprobes.c looks good to me.
> Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Agreed, the changes in uprobes.c look fine.
> > @@ -1700,7 +1700,13 @@ static int is_trap_at_addr(struct mm_str
> > if (likely(result == 0))
> > goto out;
> >
> > - result = get_user_pages(NULL, mm, vaddr, 1, 0, 1, &page, NULL);
> > + /*
> > + * The NULL 'tsk' here ensures that any faults that occur here
> > + * will not be accounted to the task. 'mm' *is* current->mm,
> > + * but we treat this as a 'foreign' access since it is
> > + * essentially a kernel access to the memory.
> > + */
> > + result = get_user_pages_foreign(NULL, mm, vaddr, 1, 0, 1, &page, NULL);
> > if (result < 0)
> > return result;
Yes, but perhaps we should simply remove this get_user_pages_foreign() and just
return -EFAULT if copy_from_user_inatomic() fails. This should be very unlikely
case, I think it would be fine to restart this insn and take another bp hit to
fault this page in.
Srikar what do you think? IIRC, this get_user_pages() was needed before, when
is_trap_at_addr() had other (non-restartable) callers with mm != current->mm.
But again, I think this patch is fine, we can do this later.
Oleg.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Dave Hansen <dave@sr71.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
dave.hansen@linux.intel.com, akpm@linux-foundation.org,
kirill.shutemov@linux.intel.com, aarcange@redhat.com,
n-horiguchi@ah.jp.nec.com, vbabka@suse.cz, jack@suse.cz
Subject: Re: [PATCH] mm, gup: introduce concept of "foreign" get_user_pages()
Date: Mon, 25 Jan 2016 19:18:12 +0100 [thread overview]
Message-ID: <20160125181812.GA9050@redhat.com> (raw)
In-Reply-To: <20160125131723.GB17206@linux.vnet.ibm.com>
On 01/25, Srikar Dronamraju wrote:
>
> > The uprobes is_trap_at_addr() location holds mmap_sem and
> > calls get_user_pages(current->mm) on an instruction address. This
> > makes it a pretty unique gup caller.
Yes, in particular is_trap_at_addr() doesn't look really nice. But we need
to read the insn under mmap_sem to avoid the race with unregister + register
at the same address, so that we won't send the wrong SIGTRAP in this case.
> Changes for uprobes.c looks good to me.
> Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Agreed, the changes in uprobes.c look fine.
> > @@ -1700,7 +1700,13 @@ static int is_trap_at_addr(struct mm_str
> > if (likely(result == 0))
> > goto out;
> >
> > - result = get_user_pages(NULL, mm, vaddr, 1, 0, 1, &page, NULL);
> > + /*
> > + * The NULL 'tsk' here ensures that any faults that occur here
> > + * will not be accounted to the task. 'mm' *is* current->mm,
> > + * but we treat this as a 'foreign' access since it is
> > + * essentially a kernel access to the memory.
> > + */
> > + result = get_user_pages_foreign(NULL, mm, vaddr, 1, 0, 1, &page, NULL);
> > if (result < 0)
> > return result;
Yes, but perhaps we should simply remove this get_user_pages_foreign() and just
return -EFAULT if copy_from_user_inatomic() fails. This should be very unlikely
case, I think it would be fine to restart this insn and take another bp hit to
fault this page in.
Srikar what do you think? IIRC, this get_user_pages() was needed before, when
is_trap_at_addr() had other (non-restartable) callers with mm != current->mm.
But again, I think this patch is fine, we can do this later.
Oleg.
next prev parent reply other threads:[~2016-01-25 18:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 18:02 [PATCH] mm, gup: introduce concept of "foreign" get_user_pages() Dave Hansen
2016-01-22 18:02 ` Dave Hansen
2016-01-22 18:16 ` kbuild test robot
2016-01-22 18:16 ` kbuild test robot
2016-01-22 21:31 ` Dave Hansen
2016-01-22 21:31 ` Dave Hansen
2016-01-25 13:17 ` Srikar Dronamraju
2016-01-25 13:17 ` Srikar Dronamraju
2016-01-25 18:18 ` Oleg Nesterov [this message]
2016-01-25 18:18 ` Oleg Nesterov
2016-01-27 11:30 ` Vlastimil Babka
2016-01-27 11:30 ` Vlastimil Babka
2016-01-27 22:59 ` Dave Hansen
-- strict thread matches above, loose matches on Subject: below --
2016-01-20 17:35 Dave Hansen
2016-01-20 17:35 ` Dave Hansen
2016-01-20 17:56 ` Vlastimil Babka
2016-01-20 17:56 ` Vlastimil Babka
2016-01-20 18:48 ` Dave Hansen
2016-01-20 18:48 ` Dave Hansen
2016-01-20 19:30 ` Vlastimil Babka
2016-01-20 19:30 ` Vlastimil Babka
2016-01-15 18:11 Dave Hansen
2016-01-15 18:11 ` Dave Hansen
2016-01-18 15:20 ` Vlastimil Babka
2016-01-18 15:20 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160125181812.GA9050@redhat.com \
--to=oleg@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=dave@sr71.net \
--cc=jack@suse.cz \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=vbabka@suse.cz \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.