y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: > > Right, uvm_anon_locklaonpg() dance can happen only in O->A case. > > However, having uvm_anfree() able to release the lock by its interface > > definition is potentially defective. It is the main motivation why I > > want to slightly rework the code into uvm_anon_freelst() which would > > always drop the lock and move freeing of anons to the end point. > > Cleaner, less error prone. > > the committed change seems broken in case uvm_anon_dispose sets > PG_RELEASED. in that case, uvm_anon_freelst should leave the anon as it > will be freed by uvm_anon_release later.
Right. Fix committed. Do we have a better regression test to trigger PG_RELEASED cases? -- Mindaugas
