Thanks for fixing this -- I can't test right now, will do
that next week.

chuq@chuq.com said:
> I would say that any copyin() that reads from the kernel side that
> doesn't have to is broken, so it's only an issue on alpha. =


Well, I wouldn't call it "broken", it is just unusual.
The VM system just shouldn't make assumptions about
implementation details of md code.

For me, it still doesn't look as clean as it should. The
use of "access_type" overloads the VM level permission
control with higher level filesystem semantics.
How about using a bit of "flags" in ubc_fault() and the
pager/fs functions called to tell "this is for a filesystem
write", and let access_type still tell the true type
of the trap? After all, the access_type is named "VM_PROT_*",
so it should be just this instead of a filesystem access type.
(At that point I'm asking myself whether the VM access_type
should be passed to the filesystem vop_getpages at all. Cleaner
would be something with filesystem semantics. Just an idea,
didn't look deeper.)

> I checked in a different fix for this issue,
> update uvm_bio.c.

This is more or less what I meant with
> A flag set somewhere in the upper
> layer, where we still know that we are doing a write(),

I was concerned about concurrency, but since the whole thing
is locked anyway at vnode level this is probably not an issue.
(And there was already state kept between the ubc_alloc()
and the fault handler.)

best regards
Matthias