[{"id":3676426,"web_url":"http://patchwork.ozlabs.org/comment/3676426/","msgid":"<adxiNs3KpMO-nEVG@redhat.com>","list_archive_url":null,"date":"2026-04-13T03:25:42","subject":"Re: [LTP] [PATCH] mmap: fix intermittent OOM kill of test parent in\n mmap22","submitter":{"id":73704,"url":"http://patchwork.ozlabs.org/api/people/73704/","name":"Li Wang","email":"liwang@redhat.com"},"content":"Hi Soma,\n\n>  static void stress_child(void)\n>  {\n>      for (;;) {\n> @@ -63,9 +82,25 @@ static void test_mmap(void)\n> \n>      vec = SAFE_MALLOC(npages);\n> \n> +    /*\n> +     * Protect the parent (test harness) from the OOM killer. Both parent\n> +     * and child share the same memcg, so without an explicit hint the OOM\n> +     * killer picks based on heuristics that can favour the parent.\n> +     */\n> +    set_oom_score_adj(-1000);\n> +\n>      child = SAFE_FORK();\n> -    if (!child)\n> +    if (!child) {\n> +        /*\n> +         * Make the child the preferred OOM victim. If OOM fires while\n> +         * the stress worker is filling memory, the kernel must kill the\n> +         * child (stress worker) and not the parent (test harness).\n> +         * oom_score_adj=1000 is the maximum, guaranteeing this process\n> +         * is chosen first within the cgroup.\n> +         */\n> +        set_oom_score_adj(1000);\n\nSetting the child's oom_score_adj to 1000 does severely compromise the\nvalidity of the test. This would typically result in a false negative.\n\nBecause once the child gets killed the memory stress will disappear\nimmediately, but the parent still keeps looping for check if kernel reclaim\nthose memory, it will evantaully report TFAIL when time elapsed.\n\nInstead of modifying oom_score_adj to interfere with the OOM killer, a\nbetter approach is to optimize how the child process generates memory\npressure, making it more reflective of real-world memory reclaim scenarios.\n\nFor example, the child process can allocate larger chunks (e.g., 1MB) to\nrapidly build up memory pressure. Once the total allocated memory approaches\nthe cgroup limit (e.g., 80% capacity), a small delay can be introduced\ninto the allocation loop. This approach efficiently drives the system to\nits memory limit while providing the kernel's reclaim mechanism a sufficient\ntime window to identify and drop MAP_DROPPABLE pages. It also effectively\navoids an instantaneous memory spike that would otherwise trigger the OOM\nkiller prematurely.\n\n#define CHUNK_SIZE (1024 * 1024)\n\nstatic void stress_child(size_t cg_limit)\n{\n\tsize_t allocated = 0;\n\tsize_t threshold = cg_limit * 8 / 10;\n\n\tfor (;;) {\n\t\tchar *buf = malloc(CHUNK_SIZE);\n\n\t\tif (!buf) {\n\t\t\tusleep(10000);\n\t\t\tcontinue;\n\t\t}\n\n\t\tmemset(buf, 'B', CHUNK_SIZE);\n\t\tallocated += CHUNK_SIZE;\n\n\t\tif (allocated >= threshold) {\n\t\t\tusleep(1000);\n\t\t}\n\t}\n}\n\nAnd some workflow issues:\n\n - please rebase you code on the latest branch before cooking a patch.\n\n - Use git send-email to send patch to LTP mailing list.\n\n - FYI: LTP has already achieved the oom protection fucntions:\n   see: lib/tst_memutils.h\n\nNote:\n This work-email will be disabled soon, reply to: wangli.ahau@gmail.com","headers":{"Return-Path":"<ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it>","X-Original-To":["incoming@patchwork.ozlabs.org","ltp@lists.linux.it"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ltp@picard.linux.it"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=lists.linux.it header.i=@lists.linux.it\n header.a=rsa-sha256 header.s=picard header.b=JV8eEMo4;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=EZcAZKOI;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it\n (client-ip=2001:1418:10:5::2; helo=picard.linux.it;\n envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it;\n receiver=patchwork.ozlabs.org)"],"Received":["from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fvCVL0QWcz1yDF\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 13:25:59 +1000 (AEST)","from picard.linux.it (localhost [IPv6:::1])\n\tby picard.linux.it (Postfix) with ESMTP id 143A43E2E1C\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 05:25:56 +0200 (CEST)","from in-5.smtp.seeweb.it (in-5.smtp.seeweb.it [217.194.8.5])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature ECDSA (secp384r1))\n (No client certificate requested)\n by picard.linux.it (Postfix) with ESMTPS id 10D963DD13E\n for <ltp@lists.linux.it>; Mon, 13 Apr 2026 05:25:51 +0200 (CEST)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.133.124])\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 in-5.smtp.seeweb.it (Postfix) with ESMTPS id 5663A600541\n for <ltp@lists.linux.it>; Mon, 13 Apr 2026 05:25:50 +0200 (CEST)","from mail-pg1-f197.google.com (mail-pg1-f197.google.com\n [209.85.215.197]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-530-VvX6x84JOVWqsUymeU3HDg-1; Sun, 12 Apr 2026 23:25:46 -0400","by mail-pg1-f197.google.com with SMTP id\n 41be03b00d2f7-c6e24ee93a6so1852871a12.0\n for <ltp@lists.linux.it>; Sun, 12 Apr 2026 20:25:46 -0700 (PDT)","from redhat.com ([123.121.104.131]) by smtp.gmail.com with ESMTPSA\n id\n 41be03b00d2f7-c7921a1d0d2sm7476459a12.27.2026.04.12.20.25.43\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Sun, 12 Apr 2026 20:25:44 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=lists.linux.it;\n i=@lists.linux.it; q=dns/txt; s=picard; t=1776050756; h=date : to :\n message-id : references : mime-version : in-reply-to : subject :\n list-id : list-unsubscribe : list-archive : list-post : list-help :\n list-subscribe : from : reply-to : cc : content-type :\n content-transfer-encoding : sender : from;\n bh=BEfibAkdRBkp09Q3l8mAikrj8XhliMCgjpHlthMIFJk=;\n b=JV8eEMo4boxKYudgDWlIIcq861H/MKW+2psa9r1zHZDo4Rrgg7HdUO2/G04UDMgK5l9tn\n DA2i8Paet+VWuJ7b554az0z4r/DhMub19kj0VpoTGSF3ZxujvxVBOSWgl0dH1FthS2SGhri\n OAbgH6G1eUvOnwNa/0bYQQS+2/3Nqo0=","v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1776050748;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=dkulzlithTP7oOu2npQxcOHxUF7aeI4n50UI6A+722s=;\n b=EZcAZKOIEC/vYEgS3ATUNh/STZbRyprBTIJfArU1p7KrEjSxEMEhugKCZr/dnT21WUvlSq\n nVzd5ZdQI89QWnpPGSvIipI+cNlnCXtNqWu67mXa2cIQBt11oSQ0hto1d5S/txSBjlk5D1\n HPE0+bn/kJIalUEFVqSBIcunRlRzU0w="],"X-MC-Unique":"VvX6x84JOVWqsUymeU3HDg-1","X-Mimecast-MFC-AGG-ID":"VvX6x84JOVWqsUymeU3HDg_1776050746","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776050746; x=1776655546;\n h=in-reply-to:content-transfer-encoding:content-disposition\n :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg\n :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n bh=dkulzlithTP7oOu2npQxcOHxUF7aeI4n50UI6A+722s=;\n b=kWDz7L99HdUlPv0M8AGJb1cxxeNCHnUkd2QF0f3d8lpywNu+PyGU9U93fO5e443JCF\n lCHPAGNttklhtd7SuMkWWscLGCScaYtlEI/6C0UIjGa5NjsLQSyXH+2Ql6hM4x/WjwBN\n mFrWTB5yJI3ilE0EZsc25cmLW0VNTG8eEqiYqGE93K0YtpthzDHvoyyERtByw+WBB1e+\n JWUItLUcnB1P9NNLTySkpawJHjuzZSOh+vy/vtU5uIY8JzBbgHQBNy4P3OeniSgN0Xca\n QtZT5AEOwQmESBxYiezWI5m/MqckRabiFO7ch2xO8Fyd6h8Y8YV0Doqvy6bl6L4ZbmH/\n N7ug==","X-Gm-Message-State":"AOJu0YxWWZblpze5lNEIMUygKRtX6qIgXGUoIAu630NheTPahQ3xe9Ik\n QGGs8oailiSPNfGpdBO8WHcUcKgsWRxm+npUmMnoZM1gmlGnl+OaNqcE2EfxV+z61p28P1mkfpr\n oXka6L3nkdTeasVkjgXc4CiAZrNWbeF87ztbGsvj/aONDR6Z7vGIk","X-Gm-Gg":"AeBDiesXrcWo8/gqbgV1kJiQxSpVcBG+Cyy0r+k9xZJ7iO4j6dlOnarq8HFico6Ei5j\n cAqW9wykwnZ0l/ogQ4cDicQsf9RUC4g0i8GPWFtYIQCnHOZJv8VYB2BJPyangaMoRab/uczocjr\n VmNJKbpVNZI/iYMhWxo+R0VO3jG45Qzj5XjpBu2pIChbs6czNddeyUk/ZkjmbDMjIeL3TQYgoJc\n +4XPJgvLcWczEdj87EV5cyS/kCdmqp3Qbpy7XKq8XQGUXlGD/cxS1Gkk+iIinAGfVeRp6AWJnqW\n kAQtduwgi13274Hgy3vtbctlYrkXJXcf8lJrkEMsly10BW4I1WIojMPKjc07VVfBuaxyP68EaFf\n s2AdnRU1cjxeyw/TPcA==","X-Received":["by 2002:a05:6a20:7486:b0:39f:c93e:c7f7 with SMTP id\n adf61e73a8af0-39fe3f29f63mr10656634637.0.1776050745620;\n Sun, 12 Apr 2026 20:25:45 -0700 (PDT)","by 2002:a05:6a20:7486:b0:39f:c93e:c7f7 with SMTP id\n adf61e73a8af0-39fe3f29f63mr10656604637.0.1776050745049;\n Sun, 12 Apr 2026 20:25:45 -0700 (PDT)"],"Date":"Mon, 13 Apr 2026 11:25:42 +0800","To":"Soma Das <somadas1@linux.ibm.com>","Message-ID":"<adxiNs3KpMO-nEVG@redhat.com>","References":"<6215241a-07c4-4eed-8549-0e0afc2fc096@linux.ibm.com>","MIME-Version":"1.0","In-Reply-To":"<6215241a-07c4-4eed-8549-0e0afc2fc096@linux.ibm.com>","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"OUGSCTM4vGr2yswmfHHdmdYBFW-IBfVI1EZsnoehQJU_1776050746","X-Mimecast-Originator":"redhat.com","Content-Disposition":"inline","X-Spam-Status":"No, score=0.1 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,\n DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS shortcircuit=no\n autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on in-5.smtp.seeweb.it","X-Virus-Scanned":"clamav-milter 1.0.9 at in-5.smtp.seeweb.it","X-Virus-Status":"Clean","Subject":"Re: [LTP] [PATCH] mmap: fix intermittent OOM kill of test parent in\n mmap22","X-BeenThere":"ltp@lists.linux.it","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"Linux Test Project <ltp.lists.linux.it>","List-Unsubscribe":"<https://lists.linux.it/options/ltp>,\n <mailto:ltp-request@lists.linux.it?subject=unsubscribe>","List-Archive":"<http://lists.linux.it/pipermail/ltp/>","List-Post":"<mailto:ltp@lists.linux.it>","List-Help":"<mailto:ltp-request@lists.linux.it?subject=help>","List-Subscribe":"<https://lists.linux.it/listinfo/ltp>,\n <mailto:ltp-request@lists.linux.it?subject=subscribe>","From":"Li Wang via ltp <ltp@lists.linux.it>","Reply-To":"Li Wang <liwang@redhat.com>","Cc":"ltp@lists.linux.it","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it","Sender":"\"ltp\" <ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it>"}},{"id":3676461,"web_url":"http://patchwork.ozlabs.org/comment/3676461/","msgid":"<f5b8b153-2fd8-4e6e-8446-0d9fe82221cd@linux.ibm.com>","list_archive_url":null,"date":"2026-04-13T05:27:36","subject":"Re: [LTP] [PATCH] mmap: fix intermittent OOM kill of test parent in\n mmap22","submitter":{"id":93035,"url":"http://patchwork.ozlabs.org/api/people/93035/","name":"Soma Das","email":"somadas1@linux.ibm.com"},"content":"Hi Li Wang,\n\nThanks for the review.\n\nUnderstood. Setting the child to +1000 removes memory pressure \nimmediately once it gets killed, causing the parent to time out with \nTFAIL. I'll rework using your suggested |stress_child()| approach with \n1MB chunks and the 80% threshold delay.\n\nI'll also check |lib/tst_memutils.h| before finalizing.\n\nv2 will be rebased on latest master and sent via git send-email.\n\nThanks, Soma Das\n\n\nOn 13/04/26 8:55 AM, Li Wang wrote:\n> Hi Soma,\n>\n>>   static void stress_child(void)\n>>   {\n>>       for (;;) {\n>> @@ -63,9 +82,25 @@ static void test_mmap(void)\n>>\n>>       vec = SAFE_MALLOC(npages);\n>>\n>> +    /*\n>> +     * Protect the parent (test harness) from the OOM killer. Both parent\n>> +     * and child share the same memcg, so without an explicit hint the OOM\n>> +     * killer picks based on heuristics that can favour the parent.\n>> +     */\n>> +    set_oom_score_adj(-1000);\n>> +\n>>       child = SAFE_FORK();\n>> -    if (!child)\n>> +    if (!child) {\n>> +        /*\n>> +         * Make the child the preferred OOM victim. If OOM fires while\n>> +         * the stress worker is filling memory, the kernel must kill the\n>> +         * child (stress worker) and not the parent (test harness).\n>> +         * oom_score_adj=1000 is the maximum, guaranteeing this process\n>> +         * is chosen first within the cgroup.\n>> +         */\n>> +        set_oom_score_adj(1000);\n> Setting the child's oom_score_adj to 1000 does severely compromise the\n> validity of the test. This would typically result in a false negative.\n>\n> Because once the child gets killed the memory stress will disappear\n> immediately, but the parent still keeps looping for check if kernel reclaim\n> those memory, it will evantaully report TFAIL when time elapsed.\n>\n> Instead of modifying oom_score_adj to interfere with the OOM killer, a\n> better approach is to optimize how the child process generates memory\n> pressure, making it more reflective of real-world memory reclaim scenarios.\n>\n> For example, the child process can allocate larger chunks (e.g., 1MB) to\n> rapidly build up memory pressure. Once the total allocated memory approaches\n> the cgroup limit (e.g., 80% capacity), a small delay can be introduced\n> into the allocation loop. This approach efficiently drives the system to\n> its memory limit while providing the kernel's reclaim mechanism a sufficient\n> time window to identify and drop MAP_DROPPABLE pages. It also effectively\n> avoids an instantaneous memory spike that would otherwise trigger the OOM\n> killer prematurely.\n>\n> #define CHUNK_SIZE (1024 * 1024)\n>\n> static void stress_child(size_t cg_limit)\n> {\n> \tsize_t allocated = 0;\n> \tsize_t threshold = cg_limit * 8 / 10;\n>\n> \tfor (;;) {\n> \t\tchar *buf = malloc(CHUNK_SIZE);\n>\n> \t\tif (!buf) {\n> \t\t\tusleep(10000);\n> \t\t\tcontinue;\n> \t\t}\n>\n> \t\tmemset(buf, 'B', CHUNK_SIZE);\n> \t\tallocated += CHUNK_SIZE;\n>\n> \t\tif (allocated >= threshold) {\n> \t\t\tusleep(1000);\n> \t\t}\n> \t}\n> }\n>\n> And some workflow issues:\n>\n>   - please rebase you code on the latest branch before cooking a patch.\n>\n>   - Use git send-email to send patch to LTP mailing list.\n>\n>   - FYI: LTP has already achieved the oom protection fucntions:\n>     see: lib/tst_memutils.h\n>\n> Note:\n>   This work-email will be disabled soon, reply to:wangli.ahau@gmail.com\n>","headers":{"Return-Path":"<ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it>","X-Original-To":["incoming@patchwork.ozlabs.org","ltp@lists.linux.it"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ltp@picard.linux.it"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=E6pCvlA8;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it\n (client-ip=2001:1418:10:5::2; helo=picard.linux.it;\n envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it;\n receiver=patchwork.ozlabs.org)"],"Received":["from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fvGBz6ZkVz1yDF\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 15:27:54 +1000 (AEST)","from picard.linux.it (localhost [IPv6:::1])\n\tby picard.linux.it (Postfix) with ESMTP id BDCC53E1E95\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 07:27:52 +0200 (CEST)","from in-2.smtp.seeweb.it (in-2.smtp.seeweb.it\n [IPv6:2001:4b78:1:20::2])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature ECDSA (secp384r1))\n (No client certificate requested)\n by picard.linux.it (Postfix) with ESMTPS id 7E34B3C0E59\n for <ltp@lists.linux.it>; Mon, 13 Apr 2026 07:27:47 +0200 (CEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n [148.163.156.1])\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 in-2.smtp.seeweb.it (Postfix) with ESMTPS id B51BF600110\n for <ltp@lists.linux.it>; Mon, 13 Apr 2026 07:27:46 +0200 (CEST)","from pps.filterd (m0360083.ppops.net [127.0.0.1])\n by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 63CMQWVI3538921; Mon, 13 Apr 2026 05:27:44 GMT","from ppma11.dal12v.mail.ibm.com\n (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219])\n by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4dfdt3p4yq-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n Mon, 13 Apr 2026 05:27:43 +0000 (GMT)","from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1])\n by ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id\n 63D55us6025781;\n Mon, 13 Apr 2026 05:27:43 GMT","from smtprelay03.dal12v.mail.ibm.com ([172.16.1.5])\n by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4dg3b1bh5h-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n Mon, 13 Apr 2026 05:27:43 +0000","from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com\n [10.39.53.228])\n by smtprelay03.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 63D5RgEj10158610\n (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n Mon, 13 Apr 2026 05:27:42 GMT","from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id 4A22958059;\n Mon, 13 Apr 2026 05:27:42 +0000 (GMT)","from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id 0DAA35804B;\n Mon, 13 Apr 2026 05:27:40 +0000 (GMT)","from [9.43.104.112] (unknown [9.43.104.112])\n by smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTPS;\n Mon, 13 Apr 2026 05:27:39 +0000 (GMT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc\n :content-type:date:from:in-reply-to:message-id:mime-version\n :references:subject:to; s=pp1; bh=SVxOFqRsC3ixlg75cc2qGaS9t15PHb\n AACdkUvwUVwrQ=; b=E6pCvlA8lvfKB48vyH1r7LEKMm8qSSxTeqjiU+3u0q74L4\n EIWhhKaPGF8Pky8J8etSw6hgEKD2yhRLugMF9h8RIvkdpSVFkTCw/ebUT/kT8k4N\n gXZ+r0fu5mmS6hYuqvF3OUfHageYSyP6+4FvaT0DZvQ4R/Gw+UXRn0DhXFAUcx+Q\n i+j/ScqlRT4fkd4+UT8W1zVBZxGzfOhlW0Hz436KBYCDsq3w17QPz3MW4t+f4Az0\n /yT7wvM05dx9+vmsYxouhW3l7i83BYCrhPvzz1Zq7Pca4iPpNlVLoigZYgCqZJ9Z\n GmVPmiMsRj6Ig+lMPItZo4z0etuyXl/OPifvg3dA==","Message-ID":"<f5b8b153-2fd8-4e6e-8446-0d9fe82221cd@linux.ibm.com>","Date":"Mon, 13 Apr 2026 10:57:36 +0530","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","To":"Li Wang <liwang@redhat.com>","References":"<6215241a-07c4-4eed-8549-0e0afc2fc096@linux.ibm.com>\n <adxiNs3KpMO-nEVG@redhat.com>","Content-Language":"en-US","From":"Soma Das <somadas1@linux.ibm.com>","In-Reply-To":"<adxiNs3KpMO-nEVG@redhat.com>","X-TM-AS-GCONF":"00","X-Proofpoint-Reinject":"loops=2 maxloops=12","X-Proofpoint-ORIG-GUID":"GBn07ya7JYmr6zWUa4XqJ-4zr8dppvxG","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDEzMDA0OCBTYWx0ZWRfXwnEmqReBXbq9\n +fvkEP4JGMeSmu8lgCv9MjT0w9osXsOOGrsQ/PHmigPRVWyagV2Ekqrd6Uw3aBuMraBcR02awlG\n 0xShJW4/f9mU3uhxK44r8JF0/xCOy+cu/Y3jkFwaJHgLBVEnWabwFosAOYaRK3hMG+bSz/vSC+N\n zgdjQ/XMg+jkA5o4Z+Hh2mD3Eokk2A9Kucr7H/eFwkP0gA53D4Kw1v7nmeovBgvrZAqIQsUti3m\n dJMpdS3FVW0doICsx0u+OhjA8a7d6PmLc2Swgx+zYvVdNRyNiuFW3l0nBsncQ41ayB9NTHLD1M4\n wzC4X1OQftcB88j8LD4BtNbS4dJ3LLnrjYxQz0NGDgysBW0GFWMyvd0Pq1JA/JQfCrhNNIt2HiK\n xMzV6j1XwjoHGi4pDPxd8BbL8oeaXTCFIzu6A1/XFNk9YYUfyQsV81m21PQ1R/MfldKJHuTgnjV\n yPqYz9OABWIwxB3T9Mg==","X-Proofpoint-GUID":"RADzpe4uVJwHV5Hu1T2jYSo2FjqfJxrz","X-Authority-Analysis":"v=2.4 cv=WpEb99fv c=1 sm=1 tr=0 ts=69dc7ed0 cx=c_pps\n a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17\n a=A5OVakUREuEA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22\n a=iQ6ETzBq9ecOQQE5vZCe:22 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8\n a=WVoxJWIhaqlnrWsZqHgA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=20KFwNOVAAAA:8\n a=TEv-KCbQBO2lq7Ilr10A:9 a=3ZE5zfFXTYcXvKQm:21 a=_W_S_7VecoQA:10\n a=lqcHg5cX4UMA:10","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-13_01,2026-04-09_02,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n priorityscore=1501 phishscore=0 bulkscore=0 adultscore=0 spamscore=0\n malwarescore=0 clxscore=1015 lowpriorityscore=0 suspectscore=0\n impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc=\n route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2604010000\n definitions=main-2604130048","X-Spam-Status":"No, score=0.1 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,\n DMARC_PASS,HTML_MESSAGE,SPF_HELO_NONE,SPF_PASS shortcircuit=no\n autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on in-2.smtp.seeweb.it","X-Virus-Scanned":"clamav-milter 1.0.9 at in-2.smtp.seeweb.it","X-Virus-Status":"Clean","X-Content-Filtered-By":"Mailman/MimeDel 2.1.29","Subject":"Re: [LTP] [PATCH] mmap: fix intermittent OOM kill of test parent in\n mmap22","X-BeenThere":"ltp@lists.linux.it","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"Linux Test Project <ltp.lists.linux.it>","List-Unsubscribe":"<https://lists.linux.it/options/ltp>,\n <mailto:ltp-request@lists.linux.it?subject=unsubscribe>","List-Archive":"<http://lists.linux.it/pipermail/ltp/>","List-Post":"<mailto:ltp@lists.linux.it>","List-Help":"<mailto:ltp-request@lists.linux.it?subject=help>","List-Subscribe":"<https://lists.linux.it/listinfo/ltp>,\n <mailto:ltp-request@lists.linux.it?subject=subscribe>","Cc":"ltp@lists.linux.it","Content-Transfer-Encoding":"base64","Content-Type":"text/plain; charset=\"utf-8\"; Format=\"flowed\"","Errors-To":"ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it","Sender":"\"ltp\" <ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it>"}}]