[{"id":3675081,"web_url":"http://patchwork.ozlabs.org/comment/3675081/","msgid":"","list_archive_url":null,"date":"2026-04-09T05:27:39","subject":"ACK: [SRU][Q][PATCH 0/1] System hangs during stress-ng stack test","submitter":{"id":85372,"url":"http://patchwork.ozlabs.org/api/people/85372/","name":"Masahiro Yamada","email":"masahiro.yamada@canonical.com"},"content":"On 4/7/26 15:34, AceLan Kao wrote:\n> From: \"Chia-Lin Kao (AceLan)\" \n>\n> BugLink: https://bugs.launchpad.net/bugs/2137755\n>\n> [Impact]\n> stress-ng memory stress test fails with stack stressor timeout on Dell\n> systems (CID: 202511-38062) running kernel 6.17.0-1007-oem. The stack\n> stressor, which creates heavy memory pressure and swap activity,\n> consistently times out after running for the expected duration.\n>\n> The issue occurs because the swap allocator uses an incorrect index when\n> retrying swap cache reclaim after encountering a race condition. During\n> heavy memory pressure (such as generated by the stack stressor), the\n> allocator reclaims cached swap slots while scanning. If it finds a folio\n> that's already removed from the swap cache due to a race, it retries - but\n> the retry uses the wrong index, which can lead to:\n> 1. Reclaiming irrelevant swap folios instead of the intended ones\n> 2. Inefficient swap reclaim behavior under memory pressure\n> 3. Performance degradation that causes stress tests to timeout\n>\n> Affected hardware: Dell systems (CID: 202511-38062) with high core count\n> and memory configurations\n> Failure rate: 100% (2/2 test runs failed)\n>\n> [Fix]\n> Upstream commit a733d8de7f1cc (\"mm, swap: fix swap cache index error when\n> retrying reclaim\") fixes the swap cache index handling.\n>\n> The fix makes two key changes:\n> 1. Makes the `entry` variable const to prevent incorrect reassignment\n> 2. Uses `folio->swap` directly when updating the offset after retrying,\n> instead of using the stale `entry` variable\n>\n> This ensures that when the allocator retries after a race condition, it\n> uses the correct swap cache index from the locked folio, preventing reclaim\n> of irrelevant folios.\n>\n> The patch is upstream in mainline kernel v6.18 and reviewed by multiple\n> memory management maintainers.\n>\n> Link: https://lkml.kernel.org/r/20250916160100.31545-4-ryncsn@gmail.com\n> Fixes: fae859550531 (\"mm, swap: avoid reclaiming irrelevant swap cache\")\n>\n> [Test Plan]\n> On affected Dell systems (CID: 202511-38062) or similar systems with high\n> core count and memory:\n>\n> 1. Install kernel with the fix\n>\n> 2. Run the stress test:\n> ```\n> # Run stress-ng with stack stressor\n> stress-ng --aggressive --verify --oom-avoid-bytes 10% --timeout 920 --stack 8\n> ```\n>\n> 3. Monitor the test execution:\n> - The test should complete within the expected 920 second timeout\n> - Check that stress-ng reports \"successful run completed\" for the stack\n> stressor\n>\n> Without the patch:\n> - stress-ng stack stressor times out and is forcefully terminated\n> - System may hang if the stress-ng process fails to be killed\n>\n> With the patch:\n> - stress-ng stack stressor completes within timeout period\n>\n> 4. Optionally verify swap activity during the test:\n> ```\n> # Monitor swap usage\n> watch -n 1 'free -h && cat /proc/swaps'\n> ```\n> Swap should be actively used and reclaimed without unusual delays.\n>\n> [Where problems could occur]\n> The changes affect the swap file subsystem's reclaim logic in mm/swapfile.c,\n> specifically the __try_to_reclaim_swap() function.\n>\n> If the fix introduces incorrect behavior:\n>\n> 1. **Incorrect folio identification**: If `folio->swap` doesn't properly\n> reflect the current state after locking, the code might still reclaim the\n> wrong folio. However, this is unlikely since the folio is locked and the\n> swap entry is validated before use.\n>\n> 2. **Performance regression**: The change from using a cached `entry` value\n> to dereferencing `folio->swap` multiple times could theoretically impact\n> performance. However, this should be negligible as the additional\n> dereferences only occur in the retry path (race condition case) which is not\n> the common case.\n>\n> 3. **Const qualifier issues**: Making `entry` const prevents reassignment.\n> If there were other code paths that relied on reassigning `entry` (not\n> visible in the upstream patch), compilation would fail. However, the\n> upstream kernel has this change merged and tested.\n>\n> 4. **Backport conflicts**: The backport required manual resolution because\n> the target branch still has an `address_space` variable that was removed\n> upstream. If the resolution was incorrect, swap cache lookups could fail.\n> However, the resolution preserves the `address_space` variable while\n> applying the const qualifier and folio->swap usage as intended.\n>\n> The impact is limited to swap reclaim behavior under memory pressure. The\n> fix makes the code more correct by ensuring the right swap slots are\n> reclaimed during races, which should improve rather than degrade stability.\n>\n>\n> Kairui Song (1):\n> mm, swap: fix swap cache index error when retrying reclaim\n>\n> mm/swapfile.c | 8 ++++----\n> 1 file changed, 4 insertions(+), 4 deletions(-)\n>\n\nAcked-by: Masahiro Yamada ","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (4096-bit key;\n unprotected) header.d=canonical.com header.i=@canonical.com\n header.a=rsa-sha256 header.s=20251003 header.b=dJmi1xYz;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com\n (client-ip=185.125.189.65; helo=lists.ubuntu.com;\n envelope-from=kernel-team-bounces@lists.ubuntu.com;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.ubuntu.com (lists.ubuntu.com [185.125.189.65])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4frpNm5qR9z1yCv\n\tfor ; Thu, 09 Apr 2026 15:27:52 +1000 (AEST)","from localhost ([127.0.0.1] helo=lists.ubuntu.com)\n\tby lists.ubuntu.com with esmtp (Exim 4.86_2)\n\t(envelope-from )\n\tid 1wAhve-0008Sw-0y; Thu, 09 Apr 2026 05:27:46 +0000","from smtp-relay-internal-0.internal ([10.131.114.225]\n helo=smtp-relay-internal-0.canonical.com)\n by lists.ubuntu.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.86_2) (envelope-from )\n id 1wAhvc-0008So-QC\n for kernel-team@lists.ubuntu.com; Thu, 09 Apr 2026 05:27:44 +0000","from mail-qk1-f197.google.com (mail-qk1-f197.google.com\n [209.85.222.197])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id A3A583F655\n for ; Thu, 9 Apr 2026 05:27:44 +0000 (UTC)","by mail-qk1-f197.google.com with SMTP id\n af79cd13be357-8d5b5d607d1so102768385a.3\n for ; Wed, 08 Apr 2026 22:27:44 -0700 (PDT)","from ?IPV6:2001:67c:1562:8007::aac:401c?\n ([2001:67c:1562:8007::aac:401c]) by smtp.gmail.com with ESMTPSA id\n af79cd13be357-8da77e51e87sm459535985a.17.2026.04.08.22.27.41\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Wed, 08 Apr 2026 22:27:42 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com;\n s=20251003; t=1775712464;\n bh=tgogbRiOEU98s6m5sHURLMUvQB1hj4ZRN+co0FpxjfU=;\n h=Message-ID:Date:MIME-Version:Subject:To:References:From:\n In-Reply-To:Content-Type;\n b=dJmi1xYz62YKI29iseYQU8SDhnyONFD4HwMnVqiGefN6aIxTY2D0+Bpvn74dY9iSq\n U4fYxPfrHC01F8pgTDYplRKUI0uZH8UD0gPclSMsm6J06FIPQzmi+3bbRCP69ufyEo\n pRzQ6q4lbU9XdO/TYB0e8dZrwFMkkE+WTtacCIBaGJlOjqKa1pyjZIJi6ToP6QPxkn\n saN7CAlLjJOCxO58aemaILEIVA5gjVr6gcwOyXVPVCvvJfDaioMnJySs3TM1aCutXZ\n WfdHVz5n8FU69ozclpf2vtJl696cwM5b26lXpgVDhBD07WAG9Y1T0itdFrD5lBHbLa\n vlK2pok8SlfJV/Brt8h2XJP4UfjKrexZ4I+HjrbDGl/B5IIeZBdVJom2zVsz62s49o\n sO4pTYDh18LU/uxFs3Hf3o1eJ+iwGuJ2eiHadWK8UEO/DhmhYTLrKJAAqSxHxvMoSQ\n bu1WdhTCyltdb/lH2+36oWJgAiv6+jy1mVulY/H5ObYEx1iKNIfcjE+gyOtxaW0dMn\n 70KI6VakNUaw5q5DqRGor+GL0G+y9w6c6VdzIXwQ8Yg84j6CKIi7atg0ozmdpVtFdi\n xMApvzkIZB3h1ajbmfXK5G8ReBO/jZCqDP0bNdjF+nV+9MkNPg3WjSfP6vN93OWt42\n 7wqE4HGaHyjn2nPqqVwpKDS8=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775712463; x=1776317263;\n h=content-transfer-encoding:in-reply-to:content-language:from\n :references:to:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=tgogbRiOEU98s6m5sHURLMUvQB1hj4ZRN+co0FpxjfU=;\n b=IVM9IfuLQjKLjdy6ZcyWl1+iaLYbm8KREpGkjYgXVx8lKp+lVzh0oXg2YxDjMJw8Mo\n m7ZqXYjGYASp8XTvK6ismJAv9ebKD+DeEdLF9b84p7ZPYbEvELmKgAsMaLZjNLkBxwpw\n fYzYrgoGb3gKb9umpHPI0DWL3BcegoY2czp+nsDlexIOMgbn/WZ3vBm1fGWXR8rDkUS1\n YVfrtNkTCbOm3yJcyA2DKBnzFxHVCJUsWktDLhRIgTzCvh1iEr/rpuchthdkApsJ3sQ9\n PlrKnDhE/axAOdlSZbEPx0WftaMPs5NKJjFnFf33Pp7DLvF0FQpbgGf3t7o922EDOlqx\n z3Iw==","X-Forwarded-Encrypted":"i=1;\n AJvYcCUZr2VHh2MQxXmTORUePbmsq+YoHTfRCfhAEjdIuCaEqRj4s+fOoLFyPGycFgD2VbNbaB9i/OWHRJ+LQA==@lists.ubuntu.com","X-Gm-Message-State":"AOJu0YzeEvWQp8X7/ONZlX7bkq3zHWDH19ZEJ2TGWfNYuEjS+ZsiJBbr\n ewSJlgaHk8T8zM47dXGxLquda2YKD5YHkgAkA4hRRAtotqDqqZYBQaFyAhlHUdSTbCFLdrYwetP\n j2E4SxU+OuLGBobnMDhs3BNwenzNErz3/tVNQUmNlv/r4B5ZDHvYTpDMG6CJLOnK68ShH3WXecg\n 62LxuEOA==","X-Gm-Gg":"AeBDiev77o2PcgKABdWdLyh6ZLiCoVJSS07QQG1O9sRDlHaguYSED3+fbzsRlHK/Of9\n VSsPQCQ9HYKOG/lPhgVS12PmNXUx/bf+QluxsaJu02f/9amxcMkDM1+ctE0efXLA5WRaEr7ibE/\n aqr87CzsZtzJ5DrYg8LcoKl7XOxmZU2ur3M1lo88gYKY1w5hloQrHzBnTqoiTgBRpKbPZEvnIiw\n XPyWwsppPAApe/s9t0CmeaFK/1WDEZ2V3Wc7pl5vkxwfKSptRALNspnxNCgR7EQerm5U91AWic7\n 3SswCC/7OAmOEC3nrOFdEPHsHH+uAEzY4YAFdHqma+bTOX0sSeK7FNrx0aCGHUGeXlegHjX8qz+\n TAIRAPAM9Y50NAFjKf9wdGXsZXD5PjJL1F9N5apfnyM4g2Ec7om2tPl//","X-Received":["by 2002:a05:620a:45a0:b0:8d7:2745:6467 with SMTP id\n af79cd13be357-8dc3d565d1bmr363299685a.36.1775712463495;\n Wed, 08 Apr 2026 22:27:43 -0700 (PDT)","by 2002:a05:620a:45a0:b0:8d7:2745:6467 with SMTP id\n af79cd13be357-8dc3d565d1bmr363298285a.36.1775712463072;\n Wed, 08 Apr 2026 22:27:43 -0700 (PDT)"],"Message-ID":"","Date":"Thu, 9 Apr 2026 14:27:39 +0900","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"ACK: [SRU][Q][PATCH 0/1] System hangs during stress-ng stack test","To":"AceLan Kao , kernel-team@lists.ubuntu.com","References":"<20260407063459.106734-1-acelan.kao@canonical.com>","From":"Masahiro Yamada ","Content-Language":"en-US","In-Reply-To":"<20260407063459.106734-1-acelan.kao@canonical.com>","X-BeenThere":"kernel-team@lists.ubuntu.com","X-Mailman-Version":"2.1.20","Precedence":"list","List-Id":"Kernel team discussions ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Transfer-Encoding":"base64","Content-Type":"text/plain; charset=\"utf-8\"; Format=\"flowed\"","Errors-To":"kernel-team-bounces@lists.ubuntu.com","Sender":"\"kernel-team\" "}},{"id":3675646,"web_url":"http://patchwork.ozlabs.org/comment/3675646/","msgid":"","list_archive_url":null,"date":"2026-04-10T04:11:35","subject":"ACK: [SRU][Q][PATCH 0/1] System hangs during stress-ng stack test","submitter":{"id":92836,"url":"http://patchwork.ozlabs.org/api/people/92836/","name":"Yufeng Gao","email":"yufeng.gao@canonical.com"},"content":"On 7/4/26 16:34, AceLan Kao wrote:\n> From: \"Chia-Lin Kao (AceLan)\" \n>\n> BugLink: https://bugs.launchpad.net/bugs/2137755\n>\n> [Impact]\n> stress-ng memory stress test fails with stack stressor timeout on Dell\n> systems (CID: 202511-38062) running kernel 6.17.0-1007-oem. The stack\n> stressor, which creates heavy memory pressure and swap activity,\n> consistently times out after running for the expected duration.\n>\n> The issue occurs because the swap allocator uses an incorrect index when\n> retrying swap cache reclaim after encountering a race condition. During\n> heavy memory pressure (such as generated by the stack stressor), the\n> allocator reclaims cached swap slots while scanning. If it finds a folio\n> that's already removed from the swap cache due to a race, it retries - but\n> the retry uses the wrong index, which can lead to:\n> 1. Reclaiming irrelevant swap folios instead of the intended ones\n> 2. Inefficient swap reclaim behavior under memory pressure\n> 3. Performance degradation that causes stress tests to timeout\n>\n> Affected hardware: Dell systems (CID: 202511-38062) with high core count\n> and memory configurations\n> Failure rate: 100% (2/2 test runs failed)\n>\n> [Fix]\n> Upstream commit a733d8de7f1cc (\"mm, swap: fix swap cache index error when\n> retrying reclaim\") fixes the swap cache index handling.\n>\n> The fix makes two key changes:\n> 1. Makes the `entry` variable const to prevent incorrect reassignment\n> 2. Uses `folio->swap` directly when updating the offset after retrying,\n> instead of using the stale `entry` variable\n>\n> This ensures that when the allocator retries after a race condition, it\n> uses the correct swap cache index from the locked folio, preventing reclaim\n> of irrelevant folios.\n>\n> The patch is upstream in mainline kernel v6.18 and reviewed by multiple\n> memory management maintainers.\n>\n> Link: https://lkml.kernel.org/r/20250916160100.31545-4-ryncsn@gmail.com\n> Fixes: fae859550531 (\"mm, swap: avoid reclaiming irrelevant swap cache\")\n>\n> [Test Plan]\n> On affected Dell systems (CID: 202511-38062) or similar systems with high\n> core count and memory:\n>\n> 1. Install kernel with the fix\n>\n> 2. Run the stress test:\n> ```\n> # Run stress-ng with stack stressor\n> stress-ng --aggressive --verify --oom-avoid-bytes 10% --timeout 920 --stack 8\n> ```\n>\n> 3. Monitor the test execution:\n> - The test should complete within the expected 920 second timeout\n> - Check that stress-ng reports \"successful run completed\" for the stack\n> stressor\n>\n> Without the patch:\n> - stress-ng stack stressor times out and is forcefully terminated\n> - System may hang if the stress-ng process fails to be killed\n>\n> With the patch:\n> - stress-ng stack stressor completes within timeout period\n>\n> 4. Optionally verify swap activity during the test:\n> ```\n> # Monitor swap usage\n> watch -n 1 'free -h && cat /proc/swaps'\n> ```\n> Swap should be actively used and reclaimed without unusual delays.\n>\n> [Where problems could occur]\n> The changes affect the swap file subsystem's reclaim logic in mm/swapfile.c,\n> specifically the __try_to_reclaim_swap() function.\n>\n> If the fix introduces incorrect behavior:\n>\n> 1. **Incorrect folio identification**: If `folio->swap` doesn't properly\n> reflect the current state after locking, the code might still reclaim the\n> wrong folio. However, this is unlikely since the folio is locked and the\n> swap entry is validated before use.\n>\n> 2. **Performance regression**: The change from using a cached `entry` value\n> to dereferencing `folio->swap` multiple times could theoretically impact\n> performance. However, this should be negligible as the additional\n> dereferences only occur in the retry path (race condition case) which is not\n> the common case.\n>\n> 3. **Const qualifier issues**: Making `entry` const prevents reassignment.\n> If there were other code paths that relied on reassigning `entry` (not\n> visible in the upstream patch), compilation would fail. However, the\n> upstream kernel has this change merged and tested.\n>\n> 4. **Backport conflicts**: The backport required manual resolution because\n> the target branch still has an `address_space` variable that was removed\n> upstream. If the resolution was incorrect, swap cache lookups could fail.\n> However, the resolution preserves the `address_space` variable while\n> applying the const qualifier and folio->swap usage as intended.\n>\n> The impact is limited to swap reclaim behavior under memory pressure. The\n> fix makes the code more correct by ensuring the right swap slots are\n> reclaimed during races, which should improve rather than degrade stability.\n>\n>\n> Kairui Song (1):\n> mm, swap: fix swap cache index error when retrying reclaim\n>\n> mm/swapfile.c | 8 ++++----\n> 1 file changed, 4 insertions(+), 4 deletions(-)\n>\nAcked-by: Yufeng Gao ","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (4096-bit key;\n unprotected) header.d=canonical.com header.i=@canonical.com\n header.a=rsa-sha256 header.s=20251003 header.b=haUvCuIc;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com\n (client-ip=185.125.189.65; helo=lists.ubuntu.com;\n envelope-from=kernel-team-bounces@lists.ubuntu.com;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.ubuntu.com (lists.ubuntu.com [185.125.189.65])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsNfZ3ySGz1y2d\n\tfor ; Fri, 10 Apr 2026 14:11:50 +1000 (AEST)","from localhost ([127.0.0.1] helo=lists.ubuntu.com)\n\tby lists.ubuntu.com with esmtp (Exim 4.86_2)\n\t(envelope-from )\n\tid 1wB3Db-0003j0-M8; Fri, 10 Apr 2026 04:11:43 +0000","from smtp-relay-internal-0.internal ([10.131.114.225]\n helo=smtp-relay-internal-0.canonical.com)\n by lists.ubuntu.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.86_2) (envelope-from )\n id 1wB3Da-0003i5-2o\n for kernel-team@lists.ubuntu.com; Fri, 10 Apr 2026 04:11:42 +0000","from mail-pj1-f72.google.com (mail-pj1-f72.google.com\n [209.85.216.72])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id E04CB3F56B\n for ; Fri, 10 Apr 2026 04:11:41 +0000 (UTC)","by mail-pj1-f72.google.com with SMTP id\n 98e67ed59e1d1-35d9010602bso1973626a91.3\n for ; Thu, 09 Apr 2026 21:11:41 -0700 (PDT)","from ?IPV6:2001:8003:ec14:5900:1079:dba2:1a81:86a8?\n ([2001:8003:ec14:5900:1079:dba2:1a81:86a8])\n by smtp.gmail.com with ESMTPSA id\n 41be03b00d2f7-c79219c618asm913322a12.18.2026.04.09.21.11.38\n for \n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Thu, 09 Apr 2026 21:11:39 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com;\n s=20251003; t=1775794301;\n bh=iagRsw4Fqkwj0hpWP/7uTVaa36XaqiFYMJKIduSJ2f8=;\n h=Message-ID:Date:MIME-Version:Subject:To:References:From:\n In-Reply-To:Content-Type;\n b=haUvCuIcI/F8Djd7NkdQNQH43TDZKULz3mrQmYsr9vAfu1D/qbxWJL9NtexjG63WR\n dLtsKAWr8uX4eg8F+wP7Sxo4UUWTBuSkvZn+/o0xbeJrLNgvEzLIP+YACHRFBgqawC\n OzG5cYAwBdA80WGW1+fipn//88gzRD/6PvGX/TifKpxh9qT1DBgzSW5Jr8F1G5oCdD\n zWI4b1gucAbZ7bM/c7ad5ijuJY91T6Kz9BYNE0+hLW6t0fv0T0Te03RBLRTCgIfOMl\n iyWqrZdu2rKBnX4LOHnMQKEwBYtcSwPz7IwUAJ0xEF6XSQg927OlLYx3o9qakaWymG\n 13cKcX34urxSrS3GaEUAdBRBICMclSBY8G7CLODRUa59g0e2Xil2GNQmfQHQ4mOkmR\n cr9zd7BBaZ2oCky3AJvm2HXk+1dFaJA+pHvmuLrqdf5Nm39KJrRjrNiK5bkyWTWcCb\n 9OgynHBCwo02lI1wqkY7glfU9KXgLfach3x39JDwIhYCKXgwv1QHDgCRBJqG/BNy+Q\n zyHZu+erw/byMwbckqRsXTTc3mW4NMcJ82wJK7ffZPGjZmWuBudY3AyMEZVZ6LYgzV\n IBuJVR61BISSebey9cSAGWhJttM31dYpJfP/JOTgzR9vYryqIVXR6vng93fs8S7yrQ\n iSljzt8I3FzGP68rju/1GDHQ=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775794300; x=1776399100;\n h=content-transfer-encoding:in-reply-to:content-language:from\n :references:to:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=iagRsw4Fqkwj0hpWP/7uTVaa36XaqiFYMJKIduSJ2f8=;\n b=iTXgvu6zUysrfQ5BtRYGShyRH6VWufDgZbVVHIaHnPOGFMKj1reRfka+oAfF8R5ONu\n 0sc21Ffg9aZDjyuCqpZ2jk0aP/ARz/FMydbRw5rf6nxyy21oTd2Qbcu03YDhmN38N26k\n kOM9PrAK7lIhNAbajJ17n3BVxnlCzD1KeUxbuBE/vhduZwUqJH2/tCVfz/UWwa+QX+6o\n jgEqOSvwlajYw3AMFR60IXITAR2u+h+L3Np7P9cdaUmJkHXTp2WmCR1+ru+GxX6q15zw\n 1CYCcNu9L9TKH/P8kUoJD6lHbbyoZVXUIz/FJIVnhpCFvqqnj1S5T5VAE1Bb1QiKsS26\n 2XtQ==","X-Gm-Message-State":"AOJu0YyfyrXLewAweolP9e3QBl6z2gCDosmwXbB1ILx4TYj6EzVEQk3W\n F9XoceN1zTgCyKQg4IP9aX6M8Nz2Nipkg9qreHY4VN1fjScQcUlBvFG3mVdpOcj+XnBu1VoPFg1\n zjnWQVErT8CYlvXNpO+kqjQEST8EDusVt8uqUbMskGnkEVFn86ZMjN8RWwbhxbLGuMmdndQTIAL\n eMQfS6XFMqiPlsGg==","X-Gm-Gg":"AeBDieulJNy2d0JfuJYaOp8vOQsciHzWL69WgtH44C768xWPEjVLkuD0UPEeVC6s6y5\n z7L6RR3931wL2xzyfdMwlx/loZULY2jKP80m6XPC8A1OUa87EDBCpdfu52qmBldQfHU9qr4qn2A\n ppLo78Mwy55VxETBdLNp0gHzOXxb0xD7AdDUQGM74BVE+YiYI3gdkqCtCVXvfip1pskYNWm8SxS\n 1xbL2ACqWfuHrzjieZgJRuGP3EbTeDSUtOYkSOc6W6C8GTV/EWHXFk8KGYJtHWtYmEWuEtAx4Fo\n 8IUXi/ND7iPmF1NjNz2SkkY32BjgU8qVwnV8a8xvoga62bykLKDc9tM3LLG6GD9BLLXxCtEMUPx\n TAS1+fCZZh/2EeAE1vjw6LYIIjr6aSJ7/0DWcaL2IeuFXnza0+zl0uJYo/pqz/vwp/astkuRovu\n k3L8o=","X-Received":["by 2002:a05:6a20:12d2:b0:398:9ae9:710f with SMTP id\n adf61e73a8af0-39fe3d53b21mr1802410637.13.1775794300511;\n Thu, 09 Apr 2026 21:11:40 -0700 (PDT)","by 2002:a05:6a20:12d2:b0:398:9ae9:710f with SMTP id\n adf61e73a8af0-39fe3d53b21mr1802384637.13.1775794300067;\n Thu, 09 Apr 2026 21:11:40 -0700 (PDT)"],"Message-ID":"","Date":"Fri, 10 Apr 2026 14:11:35 +1000","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"ACK: [SRU][Q][PATCH 0/1] System hangs during stress-ng stack test","To":"kernel-team@lists.ubuntu.com","References":"<20260407063459.106734-1-acelan.kao@canonical.com>","From":"Yufeng Gao ","Content-Language":"en-US","In-Reply-To":"<20260407063459.106734-1-acelan.kao@canonical.com>","X-BeenThere":"kernel-team@lists.ubuntu.com","X-Mailman-Version":"2.1.20","Precedence":"list","List-Id":"Kernel team discussions ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Transfer-Encoding":"base64","Content-Type":"text/plain; charset=\"utf-8\"; Format=\"flowed\"","Errors-To":"kernel-team-bounces@lists.ubuntu.com","Sender":"\"kernel-team\" "}},{"id":3675997,"web_url":"http://patchwork.ozlabs.org/comment/3675997/","msgid":"<87fr52sout.fsf@gmail.com>","list_archive_url":null,"date":"2026-04-10T17:32:26","subject":"APPLIED: [SRU][Q][PATCH 0/1] System hangs during stress-ng stack test","submitter":{"id":89305,"url":"http://patchwork.ozlabs.org/api/people/89305/","name":"Mehmet Basaran","email":"mehmet.basaran@canonical.com"},"content":"Applied to questing:linux master-next branch. Thanks.\nAceLan Kao writes:\n\n> From: \"Chia-Lin Kao (AceLan)\" \n>\n> BugLink: https://bugs.launchpad.net/bugs/2137755\n>\n> [Impact]\n> stress-ng memory stress test fails with stack stressor timeout on Dell\n> systems (CID: 202511-38062) running kernel 6.17.0-1007-oem. The stack\n> stressor, which creates heavy memory pressure and swap activity,\n> consistently times out after running for the expected duration.\n>\n> The issue occurs because the swap allocator uses an incorrect index when\n> retrying swap cache reclaim after encountering a race condition. During\n> heavy memory pressure (such as generated by the stack stressor), the\n> allocator reclaims cached swap slots while scanning. If it finds a folio\n> that's already removed from the swap cache due to a race, it retries - but\n> the retry uses the wrong index, which can lead to:\n> 1. Reclaiming irrelevant swap folios instead of the intended ones\n> 2. Inefficient swap reclaim behavior under memory pressure\n> 3. Performance degradation that causes stress tests to timeout\n>\n> Affected hardware: Dell systems (CID: 202511-38062) with high core count\n> and memory configurations\n> Failure rate: 100% (2/2 test runs failed)\n>\n> [Fix]\n> Upstream commit a733d8de7f1cc (\"mm, swap: fix swap cache index error when\n> retrying reclaim\") fixes the swap cache index handling.\n>\n> The fix makes two key changes:\n> 1. Makes the `entry` variable const to prevent incorrect reassignment\n> 2. Uses `folio->swap` directly when updating the offset after retrying,\n> instead of using the stale `entry` variable\n>\n> This ensures that when the allocator retries after a race condition, it\n> uses the correct swap cache index from the locked folio, preventing reclaim\n> of irrelevant folios.\n>\n> The patch is upstream in mainline kernel v6.18 and reviewed by multiple\n> memory management maintainers.\n>\n> Link: https://lkml.kernel.org/r/20250916160100.31545-4-ryncsn@gmail.com\n> Fixes: fae859550531 (\"mm, swap: avoid reclaiming irrelevant swap cache\")\n>\n> [Test Plan]\n> On affected Dell systems (CID: 202511-38062) or similar systems with high\n> core count and memory:\n>\n> 1. Install kernel with the fix\n>\n> 2. Run the stress test:\n> ```\n> # Run stress-ng with stack stressor\n> stress-ng --aggressive --verify --oom-avoid-bytes 10% --timeout 920 --stack 8\n> ```\n>\n> 3. Monitor the test execution:\n> - The test should complete within the expected 920 second timeout\n> - Check that stress-ng reports \"successful run completed\" for the stack\n> stressor\n>\n> Without the patch:\n> - stress-ng stack stressor times out and is forcefully terminated\n> - System may hang if the stress-ng process fails to be killed\n>\n> With the patch:\n> - stress-ng stack stressor completes within timeout period\n>\n> 4. Optionally verify swap activity during the test:\n> ```\n> # Monitor swap usage\n> watch -n 1 'free -h && cat /proc/swaps'\n> ```\n> Swap should be actively used and reclaimed without unusual delays.\n>\n> [Where problems could occur]\n> The changes affect the swap file subsystem's reclaim logic in mm/swapfile.c,\n> specifically the __try_to_reclaim_swap() function.\n>\n> If the fix introduces incorrect behavior:\n>\n> 1. **Incorrect folio identification**: If `folio->swap` doesn't properly\n> reflect the current state after locking, the code might still reclaim the\n> wrong folio. However, this is unlikely since the folio is locked and the\n> swap entry is validated before use.\n>\n> 2. **Performance regression**: The change from using a cached `entry` value\n> to dereferencing `folio->swap` multiple times could theoretically impact\n> performance. However, this should be negligible as the additional\n> dereferences only occur in the retry path (race condition case) which is not\n> the common case.\n>\n> 3. **Const qualifier issues**: Making `entry` const prevents reassignment.\n> If there were other code paths that relied on reassigning `entry` (not\n> visible in the upstream patch), compilation would fail. However, the\n> upstream kernel has this change merged and tested.\n>\n> 4. **Backport conflicts**: The backport required manual resolution because\n> the target branch still has an `address_space` variable that was removed\n> upstream. If the resolution was incorrect, swap cache lookups could fail.\n> However, the resolution preserves the `address_space` variable while\n> applying the const qualifier and folio->swap usage as intended.\n>\n> The impact is limited to swap reclaim behavior under memory pressure. The\n> fix makes the code more correct by ensuring the right swap slots are\n> reclaimed during races, which should improve rather than degrade stability.\n>\n>\n> Kairui Song (1):\n> mm, swap: fix swap cache index error when retrying reclaim\n>\n> mm/swapfile.c | 8 ++++----\n> 1 file changed, 4 insertions(+), 4 deletions(-)\n>\n> -- \n> 2.53.0\n>\n>\n> -- \n> kernel-team mailing list\n> kernel-team@lists.ubuntu.com\n> https://lists.ubuntu.com/mailman/listinfo/kernel-team","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (4096-bit key;\n unprotected) header.d=canonical.com header.i=@canonical.com\n header.a=rsa-sha256 header.s=20251003 header.b=HlX06jiN;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com\n (client-ip=185.125.189.65; helo=lists.ubuntu.com;\n envelope-from=kernel-team-bounces@lists.ubuntu.com;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.ubuntu.com (lists.ubuntu.com [185.125.189.65])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fskQZ1DvBz1yGS\n\tfor ; Sat, 11 Apr 2026 03:32:38 +1000 (AEST)","from localhost ([127.0.0.1] helo=lists.ubuntu.com)\n\tby lists.ubuntu.com with esmtp (Exim 4.86_2)\n\t(envelope-from )\n\tid 1wBFiZ-0003B5-1R; Fri, 10 Apr 2026 17:32:31 +0000","from smtp-relay-internal-1.internal ([10.131.114.114]\n helo=smtp-relay-internal-1.canonical.com)\n by lists.ubuntu.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.86_2) (envelope-from )\n id 1wBFiX-0003Ak-Mh\n for kernel-team@lists.ubuntu.com; Fri, 10 Apr 2026 17:32:29 +0000","from mail-wm1-f69.google.com (mail-wm1-f69.google.com\n [209.85.128.69])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 8DC773F16E\n for ; Fri, 10 Apr 2026 17:32:29 +0000 (UTC)","by mail-wm1-f69.google.com with SMTP id\n 5b1f17b1804b1-488c0120047so15276525e9.0\n for ; Fri, 10 Apr 2026 10:32:29 -0700 (PDT)","from localhost ([94.54.18.154]) by smtp.gmail.com with ESMTPSA id\n 5b1f17b1804b1-488d5b3c597sm83997295e9.12.2026.04.10.10.32.27\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Fri, 10 Apr 2026 10:32:27 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com;\n s=20251003; t=1775842349;\n bh=+HCXnSWKecV3KyEU39UYB004GT1nxz/XB1McnVSSwgc=;\n h=From:To:Subject:In-Reply-To:References:Date:Message-ID:\n MIME-Version:Content-Type;\n b=HlX06jiN+OsFS2JGrPgCtMLh3A/NRmDZUNcF1Vb8qG3XK+WyOV/brPO1lL4sOdb/p\n uqPGB6GRtswEVPDxDq1rmPXNoSYR/YixMJJJ9H9M3JpGGJqyHCh4iXgCLbnFKf1qaG\n cBnH5HBCK/bNErJ6+1baTPvFzeuWnMvpenbqicC2RInHRFGEksPxqPO8IGO6O2pyrc\n TjHqf1m1MZgG4z0SkbAagLqtro0L2QLZNOKYNRbVQZZ6r90PhmKRs6w4lF4zzTTD+/\n UwP97TfNgXIYda4g2hQrM9hdIA7Fz4U/JZZhLjFlQ53tYAagaIUIbTKU8zhzNZa7aS\n XwKWoTzvQQOySjHtI6+AN/HhsU5ihoVyB4ugg3201IBMFjk9gbd2x/RpQ4xP/jXI3J\n P9KX898UqhEyoFgvkTuscZP5O5qU6wI7qNRUUX2R22bI2SnLXnQtK4lWLsN7f1j7eX\n +G51L/MGHbSx/Ktsj7NmY0roWgzNvTsAkaZy/S736WYR1Ts1LRD11M88U1A3ipAYZx\n AHnqGt8PFYM4cxH5eXicHLuqeFBrpYiU54LoWdwx0+OJWnq7zfOFRxEXNvjODUbdrx\n fQuovnEYrNUMlFuIphMhzfpK2j3PvlJ88e4iGuDsVVEOrly9d2Q5SRzZnrOEuUQmFK\n wf5gl8uQ8L1EoZWXx9+T1gVI=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775842349; x=1776447149;\n h=mime-version:message-id:date:references:in-reply-to:subject:to:from\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=+HCXnSWKecV3KyEU39UYB004GT1nxz/XB1McnVSSwgc=;\n b=UCQ3DKm0lWIy04Saq3tM8PwjNkAAfMkD8hRtB5KIbYoouSkq7NYwrZaeHDC7ZqgDqC\n V4wQzVndyC3ncQSq+vbURPgql2btfFYMC4YJ4bJn1hHz5+2tnyC2Q6xFYFtUa4ykv6J5\n V+2/Lyl5a2byCD6pNV8abD2wtzHecrgw8QyRhNuU1u9Co5XwdeZ8dbGDKXYYQDZAWNeF\n 8Uqke0Pj3gGTzD+7eWXjKreHAMEtP8oJ7PkOQ9ulZd/PX4zKbvu4uiG9vylO/kx4YCrJ\n PFvbyuWNGAv3A240ssHpQ+L0exV1BH9OBYQJwrtzoDtBX+tM6vAnnSA3cAO9wSioJ5EX\n 5NDQ==","X-Forwarded-Encrypted":"i=1;\n AJvYcCUOhbChSLJCR6ZTdoU+R+KtnNyp2/TKQt+1+j5QvaZWNeV4p+2IgVU2z1w/6dfYekfUzMxW4pIhiQLLbw==@lists.ubuntu.com","X-Gm-Message-State":"AOJu0YwU31wMaFvm9AEiS1be7bdgODQmM0gC0MnVTEvNK52HqqEpe5A2\n vh3zWnxNiPKXthiAAx7610VFP6Is4CIvaYT5AURQhuryqpPFzAViF6r91QkfhmHNH0cx3YVYTgQ\n 4q0jZlqaz1faR9OLaa6+VkGpv7yEVUK0k4t14QQX94LL1K31hARLnleJt9x0ExdKzoKYVGG4cEf\n uqs8Z/+d/V2cYeUw==","X-Gm-Gg":"AeBDieuN/vzpWQ/3ox1ImlpODdbvgiZ5+wAKOy2CZcsn7wOHjthByppiF/BGXvOHxWx\n piSZGJ3OF60OakkvCDlzk2O6CrH6ScQJY3tAE6/moGJxW5VJRJdDQ9uOlOgIoXmwuTSYxhGkijr\n /8RfGDUWXAaCTRhGVPMsRGlGOyd1q5UUN5v2geFRLmRw7sVsp3azNPeGBUOTe/Vj9iS5ZIaBt/U\n DbktFfg0wXnfUNmFQFJ7Y8HkVUYvOlp2McPmXPLwe2u6XdAHxG0UAWEKo21UtIgC2tYFudTZzlu\n le8blBy/A7M0GASB/u+u6KlkbbX7ZR+V4FGGa2bawi8qArGeK5R2VNiTb2kK84VQ5zrCHykR+dA\n AHIJ8RHdvygoEov5tgWpaUmFZBEt8","X-Received":["by 2002:a05:600c:c088:b0:486:f4d2:eac6 with SMTP id\n 5b1f17b1804b1-488d67e6776mr38862725e9.13.1775842348895;\n Fri, 10 Apr 2026 10:32:28 -0700 (PDT)","by 2002:a05:600c:c088:b0:486:f4d2:eac6 with SMTP id\n 5b1f17b1804b1-488d67e6776mr38862475e9.13.1775842348490;\n Fri, 10 Apr 2026 10:32:28 -0700 (PDT)"],"From":"Mehmet Basaran ","To":"AceLan Kao , kernel-team@lists.ubuntu.com","Subject":"APPLIED: [SRU][Q][PATCH 0/1] System hangs during stress-ng stack test","In-Reply-To":"<20260407063459.106734-1-acelan.kao@canonical.com>","References":"<20260407063459.106734-1-acelan.kao@canonical.com>","Date":"Fri, 10 Apr 2026 20:32:26 +0300","Message-ID":"<87fr52sout.fsf@gmail.com>","MIME-Version":"1.0","Content-Type":"multipart/mixed; boundary=\"=-=-=\"","X-BeenThere":"kernel-team@lists.ubuntu.com","X-Mailman-Version":"2.1.20","Precedence":"list","List-Id":"Kernel team discussions ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"kernel-team-bounces@lists.ubuntu.com","Sender":"\"kernel-team\" "}}]