Linux Test Project
 help / color / mirror / Atom feed
From: Wei Gao via ltp <ltp@lists.linux.it>
To: jstancek@redhat.com
Cc: ltp@lists.linux.it
Subject: [LTP] hugemmap34 trigger oom if compile with CFLAGS='-fstack-clash-protection'
Date: Tue, 4 Feb 2025 21:54:41 -0500	[thread overview]
Message-ID: <Z6LS8SfWeWnd5A3C@wegao> (raw)

Hi Jan

Compiling hugemmap34 with CFLAGS='-fstack-clash-protection' causes gcc to insert additional stack address validation checks during alloca calls.  This results in kernel start allocate memory really , eventually triggering an OOM.

In our normal openqa env we do not have such big memory(1024GB) to support this test. So we
 have to disable CFLAGS='-fstack-clash-protection' if we still need this case running in our env.

===log with CFLAGS='-fstack-clash-protection'===
[71073.562094] [T13546] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-1,global_oom,task_memcg=/,task=hugemmap34,pid=13542,uid=0
[71073.562109] [T13546] Out of memory: Killed process 13542 (hugemmap34) total-vm:4764864kB, anon-rss:2816000kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:636kB oom_score_adj:0

tst_hugepage.c:84: TINFO: 1 hugepage(s) reserved
tst_tmpdir.c:317: TINFO: Using /tmp/LTP_hug2vxfh1 as tmpdir (btrfs filesystem)
tst_test.c:1097: TINFO: Mounting none to /tmp/LTP_hug2vxfh1/hugetlbfs fstyp=hugetlbfs flags=0
tst_test.c:1900: TINFO: LTP version: 20240930
tst_test.c:1904: TINFO: Tested kernel: 6.4.0-150700.40-default #1 SMP Thu Jan 9 12:43:31 UTC 2025 (f78fd5e) ppc64le
tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
tst_kconfig.c:669: TINFO: CONFIG_LATENCYTOP kernel option detected which might slow the execution
tst_test.c:1724: TINFO: Overall timeout per run is 0h 02m 00s
hugemmap34.c:152: TINFO: searching for huge page and child stack placement
hugemmap34.c:175: TINFO: potential stack at address 0x7effff000000
hugemmap34.c:192: TINFO: stack = 0x7effff000000-0x7f0000000000, hugepage = 0x7dffff000000-0x7e0000000000
tst_coredump.c:32: TINFO: Avoid dumping corefile for process(pid=20714)
hugemmap34.c:56: TINFO: Child process starting with top of stack at 0x7effffffff80

tst_test.c:1785: TINFO: Killed the leftover descendant processes
tst_test.c:1792: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1
tst_test.c:1793: TBROK: Test killed! (timeout?)


===log without CFLAGS='-fstack-clash-protection'===
tst_hugepage.c:84: TINFO: 1 hugepage(s) reserved
tst_tmpdir.c:317: TINFO: Using /tmp/LTP_hugjztvoX as tmpdir (btrfs filesystem)
tst_test.c:1097: TINFO: Mounting none to /tmp/LTP_hugjztvoX/hugetlbfs fstyp=hugetlbfs flags=0
tst_test.c:1900: TINFO: LTP version: 20240930
tst_test.c:1904: TINFO: Tested kernel: 6.4.0-150700.40-default #1 SMP Thu Jan 9 12:43:31 UTC 2025 (f78fd5e) ppc64le
tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
tst_kconfig.c:669: TINFO: CONFIG_LATENCYTOP kernel option detected which might slow the execution
tst_test.c:1724: TINFO: Overall timeout per run is 0h 02m 00s
hugemmap34.c:152: TINFO: searching for huge page and child stack placement
hugemmap34.c:175: TINFO: potential stack at address 0x7effff000000
hugemmap34.c:192: TINFO: stack = 0x7effff000000-0x7f0000000000, hugepage = 0x7dffff000000-0x7e0000000000
tst_coredump.c:32: TINFO: Avoid dumping corefile for process(pid=20704)
hugemmap34.c:56: TINFO: Child process starting with top of stack at 0x7effffffff80
hugemmap34.c:77: TINFO: Child process extended stack up to 0x7dfffffeff80, hasn't reached 0x7dffeffeff80
hugemmap34.c:79: TPASS: Child killed by SIGSEGV as expected

Thanks.
Regards
Gao Wei

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

             reply	other threads:[~2025-02-05  2:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05  2:54 Wei Gao via ltp [this message]
2025-02-05 10:33 ` [LTP] hugemmap34 trigger oom if compile with CFLAGS='-fstack-clash-protection' Jan Stancek
2025-02-06  2:28   ` Wei Gao via ltp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z6LS8SfWeWnd5A3C@wegao \
    --to=ltp@lists.linux.it \
    --cc=jstancek@redhat.com \
    --cc=wegao@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox