[PATCH] Proposed update to the kernel kmap/kunmap API

[PATCH] Proposed update to the kernel kmap/kunmap API

[James Bottomley]

The simple part of the proposal is to give non-highmem architectures
access to the kmap API for the purposes of overriding (this is what the
attached patch does).

The more controversial part of the proposal is that we should now
require all architectures with coherence issues to manage data coherence
via the kmap/kunmap API.  Thus driver writers never have to write code
like

kmap(page)
modify data in page
flush_kernel_dcache_page(page)
kunmap(page)

instead, kmap/kunmap will manage the coherence and driver (and
filesystem) writers don't need to worry about how to flush between kmap
and kunmap.   For most architectures, the page only needs to be flushed
if it was actually written to *and* there are user mappings of it, so
the best implementation looks to be:  clear the page dirty pte bit in
the kernel page tables on kmap and on kunmap, check page->mappings for
user maps, and then the dirty bit, and only flush if it both has user
mappings and is dirty.

James

Index: linux-2.6/include/linux/highmem.h
===================================================================
--- linux-2.6.orig/include/linux/highmem.h      2006-07-26 17:51:09.000000000 -0700
+++ linux-2.6/include/linux/highmem.h   2006-07-26 17:51:18.000000000 -0700
@@ -29,6 +29,7 @@
 
 static inline unsigned int nr_free_highpages(void) { return 0; }
 
+#ifndef ARCH_HAS_KMAP
 static inline void *kmap(struct page *page)
 {
        might_sleep();
@@ -41,6 +42,7 @@
 #define kunmap_atomic(addr, idx)       do { } while (0)
 #define kmap_atomic_pfn(pfn, idx)      page_address(pfn_to_page(pfn))
 #define kmap_atomic_to_page(ptr)       virt_to_page(ptr)
+#endif
 
 #endif /* CONFIG_HIGHMEM */
 

Re: [PATCH] Proposed update to the kernel kmap/kunmap API

[Andrew Morton]

On Sun, 06 Aug 2006 10:01:55 -0500
James Bottomley <James.Bottomley@SteelEye.com> wrote:

> The simple part of the proposal is to give non-highmem architectures
> access to the kmap API for the purposes of overriding (this is what the
> attached patch does).
> 
> The more controversial part of the proposal is that we should now
> require all architectures with coherence issues to manage data coherence
> via the kmap/kunmap API.  Thus driver writers never have to write code
> like

kmap() is a nasty thing.  It has theoretical deadlock problems (which used
to be real ones back in the 2.4 days) and the present implementation uses a
kernel-wide lock.

We've been gradually and sporadically working to make kmap() go away, so
please let's not do anything which encourages its use.

kmap_atomic() is much preferred.  Can this initiative be recast around
kmap_atomic()?

Re: [PATCH] Proposed update to the kernel kmap/kunmap API

[James Bottomley]

On Sun, 2006-08-06 at 12:48 -0700, Andrew Morton wrote:
> kmap() is a nasty thing.  It has theoretical deadlock problems (which used
> to be real ones back in the 2.4 days) and the present implementation uses a
> kernel-wide lock.
> 
> We've been gradually and sporadically working to make kmap() go away, so
> please let's not do anything which encourages its use.
> 
> kmap_atomic() is much preferred.  Can this initiative be recast around
> kmap_atomic()?

Well the API change intercepts both kmap/kunmap and
kmap_atomic/kunmap_atomic; it's designed to be agnostic to the _atomic
bit (I just wrote kmap/kunmap in the Subject line because I was saving
letters).  Since it's intended as a flushing API, it has no context
issues, so the parisc implementation is the similar for both (the only
difference being the return value).

However, while kmap exists, it also has to be intercepted for this
approach to work...

James