Received: by 10.192.165.148 with SMTP id m20csp2856347imm; Sun, 22 Apr 2018 17:30:21 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/3j/dtbdd4LLRJ4QCWYj4ViaQr7k42KZ3S+Pp8WDDK4STSfF35+EdqpwIEslRhgYoclo2x X-Received: by 2002:a17:902:8342:: with SMTP id z2-v6mr18485264pln.311.1524443421222; Sun, 22 Apr 2018 17:30:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524443421; cv=none; d=google.com; s=arc-20160816; b=D0evCoJeCMNxzoxmuCEk+eihqQ/n7u5A7zrxG2RvxU26Wsl07e1kXHU4pyatHeZ0d6 vrOql5cJIpL7Yn/kMh8SMWvWsuovQI39+eCZ/Gb9zHpH7fwbnCjjPX7WqhaYCpPq2fEi n1H3J/X6o5OE7mUX/mhuB2ieF/GAsqd1gGYPGLEITmMAy3KvEVANjNyNlNcOZYD5Bfpa liZCBefSwfGxEFKz9S1VXUxDj/r1CBbIHneEA/FhKErN1X/1K1OK5mZyICaYAZVigkoZ wE1PZ5wUt9ReiuwyWvV/2vl6HIY/B2SS7iqgotuyIXST/U4ARcUi7dGK/hiZJ7d15Wjt 8tJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=LUnrg3nMxzknwmCj9dvyDuI2nrSEqzMg6b83pydjJyQ=; b=S+YcKWX4xTOMKjQdG+fgBL72rUkRNe0NA0NKUIbl21tTLDiuKEpnQ/iWyhh9LUmHnq iUS/aEsqA/Ue3Jh6UxNBRy+L+GnUfp9c275ON2tmVHp4N4LV4WeArviHeZWU33mDoarH Z2YKCmMu5m9E+NGwzMt2S+brTmzJeOiETGF5RCC9pX64LHWeIWE9V4KVXE4IEbMEUxux itqidD6mJg0PNPajl1x7nRxoyAFF7fav1zlf2kaiw/tVQBnVyruex9h3Nhsy4ZyOYJt4 K5DPFWN92vJLEJBf4kMqRFyRPcxzIgNiSCXis2GOKd3PqLvUJosjLRympkt+Ojv49rFV aQIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n11-v6si10206509pls.422.2018.04.22.17.29.54; Sun, 22 Apr 2018 17:30:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753824AbeDWA1p (ORCPT + 99 others); Sun, 22 Apr 2018 20:27:45 -0400 Received: from mx2.suse.de ([195.135.220.15]:45430 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753791AbeDWA1m (ORCPT ); Sun, 22 Apr 2018 20:27:42 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DA4D2AB32; Mon, 23 Apr 2018 00:27:40 +0000 (UTC) Date: Sun, 22 Apr 2018 18:27:38 -0600 From: Michal Hocko To: vcaputo@pengaru.com Cc: Pavel Machek , Ferry Toth , linux-kernel@vger.kernel.org Subject: Re: DOS by unprivileged user Message-ID: <20180423002738.GF16083@dhcp22.suse.cz> References: <9023506.UBh6vynRGa@delfion> <20180422101654.GA26243@amd> <20180422174300.srzhf3veqxfigqhg@shells.gnugeneration.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180422174300.srzhf3veqxfigqhg@shells.gnugeneration.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun 22-04-18 10:43:00, vcaputo@pengaru.com wrote: > On Sun, Apr 22, 2018 at 12:16:54PM +0200, Pavel Machek wrote: > > On Thu 2018-04-19 21:13:35, Ferry Toth wrote: > > > It appears any ordinary user can easily create a DOS on linux. > > > > > > One sure way to reproduce this is to open gitk on the linux kernel repo > > > (SIC) on a machine with 8GB RAM 16 GB swap on a HDD with btrfs and quad core > > > + hyperthreading. But I will be easy enough to get the same effect with more > > > RAM, other fs etc. > > > > You may want to disable swap. > > > > I run without swap on my laptops, and still observe long periods of > thrashing on the road towards OOM. What seems to occur is the active > file-backed mappings of executables/libraries become a sort of swap > area, repeatedly being discarded and faulted back in as the context > switches occur. > > If there's any good way to prevent this, I'd like to know. I am afraid there is none yet. Johannes had some ground work for page cache trashing detection https://marc.info/?i=20170727153010.23347-1-hannes%40cmpxchg.org but there was no version of the patchseries for quite some time and there was no integration into the oom detection which would be non-trivial as well. I realize this sucks. But the reality is that this is far from trivial to resolve without introducing pre-mature OOM killer invocations. -- Michal Hocko SUSE Labs