Ping Paolo :) >> This is probably ok but can you maybe outline why we no longer need the >> _lock variant of set_page_dirty? (Or asked differently: why did we use >> the _locked varaint) >> >> Other than that everything looks sane, I am just not sure about this part. >> > > Short answer: As x86 uses this heavily, I was expecting it to do the > right thing. I can't sport any additional page locking in x86 code. > > Long answer: > > mm/page-writeback.c: It only seems to be relevant for !anonymous mappings. > > "set_page_dirty() is racy [...] This is because another CPU could > truncate the page off the mapping and then free the mapping." > > "For pages with a mapping this should be done under the page lock for > the benefit of asynchronous memory errors who prefer a consistent dirty > state. This rule can be broken in some special cases [...]" > > Sounds to me like the worst thing that could happen is losing a dirty > flag. Which should not matter if somebody tries to do nasty stuff with > the mapping either way. > > > But to verify: Paolo, can you recall why we don't need the _locked > variants in kvm common code? > -- Thanks, David
