Subject: Re: pmap_unwire: wiring for pmap 0xfoo va 0xbar didn't change!
To: YAMAMOTO Takashi <email@example.com>
From: Chuck Silvers <firstname.lastname@example.org>
Date: 08/30/2005 09:20:37
On Tue, Aug 30, 2005 at 11:02:33AM +0900, YAMAMOTO Takashi wrote:
> > > but isn't it more generic uvm_vslock/unlock problem?
> > > ie. anyone can modify the mapping between uvm_vslock and uvm_vsunlock.
> > that's a different problem, which requires multiple LWPs in one process
> > to trigger (since I don't think we have any way for a process to modify
> > the mappings of another process). the problem at hand can happen even with
> > traditional single-threaded programs.
> your analysis (a fault overwrites wired mapping with non-wired one)
> implies that the corresponding map entry is not wired, right?
> is it possible without uvm_vslock?
currently, uvm_fault() will pass PMAP_WIRED to pmap_enter() if the vm_map
entry was wired, so the problem at hand (the "pmap_unwire: wiring for ...
didn't change!" messages) will only occur if the vm_map_entry is not wired,
yea. I can't think of anything other than uvm_vslock() that creates the
situation of a wired pmap entry with a non-wired vm_map_entry currently.
> > is there a PR for it?