On 23.01.2023 16:20, George Dunlap wrote: > Re the original question: I've stared at the code for a bit now, and I > can't see anything obviously wrong or dangerous about it. > > But it does make me ask, why do we need the "unpinning_l3" pseudo-argument > at all? Is there any reason not to unconditionally zero out sp->up when we > find a head_type of SH_type_l3_64_shadow? As far as I can tell, sp->list > doesn't require any special state. Why do we make the effort to leave it > alone when we're not unpinning all l3s?
This was an attempt to retain original behavior as much as possible, but I'm afraid that, ... > In fact, is there a way to unpin an l3 shadow *other* than when we're > unpinning all l3's? ... since the answer here is of course "yes", ... > If so, then this patch, as written, is broken -- the > original code clears the up-pointer for *all* L3_64 shadows, regardless of > whether they're on the pinned list; the new patch will only clear the ones > on the pinned list. But unconditionally clearing sp->up could actually fix > that. ... you're right, and I failed (went too far) with that attempt. Plus it'll naturally resolve the parameter-vs-state aspect. Jan
