On Thu, 10 Feb 2022, Vlastimil Babka wrote: > On 2/9/22 23:28, Hugh Dickins wrote: > > > > Though taking this apart and putting it back together brings its own > > dangers. That second suggestion probably won't fly very well, with > > 06/13 using mlock_count only while on the unevictable. I'm not sure > > how much rethinking the bisection possibility deserves. > > Right, if it's impractical to change for a potential and hopefully unlikely > bad bisection luck, just a note at the end of each patch's changelog > mentioning what temporarily doesn't work, should be enough. I'm adding a paragraph on that to the end of this 01/13's changelog. If you or akpm think it's better duplicated in 02, 03, 04, 05, 06 then I think it will be easiest if Andrew edits it into them, rather than me updating them one by one. > > As to VM_LOCKED: yes, you're right, at this stage of the series the > > munlock really ought to be clearing VM_LOCKED (even while it doesn't > > go on to do anything about the pages), as it claims in the comment above. > > I removed this line at a later stage (07/13), when changing it to > > mlock_vma_pages_range() serving both mlock and munlock according to > > whether VM_LOCKED is provided - and mistakenly folded back that deletion > > to this patch. End result the same, but better to restore that maskout > > in this patch, as you suggest. > > Great, thanks. That restores any effect on VM_LOCKONFAULT in any case as well. Yes, it turned out to be a mistake in my rebasing the series, the original had the VM_LOCKED_CLEAR_MASK masking still there (up until the interface changes in 07/13). Thanks for spotting that. Vlastimil, many thanks for your valiant effort reviewing this series: it's not at all easy, and I much appreciate the time you've put into it. I'm now going to send out v2 updates to 01, 04, 07, 10, 11 (only), still based on 5.17-rc2, but incorporating your and others' suggestions. Hugh
