Thread (44 messages) 44 messages, 7 authors, 2011-01-10

still nfs problems [Was: Linux 2.6.37-rc8]

From: Trond Myklebust <hidden>
Date: 2011-01-05 21:17:02
Also in: linux-arch, linux-nfs, lkml

On Wed, 2011-01-05 at 13:08 -0800, Linus Torvalds wrote: 
On Wed, Jan 5, 2011 at 1:04 PM, Russell King - ARM Linux
[off-list ref] wrote:
quoted
On Wed, Jan 05, 2011 at 12:48:32PM -0800, Linus Torvalds wrote:
quoted
(You can also force the problem with vmalloc() an then following the
kernel page tables, but I hope nobody does that any more. I suspect
I'm wrong, though, there's probably code that mixes vmalloc and
physical page accesses in various drivers)
Should vmalloc_to_page() (84 users)/vmalloc_to_pfn() (17 users) be
deprecated then? ;)
I do think that the "modern" way of doing it is
"vmap()"/"vm_map_ram()" and friends, and it should be preferred over
using vmalloc() and then looking up the pages.

But in the end, the two approaches really are equivalent, so it's not
like it really matters. So I don't think we need to deprecate things
officially, but obviously we should make people more aware of the
whole virtual alias thing that crops up whenever you use any of these
approaches.
So what should be the preferred way to ensure data gets flushed when
you've written directly to a page, and then want to read through the
vm_map_ram() virtual range? Should we be adding new semantics to
flush_kernel_dcache_page()?

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust at netapp.com
www.netapp.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help