> It'd be more robust to do something like:
That's also what I had in mind. But all this lockless stuff makes me a bit nervous :)
Yeah the code is not very straightforward... :/
But technically the diff that I pasted here should be enough to fix this... or do you have any alternative approach in mind?
Hopefully, I'm not convinced this code is not buggy, but at least regarding concurrent migration it should be fine with that.
I've been thinking about this...
Actually, it'll make more sense to open-code what pte_map_offset_lock() does in the mainline:
- do not remove the "bad pte" checks, because pte_offset_map() in pre-6.5 kernels doesn't do the check for us unlike the mainline.
- check is_swap_pmd(), pmd_trans_huge(), pmd_devmap() without ptl, but atomically.
- after acquiring ptl in change_pte_range(), check if pmd has changed since step 1 and 2. if yes, retry (like mainline). if no, we're all good.
What do you think?
Apologies for late reply...
Only for -stable, right?
Right!
Does not sound too wrong for me, but I would have to take a closer look at the end result!
FYI I'll test these two patches and see if they survive for a week, and then submit them to -stable. Thanks.
The first patch is also going to be backported since change_pte_range() cannot return negative values without it.
That sound reasonable to me!