search for: page_flags_check_at_free

...l remove the entry whilst others will wait on the page lock without holding a reference. This can lead to threads locking or waiting on a page with a zero refcount. Whilst mmap_lock prevents the pages getting freed via munmap() they may still be freed by a migration. This leads to 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. Signed-off-by: Alistair Popple <apopple at nvidia.com> Fixes: b756a3b5e7e...

...remove the entry whilst others will wait on the page lock without holding a reference. This can lead to threads locking or waiting on a folio with a zero refcount. Whilst mmap_lock prevents the pages getting freed via munmap() they may still be freed by a migration. This leads to warnings such as PAGE_FLAGS_CHECK_AT_FREE due to the page being locked when the refcount drops to zero. Fix this by trying to take a reference on the folio before locking it. The code already checks the PTE under the PTL and aborts if the entry is no longer there. It is also possible the folio has been unmapped, freed and re-allocated all...

...tdb_recovered pfn:8c8e00 Jun 20 16:31:13 metamora kernel: page:ffffea0023238000 count:0 mapcount:0 mapping: (null) index:0x7ff509800 Jun 20 16:31:13 metamora kernel: page flags: 0x2fffff00184008(uptodate|head|swapbacked|unevictable) Jun 20 16:31:13 metamora kernel: page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Jun 20 16:31:13 metamora kernel: bad because of flags: Jun 20 16:31:13 metamora kernel: page flags: 0x100000(unevictable) Jun 20 16:31:13 metamora kernel: Modules linked in: iptable_filter binfmt_misc fuse bonding iTCO_wdt iTCO_vendor_support mxm_wmi intel_powerclamp coretemp intel_ra...

On Mon, 27 Mar 2023 23:25:49 -0700 John Hubbard <jhubbard at nvidia.com> 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

...gt; Jun 20 16:31:13 metamora kernel: page:ffffea0023238000 count:0 mapcount:0 > mapping: (null) index:0x7ff509800 > Jun 20 16:31:13 metamora kernel: page flags: > 0x2fffff00184008(uptodate|head|swapbacked|unevictable) > Jun 20 16:31:13 metamora kernel: page dumped because: > PAGE_FLAGS_CHECK_AT_FREE flag(s) set > Jun 20 16:31:13 metamora kernel: bad because of flags: > Jun 20 16:31:13 metamora kernel: page flags: 0x100000(unevictable) > Jun 20 16:31:13 metamora kernel: Modules linked in: iptable_filter > binfmt_misc fuse bonding iTCO_wdt iTCO_vendor_support mxm_wmi > intel_power...

...> This can lead to threads locking or waiting on a page with a zero > refcount. Whilst mmap_lock prevents the pages getting freed via > munmap() they may still be freed by a migration. This leads to An important point! So I'm glad that you wrote it here clearly. > 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: "F...