On 11/13/24 17:25, David Hildenbrand wrote: > On 13.11.24 17:18, Vlastimil Babka wrote: >> On 11/13/24 17:09, David Hildenbrand wrote: >>>> --- >>>> Hi, we've seen this in our 5.14 based kernel and it involved the out of >>>> tree gpfs module, but I believe the same thing can happen in LTS's 5.10 >>>> and 5.15 without out of tree modules as well. So I'd like your opinion >>>> on this fix before I propose it to stable as a non-standard >>>> version-specific fix (I don't think we'd want to backport fb3d824d1a46 >>>> with prerequisities). Thanks. >>> >>> I recall seeing+discussing this exact patch already a couple years ago :D >>> >>> Ah, here is the 5.15 version >>> >>> https://lkml.kernel.org/r/20221028075244.3112566-1-songyuanzheng@xxxxxxxxxx >>> >>> And the 5.10 version >>> >>> https://lore.kernel.org/lkml/20221024094911.3054769-1-songyuanzheng@xxxxxxxxxx/ >>> >>> >>> ... I could have sworn they got applied. >>> >>> ... and in linux-5.10.y I see >>> >>> commit 935a8b6202101d7f58fe9cd11287f9cec0d8dd32 >>> Author: Yuanzheng Song <songyuanzheng@xxxxxxxxxx> >>> Date: Fri Oct 28 03:07:05 2022 +0000 >>> >>> mm/memory: add non-anonymous page check in the copy_present_page() >>> >>> The vma->anon_vma of the child process may be NULL because >>> the entire vma does not contain anonymous pages. In this >>> case, a BUG will occur when the copy_present_page() passes >>> a copy of a non-anonymous page of that vma to the >>> page_add_new_anon_rmap() to set up new anonymous rmap. >>> >>> >>> >>> Maybe you missed that the PageAnon() check is simply a couple of lines >>> further down in there? >> >> No I was only looking at the 5.15 branch so far, and seems it was never >> applied there, unlike 5.10. Weird. But thanks for the heads up. > > Indeed, looks like it never got applied to 5.15 ... The author forgot to actually include stable@ will forward it