From: Andrew Morton <akpm@linux-foundation.org>
To: Minchan Kim <minchan@kernel.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org
Subject: Re: [Bug 215323] New: Frequently swapping, userspace program will abnormally exit.
Date: Mon, 13 Dec 2021 08:51:00 -0800 [thread overview]
Message-ID: <20211213085100.61b8bb179871b5f42704a8e6@linux-foundation.org> (raw)
In-Reply-To: <bug-215323-27@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 13 Dec 2021 16:38:44 +0000 bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=215323
Thanks.
>
> Bug ID: 215323
> Summary: Frequently swapping, userspace program will abnormally
> exit.
Looks like a zram data corruption.
> Product: Memory Management
> Version: 2.5
> Kernel Version: Linux 5.15.6
> Hardware: Intel
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> Assignee: akpm@linux-foundation.org
> Reporter: dengchangcheng2021@163.com
> Regression: No
Are you sure "No"? Did previous kernels do this, or only 5.15?
> kernel: 5.15.6 version kernel
> config: using x86_64_defconfig plus docker and zram configurations
>
> # free -m
> total used free shared buff/cache available
> Mem: 3868 3560 37 3 270 42
> Swap: 3868 1819 2049
>
> Userspace program(for example dockerd) had a big chance to exit abnormally when
> frequently swapping with zram in about an hour. We found that a page on the
> stack of the program is cleaned to zero. In order to find out who cleans stack,
> we add a monitor to catch whether a page is modifed by swap. And we found out a
> page is indeed modifed after swap out/in.
>
> To reproduce, do the following.
> At first, set the value of /proc/sys/vm/swappiness to 100.
> Then use programs that include mmap or malloc to consume memory, so that to
> trigger swap frequently occurs.
> Finally, use docker to load images in multiple ways.
> After running for a while, dockerd will exit. At the same time dockerd will
> record the following:
> runtime: unexpected return pc for 2021-12-09T03:32:30.290948+00:00 (none)
> dockerd[350]: time="2021-12-09T03:32:30.290846695Z" level=info msg="Applied
> tar sha256:d69d9fecbe66f52f6ba42cf251286a8912d80c20938e25620654a87e5760ccae
> to cca4b9df0747f37898e41bd2059d1a38fdf57c24b31bd00e248e2ba6cd03d63d, size:
> 10565287"
> runtime.gopark called from 0x0
> stack: frame={sp:0xc4202c1dd8, fp:0xc4202c1df8}
> stack=[0xc4202c1800,0xc4202c2000)
> 000000c4202c1cd8: 0000000000000000 0000000000000000
> 000000c4202c1ce8: 0000000000000000 0000000000000000
> 000000c4202c1cf8: 0000000000000000 0000000000000000
> 000000c4202c1d08: 0000000000000000 0000000000000000
> 000000c4202c1d18: 0000000000000000 0000000000000000
> 000000c4202c1d28: 0000000000000000 0000000000000000
> 000000c4202c1d38: 0000000000000000 0000000000000000
> 000000c4202c1d48: 0000000000000000 0000000000000000
> 000000c4202c1d58: 0000000000000000 0000000000000000
> 000000c4202c1d68: 0000000000000000 0000000000000000
> 000000c4202c1d78: 0000000000000000 0000000000000000
> 000000c4202c1d88: 0000000000000000 0000000000000000
> 000000c4202c1d98: 0000000000000000 0000000000000000
> 000000c4202c1da8: 0000000000000000 0000000000000000
> 000000c4202c1db8: 0000000000000000 0000000000000000
> 000000c4202c1dc8: 0000000000000000 0000000000000000
> 000000c4202c1dd8: <0000000000000000 0000000000000000
> 000000c4202c1de8: 0000000000000000 !0000000000000000
> 000000c4202c1df8: >0000000000000000 0000000000000000
> 000000c4202c1e08: 0000000000000000 0000000000000000
> 000000c4202c1e18: 0000000000000000 0000000000000000
> 000000c4202c1e28: 0000000000000000 0000000000000000
> 000000c4202c1e38: 0000000000000000 0000000000000000
> 000000c4202c1e48: 0000000000000000 0000000000000000
> 000000c4202c1e58: 0000000000000000 0000000000000000
> 000000c4202c1e68: 0000000000000000 0000000000000000
> 000000c4202c1e78: 0000000000000000 0000000000000000
> 000000c4202c1e88: 0000000000000000 0000000000000000
> 000000c4202c1e98: 0000000000000000 0000000000000000
> 000000c4202c1ea8: 0000000000000000 0000000000000000
> 000000c4202c1eb8: 0000000000000000 0000000000000000
> 000000c4202c1ec8: 0000000000000000 0000000000000000
> 000000c4202c1ed8: 0000000000000000 0000000000000000
> 000000c4202c1ee8: 0000000000000000 0000000000000000
> fatal error: unknown caller pc
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You are the assignee for the bug.
parent reply other threads:[~2021-12-13 16:51 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <bug-215323-27@https.bugzilla.kernel.org/>]
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=20211213085100.61b8bb179871b5f42704a8e6@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=senozhatsky@chromium.org \
/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