LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: Ferry Toth <ftoth@telfort.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: DOS by unprivileged user
Date: Mon, 23 Apr 2018 10:04:36 +0200	[thread overview]
Message-ID: <1524470676.5451.1.camel@gmx.de> (raw)
In-Reply-To: <6057755.ozdVOybsI6@delfion>

On Sun, 2018-04-22 at 21:37 +0200, Ferry Toth wrote:
> > Yes your memory hog scenario thoroughly wrecks the user experience, but
> > the process scheduler in not the source of that wreckage, it's a memory
> > management issue.  With no constraints in place, anybody can just keep
> > on allocating until the entire system starts grinding itself to dust.
> > 
> > 	-Mike
>  
> That is exactly the issue I think. It is not just a user experience,
> they is no distinction between crashing the kernel and grinding it to
> dust. The effect we have is: any user on a multi user system can
> crash the system.
>  
> Memory management / constraints can't solve the problem either: it
> might be intentional to alloc such amounts of memory.

Constraints definitely can solve this particular problem instance. 
Plain old ulimit can stop the memory hog (wish) dead in its tracks, or
you can use memory cgroup controller to constrain it in a more friendly
manner.  I started gitk in a 4G constrained cgroup, which redirected
its greedy fingers to the swap bin for the remainder of its needs.

But yes, there is currently no wonderful one size fits all fully
automatic solution to running low on memory that doesn't involve
running to the store.

> I think memory allocation and io waits can't be decoupled from
> scheduling as they are now.

The scheduler is not decoupled from either, it is intimately involved
in both.  However, none of the decision making smarts for either reside
in the scheduler, nor should they.

	-Mike

  parent reply	other threads:[~2018-04-23  8:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19 19:13 Ferry Toth
2018-04-20  4:46 ` Mike Galbraith
2018-04-20  8:39   ` Ferry Toth
2018-04-20 12:37     ` Mike Galbraith
2018-04-22 10:16 ` Pavel Machek
2018-04-22 17:43   ` vcaputo
2018-04-23  0:27     ` Michal Hocko
2018-04-23  7:13       ` Pavel Machek
     [not found] ` <4285098.DEWjdbWF2X@delfion>
     [not found]   ` <1524325275.8078.2.camel@gmx.de>
     [not found]     ` <6057755.ozdVOybsI6@delfion>
2018-04-23  8:04       ` Mike Galbraith [this message]
2018-04-25 14:54         ` Alan Cox
2018-04-25 16:21           ` Mike Galbraith
2018-04-25 16:50           ` Mike Galbraith
2018-04-30 10:00           ` Ferry Toth
2018-04-30 10:35             ` Miguel Ojeda

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=1524470676.5451.1.camel@gmx.de \
    --to=efault@gmx.de \
    --cc=ftoth@telfort.nl \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: DOS by unprivileged user' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).