Consider a Linux driver that uses **`get_user_pages`** (or `get_page`) to map pages from the calling process. The physical address of the pages are then passed to a hardware device. Both the process and the device may read and write to the pages until the parties decide to end the communication. In particular, the communication may continue using the pages after the system call that calls `get_user_pages` returns. The system call is in effect setting up a **shared memory zone between the process and the hardware device**.

I'm concerned about what happens if the process calls **`fork`** (it could be from another thread, and could happen either while the syscall that calls `get_user_pages` is in progress or later). In particular, if the parent writes to the shared memory area after the fork, what do I know about the underlying physical address (presumably changed due to copy-on-write)? I want to understand:

1. what the kernel needs to do to defend against a potentially misbehaving process (I don't want to create a **security** hole!);
2. what restrictions the process need to obey so that the **functionality** of our driver works correctly (i.e. the physical memory remains mapped at the same address in the parent process).

	* Ideally, I would like the common case where the child process doesn't use our driver at all (it probably calls `exec` almost immediately) to work.
	* Ideally, the parent process should not have to take any special steps when allocating the memory, as we have existing code that passes a stack-allocated buffer to the driver.
	* I'm aware of `madvise` with `MADV_DONTFORK`, and it would be ok to have the memory disappear from the child process's space, but it's not applicable to a stack-allocated buffer.
	* “Don't use fork while you have a connection active with our driver” would be annoying, but acceptable as a last resort if point 1 is satisfied.

I'm willing to be pointed to documentation or source code. I've looked in particular at [Linux Device Drivers](http://lwn.net/Kernel/LDD3/), but didn't find this issue addressed. RTFS applied to even just the relevant part of the kernel source is a bit overwhelming.

The kernel version is not completely fixed but is a recent one (let's say ​≥2.6.26). We're only targetting Arm platforms (single-processor so far but multicore is just round the corner), if it matters.