![]() | |||||||||||
Messages in this thread |
On Fri, 23 Dec 2005, David S. Miller wrote: > From: Hugh Dickins <hugh@veritas.com> > Date: Sat, 24 Dec 2005 01:21:07 +0000 (GMT) > > > Those "prot = __pgprot(pg_iobits);" lines - any idea why they ever > > got inserted? I guess to add _PAGE_E in the sparc64 case, and > > whatever the equivalent was in the earlier sparc cases? > > Can they safely be corrected early in 2.6.16? > > Corrected? By that you mean removed? Removed would make the source look prettier, but I assume it's there for a reason, and should be corrected rather than removed. I assume the reason is to add some necessary flagbits into prot; and not to violate the permissions model by giving shared write access to areas mapped privately. I was wondering your estimation of the likelihood of problems if we change sparc and sparc64 io_remap_pfn_range to respect the distinction between shared and private, readonly and writable, early in 2.6.16, or early in 2.6.17. But this incident of X trying for MAP_PRIVATE (wanting that to mean shared) before MAP_SHARED shows we cannot assume sanity around here. Looks like we'd need to scatter VM_SHARED tests (like yours) around various driver mmaps at the same time, to get X back to working on them. I knew there were several drivers ignoring vm_page_prot in their calls to (io_)remap_pfn_range; I hadn't realized that whole architectures were doing so in low-level functions used by many. Or is there a good argument that the shared-write/private-readonly distinction makes no sense on anything you might apply io_remap_pfn_range to? That read access to the device amounts to write access, because of side-effects? (I know nothing of this, I'm just trying to guess how I might be fussing unnecessarily over it.) > We have so many hacks > in the tree dealing with this kind of stuff. For example, > pgprot_noncached() as used by things like snd_pccm_lib_mmap_iomem(). pgprot_noncached looks okay to me: not pretty, but doing just what I'd expect, adding in some necessary flagbits while respecting the permissions. A hack yes (a subsequent mprotect would lose the added flagbits I think), but good enough for most. Hugh - 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/ | ||||||||||
| Last update: 2005-12-24 10:11 [from the cache] ©2003-2008 | |||||||||||