Message-ID: <3D8223BE.31C564F2@digeo.com>
Date: Fri, 13 Sep 2002 10:43:26 -0700
From: Andrew Morton <akpm@digeo.com>
MIME-Version: 1.0
To: Hirokazu Takahashi <taka@valinux.co.jp>
CC: linux-kernel@vger.kernel.org, janetmor@us.ibm.com
Subject: Re: [patch] readv/writev rework
References: <3D81A200.C1B6A293@digeo.com> <20020913.182350.43012479.taka@valinux.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1450
Lines: 42

Hirokazu Takahashi wrote:
> 
> Hello,
> 
> I fixed the patch.

Thanks again.

> But I have one more question.
> 
> Please consider...
> while a process sleep in copy_*_user() another one may call kmap_atomic
> and kunmap_atomic. And the process will restart and might access the
> wrong page as kunmap_atomic do nothing without CONFIG_DEBUG_HIGHMEM flag.
> I mean it wouldn't any faults as another page is still kmapped.

Yes; this is why it is illegal to sleep, or to switch CPUs by any means
while holding an atomic kmap:


	kmap_atomic(...);
	__copy_*_user(...);
	kunmap_atomic(...);

the kmap_atomic() will increment the preempt count (even on CONFIG_PREEMPT=n).

- The incremented preempt count pins this code path onto this CPU
  while the kmap is held. (This is only relevant to CONFIG_PREEMPT=y)

- The incremented preempt count tells do_page_fault() that we cannot
  handle a pagefault; if a fault is encountered during the copy_*_user(),
  do_page_fault() will arrange for the __copy_*_user() to return a short
  copy.

So.  The code path is atomic, and is pinned to a single CPU.  The atomic
kmap pool uses a different batch of virtual addresses for each CPU (it's
a per-CPU pool of addresses).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/