Re: [Bug 215323] New: Frequently swapping, userspace program will abnormally exit.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx
>           Reporter: dengchangcheng2021@xxxxxxx
>         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.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux