Messages in this thread |  | | Date | Fri, 13 Sep 2002 10:43:26 -0700 | From | Andrew Morton <> | Subject | Re: [patch] readv/writev rework |
| |
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/
|  |