On 01/12/20(Tue) 18:23, Mark Kettenis wrote: > > Date: Tue, 1 Dec 2020 13:18:59 -0300 > > From: Martin Pieuchot <[email protected]> > > > > On 01/12/20(Tue) 15:18, Mark Kettenis wrote: > > > > Date: Tue, 1 Dec 2020 11:08:50 -0300 > > > > From: Martin Pieuchot <[email protected]> > > > > > > > > As recently pointed out by jmatthew@ these need the lock as well, ok? > > > > > > No. These pages are "unmanaged" and therefore they can not be on any > > > of the page queues and locking those page queues would be pointless. > > > > > > We probably should adjust the documentation to reflect this. > > > > Something like that? > > Yes, because... > > > Btw did you look at the uses of uvm_pagefree(), uvm_pagelookup() & co in > > the various pmap? Do you have any suggestion about how to handle them? > > ...the pages in the various pmaps aren't managed either. However the > use of uvm_pagelookup() in some of the pmaps suggests that we need to > think a bit about PG_TABLED. It doesn't really make sense to use the > page queue lock for that though.
The use of the page queue lock to protect `uobject' is indeed incoherent and questionable. > For the amd64 pmap there are separate objects for each individual > userland pmap. So the per-pmap lock may already provide the necessary > locking. What about the pages allocated via km_alloc(9) in the code randomizing the location of the pmap? > I also need to go back to your previous diff. In hindsight I think > locking the page queues should not be necessary for buffer map pages > either. Why? Is it because `wire_count' and `uanon' are never set for such pages?
