From owner-freebsd-current  Wed Jul 26 12:58:41 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33])
	by hub.freebsd.org (Postfix) with ESMTP id EFA3C37BF8D
	for <current@freebsd.org>; Wed, 26 Jul 2000 12:58:31 -0700 (PDT)
	(envelope-from luoqi@watermarkgroup.com)
Received: (from luoqi@localhost)
	by lor.watermarkgroup.com (8.10.1/8.10.1) id e6QJwRT13115
	for current@freebsd.org; Wed, 26 Jul 2000 15:58:27 -0400 (EDT)
Date: Wed, 26 Jul 2000 15:58:27 -0400 (EDT)
From: Luoqi Chen <luoqi@watermarkgroup.com>
Message-Id: <200007261958.e6QJwRT13115@lor.watermarkgroup.com>
To: current@freebsd.org
Subject: page fault at write-only mmapped address
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Because there is no write-only hardware page protection on ia32,
a write-only page fault is handled just like a read/write one.
But the mi vm layer distinguishes between the write-only and the
read/write protections, so if the fault takes place in a write-only
region, the vm layer would think that the write-only operation is
trying to read from a write-only address and violates the page protection.
As a consequence, if you want to use the sound device in mmapped mode,
you'll have to map the playback buffer read/write instead of write-only.

I'd like to reverse the way read/write and write-only page faults
are handled, i.e., handle both of them like a write-only fault. Does
anyone know any reason why I shouldn't do that?  I'm currently running
a kernel with this modification and I have seen no ill-effect so far.

-lq


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message