Re: More info for DSM w/r/t sunffb on 2.6.15-rc6

[Hugh Dickins <hugh@veritas.com>]

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/