)]}' { "log": [ { "commit": "98fa22f9fff105842c6faded7c4f6c86d6683db8", "tree": "df5db110c17d4dda96a5d3514d7c97cd1cf1bfa2", "parents": [ "d2f3ce7f42140d4830379ae2131148251b1654d6", "0c5e59ab3e2053bd6c0f9666d040fe599cccb945" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:39 2023 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:39 2023 -0500" }, "message": "Merge remote-tracking branch \u0027gitlab/main-5.15.y\u0027 into main-5.15.y\n\nd2f3ce7f42140d4830379ae2131148251b1654d6\n\n- revert one more page_count check in the NUMA hinting fault path\n\n- added the bpf_prefault writable tracepoint which is the dependency\n to run BPFML in non simulation mode\n\nb6580318481399405e1368d38d13ec5c58071352\n\n- remove a PageAnonGup() BUG_ON() from unuse_pte() because it\n triggered a false positive during swapoff().\n\n51d469787f3e79c2f4540267dd204ed75a532613\n\n- optimize the universal fix for the synchronicity of all GUP pins\n further with the PageAnonGup filter\n\nac721fb4219c46772f4dd5861e83335eb3718214\n\n- add synchronicity to all GUP pins, including thread+gup+fork at\n hardblocksize subpage granularity without requiring FOLL_PIN\n\n38ecec4f7a55bb85c8affa97c546991a5351f326\n\n- defer the ksm wse opt-in experimental feature\n\n- deliver full accuracy to the THP mapcount with thp_idx to avoid GUP\n pin synchronicity loss after a THP virtual split followed by fork\n\n- fix a FOLL_LONGTERM synchronicity loss in presence of swapping over\n raid5/blk-integrity that would enable SWP_STABLE_WRITES\n\n- fix a FOLL_LONGTERM synchronicity loss if multiple threads take a\n long term GUP pin at the same time while a child exists\n\n8f74a7d45e5a7d33084bd0958f7a491bbd8f3fc5\n\n- fix kvm_mmu_notifier_change_pte()\n\n608641cdbe7a69741088f8bd0072cab4e1943ff6\n\n- tentative working set estimation for KSM\n- fix missing young bit after NUMA migrate-on-fault and THP splits\n\n47b23851febb91384f497da51c77f23b47376eba\n\n- v5 fix for the KSM swapin anon_vma use after free.\n\ne4dbaa0db656bc7e3fce23695c00dc8fc15d96ea\n\n- v4 fix for the KSM swapin anon_vma use after free.\n\nce4bc19086d1e96ca9ed1491a39aa5291d14b08e\n\n- v3 fix for the KSM swapin anon_vma use after free.\n\n- Cleanup FOLL_UNSHARE definition from code and commit headers and\n other no-op cleanups. It\u0027s a further sync-up with the cleanups from\n the v1 \"mm: COW fixes part 1: fix the COW security issue for THP and\n hugetlb\" submit.\n\na8e5bf4916fecaacbe49f60cedcf20c658b54707\n\n- Tentative fix for the false positive BUILD_BUG_ON build error on some\n arches reported by the kernel test robot.\n\n- Fixed KSM checksum initialization reported by Dan Carpenter and the\n kernel test robot with smatch.\n\n- Worked around a coding style warning from the kernel test robot.\n\n8a4fc2ffa29df05a65a5d662e0db910dcb93a176\n\n- The mprotect optimization that was proposed upstream to skip\n spurious COW faults had a bug in not checking the swapcount which\n could result in erroneously skipping the COW fault with swap\n enabled. This implementation inherited the same bug that the\n original upstream posted patch had. The bug has been found by source\n review and it has been fixed: in this implementation the swapcount\n is now taken into account as required for safety.\n\ne60b432637711574fba6507c2dbc26043f2f7e9e\n\n- optimized wp_page_unshare() with can_read_pin_swap_page(), in\n addition this change is a dependency for the PageKsm FOLL_MM_SYNC\n rework.\n\n- reworked from scratch PageKsm FOLL_MM_SYNC using\n can_read_pin_swap_page(). Enforcing that no FOLL_LONGTERM read pin\n can be ever taken on any PageKsm feels simpler in comparison to\n enforcing no PageAnon can be converted to PageKsm if there\u0027s any\n outstanding pin and that no wrprotected PageAnon can be replaced by\n an equal PageKsm if the PageAnon had any outstanding FOLL_LONGTERM\n pins. Both guarantees are required for FOLL_MM_SYNC to deliver\n full synchronicity to FOLL_LONGTERM pins on VM_MERGEABLE vmas too.\n\ne8a5fe3acb45be705bde7d167d4d89ea6151bec9\n\n- gup_must_unshare() optimized with can_read_pin_swap_page().\n\n- added the page lock in the hugetlbfs gup_must_unshare() path to\n protect against page migration. It\u0027d be ideal if page migration could\n be improved to count how many migration entries it installed and then\n drop the mapcount accordingly only after the refcount freezing.\n\n- Improved FOLL_MM_SYNC for PageKsm: KSM code should cooperate with\n GUP and make sure to never de-dup pages with GUP pins. GUP already does\n its part in unsharing PageKsm pages with the COR fault before taking\n readonly FOLL_LONGTERM pins (with FOLL_MM_SYNC implicitly set).\n\n- Minor: added more consistency to the SWAP\u003dn version of\n reuse_swap_page(), just in case.\n\n129b654f78e4e2386d823d616201b0775d69b382\n\n- More noop cleanups.\n\n- Added a missing update_mmu_tlb() which is also a noop for all arches\n except mips.\n\nc1e6044c5bd1ed2592f7196e7ad99b8c47f7787c\n\n- A solution based on the FOLL_UNSHARE+COR solution that originated in\n this tree has been proposed upstream and the review showed the\n gup_must_unshare() didn\u0027t properly take into account the swapcount.\n\n The lack of swapcount calculation reported upstream is a minor\n implementation issue and requires no change in design to fix. In\n fact it has been fixed in less than 48 hours as demonstrated by this\n quick hotfix update.\n\n It\u0027s worth pointing out that the lack of swapcount calculation in\n the previous version caused zero regressions compared to upstream\n v5.7 and in fact the previous version was preferable than v5.7.\n\n As opposed upstream still randomly corrupts memory if swap is\n enabled with O_DIRECT + swap if using 64k PAGE SIZE on aarch64 and a\n 4k db blocksize, with io_uring and all FOLL_LONGTERM and causes\n various horizontal regressions (for example all swapcache is COWed\n unconditionally even if it\u0027s exclusive).\n\n At the time of this writing, this is the only known solution that\n resolves all known security issues and that introduces zero user ABI\n regression compared to v5.7 and that retains the full power of the\n MM.\n\n In fact this goes beyond what v5.7 could do: with FOLL_MM_SYNC for\n the first time this solution provides full POSIX semantics to all\n FOLL_LONGTERM and short term pins by leveraging the COR (Copy On\n Read) fault.\n\n170df1aaab8e5dc923479b75d91500d6cf366796\n\n- Peter Xu discovered that the THP path of __page_mapcount was reading\n the first tail page instead of the right tailpage in a doublemap.\n This has been corrected.\n\n- David Hildenbrand reported that __page_mapcount and gup_must_unshare\n shared some code paths between THP and hugetlbfs, but the mapcount\n seqcount wasn\u0027t initialized in hugetlbfs which could result in a\n softlockup. This has been corrected and the hugetlbfs paths in\n __page_mapcount and gup_must_unshare don\u0027t share the same code paths\n anymore.\n\n- Merged a permutation from David Hildenbrand that simplifies\n __split_huge_pmd_locked() and reduces the\n page_trans_huge_mapcount_lock() hold time as well.\n\n- Merged FOLL_NOUNSHARE from David Hildenbrand \"deactivate\" the COR\n fault in follow_page(). follow_page() is special because the kernel\n is the \"user\" and the kernel intends to work on the real thing, not\n on the post-COR copy. Obtaining a (post-COR) copy of the page is\n functionally harmless from the userland point of view, but it\u0027d\n defeat various kernel MM optimizations.\n\n- Added a tentative fix for an user after free in KSM rmap reported\n upstream.\n\n- Added a tentative fix to eliminate the KVM COW side channel.\n\n08afe7e6dd05f64c64af20ea11825067d497004b\n\n- added the COR fault and the FAULT_FLAG_UNSHARE support to hugetlbfs.\n\n806134b9aae1c4f00d92bf942869adb0b0e257e4\n\n- added \"mm/userfaultfd: provide unmasked address on page-fault\".\n\n828efbc74a232a39869c1612af02bd75b98bb497\n\n- Improved the 3771dc26618494d2fca1f8489cc1581a63a51ce8 commit header.\n\nd22a27cc8aa072e6fb002ec127b5891253658055\n\n- cleanup gup_must_unshare(): added is_fast_only_in_irq() to document\n and deduplicate the irq_count() check.\n\n6d6837a51fe0e71e3dc9c10deefbd616aeaec1fa\n\n- Added feb889fb40fafc6933339cf1cca8f770126819fb to the list of\n reverts since it\u0027s unnecessary after reverting\n 09854ba94c6aad7886996bfbee2530b3d8a7f4f4.\n\n- Documented more details on the SMP race against pin-fast of\n feb889fb40fafc6933339cf1cca8f770126819fb and\n 9348b73c2e1bfea74ccd4a44fb4ccc7276ab9623 at the end of the commit\n header of 5f3f91f23e41359338a41991fe19e4735d7e56e4 (\"mm: COW:\n restore full accuracy in page reuse\").\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "d2f3ce7f42140d4830379ae2131148251b1654d6", "tree": "df5db110c17d4dda96a5d3514d7c97cd1cf1bfa2", "parents": [ "a75ea1d6ec9ef194a456139406304dae913de076" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Thu Sep 28 15:07:39 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:39 2023 -0500" }, "message": "mm: bpf: trace_bpf_prefault writable raw tracepoint\n\nThis adds a writable raw tracepoint to allow bpf ML models to infer\nfuture page faults.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "a75ea1d6ec9ef194a456139406304dae913de076", "tree": "4c62ad0055fb572d98a1fc495f781a143b5d5fa1", "parents": [ "bc0f7e73bafbb958db429bc26a78a32042bb0c6f" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Oct 11 19:04:15 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:39 2023 -0500" }, "message": "bpf: disable retpoline if unprivileged ebpf is disabled\n\nIf privileges are required and the kernel isn\u0027t in confidentiality\nlockdown, bpf can already read kernel and user memory with\nbpf_probe_read_kernel or bpf_probe_read_user.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "bc0f7e73bafbb958db429bc26a78a32042bb0c6f", "tree": "9bbf3cb41358d117695ebadc321eab8d055cac52", "parents": [ "f27bae11f13518526b1f879c991c3b0423adf912" ], "author": { "name": "Andrii Nakryiko", "email": "andrii@kernel.org", "time": "Thu Jul 14 22:31:43 2022 -0700" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:39 2023 -0500" }, "message": "bpf: fix potential 32-bit overflow when accessing ARRAY map element\n\nIf BPF array map is bigger than 4GB, element pointer calculation can\noverflow because both index and elem_size are u32. Fix this everywhere\nby forcing 64-bit multiplication. Extract this formula into separate\nsmall helper and use it consistently in various places.\n\nSpeculative-preventing formula utilizing index_mask trick is left as is,\nbut explicit u64 casts are added in both places.\n\nFixes: c85d69135a91 (\"bpf: move memory size checks to bpf_map_charge_init()\")\nSigned-off-by: Andrii Nakryiko \u003candrii@kernel.org\u003e\nLink: https://lore.kernel.org/r/20220715053146.1291891-2-andrii@kernel.org\nSigned-off-by: Alexei Starovoitov \u003cast@kernel.org\u003e\n(cherry picked from commit 87ac0d600943994444e24382a87aa19acc4cd3d4)\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "f27bae11f13518526b1f879c991c3b0423adf912", "tree": "3d33bea028abd291ae2a452b0f8bf4ed6aade08c", "parents": [ "1e8758a8f369b39fc274fd93f2d0d2bf7a24ae1b" ], "author": { "name": "David Hildenbrand", "email": "david@redhat.com", "time": "Mon Dec 12 19:20:18 2022 +0100" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "mm/gup_test: free memory allocated via kvcalloc() using kvfree()\n\nWe have to free via kvfree(), not via kfree().\n\nLink: https://lkml.kernel.org/r/20221212182018.264900-1-david@redhat.com\nFixes: c77369b437f9 (\"mm/gup_test: start/stop/read functionality for PIN LONGTERM test\")\nSigned-off-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nReported-by: kernel test robot \u003clkp@intel.com\u003e\nReported-by: Julia Lawall \u003cjulia.lawall@lip6.fr\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "1e8758a8f369b39fc274fd93f2d0d2bf7a24ae1b", "tree": "6ba1bf2aa7c9c2e788c178d26a0a7df3676206cb", "parents": [ "aaa94b485e3cb22ff8a78831ae4f2e9a71309e20" ], "author": { "name": "David Hildenbrand", "email": "david@redhat.com", "time": "Mon Dec 05 20:37:13 2022 +0100" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "mm/gup_test: fix PIN_LONGTERM_TEST_READ with highmem\n\nPatch series \"selftests/vm: fix some tests on 32bit\".\n\nI finally had the time to run some of the selftests written by me\n(especially \"cow\") on x86 PAE. I found some unexpected \"surprises\" :)\n\nWith these changes, and with [1] on top of mm-unstable, the \"cow\" tests\nand the \"ksm_functional_tests\" compile and pass as expected (expected\nfailures with hugetlb in the \"cow\" tests). \"madv_populate\" has one\nexpected test failure -- x86 does not support softdirty tracking.\n\n#1-#3 fix commits with stable commit ids. #4 fixes a test that is not in\nmm-stable yet.\n\nA note that there are many other compile errors/warnings when compiling on\n32bit and with older Linux headers ... something for another day.\n\n[1] https://lkml.kernel.org/r/20221205150857.167583-1-david@redhat.com\n\nThis patch (of 4):\n\n... we have to kmap()/kunmap(), otherwise this won\u0027t work as expected\nwith highmem.\n\nLink: https://lkml.kernel.org/r/20221205193716.276024-1-david@redhat.com\nLink: https://lkml.kernel.org/r/20221205193716.276024-2-david@redhat.com\nFixes: c77369b437f9 (\"mm/gup_test: start/stop/read functionality for PIN LONGTERM test\")\nSigned-off-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nCc: Shuah Khan \u003cshuah@kernel.org\u003e,\nCc: Yang Li \u003cyang.lee@linux.alibaba.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "aaa94b485e3cb22ff8a78831ae4f2e9a71309e20", "tree": "a1ce0b4c0a27036898513b03c8025d0e08a05ff2", "parents": [ "b544a2eb4980622bd4794448090958b8fad38d85" ], "author": { "name": "David Hildenbrand", "email": "david@redhat.com", "time": "Tue Sep 27 13:01:19 2022 +0200" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "mm/gup_test: start/stop/read functionality for PIN LONGTERM test\n\nWe want an easy way to take a R/O or R/W longterm pin on a range and be\nable to observe the content of the pinned pages, so we can properly test\nhow longterm puns interact with our COW logic.\n\n[david@redhat.com: silence a warning on 32-bit]\n Link: https://lkml.kernel.org/r/74adbb51-6e33-f636-8a9c-2ad87bd9007e@redhat.com\n[yang.lee@linux.alibaba.com: ./mm/gup_test.c:281:2-3: Unneeded semicolon]\n Link: https://bugzilla.openanolis.cn/show_bug.cgi?id\u003d2455\n Link: https://lkml.kernel.org/r/20221020024035.113619-1-yang.lee@linux.alibaba.com\nLink: https://lkml.kernel.org/r/20220927110120.106906-7-david@redhat.com\nSigned-off-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nSigned-off-by: Yang Li \u003cyang.lee@linux.alibaba.com\u003e\nCc: Andrea Arcangeli \u003caarcange@redhat.com\u003e\nCc: Christoph von Recklinghausen \u003ccrecklin@redhat.com\u003e\nCc: Don Dutile \u003cddutile@redhat.com\u003e\nCc: Jason Gunthorpe \u003cjgg@nvidia.com\u003e\nCc: John Hubbard \u003cjhubbard@nvidia.com\u003e\nCc: Mike Rapoport \u003crppt@kernel.org\u003e\nCc: Nadav Amit \u003cnamit@vmware.com\u003e\nCc: Peter Xu \u003cpeterx@redhat.com\u003e\nCc: Shuah Khan \u003cshuah@kernel.org\u003e\nCc: Vlastimil Babka \u003cvbabka@suse.cz\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "b544a2eb4980622bd4794448090958b8fad38d85", "tree": "c3a0bfa2afea4b816bcc650204f3ed39e9d2308f", "parents": [ "8734f1fbedbca7778b5af8cb9bb92e5a5e571468" ], "author": { "name": "David Hildenbrand", "email": "david@redhat.com", "time": "Mon May 09 18:20:42 2022 -0700" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "mm/rmap: fix missing swap_free() in try_to_unmap() after arch_unmap_one() failed\n\nPatch series \"mm: COW fixes part 2: reliable GUP pins of anonymous pages\", v4.\n\nThis series is the result of the discussion on the previous approach [2].\nMore information on the general COW issues can be found there. It is\nbased on latest linus/master (post v5.17, with relevant core-MM changes\nfor v5.18-rc1).\n\nThis series fixes memory corruptions when a GUP pin (FOLL_PIN) was taken\non an anonymous page and COW logic fails to detect exclusivity of the page\nto then replacing the anonymous page by a copy in the page table: The GUP\npin lost synchronicity with the pages mapped into the page tables.\n\nThis issue, including other related COW issues, has been summarized in [3]\nunder 3):\n\"\n 3. Intra Process Memory Corruptions due to Wrong COW (FOLL_PIN)\n\n page_maybe_dma_pinned() is used to check if a page may be pinned for\n DMA (using FOLL_PIN instead of FOLL_GET). While false positives are\n tolerable, false negatives are problematic: pages that are pinned for\n DMA must not be added to the swapcache. If it happens, the (now pinned)\n page could be faulted back from the swapcache into page tables\n read-only. Future write-access would detect the pinning and COW the\n page, losing synchronicity. For the interested reader, this is nicely\n documented in feb889fb40fa (\"mm: don\u0027t put pinned pages into the swap\n cache\").\n\n Peter reports [8] that page_maybe_dma_pinned() as used is racy in some\n cases and can result in a violation of the documented semantics: giving\n false negatives because of the race.\n\n There are cases where we call it without properly taking a per-process\n sequence lock, turning the usage of page_maybe_dma_pinned() racy. While\n one case (clear_refs SOFTDIRTY tracking, see below) seems to be easy to\n handle, there is especially one rmap case (shrink_page_list) that\u0027s hard\n to fix: in the rmap world, we\u0027re not limited to a single process.\n\n The shrink_page_list() issue is really subtle. If we race with\n someone pinning a page, we can trigger the same issue as in the FOLL_GET\n case. See the detail section at the end of this mail on a discussion\n how bad this can bite us with VFIO or other FOLL_PIN user.\n\n It\u0027s harder to reproduce, but I managed to modify the O_DIRECT\n reproducer to use io_uring fixed buffers [15] instead, which ends up\n using FOLL_PIN | FOLL_WRITE | FOLL_LONGTERM to pin buffer pages and can\n similarly trigger a loss of synchronicity and consequently a memory\n corruption.\n\n Again, the root issue is that a write-fault on a page that has\n additional references results in a COW and thereby a loss of\n synchronicity and consequently a memory corruption if two parties\n believe they are referencing the same page.\n\"\n\nThis series makes GUP pins (R/O and R/W) on anonymous pages fully\nreliable, especially also taking care of concurrent pinning via GUP-fast,\nfor example, also fully fixing an issue reported regarding NUMA balancing\n[4] recently. While doing that, it further reduces \"unnecessary COWs\",\nespecially when we don\u0027t fork()/KSM and don\u0027t swapout, and fixes the COW\nsecurity for hugetlb for FOLL_PIN.\n\nIn summary, we track via a pageflag (PG_anon_exclusive) whether a mapped\nanonymous page is exclusive. Exclusive anonymous pages that are mapped\nR/O can directly be mapped R/W by the COW logic in the write fault\nhandler. Exclusive anonymous pages that want to be shared (fork(), KSM)\nfirst have to be marked shared -- which will fail if there are GUP pins on\nthe page. GUP is only allowed to take a pin on anonymous pages that are\nexclusive. The PT lock is the primary mechanism to synchronize\nmodifications of PG_anon_exclusive. We synchronize against GUP-fast\neither via the src_mm-\u003ewrite_protect_seq (during fork()) or via\nclear/invalidate+flush of the relevant page table entry.\n\nSpecial care has to be taken about swap, migration, and THPs (whereby a\nPMD-mapping can be converted to a PTE mapping and we have to track\ninformation for subpages). Besides these, we let the rmap code handle\nmost magic. For reliable R/O pins of anonymous pages, we need\nFAULT_FLAG_UNSHARE logic as part of our previous approach [2], however,\nit\u0027s now 100% mapcount free and I further simplified it a bit.\n\n #1 is a fix\n #3-#10 are mostly rmap preparations for PG_anon_exclusive handling\n #11 introduces PG_anon_exclusive\n #12 uses PG_anon_exclusive and make R/W pins of anonymous pages\n reliable\n #13 is a preparation for reliable R/O pins\n #14 and #15 is reused/modified GUP-triggered unsharing for R/O GUP pins\n make R/O pins of anonymous pages reliable\n #16 adds sanity check when (un)pinning anonymous pages\n\n[1] https://lkml.kernel.org/r/20220131162940.210846-1-david@redhat.com\n[2] https://lkml.kernel.org/r/20211217113049.23850-1-david@redhat.com\n[3] https://lore.kernel.org/r/3ae33b08-d9ef-f846-56fb-645e3b9b4c66@redhat.com\n[4] https://bugzilla.kernel.org/show_bug.cgi?id\u003d215616\n\nThis patch (of 17):\n\nIn case arch_unmap_one() fails, we already did a swap_duplicate(). let\u0027s\nundo that properly via swap_free().\n\nLink: https://lkml.kernel.org/r/20220428083441.37290-1-david@redhat.com\nLink: https://lkml.kernel.org/r/20220428083441.37290-2-david@redhat.com\nFixes: ca827d55ebaa (\"mm, swap: Add infrastructure for saving page metadata on swap\")\nSigned-off-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nReviewed-by: Khalid Aziz \u003ckhalid.aziz@oracle.com\u003e\nAcked-by: Vlastimil Babka \u003cvbabka@suse.cz\u003e\nCc: Hugh Dickins \u003chughd@google.com\u003e\nCc: David Rientjes \u003crientjes@google.com\u003e\nCc: Shakeel Butt \u003cshakeelb@google.com\u003e\nCc: John Hubbard \u003cjhubbard@nvidia.com\u003e\nCc: Jason Gunthorpe \u003cjgg@nvidia.com\u003e\nCc: Mike Kravetz \u003cmike.kravetz@oracle.com\u003e\nCc: Mike Rapoport \u003crppt@linux.ibm.com\u003e\nCc: Yang Shi \u003cshy828301@gmail.com\u003e\nCc: \"Kirill A. Shutemov\" \u003ckirill.shutemov@linux.intel.com\u003e\nCc: \"Matthew Wilcox (Oracle)\" \u003cwilly@infradead.org\u003e\nCc: Jann Horn \u003cjannh@google.com\u003e\nCc: Michal Hocko \u003cmhocko@kernel.org\u003e\nCc: Nadav Amit \u003cnamit@vmware.com\u003e\nCc: Rik van Riel \u003criel@surriel.com\u003e\nCc: Roman Gushchin \u003cguro@fb.com\u003e\nCc: Andrea Arcangeli \u003caarcange@redhat.com\u003e\nCc: Peter Xu \u003cpeterx@redhat.com\u003e\nCc: Don Dutile \u003cddutile@redhat.com\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\nCc: Oleg Nesterov \u003coleg@redhat.com\u003e\nCc: Jan Kara \u003cjack@suse.cz\u003e\nCc: Liang Zhang \u003czhangliang5@huawei.com\u003e\nCc: Pedro Demarchi Gomes \u003cpedrodemargomes@gmail.com\u003e\nCc: Oded Gabbay \u003coded.gabbay@gmail.com\u003e\nCc: David Hildenbrand \u003cdavid@redhat.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "8734f1fbedbca7778b5af8cb9bb92e5a5e571468", "tree": "f561f4c3ce7176a2961d8eedc7da07f7e5eb0422", "parents": [ "2a794b1696ad29aa4213e952eeb9b987deabcfe2" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Tue Jan 25 02:03:17 2022 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "mm: ksm: fix use-after-free kasan report in ksm_might_need_to_copy v5\n\nThe non linearity of swap entries that PageKsm generates requires\nspecial revalidation of the anon_vma pointed by the swapcache.\n\nAll detailed commentary can be found in code comments that are more\nimportant than this commit header.\n\nThis should fix the crash reported here:\nhttps://lkml.kernel.org/r/81416741-d11c-61d4-26f9-4546dd874581@huawei.com\n\nv3: the two previous attempts weren\u0027t still fully correct. Hugh\n Dickins pointed two remaining bugs that this new version addresses\n through the forced reinitialization of page-\u003emapping in the\n !page_mapped case, and with the RCU read lock for the !!page_mapped\n case.\n\nv4: Hugh Dickins reported clearing the page-\u003emapping of THP swapcache\n didn\u0027t work as intended since it failed to clear PageAnon which checks\n the head. Luckily THP swapcache cannot point to a swapentry created by\n a PageKsm swapout, so there\u0027s no need of re-initializing the\n page-\u003emapping of a THP.\n\nv5: page-\u003eindex was read from the tail page, but it\u0027s only valid in\n the head page, so instead of doing the math on the linear subpage\n index to pass it, check the PageTransCompound() early on.\n\nFixes: e1c63e110f97 (\"mm: ksm: fix use-after-free kasan report in ksm_might_need_to_copy\")\nFixes: ba6f0ff3981e (\"ksm: fix ksm swapin time optimization\")\nCc: stable@kernel.org\nCo-developed-by: Hugh Dickins \u003chughd@google.com\u003e\nReported-by: Nanyong Sun \u003csunnanyong@huawei.com\u003e\nReported-by: Hugh Dickins \u003chughd@google.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "2a794b1696ad29aa4213e952eeb9b987deabcfe2", "tree": "1a6ec10d60a6e0f2aa970627bc37368fb75008cb", "parents": [ "671b5ac3da49479aa54b2163de16b016a35a1bda" ], "author": { "name": "Nanyong Sun", "email": "sunnanyong@huawei.com", "time": "Fri Jan 14 14:08:59 2022 -0800" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "mm: ksm: fix use-after-free kasan report in ksm_might_need_to_copy\n\nWhen under the stress of swapping in/out with KSM enabled, there is a\nlow probability that kasan reports the BUG of use-after-free in\nksm_might_need_to_copy() when do swap in. The freed object is the\nanon_vma got from page_anon_vma(page).\n\nIt is because a swapcache page associated with one anon_vma now needed\nfor another anon_vma, but the page\u0027s original vma was unmapped and the\nanon_vma was freed. In this case the if condition below always return\nfalse and then alloc a new page to copy. Swapin process then use the\nnew page and can continue to run well, so this is harmless actually.\n\n } else if (anon_vma-\u003eroot \u003d\u003d vma-\u003eanon_vma-\u003eroot \u0026\u0026\n page-\u003eindex \u003d\u003d linear_page_index(vma, address)) {\n\nThis patch exchange the order of above two judgment statement to avoid\nthe kasan warning. Let cpu run \"page-\u003eindex \u003d\u003d linear_page_index(vma,\naddress)\" firstly and return false basically to skip the read of\nanon_vma-\u003eroot which may trigger the kasan use-after-free warning:\n\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n BUG: KASAN: use-after-free in ksm_might_need_to_copy+0x12e/0x5b0\n Read of size 8 at addr ffff88be9977dbd0 by task khugepaged/694\n\n CPU: 8 PID: 694 Comm: khugepaged Kdump: loaded Tainted: G OE - 4.18.0.x86_64\n Hardware name: 1288H V5/BC11SPSC0, BIOS 7.93 01/14/2021\n Call Trace:\n dump_stack+0xf1/0x19b\n print_address_description+0x70/0x360\n kasan_report+0x1b2/0x330\n ksm_might_need_to_copy+0x12e/0x5b0\n do_swap_page+0x452/0xe70\n __collapse_huge_page_swapin+0x24b/0x720\n khugepaged_scan_pmd+0xcae/0x1ff0\n khugepaged+0x8ee/0xd70\n kthread+0x1a2/0x1d0\n ret_from_fork+0x1f/0x40\n\n Allocated by task 2306153:\n kasan_kmalloc+0xa0/0xd0\n kmem_cache_alloc+0xc0/0x1c0\n anon_vma_clone+0xf7/0x380\n anon_vma_fork+0xc0/0x390\n copy_process+0x447b/0x4810\n _do_fork+0x118/0x620\n do_syscall_64+0x112/0x360\n entry_SYSCALL_64_after_hwframe+0x65/0xca\n\n Freed by task 2306242:\n __kasan_slab_free+0x130/0x180\n kmem_cache_free+0x78/0x1d0\n unlink_anon_vmas+0x19c/0x4a0\n free_pgtables+0x137/0x1b0\n exit_mmap+0x133/0x320\n mmput+0x15e/0x390\n do_exit+0x8c5/0x1210\n do_group_exit+0xb5/0x1b0\n __x64_sys_exit_group+0x21/0x30\n do_syscall_64+0x112/0x360\n entry_SYSCALL_64_after_hwframe+0x65/0xca\n\n The buggy address belongs to the object at ffff88be9977dba0\n which belongs to the cache anon_vma_chain of size 64\n The buggy address is located 48 bytes inside of\n 64-byte region [ffff88be9977dba0, ffff88be9977dbe0)\n The buggy address belongs to the page:\n page:ffffea00fa65df40 count:1 mapcount:0 mapping:ffff888107717800 index:0x0\n flags: 0x17ffffc0000100(slab)\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://lkml.kernel.org/r/20211202102940.1069634-1-sunnanyong@huawei.com\nSigned-off-by: Nanyong Sun \u003csunnanyong@huawei.com\u003e\nCc: Hugh Dickins \u003chughd@google.com\u003e\nCc: Kefeng Wang \u003cwangkefeng.wang@huawei.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n(cherry picked from commit e1c63e110f977205ab9dfb38989c54e6e7b52a7b)\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "671b5ac3da49479aa54b2163de16b016a35a1bda", "tree": "a4a265db61e846d30c3a8baef3c0e8b41a080bd9", "parents": [ "a0712530d5667eed20d1eb30c2664341e94b77af" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Dec 08 02:23:15 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "randprotect: KSM: break_ksm: use the COR fault\n\nIf the KSM merge fails the PageKsm must be broken and converted back\nto an Anon page, but this has to be done with the COR fault to avoid\nreopening the KSM COW side channel.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "a0712530d5667eed20d1eb30c2664341e94b77af", "tree": "48d41bf9763ecf7a515400333b24affa19361be5", "parents": [ "c761078df7a77d13ddfaeebe56a0f4bc128b1968" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Thu Jun 16 18:32:29 2022 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "randprotect: KVM: micro-optimize mmu notifier change_pte\n\n__handle_change_spte has been optimized to allow a change of spte pfn\nif both old and new spte are wrprotected as it\u0027s the only case that\nis safe and allowed to materialize here.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "c761078df7a77d13ddfaeebe56a0f4bc128b1968", "tree": "1d96e18b5a41b5dac9bc6c91d0f5f74fa63829ca", "parents": [ "a567f6569380a7b5419f0c3cec5feee75a2b5cff" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Jun 15 19:01:52 2022 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "randprotect: KSM: re-enable mmu_notifier_change_pte during wrprotect\n\nmmu_notifier_invalidate_range_start zaps all shadow pagetables leaving\nnothing to do later for mmu_notifier_change_pte.\n\nThis hurts KVM+KSM by causing an unnecessary vmexit floods even if the\nguest only reads the memory (and KSM does its best effort to only\nmerge memory that doesn\u0027t change frequently and wasn\u0027t supposed to\ntrigger vmexists post merge).\n\nThe s/ptep_clear_flush_notify/ptep_clear_flush/ in commit 0f10851ea475\nresolved the issue only for mmu notifier users that don\u0027t need to\ninvalidate in mmu_notifier_invalidate_range_start because they share\nthe same pgtables of the primary MMU as IOMMUs, but it didn\u0027t solve\nthe issue for the KVM shadow secondary MMU.\n\nReported-by: Jonas Juffinger \u003cjonas.juffinger@lamarr.at\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "a567f6569380a7b5419f0c3cec5feee75a2b5cff", "tree": "1a3cfc338b563cad9f1de08ba228758a2dbd3275", "parents": [ "e67f9e3a80496ceb47a5f31f1400599234a8fe24" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Mon Jun 13 23:55:21 2022 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "randprotect: mm: THP: preserved young bit in the THP split\n\npage migration, in response to an AutoNUMA migrate-on-fault, should\nkeep the pgtable young to avoid slowing down the next memory access.\n\nsplit_huge_page() or page migration for compaction or CMA are more\nneutral cases: the migration entry swpentry format has to be extended\nto retain also the young/old boolean information as it retains other\npgtable bits already. In the meantime, it\u0027s preferable to set the\nyoung bit rather than to clear it, to avoid hurting performance post\nmigration or post physical THP split.\n\nThe below is a measurement of the time to read 10M of virtual memory\nafter physical THP splits as those triggered by KSM and the respective\nnumber of dTLB misses as measured by perf.\n\nbefore: Duration \u003d 740µs - 44,219 dTLB-load-misses:u\nafter: Duration \u003d 23µs - 5,198 dTLB-load-misses:u\n\nCc: stable@kernel.org\nFixes: e9b61f19858a (\"thp: reintroduce split_huge_page()\")\nReported-by: Jonas Juffinger \u003cjonas.juffinger@lamarr.at\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "e67f9e3a80496ceb47a5f31f1400599234a8fe24", "tree": "0704c5918821cbc60c1a4996158fb44b35366a86", "parents": [ "b7e13603fac38367336a8f3d19ef0f28e7ce646b" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Tue Nov 23 12:54:02 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "randprotect: KSM: eliminate the KSM COW side channel\n\nKSM is known to introduce a side channel, that has been analyzed by\nnumerous papers in literature in the past years [1] and also\ndocumented in the various product docs [2]. There was a proposal [3]\nalso on how to close both the \"write\" side channel created by the\nwrite protect fault as well as the \"read\" side channel created by\nphysically indexed CPU caches.\n\nUntil now the KSM side channel could be only accessed locally, but a\nnew paper [4] [5] however shows the \"write\" side channel can be also\naccessed remotely in certain circumstances. The new paper submitted to\narxiv.org on 16 Nov 2021 classifies this new vector as CVE-2021-3714.\n\nThe \"write\" side channel materializes because if an attacker has\ncontrol on the data payload that KSM will try to deduplicate, it\nbecomes possible to measure which data is equal in different\nguests (or processes using MADV_MERGEABLE, or other processes within\nthe same guest) by timing the write access latency after a couple of\nKSM scans without modifications to the data.\n\nThis patches introduces a technique that write protects also those\ncandidate pages that aren\u0027t changing frequently, but that aren\u0027t\nequal, based on a Bernoulli distribution \"p\" (implemented as\n1/2). This results in more COWs, but only for those pages that are\ncandidate for merging because their payload didn\u0027t change frequently\nin the first place.\n\nAt the same time those pages that can be de-duplicated won\u0027t be write\nprotected based on the same Bernoulli distribution \"p\". This reduces\nthe effectiveness of the KSM scan, but it doesn\u0027t waste extra CPU\nother than the scan itself.\n\nAfter a page stops changing for two full KSM scans and it becomes a\ncandidate page for de-deuplication, there will be a 50% chance that a\npage is generating a measurable high \"write\" latency, regardless if it\nis merged or not, in turn the attacker cannot tell if the page that\ngenerated high write access latency, is a PageKSM or not.\n\nThe new secure default is:\n\necho 50 \u003e /sys/kernel/mm/ksm/matched_random_distribution\necho 50 \u003e /sys/kernel/mm/ksm/unmatched_random_distribution\n\nTo restore the less secure behavior:\n\necho 100 \u003e /sys/kernel/mm/ksm/matched_random_distribution\necho 0 \u003e /sys/kernel/mm/ksm/unmatched_random_distribution\n\nFor QA (to retain the determinism of the KSM scan while still\nactivating the side channel obfuscation on unmatched pages):\n\necho 100 \u003e /sys/kernel/mm/ksm/matched_random_distribution\necho 50 \u003e /sys/kernel/mm/ksm/unmatched_random_distribution\n\n[1] https://svs.informatik.uni-hamburg.de/publications/2018/2018-04-10-Lindemann-Memory-Deduplication-Side-Channel.pdf\n[2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_tuning_and_optimization_guide/chap-ksm\n[3] https://download.vusec.net/papers/vusion_sosp17.pdf\n[4] https://arxiv.org/abs/2111.08553\n[5] https://arxiv.org/pdf/2111.08553.pdf\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "b7e13603fac38367336a8f3d19ef0f28e7ce646b", "tree": "58e4b31947d63360ac8f77022c678cd9ce830714", "parents": [ "09e766700bb046f7da3363a77ac8470f7d105c34" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Tue Nov 23 12:54:02 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "randprotect: KSM: only attempt to merge with KSM pages if the payload doesn\u0027t change\n\nWe wait the page data payload to stop changing before merging two anon\npages into a KSM page and before wrprotecting unmatched pages, so we\nhave to wait the payload to stop changing also before merging anon\npages with already existing KSM pages.\n\nv2: fixed checksum initialization reported by Dan Carpenter.\n\nReported-by: kernel test robot \u003clkp@intel.com\u003e\nReported-by: Dan Carpenter \u003cdan.carpenter@oracle.com\u003e\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "09e766700bb046f7da3363a77ac8470f7d105c34", "tree": "90b8ce1a919805b1b8661c112c82d4df5d0a8b26", "parents": [ "5a61c9041a4485eb9607ff32e383a65346661b87" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Tue Nov 23 12:54:02 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "randprotect: KSM: add batch random generator helper\n\ncan_write_protect() returns a random boolean generated from a 50%\nBernoulli distribution (p \u003d 1/2). This is an helper required later.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "5a61c9041a4485eb9607ff32e383a65346661b87", "tree": "c739b5219edc394e782b5552fb9518a6b4923845", "parents": [ "78e8089e340ec80006b98c291d98dc8ac48f8bf6" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Jan 09 18:46:59 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "mm: soft_dirty: fail CLEAR_REFS_SOFT_DIRTY if not built into the kernel\n\nNotify userland it\u0027s running on a kernel with soft dirty not compiled\nin.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "78e8089e340ec80006b98c291d98dc8ac48f8bf6", "tree": "8b91c218cb6f4574356f049ade4f32cac7b4c030", "parents": [ "7ac6822587f2d182c178b4caac8739c15c919c0f" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Tue Dec 03 12:32:01 2019 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "arm64: tlb: skip tlbi broadcast\n\nWith multiple NUMA nodes and multiple sockets, the tlbi broadcast\nshall be delivered through the interconnects in turn increasing the\nCPU interconnect traffic and the latency of the tlbi broadcast\ninstruction. To avoid the synchronous delivery of the tlbi broadcast\nbefore the tlbi instruction can be retired, the hardware would need to\nimplement a replicated mm_cpumask bitflag for each ASID and every CPU\nwould need to tell every other CPU which ASID is being loaded. Exactly\nwhat x86 does with mm_cpumask in software.\n\nEven within a single NUMA node the latency of the tlbi broadcast\ninstruction increases almost linearly with the number of CPUs trying\nto send tlbi broadcasts at the same time.\n\nIf a single thread of the process is running and it\u0027s also running in\nthe CPU issuing the TLB flush, or if no thread of the process are\nrunning, we can achieve full SMP scalability in the arm64 TLB flushng\nby skipping the tlbi broadcasting.\n\nAfter the local TLB flush this means the ASID context goes out of sync\nin all CPUs except the local one. This can be tracked on the per-mm\ncpumask: if the bit is set it means the ASID context is stale for that\nCPU. This results in an extra local ASID TLB flush only when threads\nare running in new CPUs after a TLB flush.\n\nSkipping the tlbi instruction broadcasting is already implemented in\nlocal_flush_tlb_all(), this patch only extends it to flush_tlb_mm(),\nflush_tlb_range() and flush_tlb_page() too.\n\nThe below benchmarks are measured on a non-NUMA 32 CPUs system (ARMv8\nAmpere), so it should be far from a worst case scenario: the\nenterprise kernel config allows multiple NUMA nodes with NR_CPUS set\nby default to 4096.\n\n\u003d\u003d\u003d stock \u003d\u003d\u003d\n\n # cat for-each-cpu.sh\n #!/bin/bash\n\n for i in $(seq `nproc`); do\n \"$@\" \u0026\u003e/dev/null \u0026\n done\n wait\n # perf stat -r 10 -e dummy ./for-each-cpu.sh ./mprotect-threaded 10000\n[..]\n 2.1696 +- 0.0122 seconds time elapsed ( +- 0.56% )\n\n # perf stat -r 10 -e dummy ./for-each-cpu.sh ./gperftools/tcmalloc_large_heap_fragmentation_unittest\n[..]\n 0.99018 +- 0.00360 seconds time elapsed ( +- 0.36% )\n\n # cat sort-compute\n #!/bin/bash\n\n for x in `seq 256`; do\n for i in `seq 32`; do /usr/bin/sort \u003c/usr/bin/sort \u003e/dev/null; done \u0026\n done\n wait\n # perf stat -r 10 -e dummy ./sort-compute\n[..]\n 1.8094 +- 0.0139 seconds time elapsed ( +- 0.77% )\n\n[..]\n\n\u003d\u003d\u003d patch applied \u003d\u003d\u003d\n\n # perf stat -r 10 -e dummy ./for-each-cpu.sh ./mprotect-threaded 10000\n[..]\n 0.13941 +- 0.00449 seconds time elapsed ( +- 3.22% )\n\n # perf stat -r 10 -e dummy ./for-each-cpu.sh ./gperftools/tcmalloc_large_heap_fragmentation_unittest\n[..]\n 0.90510 +- 0.00262 seconds time elapsed ( +- 0.29% )\n\n # perf stat -r 10 -e dummy ./sort-compute\n[..]\n 1.64025 +- 0.00618 seconds time elapsed ( +- 0.38% )\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "7ac6822587f2d182c178b4caac8739c15c919c0f", "tree": "994ae0955ed9530726d158966a92913b43557481", "parents": [ "e9720aeb58674c615f9aa3c4edb96b6777b7748b" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Fri Feb 21 18:20:24 2020 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:38 2023 -0500" }, "message": "arm64: select CPUMASK_OFFSTACK if NUMA\n\nIt\u0027s unclear why normally CPUMASK_OFFSTACK can only be manually\nconfigured \"if DEBUG_PER_CPU_MAPS\" which is not an option meant to be\nenabled on enterprise arm64 kernels.\n\nThe default enterprise kernels NR_CPUS is 4096 which is fairly large.\nSo it\u0027ll save some RAM and it\u0027ll increase reliability to select\nCPUMASK_OFFSET at least when NUMA is selected and a large NR_CPUS is\nto be expected.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "e9720aeb58674c615f9aa3c4edb96b6777b7748b", "tree": "33d430bb7b05c9551d12457aacbbac7153dc7d11", "parents": [ "4ea2a9ff98ac80bc096728c922ccf70c6d2ff7a1" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Mon Feb 03 12:31:56 2020 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "mm: use_mm: fix for arches checking mm_users to optimize TLB flushes\n\nalpha, ia64, mips, powerpc, sh, sparc are relying on a check on\nmm-\u003emm_users to know if they can skip some remote TLB flushes for\nsingle threaded processes.\n\nMost callers of kthread_use_mm() tend to invoke mmget_not_zero() or\nget_task_mm() before kthread_use_mm() to ensure the mm will remain\nalive in between kthread_use_mm() and kthread_unuse_mm().\n\nSome callers however don\u0027t increase mm_users and they instead rely on\nserialization in __mmput() to ensure the mm will remain alive in\nbetween kthread_use_mm() and kthread_unuse_mm(). Not increasing\nmm_users during kthread_use_mm() is however unsafe for aforementioned\narch TLB flushes optimizations. So either mmget()/mmput() should be\nadded to the problematic callers of\nkthread_use_mm()/kthread_unuse_mm() or we can embed them in\nkthread_use_mm()/kthread_unuse_mm() which is more robust.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "4ea2a9ff98ac80bc096728c922ccf70c6d2ff7a1", "tree": "737b99530406d56742edc1de3166b2500f29da75", "parents": [ "e80c1814c1da8a268e539ebbabd190cc943a69a5" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Sep 20 20:06:58 2017 +0200" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "userfaultfd: UFFDIO_REMAP uABI\n\nThis implements the uABI of UFFDIO_REMAP.\n\nNotably one mode bitflag is also forwarded (and in turn known) by the\nlowlevel remap_pages method.\n\nAcked-by: Pavel Emelyanov \u003cxemul@virtuozzo.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "e80c1814c1da8a268e539ebbabd190cc943a69a5", "tree": "a39f0c31206188b399cc9552ad81b913cb0b1918", "parents": [ "373825d3dd551ce5f15d20542ce965794b27c060" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Sep 20 20:06:58 2017 +0200" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "userfaultfd: UFFDIO_REMAP: rmap preparation\n\nAs far as the rmap code is concerned, UFFDIO_REMAP only alters the\npage-\u003emapping and page-\u003eindex. It does it while holding the page\nlock. However page_referenced() is doing rmap walks without taking the\npage lock first, so page_lock_anon_vma_read must be updated to\nre-check that the page-\u003emapping didn\u0027t change after we obtained the\nanon_vma read lock.\n\nUFFDIO_REMAP takes the anon_vma lock for writing before altering the\npage-\u003emapping, so if the page-\u003emapping is still the same after\nobtaining the anon_vma read lock (without the page lock), the rmap\nwalks can go ahead safely (and UFFDIO_REMAP will wait the rmap walk to\ncomplete before proceeding).\n\nUFFDIO_REMAP serializes against itself with the page lock.\n\nAll other places taking the anon_vma lock while holding the mmap_sem\nfor writing, don\u0027t need to check if the page-\u003emapping has changed\nafter taking the anon_vma lock, regardless of the page lock, because\nUFFDIO_REMAP holds the mmap_sem for reading.\n\nThere\u0027s one constraint enforced to allow this simplification: the\nsource pages passed to UFFDIO_REMAP must be mapped only in one vma,\nbut this constraint is an acceptable tradeoff for UFFDIO_REMAP\nusers.\n\nThe source addresses passed to UFFDIO_REMAP should be set as\nVM_DONTCOPY with MADV_DONTFORK to avoid any risk of the mapcount of\nthe pages increasing if some thread of the process forks() before\nUFFDIO_REMAP run.\n\nAcked-by: Pavel Emelyanov \u003cxemul@virtuozzo.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "373825d3dd551ce5f15d20542ce965794b27c060", "tree": "1ff85f4b13adb3d066ed93492f731f2680eca338", "parents": [ "aaf521f4156d748379aca0e048cb0174d7d66706" ], "author": { "name": "Nadav Amit", "email": "namit@vmware.com", "time": "Thu Oct 07 16:50:55 2021 -0700" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "mm/userfaultfd: provide unmasked address on page-fault\n\nUserfaultfd is supposed to provide the full address (i.e., unmasked) of\nthe faulting access back to userspace. However, that is not the case for\nquite some time.\n\nEven running \"userfaultfd_demo\" from the userfaultfd man page provides\nthe wrong output (and contradicts the man page). Notice that\n\"UFFD_EVENT_PAGEFAULT event\" shows the masked address.\n\n\tAddress returned by mmap() \u003d 0x7fc5e30b3000\n\n\tfault_handler_thread():\n\t poll() returns: nready \u003d 1; POLLIN \u003d 1; POLLERR \u003d 0\n\t UFFD_EVENT_PAGEFAULT event: flags \u003d 0; address \u003d 7fc5e30b3000\n\t\t(uffdio_copy.copy returned 4096)\n\tRead address 0x7fc5e30b300f in main(): A\n\tRead address 0x7fc5e30b340f in main(): A\n\tRead address 0x7fc5e30b380f in main(): A\n\tRead address 0x7fc5e30b3c0f in main(): A\n\nAdd a new \"real_address\" field to vmf to hold the unmasked address. It\nis possible to keep the unmasked address in the existing address field\n(and mask whenever necessary) instead, but this is likely to cause\nbackporting problems of this patch.\n\nCc: Andrea Arcangeli \u003caarcange@redhat.com\u003e\nCc: Mike Rapoport \u003crppt@linux.vnet.ibm.com\u003e\nCc: Peter Xu \u003cpeterx@redhat.com\u003e\nCc: Jan Kara \u003cjack@suse.cz\u003e\nCc: stable@vger.kernel.org\nFixes: 1a29d85eb0f19 (\"mm: use vmf-\u003eaddress instead of of vmf-\u003evirtual_address\")\nSigned-off-by: Nadav Amit \u003cnamit@vmware.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "aaf521f4156d748379aca0e048cb0174d7d66706", "tree": "839014c33989048229f0f040295ef5da08ccfc5e", "parents": [ "0a7da10edccd2b757c1e779da55880cdc58b6d60" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Fri Jan 04 19:55:11 2019 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "sched/fair: skip select_idle_sibling() in presence of sync wakeups\n\n__wake_up_sync() gives a very explicit hint to the scheduler that the\ncurrent task will immediately go to sleep and won\u0027t return running\nuntil after the waken tasks has started running again.\n\nThis is common behavior for message passing through pipes or local\nsockets (AF_UNIX or through the loopback interface).\n\nThe scheduler does everything right up to the point it calls\nselect_idle_sibling(). Up to that point the CPU selected for the next\ntask that got a sync-wakeup could very well be the local CPU. That way\nthe sync-waken task will start running immediately after the current\ntask goes to sleep without requiring remote CPU wakeups.\n\nHowever when select_idle_sibling() is called (especially if\nSCHED_MC\u003dy) if there\u0027s at least one idle core in the same package, the\nsync-waken task will be forcefully waken to run on a different idle\ncore, in turn destroying the \"sync\" information and all work done up\nto that point.\n\nWithout this patch under such a workload there will be two different\nCPUs at ~50% utilization and the __wake_up_sync() hint won\u0027t really\nprovide much of benefit if compared to the regular non-sync\nwakeup. With this patch there will be a single CPU used at 100%\nutilization and that increases performance for those common workloads.\n\nWith 112 threads, 28 cores per socket and 2 sockets (2 NUMA nodes):\n\n$ stress-ng --timeout 300 --times --verify --metrics-brief --sockabuse `nproc`\n\nbefore this patch:\n\nstressor bogo ops real time usr time sys time bogo ops/s bogo ops/s\n (secs) (secs) (secs) (real time) (usr+sys time)\nsockabuse 3242769 300.00 211.08 2494.69 10809.22 1198.46\nsockabuse 3243719 300.00 209.97 2491.47 10812.39 1200.74\n\nafter this patch:\n\nsockabuse 3821766 300.00 266.75 3069.13 12739.21 1145.65\nsockabuse 3758514 300.00 264.16 3043.67 12528.37 1136.25\n\nv2: improved for large CPU systems after feedback from \"kernel test robot\".\n\nReported-by: kernel test robot \u003coliver.sang@intel.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "0a7da10edccd2b757c1e779da55880cdc58b6d60", "tree": "6609b7c4bcbaaf959b62dcff401310de61e210f5", "parents": [ "056a70196479d6367cc12a0c05937a59677b1927" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Fri May 07 10:30:43 2021 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "x86: atomic_set needs WRITE_ONCE\n\nAll other atomic_set already use WRITE_ONCE, this was a leftover.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "056a70196479d6367cc12a0c05937a59677b1927", "tree": "16c2bb838ac375911959ab879a35890b77dc8bd3", "parents": [ "4ca4b6c8036829bdc03b15832b678cb6298149ff" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Jan 24 19:19:36 2018 +0100" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "x86/spectre/meltdown: avoid the vulnerability directory to weaken kernel security\n\nIf any of the fixes is disabled to gain some performance back at\nruntime or build time, should not be exposed to unprivileged userland.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "4ca4b6c8036829bdc03b15832b678cb6298149ff", "tree": "285bf9f665268f962288ed4c9e0ac4e7d1582efc", "parents": [ "0aff205ea3cbf27d0df55f583989abdae9c71b0c" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Nov 04 19:14:06 2020 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "x86: deduplicate the spectre_v2_user documentation\n\nThis would need updating to make prctl be the new default, but it\u0027s\nsimpler to delete it and refer to the dup.\n\nFixes: 6b3e64c237c0 (\"x86/speculation: Add seccomp Spectre v2 user space protection mode\")\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "0aff205ea3cbf27d0df55f583989abdae9c71b0c", "tree": "ee18c1f5d9ccf69056f63bbfd689e390e18c371c", "parents": [ "dc894512212b29738c5f20369fdb097864ee74aa" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Nov 04 18:50:54 2020 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "x86: change default to spec_store_bypass_disable\u003dprctl spectre_v2_user\u003dprctl\n\nSwitch the kernel default of SSBD and STIBP to the ones with\nCONFIG_SECCOMP\u003dn (i.e. spec_store_bypass_disable\u003dprctl\nspectre_v2_user\u003dprctl) even if CONFIG_SECCOMP\u003dy.\n\nSeveral motivations listed below:\n\n- If SMT is enabled the seccomp jail can still attack the rest of the\n system even with spectre_v2_user\u003dseccomp by using MDS-HT (except on\n XEON PHI where MDS can be tamed with SMT left enabled, but that\u0027s a\n special case). Setting STIBP become a very expensive window dressing\n after MDS-HT was discovered.\n\n- The seccomp jail cannot attack the kernel with spectre-v2-HT\n regardless (even if STIBP is not set), but with MDS-HT the seccomp\n jail can attack the kernel too.\n\n- With spec_store_bypass_disable\u003dprctl the seccomp jail can attack the\n other userland (guest or host mode) using spectre-v2-HT, but the\n userland attack is already mitigated by both ASLR and pid namespaces\n for host userland and through virt isolation with libkrun or\n kata. (if something if somebody is worried about spectre-v2-HT it\u0027s\n best to mount proc with hidepid\u003d2,gid\u003dproc on workstations where not\n all apps may run under container runtimes, rather than slowing down\n all seccomp jails, but the best is to add pid namespaces to the\n seccomp jail). As opposed MDS-HT is not mitigated and the seccomp\n jail can still attack all other host and guest userland if SMT is\n enabled even with spec_store_bypass_disable\u003dseccomp.\n\n- If full security is required then MDS-HT must also be mitigated with\n nosmt and then spectre_v2_user\u003dprctl and spectre_v2_user\u003dseccomp\n would become identical.\n\n- Setting spectre_v2_user\u003dseccomp is overall lower priority than to\n setting javascript.options.wasm false in about:config to protect\n against remote wasm MDS-HT, instead of worrying about Spectre-v2-HT\n and STIBP which again is already statistically well mitigated by\n other means in userland and it\u0027s fully mitigated in kernel with\n retpolines (unlike the wasm assist call with MDS-HT).\n\n- SSBD is needed to prevent reading the JIT memory and the primary\n user being the OpenJDK. However the primary user of SSBD wouldn\u0027t be\n covered by spec_store_bypass_disable\u003dseccomp because it doesn\u0027t use\n seccomp and the primary user also explicitly declined to set\n PR_SET_SPECULATION_CTRL+PR_SPEC_STORE_BYPASS despite it easily\n could. In fact it would need to set it only when the sandboxing\n mechanism is enabled for javaws applets, but it still declined it by\n declaring security within the same user address space as an\n untenable objective for their JIT, even in the sandboxing case where\n performance would be a lesser concern (for the record: I kind of\n disagree in not setting PR_SPEC_STORE_BYPASS in the sandbox case and\n I prefer to run javaws through a wrapper that sets\n PR_SPEC_STORE_BYPASS if I need). In turn it can be inferred that\n even if the primary user of SSBD would use seccomp, they would\n invoke it with SECCOMP_FILTER_FLAG_SPEC_ALLOW by now.\n\n- runc/crun already set SECCOMP_FILTER_FLAG_SPEC_ALLOW by default, k8s\n and podman have a default json seccomp allowlist that cannot be\n slowed down, so for the #1 seccomp user this change is already a\n noop.\n\n- systemd/sshd or other apps that use seccomp, if they really need\n STIBP or SSBD, they need to explicitly set the\n PR_SET_SPECULATION_CTRL by now. The stibp/ssbd seccomp blind\n catch-all approach was done probably initially with a wishful\n thinking objective to pretend to have a peace of mind that it could\n magically fix it all. That was wishful thinking before MDS-HT was\n discovered, but after MDS-HT has been discovered it become just\n window dressing.\n\n- For qemu \"-sandbox\" seccomp jail it wouldn\u0027t make sense to set STIBP\n or SSBD. SSBD doesn\u0027t help with KVM because there\u0027s no JIT (if it\u0027s\n needed with TCG it should be an opt-in with\n PR_SET_SPECULATION_CTRL+PR_SPEC_STORE_BYPASS and it shouldn\u0027t\n slowdown KVM for nothing). For qemu+KVM STIBP would be even more\n window dressing than it is for all other apps, because in the\n qemu+KVM case there\u0027s not only the MDS attack to worry about with\n SMT enabled. Even after disabling SMT, there\u0027s still a theoretical\n spectre-v2 attack possible within the same thread context from guest\n mode to host ring3 that the host kernel retpoline mitigation has no\n theoretical chance to mitigate. On some kernels a\n ibrs-always/ibrs-retpoline opt-in model is provided that will\n enabled IBRS in the qemu host ring3 userland which fixes this\n theoretical concern. Only after enabling IBRS in the host userland\n it would then make sense to proceed and worry about STIBP and an\n attack on the other host userland, but then again SMT would need to\n be disabled for full security anyway, so that would render STIBP\n again a noop.\n\n- last but not the least: the lack of \"spec_store_bypass_disable\u003dprctl\n spectre_v2_user\u003dprctl\" means the moment a guest boots and\n sshd/systemd runs, the guest kernel will write to SPEC_CTRL MSR\n which will make the guest vmexit forever slower, forcing KVM to\n issue a very slow rdmsr instruction at every vmexit. So the end\n result is that SPEC_CTRL MSR is only available in GCE. Most other\n public cloud providers don\u0027t expose SPEC_CTRL, which means that not\n only STIBP/SSBD isn\u0027t available, but IBPB isn\u0027t available either\n (which would cause no overhead to the guest or the hypervisor\n because it\u0027s write only and requires no reading during vmexit). So\n the current default already net loss in security (missing IBPB)\n which means most public cloud providers cannot achieve a fully\n secure guest with nosmt (and nosmt is enough to fully mitigate\n MDS-HT). It also means GCE and is unfairly penalized in performance\n because it provides the option to enable full security in the guest\n as an opt-in (i.e. nosmt and IBPB). So this change will allow all\n cloud providers to expose SPEC_CTRL without incurring into any\n hypervisor slowdown and at the same time it will remove the unfair\n penalization of GCE performance for doing the right thing and it\u0027ll\n allow to get full security with nosmt with IBPB being available (and\n STIBP becoming meaningless).\n\nExample to put things in prospective: the STIBP enabled in seccomp has\nnever been about protecting apps using seccomp like sshd from an\nattack from a malicious userland, but to the contrary it has always\nbeen about protecting the system from an attack from sshd, after a\nsuccessful remote network exploit against sshd. In fact initially it\nwasn\u0027t obvious STIBP would work both ways (STIBP was about preventing\nthe task that runs with STIBP to be attacked with spectre-v2-HT, but\naccidentally in the STIBP case it also prevents the attack in the\nother direction). In the hypothetical case that sshd has been remotely\nexploited the last concern should be STIBP being set, because it\u0027ll be\nstill possible to obtain info even from the kernel by using MDS if\nnosmt wasn\u0027t set (and if it was set, STIBP is a noop in the first\nplace). As opposed kernel cannot leak anything with spectre-v2 HT\nbecause of retpolines and the userland is mitigated by ASLR already\nand ideally PID namespaces too. If something it\u0027d be worth checking if\nsshd run the seccomp thread under pid namespaces too if available in\nthe running kernel. SSBD also would be a noop for sshd, since sshd\nuses no JIT. If sshd prefers to keep doing the STIBP window dressing\nexercise, it still can even after this change of defaults by opting-in\nwith PR_SPEC_INDIRECT_BRANCH.\n\nUltimately setting SSBD and STIBP by default for all seccomp jails is\na bad sweet spot and bad default with more cons than pros that end up\nreducing security in the public cloud (by giving an huge incentive to\nnot expose SPEC_CTRL which would be needed to get full security with\nIBPB after setting nosmt in the guest) and by excessively hurting\nperformance to more secure apps using seccomp that end up having to\nopt out with SECCOMP_FILTER_FLAG_SPEC_ALLOW.\n\nThe following is the verified result of the new default with SMT\nenabled:\n\n(gdb) print spectre_v2_user_stibp\n$1 \u003d SPECTRE_V2_USER_PRCTL\n(gdb) print spectre_v2_user_ibpb\n$2 \u003d SPECTRE_V2_USER_PRCTL\n(gdb) print ssb_mode\n$3 \u003d SPEC_STORE_BYPASS_PRCTL\n\nlkp@lists.01.org, lkp@intel.com, https://github.com/intel/lkp-tests.git reports:\n\n--------------------------\nFYI, we noticed a 9.6% improvement of apachebench.requests_per_second due to commit:\n\ncommit: 0c8dacb55181dd3eb15f2a230675b8d5eb0788eb (\"x86: change default to spec_store_bypass_disable\u003dprctl spectre_v2_user\u003dprctl\")\nhttps://git.kernel.org/cgit/linux/kernel/git/andrea/aa.git master\n\nin testcase: apachebench\non test machine: 16 threads Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 48G memory\nwith following parameters:\n\n runtime: 300s\n concurrency: 1000\n cluster: cs-localhost\n cpufreq_governor: performance\n ucode: 0x7000019\n\ntest-description: apachebench is a tool for benchmarking your Apache Hypertext Transfer Protocol (HTTP) server.\ntest-url: https://httpd.apache.org/docs/2.4/programs/ab.html\nIn addition to that, the commit also has significant impact on the following tests:\n\n+------------------+------------------------------------------------------------------+\n| testcase: change | apachebench: apachebench.requests_per_second 7.8% improvement |\n| test machine | 16 threads Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 48G memory |\n| test parameters | cluster\u003dcs-localhost |\n| | concurrency\u003d8000 |\n| | cpufreq_governor\u003dperformance |\n| | runtime\u003d300s |\n| | ucode\u003d0x7000019 |\n+------------------+------------------------------------------------------------------+\n\nLink: https://lkml.kernel.org/r/202011041411.AD961737EA@keescook\nFixes: 6b3e64c237c0 (\"x86/speculation: Add seccomp Spectre v2 user space protection mode\")\nAcked-by: Kees Cook \u003ckeescook@chromium.org\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "dc894512212b29738c5f20369fdb097864ee74aa", "tree": "cc433bfd2fda32f91d35d4beb62da51c84af323b", "parents": [ "d8f1dc1351e3bb960a61375e7c908a8f558672ae" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Nov 18 19:08:16 2020 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "x86: restore the write back cache of reserved RAM in iounmap()\n\nIf reserved memory is mapped with ioremap_noncache() or ioremap_wc(),\nthe kernel correctly splits the direct mapping and marks the PAGE_SIZE\ngranular region uncached, so both the virtual direct mapping and the\nsecond virtual mapping in vmap space will be both marked uncached or\nwrite through (i.e. _PAGE_PCD/PWT set on the pagetable).\n\nHowever when iounmap is called later, nothing restores the direct\nmapping write back memtype.\n\nSo if kernel executes this sequence:\n\n SetPageReserved\n ioremap_nocache\n iounmap\n ClearPageReserved\n\nif the page is ever freed later it remains \"uncached\" indefinitely.\n\nThose uncached regions can be tiny compared to the total size of the\nRAM, so it may take a long time until a performance critical piece of\nkernel memory gets allocated in a page that is uncached in the direct\nmapping, long after the iounmap that left it uncached.\n\nHowever when it eventually happens, it generates unexpected severe and\nnon reproducible kernel slowdowns.\n\nThe fix consist in restoring the original write back cache on reserved\nRAM at iounmap() time. This is preferable than supporting multiple\noverlapping ioremap on the same physical range because:\n\n- the malfunction will happen when an ioremap is still outstanding,\n and ideally it\u0027ll happen synchronously at iounmap time, so it should\n be easier to track down than by scanning all kernel pagetables\n searching for any PCD/PWT leftover bits\n\n- two ioremap at the same time of non write back memtype are already\n forbidden by the bugcheck in reserve_ram_page_type that verifies the\n current page type is still _PAGE_CACHE_MODE_WB before\n proceeding. And all ioremap are of write back memtype the patch will\n not make a difference\n\n- even if two ioremap at the same on RAM would be allowed, the caller\n would need to still enforce they all have the same memtype, so it is\n more likely able to enforce that it doesn\u0027t do overlapping ioremaps\n at once than to be able to undo the changes to the direct mapping\n pagetables\n\nFirst reported here:\n\nhttps://lkml.kernel.org/r/20080205011357.GA14712@linux-os.sc.intel.com\n\nFixes: f56d005d3034 (\"x86: no CPA on iounmap\")\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "d8f1dc1351e3bb960a61375e7c908a8f558672ae", "tree": "88f59151acc7417ea9a3fe053f2a8ba3f4470b7c", "parents": [ "b6ec57e1e972c2824a4a83d690ad6d15c204c26c" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed May 19 18:55:21 2021 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "mm: mm_take_all_locks: add cond_resched()\n\nAdd cond_resched() to potentially long tight loops.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "b6ec57e1e972c2824a4a83d690ad6d15c204c26c", "tree": "16206264c3e09dd89e4f6ac58f332ebbd5bd0190", "parents": [ "e116863355ca6a1ebec1d67301bfd963d400ce77" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Fri May 21 16:47:47 2021 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "mm: mprotect: avoid spurious COW faults for exclusive anon pages in cow mapping\n\nFor cow mappings (anon vmas and MAP_PRIVATE of filebacked vmas), if\nthe page is anon, the mapcount+swapcount shows the anon page is\nexclusive, if the vmas has VM_WRITE set we can mark the pte writable.\n\nIn the THP path the page_mapcount is too slow, a boolean retval is\nallowed to return \"non exclusive\" without checking every subpage so\npage_trans_huge_anon_shared() is used as an optimization instead of\npage_mapcount() !\u003d 1, but otherwise they remain identical in design.\n\nThe THP mapcount is already atomic, it uses the readonly seqlock\ninternally, so there\u0027s no need to take any page lock in the mprotect\nfast path for the THP path to skip the spurious COWs on THPs.\n\n\u003d\u003d\u003d\u003d\n #define _GNU_SOURCE\n #include \u003csys/mman.h\u003e\n #include \u003cstdlib.h\u003e\n #include \u003cstring.h\u003e\n #include \u003cstdio.h\u003e\n #include \u003cunistd.h\u003e\n\n #define SIZE (1024*1024*1024)\n\nint main(int argc, char *argv[])\n{\n\tchar *p;\n\tif (posix_memalign((void **)\u0026p, sysconf(_SC_PAGESIZE)*512, SIZE))\n\t\tperror(\"posix_memalign\"), exit(1);\n\tif (madvise(p, SIZE, argc \u003e 1 ? MADV_HUGEPAGE : MADV_NOHUGEPAGE))\n\t\tperror(\"madvise\");\n\texplicit_bzero(p, SIZE);\n\tfor (int loops \u003d 0; loops \u003c 40; loops++) {\n\t\tif (mprotect(p, SIZE, PROT_READ))\n\t\t\tperror(\"mprotect\"), exit(1);\n\t\tif (mprotect(p, SIZE, PROT_READ|PROT_WRITE))\n\t\t\tperror(\"mprotect\"), exit(1);\n\t\texplicit_bzero(p, SIZE);\n\t}\n}\n\u003d\u003d\u003d\u003d\n\nStock 3 runs (lower is better):\n\nMADV_HUGEPAGE\t1.7833 +- 0.0114 seconds time elapsed ( +- 0.64% )\nMADV_NOHUGEPAGE\t14.00 +- 1.06 seconds time elapsed ( +- 7.60% )\n\nPatched 3 runs (lower is better):\n\nMADV_HUGEPAGE\t1.7025 +- 0.0104 seconds time elapsed ( +- 0.61% )\nMADV_NOHUGEPAGE\t2.6165 +- 0.0182 seconds time elapsed ( +- 0.69% )\n\nOriginal idea and patch posted here:\n\nhttps://lkml.kernel.org/r/20210429214801.2583336-1-pcc@google.com\n\nFix for uffd-wp from Peter Xu:\n\nhttps://lkml.kernel.org/r/YKgCsmMVp3wNLLBB@t490s\n\nv2: fix false positive BUG_ON reported by \"kernel test robot\".\n\nv3: found and fixed memory corruption bug caused by the missing\n swapcount calculation in the original patch linked above that would\n trigger with swap enabled (that includes zram). This implementation\n inherited that same bug: page_mapcount \u003d\u003d 1 check wasn\u0027t enough:\n reuse_swap_cache must be checked instead.\n\nReported-by: kernel test robot \u003coliver.sang@intel.com\u003e\nSuggested-by: Peter Collingbourne \u003cpcc@google.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "e116863355ca6a1ebec1d67301bfd963d400ce77", "tree": "1a257531013731024c40045d4a61546cd98ee516", "parents": [ "f0003cd2ba0252a1236c86dce24239d0d74c1956" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Jan 27 02:54:40 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "mm: thp: cleanup and optimize compound_nr\n\nMinor cleanup and minor optimizations to compound_nr and its callers.\n\nThere\u0027s no reason to return \"unsigned long\" in compound_nr, when it\u0027s\ndefined as \"unsigned int\" in the page structure and it\u0027s occasionally\ntruncated back to a 32bit value in its callers.\n\nIn addition its retval should be allowed to be cached in a caller\nsaved register and not be forced to be re-read from memory at every\niteration if any function called in the loop isn\u0027t in scope or inline.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "f0003cd2ba0252a1236c86dce24239d0d74c1956", "tree": "7134854b6eb6a82237efe4a702ac4e3273c589f3", "parents": [ "d54319eaf2ede87b1d39d4fc9a54ccc380b7e02b" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Jan 23 18:42:25 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "mm: thp: optimize total_mapcount() with head_compound_mapcount\n\ntotal_mapcount doesn\u0027t allow tail pages so head_compound_mapcount can\nbe used instead of compound_mapcount and it\u0027s faster.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "d54319eaf2ede87b1d39d4fc9a54ccc380b7e02b", "tree": "b59d97b128b6ba972d20fcf88b8685cdaf870bc5", "parents": [ "374767adea42ce0dcca05c0a8f667e35d285c943" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Jan 23 18:12:45 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "mm: thp: page_trans_huge_mapcount_lock: optimize the lock_page_memcg\n\nOptimize away the lock_page_memcg if not needed.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "374767adea42ce0dcca05c0a8f667e35d285c943", "tree": "edb858be5b744bd20567bce5c39baa5eb5ec804b", "parents": [ "93f4b2a1687b84860d2fe34d42563f94c7c564c1" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat May 08 18:54:34 2021 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "mm: cacheline alignment for page_table_lock and mmap_lock\n\nIt\u0027s important to keep the mmap_lock in an isolated cacheline to avoid\nfalse sharing. While it at put also the page_table_lock in a separate\ncacheline.\n\nThe kernel test robot reported a per_thread_ops -7.2% regression for\nthe will-it-scale mmap2 threaded testcase when the two locks\naccidentally landed in the same cacheline with other fields before the\nprevious location of the page_table_lock.\n\nMoving the mmap_lock in an isolated cacheline as this patch\nimplements, increases the SMP scalability by an extra 3.6%.\n\nv2: fixed the BUILD_BUG_ON for arches with a small AT_VECTOR_SIZE_ARCH\nthat might prefer to save memory. The new layout still avoids false\nsharing with the rest of the mm struct. Those arches that want to\nenforce the locks are in separate cachelines need to explicitly opt-in\nthe BUILD_BUG_ON.\n\nReported-by: kernel test robot \u003clkp@intel.com\u003e\n\nReported-by: kernel test robot \u003coliver.sang@intel.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "93f4b2a1687b84860d2fe34d42563f94c7c564c1", "tree": "325a7e99f343620cdf11613a41c9da3045d2828e", "parents": [ "fbaf87de245cf84f6b21e5b0510986c6b0ea5b5e" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Fri Sep 22 02:04:07 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:37 2023 -0500" }, "message": "Revert \"mm: don\u0027t try to NUMA-migrate COW pages that have other uses\"\n\nThis reverts commit 80d47f5de5e311cbc0d01ebb6ee684e8f4c196c6.\n\n- if the other mappings are paged out and they\u0027re not in use, they\u0027re\n not interfering with NUMA balancing convergence. The only problem is\n when there\u0027s more than one mapping in use, in such case it may be\n impossible to converge into local memory, because local memory of\n one task would still be remote memory for another task.\n\n- if the page has additional pins that cannot be migrated, page\n migration will sort it out later. All short term pins will hopefully\n be gone by then. If this is meant to check for long term pins only,\n then it should have checked the pincount, not the page count.\n\n- if the page is in swapcache possibly with mapcount \u003d\u003d 1 and\n swapcount \u003d 0 (PageAnonExclusive \u003d\u003d true in upstream terms), there\u0027s\n no reason to break NUMA balancing.\n\n - On a side note the upstream PageAnonExclusive is also implementing\n the equation \"page_mapcount+page_swapcount \u003d\u003d 1\". The only\n difference is in implementation terms because it provides the\n result lockless atomically.\n\n - PageAnonExclusive (if set) works safe precisely because it ignores\n the page_count (see the exact math it implements in the previous\n paragraph). Problem is PageAnonExclusive disappears and delivers\n false negatives after fork() runs and then it\u0027s back to square one\n hitting on the page_count and doing pin-breaking and unnecessary\n extra cows.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "fbaf87de245cf84f6b21e5b0510986c6b0ea5b5e", "tree": "5744abcfe5a32274711cc0640163e7bf75fd0d2e", "parents": [ "a7ec17d378d0ec8d33b6d2a0d31ac107718662bb" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sun Jun 11 21:44:30 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "Revert \"mm: thp: avoid false positive copies in fork() with virtually splitted THPs\"\n\nThis reverts commit fe106e2a3657ebd80571119578e6fe43f3b74ef1.\n\nThis worked, but it\u0027s still experimental.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "a7ec17d378d0ec8d33b6d2a0d31ac107718662bb", "tree": "9deed0d84c11d4255b3aef81acad0f38c9f04343", "parents": [ "6f6cacb457e261c27f50d13deef2cf675b0b6e16" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Fri Jun 09 22:32:25 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: thp: avoid false positive copies in fork() with virtually splitted THPs\n\nAfter a virtual THP split, the refcount goes up by HPAGE_PMD_NR-1.\n\nHowever in fork() we hold the mmap_lock for writing so we can just\ncount how many mappings there are for this THP in this process and we\ncan use that number instead of 1, as the base page count to compare\nagainst to be sure there are no further GUP pins on the THP.\n\nEven if all other things would be equal, the extra false positive\ncopies, if they might ever happen, are preferable to deal with in\nfork() than the COW fault, because:\n\n1) there will be at most one extra false positive copy per page no\n matter the amount of later mprotect and other mm activity.\n\n2) if the false positive copy fails the allocation we can fail\n gracefully with -ENOMEM in fork() unlike in the COW fault which is\n forced to segfault.\n\n3) fork() is the only place where we can count the mappings and skip\n the extra copies for virtually splitted THP. The COW fault doesn\u0027t\n hold the right lock for that.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "6f6cacb457e261c27f50d13deef2cf675b0b6e16", "tree": "5744abcfe5a32274711cc0640163e7bf75fd0d2e", "parents": [ "051f877967290dbacff57b3f88cb0dbcc3651565" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Thu Jun 08 13:26:25 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: gup: enable PageAnonGup to reduce the false positive copies in fork\n\nThis reduces the false positives COWs during fork to the intersections\nof the anon pages that have ever been pinned with the ones that still\nhave the page count elevated for some reason and that aren\u0027t currently\nbeing shared.\n\nThe original implementation of the gup page bitflag was proposed in\nthe link. This however handles hugetlbfs and THP too so a simple page\nbitflag isn\u0027t enough and a compound one is required too.\n\nhugetlbfs only needs to reflect the \"anon gup\" bit in the compound\nfield, the subpage bitflag is never set.\n\nTHP has to reflect \"anon gup\" bit in the compound field as well as the\nsubpage bit.\n\nTo monitor the effect:\n\n bpftrace -e \u0027kretprobe:page_needs_cow_for_dma { @tot[retval] \u003d count() } kretprobe:page_needs_cow_for_dma { @tot[retval] \u003d count() }\u0027\n\nRunning the above during sddm plasma login and then starting firefox\non Fedora the output is:\n\n[..]\n@tot[1]: 80\n@tot[0]: 1037304\n\nThe false positives COWs are 80 over a total of \u003e1M COWs. THP in the\ntest was set to \"always\" in the kernel config.\n\nEven if all other things would be equal, the extra false positive\ncopies, if they might ever happen, are preferable to deal with in\nfork() than the COW fault, because:\n\n1) there will be at most one extra false positive copy per page no\n matter the amount of later mprotect and other mm activity.\n\n2) if the false positive copy fails the allocation we can fail\n gracefully with -ENOMEM in fork() unlike in the COW fault which is\n forced to segfault.\n\n3) fork() is the only place where we can count the mappings and skip\n the extra copies for virtually splitted THP. The COW fault doesn\u0027t\n hold the right lock for that.\n\nLink: lkml.kernel.org/r/20090311165833.GI27823@random.random\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "051f877967290dbacff57b3f88cb0dbcc3651565", "tree": "2931142ce91349098f3c127fdc3e56a50d7137f6", "parents": [ "6de8dad8746037c34c3755707cb860c5b810534a" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Thu Jun 08 13:26:25 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: gup: introduce PageAnonGup helpers\n\nThis uses the same technique as David\u0027s PageAnonExclusive. The\nimplementation in turn is based on upstream commit\n78fbe906cc900b33ce078102e13e0e99b5b8c406 .\n\n(cherry picked from commit 78fbe906cc900b33ce078102e13e0e99b5b8c406)\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "6de8dad8746037c34c3755707cb860c5b810534a", "tree": "6a482c5c8a6ca7a147e5cf1f9d151a9d20084787", "parents": [ "3a4badf9f0b074b2666efa3a3449bbd6e901090a" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Thu Jun 08 13:29:49 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: ksm: introduce PageHeadAnonNoKsm\n\nSame as PageAnonNoKsm, but it requires either the head page of a\ncompound page (THP or hugetlbfs) or a non compound page in input.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "3a4badf9f0b074b2666efa3a3449bbd6e901090a", "tree": "3f1c26e389d3dc749dd06709214311256c7faca4", "parents": [ "a93c0e153788d782ff95f8edef60e65f351f6c0e" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Thu Jun 08 13:29:49 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: ksm: introduce PageAnonNoKsm\n\nThis is an helper that returns true only if the Page is Anon, but not\nKsm.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "a93c0e153788d782ff95f8edef60e65f351f6c0e", "tree": "17b1b97e816e9c9829db03d9540dfc4805d63b95", "parents": [ "8cd1f8e1e8fa330299bbbae6f51ec3a1b4fd8a41" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Tue Jun 06 20:56:24 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: gup: fix synchronicity of all GUP pins universally\n\nThis makes O_DIRECT+thread+fork work completely safe with posix\nsemantics retained at subpagesize hardblocksize granularity just like\n!O_DIRECT without the need of FOLL_PIN.\n\nIt further closes any potential discussion about the vmsplice in\nparent followed by fork that should more likely -EFAULT if the parent\nmunmaps the memory backing the previous vmsplice, just before the pipe\nreads it.\n\nAnother view could be that if vmsplice must decouple itself from the\nvirtual memory, then it shouldn\u0027t show any of the memory modifications\ndone with the CPU on the pinned memory either, but it does.\n\nThis change is not done for vmsplice, but it covers vmsplice before\nfork too just because it covers it all. In fact any sign of vmsplice\nusage in an app is a sign of inefficiency and it should be replaced\nwith higher perf IPC methods based on shared memory. Last but not the\nleast the vmsplice implementation is still not safe to use even after\nthis change because it can still take long term gup pins without any\nprivilege and without using FOLL_LONGTERM and without mmu notifiers\nwhich can cause a resource DoS.\n\nThis commit is also deemed unnecessary for all security purposes.\n\nThere\u0027s no expectation userland can takes advantage of the new\nsemantics of short term FOLL_WRITE GUP pins taken before fork either.\n\nThis is done for no practical reason, but just because this is the way.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "8cd1f8e1e8fa330299bbbae6f51ec3a1b4fd8a41", "tree": "132b2205ee063ecd2df7ca5ae40c9e03928061f1", "parents": [ "26544b601846d246db8702ead4eb6d98c9a24e2c" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Mon Jun 05 18:53:12 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: thp: fix COW accuracy on double map THP\n\nDavid reported the do_wp_page() fault would erroenously copy a subpage\nmapped on a double map THP, that was actually exclusive, because some\nother subpage wasn\u0027t exclusive.\n\nThe page_trans_huge_map_swapcount() was doing the right math for the\nwhole THP that is used to decide if the THP COW can reuse the page\nwithout splitting the pmd and falling back to non-THP COW, but it was\ninaccurate and causing too much COWing if used to take the non-THP COW\ndecision.\n\nSince the day write and longterm GUP pins existed, COWing too much is\nalways a bug that causes loss of synchronicity, so this longstanding\nissue also causd a loss of synchronicity of the GUP pin.\n\nThe fix is simple and it just consists of doing the same math but\nsubpage granular if the caller is only interested to reuse the\nsubpage, not the whole THP.\n\nFixes: 6d0a07edd17c (\"mm: thp: calculate the mapcount correctly for THP pages during WP faults\")\nReported-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "26544b601846d246db8702ead4eb6d98c9a24e2c", "tree": "b7def54d0e86705c367a94d0fbd37b6712fc3103", "parents": [ "9088166cc63dc38823b5e9d1cb163f8e6f1dacfa" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Tue Dec 21 22:05:32 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: KSM: improve reuse_swap_page for CONFIG_SWAP\u003dn\n\nThere\u0027s no apparent reason why the SWAP\u003dy version should have the\nPageKsm check while the non-swap version shouldn\u0027t have it. It\u0027s non\nconsistent. It\u0027s safer to be consistent.\n\nPageKsm can still materialize with SWAP\u003dn and it should be not reused.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "9088166cc63dc38823b5e9d1cb163f8e6f1dacfa", "tree": "869333e291761ea904b896876bd87ed8d26bb62c", "parents": [ "13b65d69e4047e7395155904e573ef7636c961c3" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Tue May 30 21:22:19 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: gup: retain synchronicity of concurrent FOLL_LONGTERM R/O pins on SWP_STABLE_WRITE\n\nDavid reported a SMP race condition discovered upstream, might affect\ndownstream too. This is related to SWP_STABLE_WRITE potentially\ncausing an extra COW that shouldn\u0027t have happened.\n\nOnly swapping over zram, raid5 or blk-integrity or similar storage\nthat would set SWP_STABLE_WRITES could trigger it, even then it\u0027s an\nalmost impossible to trigger SMP race condition in real life. The only\ndefect is a FOLL_LONGTERM R/O GUP pin, if taken concurrently with\nheavy swapout activity on the aforementioned storage devices requiring\nstable writes, could lose synchronicity.\n\nShort term R/O GUP pins are always fine to see the only the current\nsnapshot of the memory even if do_wp_page replaces the page later, so\nthey wouldn\u0027t be affected by SWP_STABLE_WRITES.\n\nThis has never been reproduced except in synthetic testing and it was\nfound upstream through code review only.\n\nNOTE: this problem already could happen before the GUP/COW fixes and\nit could have affected RDMA GUP pins well before gup_must_unshare and\nthe COR fault were introduced, but thanks to gup_must_unshare and the\nCOR fault, we can now correct this longstanding defect for good.\n\nFixes: f05714293a59 (\"mm: support anonymous stable page\")\nReported-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "13b65d69e4047e7395155904e573ef7636c961c3", "tree": "090d04991aba94db5f53e188bceb152453149f83", "parents": [ "8c61820016b3b4265b1edfb2df0a8cee3c2a889a" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Tue May 30 20:59:45 2023 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: gup: retain synchronicity of concurrent FOLL_LONGTERM R/O pins taken while child exits\n\nDavid reported a theoretical SMP race discovered upstream, might\naffect downstream too. GUP R/O pins can be taken by GUP-fast (or a\nconcurrent GUP) until the pte has been cleared by __wp_page_copy.\n\nUnsharing a readonly page under a short term R/O pin is always safe,\nso the above scenario doesn\u0027t matter for short term GUP R/O pins.\n\nHowever if two FOLL_LONGTERM R/O (!FOLL_WRITE) GUP try to pin the same\npage concurrently while a child is exiting (i.e while mapcount changes\nfrom from 2 to 1), the second FOLL_LONGTERM could succeed taking the\nPIN without requiring the unshare (by seeing mapcount \u003d\u003d 1), while the\nfirst FOLL_LONGTERM (that has seen mapcount \u003d\u003d 2) hasn\u0027t reached the\n__wp_page_copy yet.\n\nThe fix is to repeat the can_read_pin_swap_page() check in\nwp_page_unshare(), but after clearing the pte to stop GUP-fast too. So\nif a R/O pin could have been taken without requiring unshare,\nwp_page_unshare will also notice that there\u0027s nothing to unshare\nanymore and GUP will try again, not invoking the COR fault next time\naround.\n\nThis only affects concurrent FOLL_LONGTERM !FOLL_WRITE on a readonly\npte while there\u0027s a concurrent child exit.\n\nThis has never been reproduced and it was found upstream through code\nreview only.\n\nReported-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "8c61820016b3b4265b1edfb2df0a8cee3c2a889a", "tree": "996c48e0aae1bca14594cc420b7f6c002cdfc557", "parents": [ "15e716f10a34ddea184eaf4c2e2c19a13b981b2b" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Tue Jan 26 23:19:39 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: gup: enable FOLL_MM_SYNC by default for FOLL_LONGTERM\n\nDrivers that for whatever reason can risk to lose coherency with the\nMM after taking readonly long term pins (as result of later COW\nfaults), can specify __FOLL_LONGTERM to opt-out from FOLL_MM_SYNC.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "15e716f10a34ddea184eaf4c2e2c19a13b981b2b", "tree": "618e198a1f39e1d94200faf1108b8bd5de92d4e5", "parents": [ "73ce6d3858b007661d46e9b0cdf34939a0914eed" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Jan 20 10:23:26 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: gup: document FOLL_MM_SYNC\n\nFOLL_MM_SYNC is fully active in the code, this add the comments that\ndocument its behavior.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "73ce6d3858b007661d46e9b0cdf34939a0914eed", "tree": "8a6f0412f0e5fedfc23ab8395ed93df90f05e5bd", "parents": [ "143fc197abb13cc287ead52590557b19c520449a" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sun Jan 17 13:51:49 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: gup: FOLL_MM_SYNC: zeropage and MAP_PRIVATE pagecache\n\nThis removes the need of FOLL_FORCE|FOLL_WRITE for MAP_PRIVATE\npagecache and zeropages on anonymous mappings.\n\nIf compared to FOLL_FORCE|FOLL_WRITE, FOLL_MM_SYNC will avoid\nunnecessary COWs and it\u0027ll retain MM coherency also for MAP_SHARED\nPROT_READ.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "143fc197abb13cc287ead52590557b19c520449a", "tree": "cfe6e7e4e4ebf001343c3add2f708e38e7341b82", "parents": [ "ba720b98c7269293d13dc5489ff30459181d39aa" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Dec 22 13:32:17 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: gup: FOLL_MM_SYNC: handle FOLL_MM_SYNC in can_read_pin_swap_page()\n\nSince the introduction of FOLL_MM_SYNC we cannot unconditionally take\npins on PageKsm anymore, it depends if FOLL_MM_SYNC is set.\n\nSo this extracts the PageKsm knowledge from can_read_pin_swap_page()\nand it requires the caller to handle the race with KSM creating a\nPageKsm.\n\nKSM also needs do its part and ensure it never converts in place a\n!PageKsm to PageKsm if there\u0027s any oustanding pins and that it won\u0027t\nchange a pgtable from a wrprotected PageAnon to a wrprotected PageKsm\nif there were any outstanding pins on the PageAnon.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "ba720b98c7269293d13dc5489ff30459181d39aa", "tree": "371fd9f42d8cca8fa87a92b8b5d9e35152550f93", "parents": [ "d5b1aa9a145f133ed0e0d68e5dacff046202cb15" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sun Jan 17 13:51:49 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:36 2023 -0500" }, "message": "mm: gup: FOLL_MM_SYNC: enable COR on PageKsm\n\nCombined with the enforced invariant that an already GUP pinned\nPageAnon cannot be merged as PageKsm, this enforces that FOLL_MM_SYNC\ncannot pin any PageKsm.\n\nThis removes the need of FOLL_FORCE|FOLL_WRITE for PageKsm.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "d5b1aa9a145f133ed0e0d68e5dacff046202cb15", "tree": "0b8596e6153ba9aa7da5093bb7548f90164495aa", "parents": [ "177f9baf529f39ee1b3e26e35c2ebfd96f5abf8d" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Jan 20 10:23:26 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: gup: introduce FOLL_MM_SYNC and FAULT_FLAG_MM_SYNC\n\nFOLL_MM_SYNC will provide MM coherency to readonly long term pins.\n\nFOLL_MM_SYNC obsoletes the need for FOLL_FORCE|FOLL_WRITE.\n\nThe spec compliance of FOLL_MM_SYNC was possible thanks to Jann Horn\npointing out the mmap.2 manpage says the following about MAP_PRIVATE:\n\"It is unspecified whether changes made to the file after the mmap()\ncall are visible in the mapped region.\".\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "177f9baf529f39ee1b3e26e35c2ebfd96f5abf8d", "tree": "e37a3d19038562d8671c42ee9da9ee122129735e", "parents": [ "4db95902ae77bd32b2ab5ce21b0c68d083631522" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Mon Dec 20 14:31:42 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: COW/COR: de-dup the lock page locking\n\nThe COW and COR faults use the exact same page locking mechanism.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "4db95902ae77bd32b2ab5ce21b0c68d083631522", "tree": "482fc3b9ac68eb1407eb1b6f4b1960873ca4a9d8", "parents": [ "49fdcd35db477d691efc7bd295c33fe66e113d54" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Mon Jan 18 18:56:28 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: COW: restore full accuracy in page reuse\n\nThis reverts commit 1a0cf26323c80e2f1c58fc04f15686de61bfab0c.\nThis reverts commit be068f29034fb00530a053d18b8cf140c32b12b3.\nThis reverts commit 09854ba94c6aad7886996bfbee2530b3d8a7f4f4.\nThis reverts commit 29a951dfb3c3263c3a0f3bd9f7f2c2cfde4baedb.\nThis reverts commit 9348b73c2e1bfea74ccd4a44fb4ccc7276ab9623.\nThis reverts commit 6ce64428d62026a10cb5d80138ff2f90cc21d367.\nThis reverts commit f4c4a3f48480730214c4f02ffa480f6bf5b0718f.\nThis reverts commit feb889fb40fafc6933339cf1cca8f770126819fb.\n\nAfter a GUP pin is taken, changing the physical address of the page\nmapped in the pagetable causes the holder of the GUP pin to lose\ncoherency with the CPU. It\u0027s a feature that a GUP pinned page acts as\nan anchor for the physical address mapped in the pagetable and\nprevents it from being copied by a spurious COW fault.\n\nThe page_count check in do_wp_page achieves the exact opposite: it\nguarantees a GUP pinned page is copied during a wrprotect fault, even\nif it is exclusive and not shared with other processes.\n\nChecking page_count instead of page_mapcount in do_wp_page makes it\nimpossible to wrprotect any page under a readonly long term GUP pin.\n\nFor example it becomes impossible to use clear_refs to track CPU\nwrites on a virtual region mapped by a readonly RDMA FOLL_LONGTERM GUP\npin. This commit resolves the ABI break which lead to silent mm\ncorruption for certain workloads that worked solid before.\n\nThe inaccuracy added to the COW fault doesn\u0027t seem to provide benefits\nto the MM, but it breaks long term readonly GUP pins and it introduces\nother related horizontal performance regressions.\n\nThis applies to FOLL_PIN and FOLL_GET alike, because from the MM\nstandpoint there is no difference.\n\nHowever, as shown in the below example, even short term GUP pins start\nexhibiting unexpected results with the page_count check. The example\nbelow uses O_DIRECT, on a process under clear_refs. There\u0027s no long\nterm GUP pin here. All GUP pins are transient. fork is never called\nand even when clear_refs is cleared by an external program, fork()\nwould not be involved.\n\nthread0\t\t\t\tthread1\t\t\tother process\n\t\t\t\t\t\t\t(or thread 3)\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\t\t\t\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\t\t\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nread syscall\nO_DIRECT\nread DMA to vaddr+0\nlen \u003d 512 bytes\nGUP(FOLL_WRITE)\nDMA writing to RAM started\n\t\t\t\t\t\t\tclear_refs\n\t\t\t\t\t\t\tpte_wrprotect\n\t\t\t\twrite vaddrA+512\n\t\t\t\tpage_count \u003d\u003d 2\n\t\t\t\twp_copy_page\nread syscall returns\nread lost\n\nThe above O_DIRECT read data corruption is also reproducible with only\nswap enabled without requiring clear_refs. It is enough that the page\npinned by O_DIRECT gets swapped out while the DMA is in flight.\n\nNotwithstanding the fact that failing O_DIRECT at sub-PAGE_SIZE\ngranularity is an ABI break, recvmsg kernel TLS and plenty of other\nGUP FOLL_WRITE iov_iter_get_pages users would write to the memory with\nsub-PAGE_SIZE granularity too. Those recvmsgs are silently lost too as\nwell as the above O_DIRECT gets lost.\n\nIn addition architectures with a PAGE_SIZE much bigger than 4k are\nmore likely to do I/O at sub-PAGE_SIZE granularity.\n\nThat COW must not happen too much is documented in commit\n6d0a07edd17cfc12fdc1f36de8072fa17cc3666f:\n\n\u003d\u003d\nThis will provide fully accuracy to the mapcount calculation in the\nwrite protect faults, so page pinning will not get broken by false\npositive copy-on-writes.\n\u003d\u003d\n\nAnd in the current comment above the THP mapcount:\n\n\u003d\u003d\n * [..] we only use\n * page_trans_huge_mapcount() in the copy-on-write faults where we\n * need full accuracy to avoid breaking page pinning, [..]\n\u003d\u003d\n\nThis revert causes no theoretical security regression because THP is\nnot yet using page_count in do_huge_pmd_wp_page.\n\nThe alternative of this patch would be to replace the mapcount with\nthe page_count in do_huge_pmd_wp_page too in order to really close the\nvmsplice long term GUP attack from child to parent that way.\n\nHowever, because a single transient GUP pin on a tail page would\nelevate the page_count for all other tail pages (unlike the mapcount\nwhich is single page granular), if the COW page reuse inaccuracy would\nbe applied to THP too, it could cross different vmas and the effect\ncould happen at a distance in vmas of different processes. A single\nGUP pin taken on a subpage mapped in a different process could trigger\n511 false positive COWs copies in the local process in the worst case,\nafter a fork(). Which would be yet an additional inefficiency on top\nof the previous cons.\n\nAnother purely performance related regression caused by the spurious\nCOW copies of exclusive anonymous memory, is that we cannot assume\nanymore that deferred TLB flushes after wrprotection are noops with\nrespect to the COW fault. The stale writable TLBs can be seen as the\nequivalent of a driver holding a GUP pin on exclusive (non shared)\nanonymous memory. If spurious COW copies can happen, the physical\naddress of the page will change after the copy. So before the COW\nfault starts copying the memory to the new physical location, to avoid\nlosing writes on the page, the stale writable TLBs have to be\ninvalidated. This is non a functional regression because it is always\npossible to \"flush the TLB\" at any time (or alternatively to wait for\nthe deferred TLB flushes to be executed). However, what\u0027s not possible\nis to \"flush the GUP pin\" (nor to wait for it to be released).\n\nlkp@lists.01.org, lkp@intel.com, https://github.com/intel/lkp-tests.git reports:\n\n--------\nFYI, we noticed a 1.5% improvement of vm-scalability.median due to commit:\n\ncommit: bcb0df12bc47f2c2bb42b66eb77fe34e509de0b8 (\"mm: COW: restore full accuracy in page reuse\")\n\nin testcase: vm-scalability\non test machine: 96 threads Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 256G memory\nwith following parameters:\n\n runtime: 300s\n size: 8T\n test: anon-cow-seq-hugetlb\n cpufreq_governor: performance\n ucode: 0x5003006\n\n vm-scalability.median\n\n 366000 +------------------------------------------------------------------+\n | O |\n 364000 |-+ O O O O O O |\n | O O O O O O O O O OO |\n | O O O O O O O O O O O O O |\n 362000 |-O O O |\n | O O O+ O + |\n 360000 |-+ :: :+ + |\n | .+ :: + + :: +.+ |\n 358000 |-+ .+ : .+ : + + + ++ : : :: : |\n |.+ .+ .+. + :.+ +.+.: + +: +: + : : :: + : |\n | :.+ + + + + + :.+ :.+ : : + +: |\n 356000 |-++ + + : + |\n | + |\n 354000 +------------------------------------------------------------------+\n\n[*] bisect-good sample\n[O] bisect-bad sample\n--------\nFYI, we noticed a 24.9% improvement of pmbench.throughput.aps due to commit:\n\ncommit: c4e16aa6ded51f55740e7f24525e5818cb35806c (\"mm: COW: restore full accuracy in page reuse\")\n\nin testcase: pmbench\non test machine: 96 threads 2 sockets Intel(R) Xeon(R) Platinum 8260L CPU @ 2.40GHz with 128G memory\nwith following parameters:\n\n runtime: 600s\n disk: 1SSD\n priority: 1\n cpunodebind: 1\n membind: 1\n thp_enabled: never\n thp_defrag: never\n nr_processes: 2\n nr_threads: 4\n pattern: normal_ih\n ratio: 90\n cold: 1\n initialize: 1\n total_setsize: 128G\n cpu_node_bind: even\n cpufreq_governor: performance\n debug-setup: yhnvme-mth\n sc_numa_balancing: 0\n sc_swappiness: 100\n ucode: 0x400002c\n\ntest-description: pmbench - paging and virtual memory benchmark\n\n pmbench.latency.ns.average\n\n 2600 +--------------------------------------------------------------------+\n 2500 |-+ : |\n | +. + : : + |\n 2400 |-+ + + :+ : : : |\n 2300 |-+ + +: + : :: |\n 2200 |++.+ + : .+. + +.+ : : + + |\n 2100 |-+ + .+ + : : : + :+ : : : :|\n | +.+ : : :.+. + + : .+. : +.+. .++. :|\n 2000 |-+ + + + +.++ + + + |\n 1900 |-+ |\n 1800 |-+ |\n 1700 |-+ O O |\n | O O |\n 1600 |-O O O O O |\n 1500 +--------------------------------------------------------------------+\n\n[*] bisect-good sample\n[O] bisect-bad sample\n--------\n\npmbench shows a performance improvement higher than with the below\npatch applied on top of 09854ba94c6aad7886996bfbee2530b3d8a7f4f4. That\nis because the below fix still cannot avoid extra allocation and\ncopies when the COW fault erroneously fails to reuse the\nswapcache. The below patch and extra code can then be reverted as well\non top of this commit, because it becomes a noop.\n\nhttps://lkml.kernel.org/r/20210519013313.1274454-1-ying.huang@intel.com\n\nCommit feb889fb40fafc6933339cf1cca8f770126819fb says: \"(c) we could\njust make do_wp_page() not COW the pinned page (which was what we\nhistorically did before that \"mm: do_wp_page() simplification\"\ncommit)\". This commit precisely implements option c) so\nfeb889fb40fafc6933339cf1cca8f770126819fb becomes unnecessary and can\nbe reverted too.\n\nLast but not the least: the check for page_maybe_dma_pinned() added by\nboth feb889fb40fafc6933339cf1cca8f770126819fb and\n9348b73c2e1bfea74ccd4a44fb4ccc7276ab9623 in the attempt to avoid\nsilent MM corruption if using FOLL_LONGTERM with swap enabled or\nFOLL_LONGTERM in combination with clear_refs tracking can SMP race\nwith pin-fast. So those two commits were only effective at rendering\nthe silent MM corruption less reproducible, they didn\u0027t prevent it. To\nclose the race the check for page_maybe_dma_pinned() would need to be\nprotected by the write_protect_seq like in fork(). So this commit that\nreverts 09854ba94c6aad7886996bfbee2530b3d8a7f4f4 eliminates the risk\nof silent MM corruption in the two aforementioned scenarios too.\n\nLink: https://lkml.kernel.org/r/20210107200402.31095-1-aarcange@redhat.com\nFixes: 09854ba94c6a (\"mm: do_wp_page() simplification\")\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "49fdcd35db477d691efc7bd295c33fe66e113d54", "tree": "65962ea030a46d29468fd75a32d42e2bef3f8c4c", "parents": [ "d1ddd6ea363334c030f91b640df448ca3829ba53" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Feb 06 04:04:00 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: thp: replace the page lock with the seqlock for the THP mapcount\n\nThe page lock has been superseded by the THP mapcount seqlock.\n\nThis reverts commit 1c2f67308af4c102b4e1e6cd6f69819ae59408e0.\nThis reverts commit c444eb564fb16645c172d550359cb3d75fe8a040.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "d1ddd6ea363334c030f91b640df448ca3829ba53", "tree": "743e35a0aef21287049406911281e49f831a4c67", "parents": [ "0fe398f64c1fb9383cfef6cdfd629e6ebd807022" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Jan 13 17:54:56 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: COW: skip the page lock in the COW copy path\n\nThe only guarantee required to be allowed to copy is that mapcount is\nnot equal 1. That is enough not to risk overestimating mapcount.\n\nThis should retain the performance improvement reported below for the\nCOW copy path, but without introducing any regression to the page\nreuse accuracy.\n\nhttps://lkml.kernel.org/r/20200914024321.GG26874@shao2-debian\n\nIn addition this optimizes the THP COW with the same logic.\n\nlkp@lists.01.org, lkp@intel.com, https://github.com/intel/lkp-tests.git reports:\n\n---------\nFYI, we noticed a 55.2% improvement of vm-scalability.throughput due to commit:\n\ncommit: 599aa62474f51a470408b28fd4365320a5357aca (\"mm: COW: skip the page lock in the COW copy path\")\nhttps://git.kernel.org/cgit/linux/kernel/git/andrea/aa.git master\n\nin testcase: vm-scalability\non test machine: 192 threads Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with 192G memory\nwith following parameters:\n\n runtime: 300s\n size: 8T\n test: anon-cow-seq\n cpufreq_governor: performance\n ucode: 0x5003006\n\n vm-scalability.throughput\n\n 6e+07 +-------------------------------------------------------------------+\n | OO O O O O O O O O O O O |\n 5e+07 |-+ O O O OO O O O O |\n | +. +. O .+. +.O +. .+ O |\n |.++ : + +.+.++. .+.++.+.+.++ +.+ +.+.+ +.+ +.+.+.+ |\n 4e+07 |-+: : + : |\n | : : +.+.+.++.|\n 3e+07 |-+ : : |\n | : : |\n 2e+07 |-+ : : |\n | : : |\n | : : |\n 1e+07 |-+ : |\n | : |\n 0 +-------------------------------------------------------------------+\n---------\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "0fe398f64c1fb9383cfef6cdfd629e6ebd807022", "tree": "f64ef0e174837e84bc4b21576a93ff45f7065fbc", "parents": [ "92a92dfb58f277a39b31c7087e07c43f0b7d426a" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Thu Nov 04 02:01:19 2021 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: hugetlbfs: gup: gup_must_unshare(): enable hugetlbfs\n\nEnable the hugetlbfs FAULT_FLAG_UNSHARE/COR support in\ngup_must_unshare().\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "92a92dfb58f277a39b31c7087e07c43f0b7d426a", "tree": "6371eaefa9ff9da04a9fb0af68cea98ac9c5d970", "parents": [ "7d5e217ddabed51681c6dfa1aa7f32b5120ee7a8" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Thu Nov 04 00:48:57 2021 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: hugetlbfs: FOLL_FAULT_UNSHARE\n\nInvoke the COR fault by setting FOLL_FAULT_UNSHARE in hugetlbfs if\ngup_must_unshare() will later require it.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "7d5e217ddabed51681c6dfa1aa7f32b5120ee7a8", "tree": "eabd17f12dae8dafc606614dce19b896d2f1f84c", "parents": [ "62e813f749a51ad2adfc1c90b0e013251bb9e47d" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Thu Nov 04 01:21:25 2021 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: hugetlbfs: COR: copy-on-read fault\n\nAdd the COR fault to hugetlbfs.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "62e813f749a51ad2adfc1c90b0e013251bb9e47d", "tree": "66b12f7a66407c73b106ce8230f78373ae45cea8", "parents": [ "009bd71ae5894040a043435dbddeb4864f4971db" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Dec 15 14:14:55 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: gup: FOLL_NOUNSHARE: optimize follow_page\n\nfollow_page would be suboptimal if it triggered COR faults for page\nmigration, KSM and other activities, so optimize it with\nFOLL_NOUNSHARE that acts just like FOLL_WRITE as far as the\nGUP unsharing logic is concerned.\n\nThis commit is based on prototype patches by David.\n\nSigned-off-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nCo-developed-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "009bd71ae5894040a043435dbddeb4864f4971db", "tree": "6489aa45cd59a3a15ea139763c347772324e6431", "parents": [ "b016eb8f2ac6d9d0653c5d7e433e94635cb4779a" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Fri Jan 15 21:18:22 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: gup: activate GUP unsharing with COR\n\nIn these two cases the Linux MM always handled the GUP pins wrong:\n\na) GUP before fork()\n\nb) GUP after fork()\n\nThe case (a) is well known as the \"fork vs gup vs thread\" race condition:\n\n https://lkml.kernel.org/r/20090311165833.GI27823@random.random\n\nCase (a) has more mild security implications because the parent\nprocess is in control, and it can prevent it from happening in many\nways, for example by stopping all O_DIRECT until the child executed\nexec().\n\nThe case (b) was first reported by Jann Horn on 27 May 2020 and it has\ngreater security implications because it can happen out of control of\nthe parent process.\n\nThis secures case (b) by un-sharing shared anonymous pages from COW\nmappings, before taking any GUP pin.\n\nIn addition this provides correct MM coherency to all readonly short\nterm GUP pins and it remains bug-to-bug compatible with\nFOLL_LONGTERM|FOLL_FORCE|FOLL_WRITE.\n\nThis doesn\u0027t cover hugetlbfs yet.\n\nCo-developed-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "b016eb8f2ac6d9d0653c5d7e433e94635cb4779a", "tree": "0573d0b81ecd77dff1e7991d31d78d6823421245", "parents": [ "70216c40f61a4aff5cae188c051796b8c07b233d" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Fri Jan 15 21:18:22 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: gup: gup_must_unshare() use can_read_pin_swap_page()\n\nThis is an optimization.\n\nThe primary benefit of using can_read_pin_swap_page() instead of\nreuse_swap_page() is that the page isn\u0027t turning writable after\ngup_must_unshare() returns, so there\u0027s no point to remove it from the\nswapcache even if it was found exclusive. Removing all the side\neffects on the page, will allow to retain a more optimal the swap\nbehavior. Furthermore it will speedup GUP so it\u0027s a win-win.\n\nThen while at it there\u0027s a micro-optimization possible: in the very\nrare case that PageAnon \u0026\u0026 !PageKsm turns into PageKsm before\ngup_must_unshare obtains the page lock, returning \"false\" as\nreuse_swap_page() has to do, would have caused an extra dummy COR\ncycle or COR copy, which has been optimized away.\n\nReported-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "70216c40f61a4aff5cae188c051796b8c07b233d", "tree": "771e95c39157f532386d81e843e40d352c2a721f", "parents": [ "63e087ffb8251bf64f6a20cfd068ce9e1ea305f5" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Fri Jan 15 21:18:22 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: gup: gup_must_unshare()\n\nIntroduce gup_must_unshare(): the GUP logic that decides on which\npages to activate the GUP unsharing with the COR fault (setting\nFAULT_FLAG_UNSHARE) while taking readonly page pins on all\nwrite-protected pages.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "63e087ffb8251bf64f6a20cfd068ce9e1ea305f5", "tree": "ce0fba54d413acf547fcb668560b2e11c4fbe066", "parents": [ "66d4d61c618297c722c15f9c7f37b0387c058ebf" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Fri Jan 15 21:18:22 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: gup: COR: copy-on-read fault\n\nCOR is a new type of page fault that generates readonly anonymous\nmemory and its only purpose is to allow the unsharing of\nwrite-protected COW shared pages, while still maintaining their write\nprotection. It is only meant to be used within GUP and it can be\ninvoked through the FAULT_FLAG_UNSHARE flag.\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "66d4d61c618297c722c15f9c7f37b0387c058ebf", "tree": "157fddb30a3d851d22a6601d54ed55895cc992f4", "parents": [ "f5063bcffc5b98891ca830d9b22cb2fb31fa0c1a" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Tue Jan 26 21:59:57 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: thp: introduce page_trans_huge_anon_shared\n\nThis is the equivalent of \"page_trans_huge_mapcount() \u003e 1\", but it is\nallowed to break the loop and it\u0027s meant to be used later outside the\nPT lock in the THP COW path to decide if to take the COW copy path as\nwell as in gup and gup-fast context.\n\nReviewed-by: Peter Xu \u003cpeterx@redhat.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "f5063bcffc5b98891ca830d9b22cb2fb31fa0c1a", "tree": "12b33b374323514c76c3761566b42905b6826f87", "parents": [ "4ae013f06fd64d19a5c0904746c6618f8667a10a" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Jan 13 17:54:56 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: thp: stabilize the THP mapcount in page_remove_anon_compound_rmap\n\nThe THP mapcount needs to behave as an atomic entity that moves in one\ndirection without jittering to be usable for GUP unsharing purposes.\n\nThe main challenge to achieve it is the PageDoubleMap. If the\ncompound_mapcount and the tail mapcounts move in the same direction\nthere\u0027s no jittering. However when the compound_mapcount is decreased\nand reaches zero, the reader will see initially a decrease in the THP\nmapcount that will then be followed by the PageDoubleMap being\ncleared. The act of clearing the PageDoubleMap will lead the reader to\noverestimate the mapcount once again until all tail mapcounts (that\nthe PageDoubleMap flag kept artificially elevated) are finally\nreleased.\n\nThe above runtime causes the THP mapcount in the reader to jitter from\na) 2 b) 1 c) 2 d) 1 and this patch will avoid that jittering.\n\nOtherwise when GUP unsharing is required, GUP could take the pin in b)\nwithout COR, and another thread in c) could trigger a spurious COW\nimmediately later, causing the readonly long term GUP pin to lose\ncoherency.\n\nThe anon compound_mapcount once zero won\u0027t increase again so the\nPageDoubleMap cannot be cleared in parallel, so the seqlock only needs\nto be taken if the PageDoubleMap flag is found set. This removes a\nlocked op from the THP freeing fast path.\n\nIn the future it may be possible to move the PageDoubleMap flag in the\nMSB of the compound_mapcount counter, in order to decrease the\ncompound_mapcount and to clear the PageDoubleMap flag in a single\natomic operation. That would prevent the jittering and it could make\nthe THP mapcount reading infallible in irq, but it would be more\ncomplex to verify as correct than the seqlock.\n\nReviewed-by: Peter Xu \u003cpeterx@redhat.com\u003e\nReported-by: Hugh Dickins \u003chughd@google.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "4ae013f06fd64d19a5c0904746c6618f8667a10a", "tree": "b0fec61686e3ad572316db488bceb90703051b7b", "parents": [ "b72abf1dee6b8a1c8b4859646dc70237e3fe9028" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Wed Jan 13 17:54:56 2021 -0500" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: thp: make the THP mapcount atomic with a seqlock\n\nIntroduce a seqlock in the THP subpage at index 1 to allow reading the\nTHP mapcount atomically outside the page lock.\n\nReviewed-by: Peter Xu \u003cpeterx@redhat.com\u003e\nReported-by: Sergey Senozhatsky \u003csergey.senozhatsky@gmail.com\u003e\nFixes: c444eb564fb1 (\"mm: thp: make the THP mapcount atomic against __split_huge_pmd_locked()\")\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "b72abf1dee6b8a1c8b4859646dc70237e3fe9028", "tree": "777e5d02a5d61c260e107611853d7917c8e5c4a5", "parents": [ "f37ec3d32902902d7f76b9c3c39c18843f80a945" ], "author": { "name": "David Hildenbrand", "email": "david@redhat.com", "time": "Wed Dec 15 15:32:47 2021 +0100" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:35 2023 -0500" }, "message": "mm: thp: consolidate mapcount logic on THP split\n\nLet\u0027s consolidate the mapcount logic to make it easier to understand and\nto prepare for further changes.\n\nSigned-off-by: David Hildenbrand \u003cdavid@redhat.com\u003e\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "f37ec3d32902902d7f76b9c3c39c18843f80a945", "tree": "96abb98aaaea4a4652dfe5ca506e4e3511e1cf24", "parents": [ "80529b4968a8052f894d00021a576d8a2d89aa08" ], "author": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Thu Apr 22 19:08:07 2021 -0400" }, "committer": { "name": "Andrea Arcangeli", "email": "aarcange@redhat.com", "time": "Sat Nov 11 22:03:34 2023 -0500" }, "message": "extraversion\n\nSigned-off-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\n" }, { "commit": "80529b4968a8052f894d00021a576d8a2d89aa08", "tree": "d019860155b637feb3954c2ad048523d8e6bb9f0", "parents": [ "3d8344a7c4a3fcb8ac43f8a1657c8a31432ea241" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:52 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:52 2023 +0100" }, "message": "Linux 5.15.138\n\nLink: https://lore.kernel.org/r/20231106130309.112650042@linuxfoundation.org\nTested-by: SeongJae Park \u003csj@kernel.org\u003e\nTested-by: Ron Economos \u003cre@w6rz.net\u003e\nTested-by: Jon Hunter \u003cjonathanh@nvidia.com\u003e\nTested-by: Harshit Mogalapalli \u003charshit.m.mogalapalli@oracle.com\u003e\nTested-by: Shuah Khan \u003cskhan@linuxfoundation.org\u003e\nTested-by: Ricardo B. Marliere \u003cricardo@marliere.net\u003e\nTested-by: Linux Kernel Functional Testing \u003clkft@linaro.org\u003e\nLink: https://lore.kernel.org/r/20231107202324.434534294@linuxfoundation.org\nTested-by: Florian Fainelli \u003cflorian.fainelli@broadcom.com\u003e\nTested-by: Allen Pais \u003capais@linux.microsoft.com\u003e\nTested-by: Jon Hunter \u003cjonathanh@nvidia.com\u003e\nTested-by: Linux Kernel Functional Testing \u003clkft@linaro.org\u003e\nTested-by: Pavel Machek (CIP) \u003cpavel@denx.de\u003e\nTested-by: Guenter Roeck \u003clinux@roeck-us.net\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "3d8344a7c4a3fcb8ac43f8a1657c8a31432ea241", "tree": "7ff5ac1d5aee6c782fe2440ff6ad781b9e5205e7", "parents": [ "f049c0c0037d8d50f986325830029a68b331ca1b" ], "author": { "name": "Mark Hasemeyer", "email": "markhas@chromium.org", "time": "Wed Oct 18 17:59:31 2023 -0600" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:51 2023 +0100" }, "message": "ALSA: hda: intel-dsp-config: Fix JSL Chromebook quirk detection\n\ncommit 7c05b44e1a50d9cbfc4f731dddc436a24ddc129a upstream.\n\nSome Jasperlake Chromebooks overwrite the system vendor DMI value to the\nname of the OEM that manufactured the device. This breaks Chromebook\nquirk detection as it expects the system vendor to be \"Google\".\n\nAdd another quirk detection entry that looks for \"Google\" in the BIOS\nversion.\n\nCc: stable@vger.kernel.org\nSigned-off-by: Mark Hasemeyer \u003cmarkhas@chromium.org\u003e\nReviewed-by: Pierre-Louis Bossart \u003cpierre-louis.bossart@linux.intel.com\u003e\nLink: https://lore.kernel.org/r/20231018235944.1860717-1-markhas@chromium.org\nSigned-off-by: Takashi Iwai \u003ctiwai@suse.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "f049c0c0037d8d50f986325830029a68b331ca1b", "tree": "bfbeb1f85de4f62a97c01b74dc48132294229b95", "parents": [ "28b8ad8ccecd0d537039e03e2dc27ae324d11312" ], "author": { "name": "Siddharth Vadapalli", "email": "s-vadapalli@ti.com", "time": "Fri Oct 20 17:32:48 2023 +0530" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:51 2023 +0100" }, "message": "misc: pci_endpoint_test: Add deviceID for J721S2 PCIe EP device support\n\ncommit 8293703a492ae97c86af27c75b76e6239ec86483 upstream.\n\nAdd DEVICE_ID for J721S2 and enable support for endpoints configured\nwith this DEVICE_ID in the pci_endpoint_test driver.\n\nSigned-off-by: Siddharth Vadapalli \u003cs-vadapalli@ti.com\u003e\nCc: stable \u003cstable@kernel.org\u003e\nReviewed-by: Manivannan Sadhasivam \u003cmanivannan.sadhasivam@linaro.org\u003e\nLink: https://lore.kernel.org/r/20231020120248.3168406-1-s-vadapalli@ti.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "28b8ad8ccecd0d537039e03e2dc27ae324d11312", "tree": "556d8f9944b40be1b341c91d424d38269e776d44", "parents": [ "44c4dfac3f021be63dcd98f239da21eb042b1929" ], "author": { "name": "Cameron Williams", "email": "cang1@live.co.uk", "time": "Fri Oct 20 17:03:17 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:51 2023 +0100" }, "message": "tty: 8250: Add Brainboxes Oxford Semiconductor-based quirks\n\ncommit e4876dacaca46a1b09f9b417480924ab12019a5b upstream.\n\nSome of the later revisions of the Brainboxes PX cards are based\non the Oxford Semiconductor chipset. Due to the chip\u0027s unique setup\nthese cards need to be initialised.\nPreviously these were tested against a reference card with the same broken\nbaudrate on another PC, cancelling out the effect. With this patch they\nwork and can transfer/receive find against an FTDI-based device.\n\nAdd all of the cards which require this setup to the quirks table.\nThanks to Maciej W. Rozycki for clarification on this chip.\n\nFixes: ef5a03a26c87 (\"tty: 8250: Add support for Brainboxes PX cards.\")\nCc: stable@vger.kernel.org\nSigned-off-by: Cameron Williams \u003ccang1@live.co.uk\u003e\nLink: https://lore.kernel.org/r/DU0PR02MB7899D222A4AB2A4E8C57108FC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "44c4dfac3f021be63dcd98f239da21eb042b1929", "tree": "d77ced24e2fbe305b58b7ae39abd215e5ded3f8e", "parents": [ "d541ccb34de24a5afc29f70dcccdbde5c2aebb3b" ], "author": { "name": "Cameron Williams", "email": "cang1@live.co.uk", "time": "Fri Oct 20 17:03:16 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:51 2023 +0100" }, "message": "tty: 8250: Add support for Intashield IX cards\n\ncommit 62d2ec2ded278c7512d91ca7bf8eb9bac46baf90 upstream.\n\nAdd support for the IX-100, IX-200 and IX-400 serial cards.\n\nCc: stable@vger.kernel.org\nSigned-off-by: Cameron Williams \u003ccang1@live.co.uk\u003e\nLink: https://lore.kernel.org/r/DU0PR02MB7899614E5837E82A03272A4BC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "d541ccb34de24a5afc29f70dcccdbde5c2aebb3b", "tree": "96cdd99577133157541d6f866140946df57689f7", "parents": [ "60debc01fcbbb6f129a9a4ed83d4430cf025c913" ], "author": { "name": "Cameron Williams", "email": "cang1@live.co.uk", "time": "Fri Oct 20 17:03:15 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:51 2023 +0100" }, "message": "tty: 8250: Add support for additional Brainboxes PX cards\n\ncommit 9604884e592cd04ead024c9737c67a77f175cab9 upstream.\n\nAdd support for some more of the Brainboxes PX (PCIe) range\nof serial cards, namely\nPX-275/PX-279, PX-475 (serial port, not LPT), PX-820,\nPX-803/PX-857 (additional ID).\n\nCc: stable@vger.kernel.org\nSigned-off-by: Cameron Williams \u003ccang1@live.co.uk\u003e\nLink: https://lore.kernel.org/r/DU0PR02MB78996BEC353FB346FC35444BC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "60debc01fcbbb6f129a9a4ed83d4430cf025c913", "tree": "365304f35be203676a8d24577060a6aa59f9dbc6", "parents": [ "1f5649aed52714a88e8b7024e22470cc0451f690" ], "author": { "name": "Cameron Williams", "email": "cang1@live.co.uk", "time": "Fri Oct 20 17:03:13 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:51 2023 +0100" }, "message": "tty: 8250: Fix up PX-803/PX-857\n\ncommit ee61337b934c99c2611e0a945d592019b2e00c82 upstream.\n\nThe PX-803/PX-857 are variants of each other, add a note.\nAdditionally fix up the port counts for the card (2, not 1).\n\nFixes: ef5a03a26c87 (\"tty: 8250: Add support for Brainboxes PX cards.\")\nCc: stable@vger.kernel.org\nSigned-off-by: Cameron Williams \u003ccang1@live.co.uk\u003e\nLink: https://lore.kernel.org/r/DU0PR02MB789978C8ED872FB4B014E132C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "1f5649aed52714a88e8b7024e22470cc0451f690", "tree": "ea7b15c3cd7e84ee5baf073cbadb9de5e2747812", "parents": [ "3fe3cc63c730d79341273f733a11db6409460575" ], "author": { "name": "Cameron Williams", "email": "cang1@live.co.uk", "time": "Fri Oct 20 17:03:12 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:51 2023 +0100" }, "message": "tty: 8250: Fix port count of PX-257\n\ncommit d0ff5b24c2f112f29dea4c38b3bac9597b1be9ba upstream.\n\nThe port count of the PX-257 Rev3 is actually 2, not 4.\n\nFixes: ef5a03a26c87 (\"tty: 8250: Add support for Brainboxes PX cards.\")\nCc: stable@vger.kernel.org\nSigned-off-by: Cameron Williams \u003ccang1@live.co.uk\u003e\nLink: https://lore.kernel.org/r/DU0PR02MB7899C804D9F04E727B5A0E8FC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "3fe3cc63c730d79341273f733a11db6409460575", "tree": "f98b587befb705d73c2abc1516a21b4d669026dd", "parents": [ "a5b6390fd609d966cf8cc99d93165f2867af7924" ], "author": { "name": "Cameron Williams", "email": "cang1@live.co.uk", "time": "Fri Oct 20 17:03:11 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:50 2023 +0100" }, "message": "tty: 8250: Add support for Intashield IS-100\n\ncommit 4d994e3cf1b541ff32dfb03fbbc60eea68f9645b upstream.\n\nAdd support for the Intashield IS-100 1 port serial card.\n\nCc: stable@vger.kernel.org\nSigned-off-by: Cameron Williams \u003ccang1@live.co.uk\u003e\nLink: https://lore.kernel.org/r/DU0PR02MB7899A0E0CDAA505AF5A874CDC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "a5b6390fd609d966cf8cc99d93165f2867af7924", "tree": "897479118882b0a1422a6f79452ccb08f17535ae", "parents": [ "738fe41b6443006cb88840e681fab063866b166c" ], "author": { "name": "Cameron Williams", "email": "cang1@live.co.uk", "time": "Fri Oct 20 17:03:10 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:50 2023 +0100" }, "message": "tty: 8250: Add support for Brainboxes UP cards\n\ncommit 2c6fec1e1532f15350be7e14ba6b88a39d289fe4 upstream.\n\nAdd support for the Brainboxes UP (powered PCI) range of\ncards, namely UP-189, UP-200, UP-869 and UP-880.\n\nCc: stable@vger.kernel.org\nSigned-off-by: Cameron Williams \u003ccang1@live.co.uk\u003e\nLink: https://lore.kernel.org/r/DU0PR02MB7899B5B59FF3D8587E88C117C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "738fe41b6443006cb88840e681fab063866b166c", "tree": "b9c4897d3b02f2032a11be9312528d7a7c076323", "parents": [ "ff6059c3d234624d8a549968db06ebc49286c161" ], "author": { "name": "Cameron Williams", "email": "cang1@live.co.uk", "time": "Fri Oct 20 17:03:09 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:50 2023 +0100" }, "message": "tty: 8250: Add support for additional Brainboxes UC cards\n\ncommit c563db486db7d245c0e2f319443417ae8e692f7f upstream.\n\nAdd device IDs for some more Brainboxes UC cards, namely\nUC-235/UC-246, UC-253/UC-734, UC-302, UC-313, UC-346, UC-357,\nUC-607 and UC-836.\n\nCc: stable@vger.kernel.org\nSigned-off-by: Cameron Williams \u003ccang1@live.co.uk\u003e\nLink: https://lore.kernel.org/r/DU0PR02MB789969998A6C3FAFCD95C85DC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "ff6059c3d234624d8a549968db06ebc49286c161", "tree": "f1f1536b9793e88e1cb401cce1462eace98986f4", "parents": [ "81a4dd5e6c78f5d8952fa8c9d36565db1fe01444" ], "author": { "name": "Cameron Williams", "email": "cang1@live.co.uk", "time": "Fri Oct 20 17:03:08 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:50 2023 +0100" }, "message": "tty: 8250: Remove UC-257 and UC-431\n\ncommit 33092fb3af51deb80849e90a17bada44bbcde6b3 upstream.\n\nThe UC-257 is a serial + LPT card, so remove it from this driver.\nA patch has been submitted to add it to parport_serial instead.\n\nAdditionaly, the UC-431 does not use this card ID, only the UC-420\ndoes. The 431 is a 3-port card and there is no generic 3-port configuration\navailable, so remove reference to it from this driver.\n\nFixes: 152d1afa834c (\"tty: Add support for Brainboxes UC cards.\")\nCc: stable@vger.kernel.org\nSigned-off-by: Cameron Williams \u003ccang1@live.co.uk\u003e\nLink: https://lore.kernel.org/r/DU0PR02MB78995ADF7394C74AD4CF3357C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "81a4dd5e6c78f5d8952fa8c9d36565db1fe01444", "tree": "10fe72df9f0a27c3b30022fd2bec53725a4b1cc9", "parents": [ "e25197747f0ea58181d56e89d19414e9b85d847e" ], "author": { "name": "Daniel Starke", "email": "daniel.starke@siemens.com", "time": "Thu Oct 26 07:58:43 2023 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:50 2023 +0100" }, "message": "tty: n_gsm: fix race condition in status line change on dead connections\n\ncommit 3a75b205de43365f80a33b98ec9289785da56243 upstream.\n\ngsm_cleanup_mux() cleans up the gsm by closing all DLCIs, stopping all\ntimers, removing the virtual tty devices and clearing the data queues.\nThis procedure, however, may cause subsequent changes of the virtual modem\nstatus lines of a DLCI. More data is being added the outgoing data queue\nand the deleted kick timer is restarted to handle this. At this point many\nresources have already been removed by the cleanup procedure. Thus, a\nkernel panic occurs.\n\nFix this by proving in gsm_modem_update() that the cleanup procedure has\nnot been started and the mux is still alive.\n\nNote that writing to a virtual tty is already protected by checks against\nthe DLCI specific connection state.\n\nFixes: c568f7086c6e (\"tty: n_gsm: fix missing timer to handle stalled links\")\nCc: stable \u003cstable@kernel.org\u003e\nSigned-off-by: Daniel Starke \u003cdaniel.starke@siemens.com\u003e\nLink: https://lore.kernel.org/r/20231026055844.3127-1-daniel.starke@siemens.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "e25197747f0ea58181d56e89d19414e9b85d847e", "tree": "df9e36ffa844aac73ee695fe2eb4892bb29e762d", "parents": [ "e5f53a68a596e04df3fde3099273435a30b6fdac" ], "author": { "name": "Andrey Konovalov", "email": "andreyknvl@gmail.com", "time": "Thu Oct 26 22:01:12 2023 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:50 2023 +0100" }, "message": "usb: raw-gadget: properly handle interrupted requests\n\ncommit e8033bde451eddfb9b1bbd6e2d848c1b5c277222 upstream.\n\nCurrently, if a USB request that was queued by Raw Gadget is interrupted\n(via a signal), wait_for_completion_interruptible returns -ERESTARTSYS.\nRaw Gadget then attempts to propagate this value to userspace as a return\nvalue from its ioctls. However, when -ERESTARTSYS is returned by a syscall\nhandler, the kernel internally restarts the syscall.\n\nThis doesn\u0027t allow userspace applications to interrupt requests queued by\nRaw Gadget (which is required when the emulated device is asked to switch\naltsettings). It also violates the implied interface of Raw Gadget that a\nsingle ioctl must only queue a single USB request.\n\nInstead, make Raw Gadget do what GadgetFS does: check whether the request\nwas interrupted (dequeued with status \u003d\u003d -ECONNRESET) and report -EINTR to\nuserspace.\n\nFixes: f2c2e717642c (\"usb: gadget: add raw-gadget interface\")\nCc: stable \u003cstable@kernel.org\u003e\nSigned-off-by: Andrey Konovalov \u003candreyknvl@gmail.com\u003e\nLink: https://lore.kernel.org/r/0db45b1d7cc466e3d4d1ab353f61d63c977fbbc5.1698350424.git.andreyknvl@gmail.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "e5f53a68a596e04df3fde3099273435a30b6fdac", "tree": "2ee672d2b5923799ada76c33d4e78bf712c91758", "parents": [ "7c4855b22a3fecb4f28cadabe7b2bff55bf6ebef" ], "author": { "name": "Jimmy Hu", "email": "hhhuuu@google.com", "time": "Fri Oct 20 01:21:32 2023 +0000" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:50 2023 +0100" }, "message": "usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm()\n\ncommit 4987daf86c152ff882d51572d154ad12e4ff3a4b upstream.\n\nIt is possible that typec_register_partner() returns ERR_PTR on failure.\nWhen port-\u003epartner is an error, a NULL pointer dereference may occur as\nshown below.\n\n[91222.095236][ T319] typec port0: failed to register partner (-17)\n...\n[91225.061491][ T319] Unable to handle kernel NULL pointer dereference\nat virtual address 000000000000039f\n[91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc\n[91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc\n[91225.308067][ T319] Call trace:\n[91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc\n[91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8\n[91225.355900][ T319] kthread_worker_fn+0x178/0x58c\n[91225.355902][ T319] kthread+0x150/0x200\n[91225.355905][ T319] ret_from_fork+0x10/0x30\n\nAdd a check for port-\u003epartner to avoid dereferencing a NULL pointer.\n\nFixes: 5e1d4c49fbc8 (\"usb: typec: tcpm: Determine common SVDM Version\")\nCc: stable@vger.kernel.org\nSigned-off-by: Jimmy Hu \u003chhhuuu@google.com\u003e\nLink: https://lore.kernel.org/r/20231020012132.100960-1-hhhuuu@google.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "7c4855b22a3fecb4f28cadabe7b2bff55bf6ebef", "tree": "4721cf9a72ab18335fa5202f501ab236f07d17a2", "parents": [ "c48aae53850c0e20ec9710e7b995a67226417b7e" ], "author": { "name": "LihaSika", "email": "lihasika@gmail.com", "time": "Fri Oct 27 20:28:04 2023 +0300" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:49 2023 +0100" }, "message": "usb: storage: set 1.50 as the lower bcdDevice for older \"Super Top\" compatibility\n\ncommit 0e3139e6543b241b3e65956a55c712333bef48ac upstream.\n\nChange lower bcdDevice value for \"Super Top USB 2.0 SATA BRIDGE\" to match\n1.50. I have such an older device with bcdDevice\u003d1.50 and it will not work\notherwise.\n\nCc: stable@vger.kernel.org\nSigned-off-by: Liha Sikanen \u003clihasika@gmail.com\u003e\nLink: https://lore.kernel.org/r/ccf7d12a-8362-4916-b3e0-f4150f54affd@gmail.com\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "c48aae53850c0e20ec9710e7b995a67226417b7e", "tree": "35a82c2cc763b0fbb86f33a1e8d58229e3ed78be", "parents": [ "6628c3627c026744744ce2a60a0b19ee6114fb42" ], "author": { "name": "Vicki Pfau", "email": "vi@endrift.com", "time": "Wed Sep 27 13:22:12 2023 -0700" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:49 2023 +0100" }, "message": "PCI: Prevent xHCI driver from claiming AMD VanGogh USB3 DRD device\n\ncommit 7e6f3b6d2c352b5fde37ce3fed83bdf6172eebd4 upstream.\n\nThe AMD VanGogh SoC contains a DesignWare USB3 Dual-Role Device that can be\noperated as either a USB Host or a USB Device, similar to on the AMD Nolan\nplatform.\n\nbe6646bfbaec (\"PCI: Prevent xHCI driver from claiming AMD Nolan USB3 DRD\ndevice\") added a quirk to let the dwc3 driver claim the Nolan device since\nit provides more specific support.\n\nExtend that quirk to include the VanGogh SoC USB3 device.\n\nLink: https://lore.kernel.org/r/20230927202212.2388216-1-vi@endrift.com\nSigned-off-by: Vicki Pfau \u003cvi@endrift.com\u003e\n[bhelgaas: include be6646bfbaec reference, add stable tag]\nSigned-off-by: Bjorn Helgaas \u003cbhelgaas@google.com\u003e\nCc: stable@vger.kernel.org\t# v3.19+\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "6628c3627c026744744ce2a60a0b19ee6114fb42", "tree": "a81f9b84182da79d18b7cd3d554f72f2127f2573", "parents": [ "b6c3c7786e2451f590b8460bee34e18ab0ad99e1" ], "author": { "name": "Mario Limonciello", "email": "mario.limonciello@amd.com", "time": "Fri Oct 20 10:26:29 2023 -0500" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:49 2023 +0100" }, "message": "drm/amd: Disable ASPM for VI w/ all Intel systems\n\ncommit 64ffd2f1d00c6235dabe9704bbb0d9ce3e28147f upstream.\n\nOriginally we were quirking ASPM disabled specifically for VI when\nused with Alder Lake, but it appears to have problems with Rocket\nLake as well.\n\nLike we\u0027ve done in the case of dpm for newer platforms, disable\nASPM for all Intel systems.\n\nCc: stable@vger.kernel.org # 5.15+\nFixes: 0064b0ce85bb (\"drm/amd/pm: enable ASPM by default\")\nReported-and-tested-by: Paolo Gentili \u003cpaolo.gentili@canonical.com\u003e\nCloses: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2036742\nSigned-off-by: Mario Limonciello \u003cmario.limonciello@amd.com\u003e\nReviewed-by: Alex Deucher \u003calexander.deucher@amd.com\u003e\nSigned-off-by: Alex Deucher \u003calexander.deucher@amd.com\u003e\nSigned-off-by: Mario Limonciello \u003cmario.limonciello@amd.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "b6c3c7786e2451f590b8460bee34e18ab0ad99e1", "tree": "29298a96bd58da2589237240c99573c78be5fe7f", "parents": [ "9015169f00ee8a16f1caf8ae5892e18e3f4e9699" ], "author": { "name": "Mario Limonciello", "email": "mario.limonciello@amd.com", "time": "Fri Jul 07 21:26:08 2023 -0500" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:49 2023 +0100" }, "message": "drm/amd: Move helper for dynamic speed switch check out of smu13\n\ncommit 188623076d0f1a500583d392b6187056bf7cc71a upstream.\n\nThis helper is used for checking if the connected host supports\nthe feature, it can be moved into generic code to be used by other\nsmu implementations as well.\n\nSigned-off-by: Mario Limonciello \u003cmario.limonciello@amd.com\u003e\nReviewed-by: Evan Quan \u003cevan.quan@amd.com\u003e\nSigned-off-by: Alex Deucher \u003calexander.deucher@amd.com\u003e\nCc: stable@vger.kernel.org # 6.1.x\nSigned-off-by: Mario Limonciello \u003cmario.limonciello@amd.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "9015169f00ee8a16f1caf8ae5892e18e3f4e9699", "tree": "8342a1ec4b881b0858c0f8a425ea9cf1d713dd78", "parents": [ "d72ff64783230a15ffdf97222064cf2ac761df24" ], "author": { "name": "Oliver Hartkopp", "email": "socketcan@hartkopp.net", "time": "Tue Oct 31 10:30:25 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:49 2023 +0100" }, "message": "can: isotp: isotp_sendmsg(): fix TX state detection and wait behavior\n\nFrom: Lukas Magel \u003clukas.magel@posteo.net\u003e\n\n[ Upstream commit d9c2ba65e651467de739324d978b04ed8729f483 ]\n\nWith patch [1], isotp_poll was updated to also queue the poller in the\nso-\u003ewait queue, which is used for send state changes. Since the queue\nnow also contains polling tasks that are not interested in sending, the\nqueue fill state can no longer be used as an indication of send\nreadiness. As a consequence, nonblocking writes can lead to a race and\nlock-up of the socket if there is a second task polling the socket in\nparallel.\n\nWith this patch, isotp_sendmsg does not consult wq_has_sleepers but\ninstead tries to atomically set so-\u003etx.state and waits on so-\u003ewait if it\nis unable to do so. This behavior is in alignment with isotp_poll, which\nalso checks so-\u003etx.state to determine send readiness.\n\nV2:\n- Revert direct exit to goto err_event_drop\n\n[1] https://lore.kernel.org/all/20230331125511.372783-1-michal.sojka@cvut.cz\n\nReported-by: Maxime Jayat \u003cmaxime.jayat@mobile-devices.fr\u003e\nCloses: https://lore.kernel.org/linux-can/11328958-453f-447f-9af8-3b5824dfb041@munic.io/\nSigned-off-by: Lukas Magel \u003clukas.magel@posteo.net\u003e\nReviewed-by: Oliver Hartkopp \u003csocketcan@hartkopp.net\u003e\nFixes: 79e19fa79cb5 (\"can: isotp: isotp_ops: fix poll() to not report false EPOLLOUT events\")\nLink: https://github.com/pylessard/python-udsoncan/issues/178#issuecomment-1743786590\nLink: https://lore.kernel.org/all/20230827092205.7908-1-lukas.magel@posteo.net\nSigned-off-by: Marc Kleine-Budde \u003cmkl@pengutronix.de\u003e\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "d72ff64783230a15ffdf97222064cf2ac761df24", "tree": "443bfb7f6770c0902f39cafcefb0b1a47c099808", "parents": [ "e163ad6a8639bb28f5aee683f04929cb07dd5990" ], "author": { "name": "Oliver Hartkopp", "email": "socketcan@hartkopp.net", "time": "Tue Oct 31 10:30:24 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:49 2023 +0100" }, "message": "can: isotp: isotp_bind(): do not validate unused address information\n\ncommit b76b163f46b661499921a0049982764a6659bfe7 upstream\n\nWith commit 2aa39889c463 (\"can: isotp: isotp_bind(): return -EINVAL on\nincorrect CAN ID formatting\") the bind() syscall returns -EINVAL when\nthe given CAN ID needed to be sanitized. But in the case of an unconfirmed\nbroadcast mode the rx CAN ID is not needed and may be uninitialized from\nthe caller - which is ok.\n\nThis patch makes sure the result of an inproper CAN ID format is only\nprovided when the address information is needed.\n\nLink: https://lore.kernel.org/all/20220517145653.2556-1-socketcan@hartkopp.net\nSigned-off-by: Oliver Hartkopp \u003csocketcan@hartkopp.net\u003e\nSigned-off-by: Marc Kleine-Budde \u003cmkl@pengutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "e163ad6a8639bb28f5aee683f04929cb07dd5990", "tree": "82c7ae01de23a756bfe4e86f517b67f559b8f3a5", "parents": [ "b4e78ea26638f6f3d27ae3ff7b43fda29169bbd2" ], "author": { "name": "Oliver Hartkopp", "email": "socketcan@hartkopp.net", "time": "Tue Oct 31 10:30:23 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:49 2023 +0100" }, "message": "can: isotp: add local echo tx processing and tx without FC\n\ncommit 4b7fe92c06901f4563af0e36d25223a5ab343782 upstream\ncommit 9f39d36530e5678d092d53c5c2c60d82b4dcc169 upstream\ncommit 051737439eaee5bdd03d3c2ef5510d54a478fd05 upstream\n\nDue to the existing patch order applied to isotp.c in the stable kernel the\noriginal order of depending patches the three original patches\n4b7fe92c0690 (\"can: isotp: add local echo tx processing for consecutive frames\")\n9f39d36530e5 (\"can: isotp: add support for transmission without flow control\")\n051737439eae (\"can: isotp: fix race between isotp_sendsmg() and isotp_release()\")\ncan not be split into different patches that can be applied in working steps\nto the stable tree.\n\nSigned-off-by: Oliver Hartkopp \u003csocketcan@hartkopp.net\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "b4e78ea26638f6f3d27ae3ff7b43fda29169bbd2", "tree": "edbabac6ca902968458adb1b75311527e2a16492", "parents": [ "2fc6f337257f4f7c21ecff429241f7acaa6df4e8" ], "author": { "name": "Oliver Hartkopp", "email": "socketcan@hartkopp.net", "time": "Tue Oct 31 10:30:22 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:48 2023 +0100" }, "message": "can: isotp: handle wait_event_interruptible() return values\n\ncommit 823b2e42720f96f277940c37ea438b7c5ead51a4 upstream\n\nWhen wait_event_interruptible() has been interrupted by a signal the\ntx.state value might not be ISOTP_IDLE. Force the state machines\ninto idle state to inhibit the timer handlers to continue working.\n\nFixes: 866337865f37 (\"can: isotp: fix tx state handling for echo tx processing\")\nCc: stable@vger.kernel.org\nSigned-off-by: Oliver Hartkopp \u003csocketcan@hartkopp.net\u003e\nLink: https://lore.kernel.org/all/20230112192347.1944-1-socketcan@hartkopp.net\nSigned-off-by: Marc Kleine-Budde \u003cmkl@pengutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "2fc6f337257f4f7c21ecff429241f7acaa6df4e8", "tree": "bccf830f278d1dd44db3bc2798959dcc26572f9f", "parents": [ "f8c3bd211cf358575da40960bac990d799b1eb61" ], "author": { "name": "Oliver Hartkopp", "email": "socketcan@hartkopp.net", "time": "Tue Oct 31 10:30:21 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:48 2023 +0100" }, "message": "can: isotp: check CAN address family in isotp_bind()\n\ncommit c6adf659a8ba85913e16a571d5a9bcd17d3d1234 upstream\n\nAdd missing check to block non-AF_CAN binds.\n\nSyzbot created some code which matched the right sockaddr struct size\nbut used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family\nfield:\n\nbind$xdp(r2, \u0026(0x7f0000000540)\u003d{0x2c, 0x0, r4, 0x0, r2}, 0x10)\n ^^^^\nThis has no funtional impact but the userspace should be notified about\nthe wrong address family field content.\n\nLink: https://syzkaller.appspot.com/text?tag\u003dCrashLog\u0026x\u003d11ff9d8c480000\nReported-by: syzbot+5aed6c3aaba661f5b917@syzkaller.appspotmail.com\nSigned-off-by: Oliver Hartkopp \u003csocketcan@hartkopp.net\u003e\nLink: https://lore.kernel.org/all/20230104201844.13168-1-socketcan@hartkopp.net\nSigned-off-by: Marc Kleine-Budde \u003cmkl@pengutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "f8c3bd211cf358575da40960bac990d799b1eb61", "tree": "a7e78d9e37cd1267a4673b5879f70ecaddd314c2", "parents": [ "615c4dd64050d5c7002ff331b251e29a9cd7fa36" ], "author": { "name": "Oliver Hartkopp", "email": "socketcan@hartkopp.net", "time": "Tue Oct 31 10:30:20 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:48 2023 +0100" }, "message": "can: isotp: isotp_bind(): return -EINVAL on incorrect CAN ID formatting\n\ncommit 2aa39889c463195a0dfe2aff9fad413139c32a4f upstream\n\nCommit 3ea566422cbd (\"can: isotp: sanitize CAN ID checks in\nisotp_bind()\") checks the given CAN ID address information by\nsanitizing the input values.\n\nThis check (silently) removes obsolete bits by masking the given CAN\nIDs.\n\nDerek Will suggested to give a feedback to the application programmer\nwhen the \u0027sanitizing\u0027 was actually needed which means the programmer\nprovided CAN ID content in a wrong format (e.g. SFF CAN IDs with a CAN\nID \u003e 0x7FF).\n\nLink: https://lore.kernel.org/all/20220515181633.76671-1-socketcan@hartkopp.net\nSuggested-by: Derek Will \u003cderekrobertwill@gmail.com\u003e\nSigned-off-by: Oliver Hartkopp \u003csocketcan@hartkopp.net\u003e\nSigned-off-by: Marc Kleine-Budde \u003cmkl@pengutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "615c4dd64050d5c7002ff331b251e29a9cd7fa36", "tree": "1fd93e96976e495ac16f62ed86e75ccd7ed04d5d", "parents": [ "6627b96851f1d2a3e8162e9e58781e40c07a3137" ], "author": { "name": "Oliver Hartkopp", "email": "socketcan@hartkopp.net", "time": "Tue Oct 31 10:30:19 2023 +0100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:48 2023 +0100" }, "message": "can: isotp: set max PDU size to 64 kByte\n\ncommit 9c0c191d82a1de964ac953a1df8b5744ec670b07 upstream\n\nThe reason to extend the max PDU size from 4095 Byte (12 bit length value)\nto a 32 bit value (up to 4 GByte) was to be able to flash 64 kByte\nbootloaders with a single ISO-TP PDU. The max PDU size in the Linux kernel\nimplementation was set to 8200 Bytes to be able to test the length\ninformation escape sequence.\n\nIt turns out that the demand for 64 kByte PDUs is real so the value for\nMAX_MSG_LENGTH is set to 66000 to be able to potentially add some checksums\nto the 65.536 Byte block.\n\nLink: https://github.com/linux-can/can-utils/issues/347#issuecomment-1056142301\nLink: https://lore.kernel.org/all/20220309120416.83514-3-socketcan@hartkopp.net\nSigned-off-by: Oliver Hartkopp \u003csocketcan@hartkopp.net\u003e\nSigned-off-by: Marc Kleine-Budde \u003cmkl@pengutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "6627b96851f1d2a3e8162e9e58781e40c07a3137", "tree": "eec9a5f90c8dbedd9f99860ccc2d80c39a7b9e15", "parents": [ "f0f9986488871ed952bd13ed4892c45db51447ce" ], "author": { "name": "Michael Ellerman", "email": "mpe@ellerman.id.au", "time": "Mon Oct 23 22:25:00 2023 +1100" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:48 2023 +0100" }, "message": "powerpc/mm: Fix boot crash with FLATMEM\n\n[ Upstream commit daa9ada2093ed23d52b4c1fe6e13cf78f55cc85f ]\n\nErhard reported that his G5 was crashing with v6.6-rc kernels:\n\n mpic: Setting up HT PICs workarounds for U3/U4\n BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe\n Faulting instruction address: 0xc00000000005dc40\n Oops: Kernel access of bad area, sig: 11 [#1]\n BE PAGE_SIZE\u003d4K MMU\u003dHash SMP NR_CPUS\u003d2 PowerMac\n Modules linked in:\n CPU: 0 PID: 0 Comm: swapper/0 Tainted: G T 6.6.0-rc3-PMacGS #1\n Hardware name: PowerMac11,2 PPC970MP 0x440101 PowerMac\n NIP: c00000000005dc40 LR: c000000000066660 CTR: c000000000007730\n REGS: c0000000022bf510 TRAP: 0380 Tainted: G T (6.6.0-rc3-PMacGS)\n MSR: 9000000000001032 \u003cSF,HV,ME,IR,DR,RI\u003e CR: 44004242 XER: 00000000\n IRQMASK: 3\n GPR00: 0000000000000000 c0000000022bf7b0 c0000000010c0b00 00000000000001ac\n GPR04: 0000000003c80000 0000000000000300 c0000000f20001ae 0000000000000300\n GPR08: 0000000000000006 feffbb62ffec65ff 0000000000000001 0000000000000000\n GPR12: 9000000000001032 c000000002362000 c000000000f76b80 000000000349ecd8\n GPR16: 0000000002367ba8 0000000002367f08 0000000000000006 0000000000000000\n GPR20: 00000000000001ac c000000000f6f920 c0000000022cd985 000000000000000c\n GPR24: 0000000000000300 00000003b0a3691d c0003e008030000e 0000000000000000\n GPR28: c00000000000000c c0000000f20001ee feffbb62ffec65fe 00000000000001ac\n NIP hash_page_do_lazy_icache+0x50/0x100\n LR __hash_page_4K+0x420/0x590\n Call Trace:\n hash_page_mm+0x364/0x6f0\n do_hash_fault+0x114/0x2b0\n data_access_common_virt+0x198/0x1f0\n --- interrupt: 300 at mpic_init+0x4bc/0x10c4\n NIP: c000000002020a5c LR: c000000002020a04 CTR: 0000000000000000\n REGS: c0000000022bf9f0 TRAP: 0300 Tainted: G T (6.6.0-rc3-PMacGS)\n MSR: 9000000000001032 \u003cSF,HV,ME,IR,DR,RI\u003e CR: 24004248 XER: 00000000\n DAR: c0003e008030000e DSISR: 40000000 IRQMASK: 1\n ...\n NIP mpic_init+0x4bc/0x10c4\n LR mpic_init+0x464/0x10c4\n --- interrupt: 300\n pmac_setup_one_mpic+0x258/0x2dc\n pmac_pic_init+0x28c/0x3d8\n init_IRQ+0x90/0x140\n start_kernel+0x57c/0x78c\n start_here_common+0x1c/0x20\n\nA bisect pointed to the breakage beginning with commit 9fee28baa601 (\"powerpc:\nimplement the new page table range API\").\n\nAnalysis of the oops pointed to a struct page with a corrupted\ncompound_head being loaded via page_folio() -\u003e _compound_head() in\nhash_page_do_lazy_icache().\n\nThe access by the mpic code is to an MMIO address, so the expectation\nis that the struct page for that address would be initialised by\ninit_unavailable_range(), as pointed out by Aneesh.\n\nInstrumentation showed that was not the case, which eventually lead to\nthe realisation that pfn_valid() was returning false for that address,\ncausing the struct page to not be initialised.\n\nBecause the system is using FLATMEM, the version of pfn_valid() in\nmemory_model.h is used:\n\nstatic inline int pfn_valid(unsigned long pfn)\n{\n\t...\n\treturn pfn \u003e\u003d pfn_offset \u0026\u0026 (pfn - pfn_offset) \u003c max_mapnr;\n}\n\nWhich relies on max_mapnr being initialised. Early in boot max_mapnr is\nzero meaning no PFNs are valid.\n\nmax_mapnr is initialised in mem_init() called via:\n\n start_kernel()\n mm_core_init() # init/main.c:928\n mem_init()\n\nBut that is too late for the usage in init_unavailable_range() called via:\n\n start_kernel()\n setup_arch() # init/main.c:893\n paging_init()\n free_area_init()\n init_unavailable_range()\n\nAlthough max_mapnr is currently set in mem_init(), the value is actually\nalready available much earlier, as soon as mem_topology_setup() has\ncompleted, which is also before paging_init() is called. So move the\ninitialisation there, which causes paging_init() to correctly initialise\nthe struct page and fixes the bug.\n\nThis bug seems to have been lurking for years, but went unnoticed\nbecause the pre-folio code was inspecting the uninitialised page-\u003eflags\nbut not dereferencing it.\n\nThanks to Erhard and Aneesh for help debugging.\n\nReported-by: Erhard Furtner \u003cerhard_f@mailbox.org\u003e\nCloses: https://lore.kernel.org/all/20230929132750.3cd98452@yea/\nSigned-off-by: Michael Ellerman \u003cmpe@ellerman.id.au\u003e\nLink: https://msgid.link/20231023112500.1550208-1-mpe@ellerman.id.au\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "f0f9986488871ed952bd13ed4892c45db51447ce", "tree": "31b5f6f599c14f958823b967f4a2a38a20373b0b", "parents": [ "78c939a88729a7cb24a87db0b8277686f801a38a" ], "author": { "name": "Douglas Anderson", "email": "dianders@chromium.org", "time": "Fri Oct 20 14:06:57 2023 -0700" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:48 2023 +0100" }, "message": "r8152: Check for unplug in r8153b_ups_en() / r8153c_ups_en()\n\n[ Upstream commit bc65cc42af737a5a35f83842408ef2c6c79ba025 ]\n\nIf the adapter is unplugged while we\u0027re looping in r8153b_ups_en() /\nr8153c_ups_en() we could end up looping for 10 seconds (20 ms * 500\nloops). Add code similar to what\u0027s done in other places in the driver\nto check for unplug and bail.\n\nSigned-off-by: Douglas Anderson \u003cdianders@chromium.org\u003e\nReviewed-by: Grant Grundler \u003cgrundler@chromium.org\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "78c939a88729a7cb24a87db0b8277686f801a38a", "tree": "875a5d5fba3cdf2d08e7a5d9ad2df7f8156f6126", "parents": [ "51cc28ce742e2f34b4cf9b4d0ed1a487bea7f681" ], "author": { "name": "Douglas Anderson", "email": "dianders@chromium.org", "time": "Fri Oct 20 14:06:56 2023 -0700" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Nov 08 17:26:48 2023 +0100" }, "message": "r8152: Check for unplug in rtl_phy_patch_request()\n\n[ Upstream commit dc90ba37a8c37042407fa6970b9830890cfe6047 ]\n\nIf the adapter is unplugged while we\u0027re looping in\nrtl_phy_patch_request() we could end up looping for 10 seconds (2 ms *\n5000 loops). Add code similar to what\u0027s done in other places in the\ndriver to check for unplug and bail.\n\nSigned-off-by: Douglas Anderson \u003cdianders@chromium.org\u003e\nReviewed-by: Grant Grundler \u003cgrundler@chromium.org\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" } ], "next": "51cc28ce742e2f34b4cf9b4d0ed1a487bea7f681" }