linux-kernel - Re: Re: [BUG] ramfs system panic when using dd to create files

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7074179d.c3fd.17aa3f148cc.Coremail.wuzhouhui14@mails.ucas.ac.cn>
Date:   Wed, 14 Jul 2021 15:35:36 +0800 (GMT+08:00)
From:   wuzhouhui <wuzhouhui14@...ls.ucas.ac.cn>
To:     "yong w" <yongw.pur@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        akpm@...ux-foundation.org, nico@...xnic.net, wang.yong12@....com.cn
Subject: Re: Re: [BUG] ramfs system panic when using dd to create files

&gt; -----Original Messages-----
&gt; From: "yong w" <yongw.pur@...il.com>
&gt; Sent Time: 2021-07-14 08:24:23 (Wednesday)
&gt; To: linux-kernel@...r.kernel.org, linux-mm@...ck.org, akpm@...ux-foundation.org, nico@...xnic.net, wang.yong12@....com.cn
&gt; Cc: 
&gt; Subject: Re: [BUG] ramfs system panic when using dd to create files
&gt; 
&gt; Hello, is there any solution, or how to avoid this problem when using ramfs?

Limit max size of ramfs.

&gt; 
&gt; yong w <yongw.pur@...il.com> 于2021年7月7日周三 下午5:58写道：
&gt; &gt;
&gt; &gt; When I  use dd to create files multiple times under the ramfs file
&gt; &gt; system，Panic appears, indicating that there is no process to kill.
&gt; &gt; I learn that ramfs will automatically grow space due to data writing,
&gt; &gt; causing all the system memory to run out,  but i think it shouldn't
&gt; &gt; cause the system to panic.

The comments already explains why kernel should panic on this situation:
            /*
             * If we got here due to an actual allocation at the
             * system level, we cannot survive this and will enter
             * an endless loop in the allocator. Bail out now.
             */
</yongw.pur@...il.com></yongw.pur@...il.com>