[lkml]   [2005]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: More info for DSM w/r/t sunffb on 2.6.15-rc6
On Fri, 23 Dec 2005, David S. Miller wrote:
> From: Hugh Dickins <>
> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-12-24 10:11    [W:0.219 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site