John Hubbard <jhubbard@xxxxxxxxxx> writes: >> warnings such as PAGE_FLAGS_CHECK_AT_FREE due to the page being locked >> when the refcount drops to zero. Note that during removal of the >> device exclusive entry the PTE is currently re-checked under the PTL >> so no futher bad page accesses occur once it is locked. > > Maybe change that last sentence to something like this: > > "Fix this by taking a page reference before starting to remove a device > exclusive pte. This is done safely in a lock-free way by first getting a > reference via get_page_unless_zero(), and then re-checking after > acquiring the PTL, that the page is the correct one." > > ? > > ...well, maybe that's not all that much help. But it does at least > provide the traditional description of what the patch *does*, at > the end of the commit description. But please treat this as just > an optional suggestion. My wording was probably a little awkward. The intent was to point out the existing code subsequent to taking the page lock was already correct/safe. I figured the patch itself does a pretty good of describing the actual fix so am inclined to leave it. Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes: > On Mon, 27 Mar 2023 23:25:49 -0700 John Hubbard <jhubbard@xxxxxxxxxx> wrote: > >> On the patch process, I see that this applies to linux-stable's 6.1.y >> branch. I'd suggest two things: >> >> 1) Normally, what I've seen done is to post against either the current >> top of tree linux.git, or else against one of the mm-stable branches. >> And then after it's accepted, create a version for -stable. > > Yup. I had to jiggle the patch a bit because > mmu_notifier_range_init_owner()'s arguments have changed. Once this > hits mainline, the -stable maintainers will probably ask for a version > which suits the relevant kernel version(s). Thanks Andrew. That's my bad, I was developing on top of v6.1 and neglected to rebase. Happy to provide versions for -stable as required.
