From: Jason Gunthorpe <jgg@ziepe.ca>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
Will Deacon <will.deacon@arm.com>,
Kostya Serebryany <kcc@google.com>,
Eric Dumazet <edumazet@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
linux-arch@vger.kernel.org, Leon Romanovsky <leon@kernel.org>,
linux-rdma@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Dave Martin <Dave.Martin@arm.com>,
Evgeniy Stepanov <eugenis@google.com>,
Kees Cook <keescook@chromium.org>,
Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
Andrey Konovalov <andreyknvl@google.com>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Dmitry Vyukov <dvyukov@google.com>,
linux-mm@kvack.org, netdev@vger.kernel.org,
Yishai Hadas <yishaih@mellanox.com>,
linux-kernel@vger.kernel.org,
Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Robin Murphy <robin.murphy@arm.com>,
"David S. Miller" <davem@davemloft.net>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Subject: Re: [PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr
Date: Fri, 3 May 2019 20:52:56 -0300 [thread overview]
Message-ID: <20190503235256.GB6660@ziepe.ca> (raw)
In-Reply-To: <20190503162846.GI55449@arrakis.emea.arm.com>
On Fri, May 03, 2019 at 05:28:46PM +0100, Catalin Marinas wrote:
> Thanks Jason and Leon for the information.
>
> On Thu, May 02, 2019 at 03:44:42PM -0300, Jason Gunthorpe wrote:
> > On Tue, Apr 30, 2019 at 12:16:25PM +0100, Catalin Marinas wrote:
> > > > Interesting, the followup question is why mlx4 is only one driver in IB which
> > > > needs such code in umem_mr. I'll take a look on it.
> > >
> > > I don't know. Just using the light heuristics of find_vma() shows some
> > > other places. For example, ib_umem_odp_get() gets the umem->address via
> > > ib_umem_start(). This was previously set in ib_umem_get() as called from
> > > mlx4_get_umem_mr(). Should the above patch have just untagged "start" on
> > > entry?
> >
> > I have a feeling that there needs to be something for this in the odp
> > code..
> >
> > Presumably mmu notifiers and what not also use untagged pointers? Most
> > likely then the umem should also be storing untagged pointers.
>
> Yes.
>
> > This probably becomes problematic because we do want the tag in cases
> > talking about the base VA of the MR..
>
> It depends on whether the tag is relevant to the kernel or not. The only
> useful case so far is for the kernel performing copy_form_user() etc.
> accesses so they'd get checked in the presence of hardware memory
> tagging (MTE; but it's not mandatory, a 0 tag would do as well).
>
> If we talk about a memory range where the content is relatively opaque
> (or irrelevant) to the kernel code, we don't really need the tag. I'm
> not familiar to RDMA but I presume it would be a device accessing such
> MR but not through the user VA directly.
RDMA exposes the user VA directly (the IOVA) as part of the wire
protocol, we must preserve the tag in these cases as that is what the
userspace is using for the pointer.
So the ODP stuff will definately need some adjusting when it interacts
with the mmu notifiers and get user pages.
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2019-05-03 23:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1553093420.git.andreyknvl@google.com>
[not found] ` <44ad2d0c55dbad449edac23ae46d151a04102a1d.1553093421.git.andreyknvl@google.com>
[not found] ` <20190322114357.GC13384@arrakis.emea.arm.com>
[not found] ` <CAAeHK+xE-ywfpVHRhBJVGiqOe0+BYW9awUa10ZP4P6Ggc8nxMg@mail.gmail.com>
[not found] ` <20190328141934.38960af0@gandalf.local.home>
2019-03-29 10:30 ` [PATCH v13 04/20] mm, arm64: untag user pointers passed to memory syscalls Catalin Marinas
2019-04-02 12:47 ` Andrey Konovalov
2019-04-11 16:40 ` Andrey Konovalov
2019-04-26 14:17 ` Catalin Marinas
2019-04-29 14:22 ` Andrey Konovalov
[not found] ` <1e2824fd77e8eeb351c6c6246f384d0d89fd2d58.1553093421.git.andreyknvl@google.com>
[not found] ` <20190429180915.GZ6705@mtr-leonro.mtl.com>
2019-04-30 11:16 ` [PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr Catalin Marinas
2019-04-30 12:03 ` Leon Romanovsky
2019-05-02 18:44 ` Jason Gunthorpe
2019-05-03 16:28 ` Catalin Marinas
2019-05-03 23:52 ` Jason Gunthorpe [this message]
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=20190503235256.GB6660@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=Dave.Martin@arm.com \
--cc=Ramana.Radhakrishnan@arm.com \
--cc=Ruben.Ayrapetyan@arm.com \
--cc=Szabolcs.Nagy@arm.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@google.com \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=edumazet@google.com \
--cc=eugenis@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kcc@google.com \
--cc=keescook@chromium.org \
--cc=kevin.brodsky@arm.com \
--cc=leon@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=vincenzo.frascino@arm.com \
--cc=will.deacon@arm.com \
--cc=yishaih@mellanox.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).