All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	kirill@shutemov.name, Andi Kleen <ak@linux.intel.com>,
	Michal Hocko <mhocko@kernel.org>,
	dave@stgolabs.net, Jan Kara <jack@suse.cz>,
	Matthew Wilcox <willy@infradead.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Mackerras <paulus@samba.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Will Deacon <will.deacon@arm.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	haren@linux.vnet.ibm.com,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	npiggin@gmail.com, bsingharora@gmail.com,
	Tim Chen <tim.c.chen@linux.intel.com>,
	linuxppc-dev@lists.ozlabs.org, "x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH v3 00/20] Speculative page faults
Date: Thu, 5 Oct 2017 16:32:07 -0700	[thread overview]
Message-ID: <20171005233206.vpg446q5k2r4g27r@ast-mbp> (raw)
In-Reply-To: <670c9a22-cf5b-3fab-b2f2-a72fbd4451c8@linux.vnet.ibm.com>

On Wed, Oct 04, 2017 at 08:50:49AM +0200, Laurent Dufour wrote:
> On 25/09/2017 18:27, Alexei Starovoitov wrote:
> > On Mon, Sep 18, 2017 at 12:15 AM, Laurent Dufour
> > <ldufour@linux.vnet.ibm.com> wrote:
> >> Despite the unprovable lockdep warning raised by Sergey, I didn't get any
> >> feedback on this series.
> >>
> >> Is there a chance to get it moved upstream ?
> > 
> > what is the status ?
> > We're eagerly looking forward for this set to land,
> > since we have several use cases for tracing that
> > will build on top of this set as discussed at Plumbers.
> 
> Hi Alexei,
> 
> Based on Plumber's note [1], it sounds that the use case is tied to the BPF
> tracing where a call tp find_vma() call will be made on a process's context
> to fetch user space's symbols.
> 
> Am I right ?
> Is the find_vma() call made in the context of the process owning the mm
> struct ?

Hi Laurent,

we're thinking about several use cases on top of your work.
First one is translation of user address to file_handle where
we need to do find_vma() from preempt_disabled context of bpf program.
My understanding that srcu should solve that nicely.
Second is making probe_read() to try harder when address is causing
minor fault. We're thinking that find_vma() followed by some new
light weight filemap_access() that doesn't sleep will do the trick.
In both cases the program will be accessing current->mm

WARNING: multiple messages have this Message-ID (diff)
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	kirill@shutemov.name, Andi Kleen <ak@linux.intel.com>,
	Michal Hocko <mhocko@kernel.org>,
	dave@stgolabs.net, Jan Kara <jack@suse.cz>,
	Matthew Wilcox <willy@infradead.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Mackerras <paulus@samba.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Will Deacon <will.deacon@arm.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	haren@linux.vnet.ibm.com,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	npiggin@gmail.com, bsingharora@gmail.com,
	Tim Chen <tim.c.chen@linux.intel.com>,
	linuxppc-dev@lists.ozlabs.org, "x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH v3 00/20] Speculative page faults
Date: Thu, 5 Oct 2017 16:32:07 -0700	[thread overview]
Message-ID: <20171005233206.vpg446q5k2r4g27r@ast-mbp> (raw)
In-Reply-To: <670c9a22-cf5b-3fab-b2f2-a72fbd4451c8@linux.vnet.ibm.com>

On Wed, Oct 04, 2017 at 08:50:49AM +0200, Laurent Dufour wrote:
> On 25/09/2017 18:27, Alexei Starovoitov wrote:
> > On Mon, Sep 18, 2017 at 12:15 AM, Laurent Dufour
> > <ldufour@linux.vnet.ibm.com> wrote:
> >> Despite the unprovable lockdep warning raised by Sergey, I didn't get any
> >> feedback on this series.
> >>
> >> Is there a chance to get it moved upstream ?
> > 
> > what is the status ?
> > We're eagerly looking forward for this set to land,
> > since we have several use cases for tracing that
> > will build on top of this set as discussed at Plumbers.
> 
> Hi Alexei,
> 
> Based on Plumber's note [1], it sounds that the use case is tied to the BPF
> tracing where a call tp find_vma() call will be made on a process's context
> to fetch user space's symbols.
> 
> Am I right ?
> Is the find_vma() call made in the context of the process owning the mm
> struct ?

Hi Laurent,

we're thinking about several use cases on top of your work.
First one is translation of user address to file_handle where
we need to do find_vma() from preempt_disabled context of bpf program.
My understanding that srcu should solve that nicely.
Second is making probe_read() to try harder when address is causing
minor fault. We're thinking that find_vma() followed by some new
light weight filemap_access() that doesn't sleep will do the trick.
In both cases the program will be accessing current->mm

--
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>

  reply	other threads:[~2017-10-05 23:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-25 16:27 [PATCH v3 00/20] Speculative page faults Alexei Starovoitov
2017-09-25 16:27 ` Alexei Starovoitov
2017-09-25 23:34 ` Andrew Morton
2017-09-25 23:34   ` Andrew Morton
2017-09-28 12:17   ` Laurent Dufour
2017-09-28 12:17     ` Laurent Dufour
2017-09-28 12:29   ` Laurent Dufour
2017-09-28 12:29     ` Laurent Dufour
2017-09-28 20:38     ` Andrew Morton
2017-09-28 20:38       ` Andrew Morton
2017-09-29 15:27       ` Laurent Dufour
2017-09-29 15:27         ` Laurent Dufour
2017-10-03  1:27         ` Michael Ellerman
2017-10-03  1:27           ` Michael Ellerman
2017-10-03  8:03           ` Laurent Dufour
2017-10-03  8:03             ` Laurent Dufour
2017-09-26  8:30 ` Laurent Dufour
2017-09-26  8:30   ` Laurent Dufour
2017-10-04  6:50 ` Laurent Dufour
2017-10-04  6:50   ` Laurent Dufour
2017-10-05 23:32   ` Alexei Starovoitov [this message]
2017-10-05 23:32     ` Alexei Starovoitov
  -- strict thread matches above, loose matches on Subject: below --
2017-09-08 18:06 Laurent Dufour
2017-09-08 18:06 ` Laurent Dufour
2017-09-18  7:15 ` Laurent Dufour
2017-09-18  7:15   ` Laurent Dufour
2017-09-08 17:32 Laurent Dufour
2017-09-08 17:32 ` Laurent Dufour
2017-09-08 17:44 ` Laurent Dufour
2017-09-08 17:44   ` Laurent Dufour

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=20171005233206.vpg446q5k2r4g27r@ast-mbp \
    --to=alexei.starovoitov@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=bsingharora@gmail.com \
    --cc=dave@stgolabs.net \
    --cc=haren@linux.vnet.ibm.com \
    --cc=hpa@zytor.com \
    --cc=jack@suse.cz \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=kirill@shutemov.name \
    --cc=ldufour@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=will.deacon@arm.com \
    --cc=willy@infradead.org \
    --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.