Re: [PATCH] rmap 22 flush_dcache_mmap_lock

[Andrew Morton]

Hugh Dickins <hugh@xxxxxxxxxxx> wrote:
>
> --- rmap21/include/asm-i386/cacheflush.h	2003-10-08 20:24:56.000000000 +0100
> +++ rmap22/include/asm-i386/cacheflush.h	2004-05-04 21:21:50.956096280 +0100
> @@ -10,6 +10,8 @@
>  #define flush_cache_range(vma, start, end)	do { } while (0)
>  #define flush_cache_page(vma, vmaddr)		do { } while (0)
>  #define flush_dcache_page(page)			do { } while (0)
> +#define flush_dcache_mmap_lock(mapping)		do { } while (0)
> +#define flush_dcache_mmap_unlock(mapping)	do { } while (0)

Looks like this patch will break a lot of architectures.  Was that
intentional?

If not, and if you expect that all other architectures do not need the lock
then the above could be cast as:

#ifndef flush_dcache_mmap_lock
#define flush_dcache_mmap_lock(mapping)		do { } while (0)
#define flush_dcache_mmap_unlock(mapping)	do { } while (0)
#endif

in some generic file.

wrt overloading of tree_lock: The main drawback is that the VM lock ranking
is now dependent upon the architecture.  That, plus the dang thing is
undocumented!

And it seems strange to be grabbing that lock expecting that it will
protect the tree which is elsewhere protected by a different lock.  You
sure this is correct?

I wonder if it wouldn't be better to simply make i_shared_lock irq-safe?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/