archive mirror
 help / color / mirror / Atom feed
From: Roland Dreier <>
To: Andrea Arcangeli <>
Cc: Hugh Dickins <>,,,
Subject: Re: [PATCH/RFC G-U-P experts] IB/umem: Modernize our get_user_pages() parameters
Date: Mon, 6 Feb 2012 09:46:23 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Andrea, sorry for the slow reply, had to work on other stuff for a bit.

On Mon, Jan 30, 2012 at 12:20 PM, Andrea Arcangeli <> wrote:
> If you map it with an mmap(PROT_READ|PROT_WRITE), force or not force
> won't change a thing in terms of cows. Just make sure you map your
> control memory right, then safely remove force=1 and you won't get the
> control page cowed by mistake. Then if you map it with MAP_SHARED it
> won't be mapped read-only by fork() (leading to either parent or child
> losing the control on the device), Hugh already suggested you to use

Actually this isn't about control memory for the RDMA adapter...
as you mentioned that typically is MMIO and mapped with remap_pfn
stuff, without using any GUP stuff.

I'm talking about the registration of other memory for reading/writing
by a remote system via RDMA.

The reason I'm talking about exporting kernel memory is that I wanted
to do a debugging trick where a kernel module exposed some state
into an mmap'able buffer.  And I wanted to be able to read that state
even if my broken module killed the whole system (in fact exactly
when things crash I want to be able to read the state to figure out
why I crashed!).

So I wrote a trivial userspace program that does nothing but mmap
the buffer, accept RDMA connections from remote systems, and
map the buffer for reading over those connections.  Then I can have
a second system that connects to that process and polls the buffer.

Because all the RDMA state is setup in advance, I can keep polling
even after the first system panics.  It's sort of like that firewire remote
debugging, except I only get access to a limited memory buffer.

The only difficulty is the problem that started this thread, ie a bogus
COW so the remote system ends up polling the wrong pages.  So with
my original patch, I'm able to debug but I guess we agree it's the
wrong fix for the general problem, and I'll write up a patch that adds
what I think is the correct fix (the new FOLL flag) soon.

 - R.

  reply	other threads:[~2012-02-06 17:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-26  5:59 [PATCH/RFC G-U-P experts] IB/umem: Modernize our get_user_pages() parameters Roland Dreier
2012-01-26 20:01 ` Hugh Dickins
2012-01-26 22:45   ` Roland Dreier
2012-01-27 17:28     ` Roland Dreier
2012-01-28  2:31       ` Hugh Dickins
2012-01-28 19:25         ` Jason Gunthorpe
2012-01-30 19:19           ` Roland Dreier
2012-01-28  2:19     ` Hugh Dickins
2012-01-30 19:16       ` Roland Dreier
2012-01-30 20:20         ` Andrea Arcangeli
2012-02-06 17:46           ` Roland Dreier [this message]
2012-01-30 20:34         ` Hugh Dickins
2012-02-06 17:39           ` Roland Dreier
2012-02-07 20:39             ` Hugh Dickins
2012-02-08 23:10               ` Hugh Dickins
2012-02-09 17:50                 ` Roland Dreier
2012-02-09 22:57                   ` Hugh Dickins

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \

* 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).