From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Phillips <daniel@phunq.net>
Subject: Re: [FYI] tux3: Core changes
Date: Tue, 26 May 2015 12:18:48 -0700
Message-ID: <5564C718.6050909@phunq.net>
References: <555D0FDF.3070303@phunq.net> <555D500B.4080901@phunq.net>
 <alpine.DEB.2.02.1505202050530.25699@nftneq.ynat.uz>
 <13c8bcdf-70e8-43d5-a05f-58ad839dbfd0@phunq.net>
 <5563F5C8.2040806@redhat.com>
 <dd591950-58c6-4268-9683-bd4c46cef292@phunq.net>
 <alpine.DEB.2.02.1505252303120.3147@nftneq.ynat.uz>
 <67294911-1776-46b8-916d-0e5642a38725@phunq.net>
 <20150526070910.GA3307@quack.suse.cz>
 <a2233e75-a0bc-4732-9d6f-ad4d7cde0bae@phunq.net>
 <20150526102239.GA466@swordfish>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: David Lang <david@lang.hm>, Rik van Riel <riel@redhat.com>,
 Jan Kara <jack@suse.cz>, tux3@tux3.org, linux-kernel@vger.kernel.org,
 linux-fsdevel@vger.kernel.org, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Return-path: <tux3-bounces@phunq.net>
In-Reply-To: <20150526102239.GA466@swordfish>
List-Unsubscribe: <http://phunq.net/mailman/options/tux3>,
 <mailto:tux3-request@phunq.net?subject=unsubscribe>
List-Archive: <http://phunq.net/pipermail/tux3/>
List-Post: <mailto:tux3@phunq.net>
List-Help: <mailto:tux3-request@phunq.net?subject=help>
List-Subscribe: <http://phunq.net/mailman/listinfo/tux3>,
 <mailto:tux3-request@phunq.net?subject=subscribe>
Errors-To: tux3-bounces@phunq.net
Sender: "Tux3" <tux3-bounces@phunq.net>
List-Id: linux-fsdevel.vger.kernel.org

Hi Sergey,

On 05/26/2015 03:22 AM, Sergey Senozhatsky wrote:
> 
> Hello,
> 
> is it possible to page-fork-bomb the system by some 'malicious' app?

Not in any new way. A page fork can happen either in the front end,
where it has to wait for memory like any other normal memory user,
or in the backend, where Tux3 may have privileged access to low
memory reserves and therefore must place bounds on its memory use
like any other user of low memory reserves.

This is not specific to page fork. We must place such bounds for
any memory that the backend uses. Fortunately, the backend does not
allocate memory extravagently, for fork or anything else, so when
this does get to the top of our to-do list it should not be too
hard to deal with. We plan to attack that after merge, as we have
never observed a problem in practice. Rather, Tux3 already seems
to survive low memory situations pretty well compared to some other
filesystems.


Regards,

Daniel