All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Yutian Yang <nglaive@gmail.com>
Cc: mhocko@kernel.org, hannes@cmpxchg.org, vdavydov.dev@gmail.com,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	shenwenbo@zju.edu.cn
Subject: Re: [PATCH] memcg: charge semaphores and sem_undo objects
Date: Thu, 15 Jul 2021 18:49:04 +0100	[thread overview]
Message-ID: <YPB1EPaunr5587h5@casper.infradead.org> (raw)
In-Reply-To: <1626333284-1404-1-git-send-email-nglaive@gmail.com>

On Thu, Jul 15, 2021 at 03:14:44AM -0400, Yutian Yang wrote:
> This patch adds accounting flags to semaphores and sem_undo allocation
> sites so that kernel could correctly charge these objects. 
> 
> A malicious user could take up more than 63GB unaccounted memory under 
> default sysctl settings by exploiting the unaccounted objects. She could 
> allocate up to 32,000 unaccounted semaphore sets with up to 32,000 
> unaccounted semaphore objects in each set. She could further allocate one 
> sem_undo unaccounted object for each semaphore set.

Do we really have to account every object that's allocated on behalf of
userspace?  ie how seriously do we take this kind of thing?  Are memcgs
supposed to be a hard limit, or are they just a rough accounting thing?

There could be a very large stream of patches turning GFP_KERNEL into
GFP_KERNEL_ACCOUNT.  For example, file locks (fs/locks.c) are only
allocated with GFP_KERNEL and you can allocate one lock per byte of a
file.  I'm sure there are hundreds more places where we do similar things.


WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Yutian Yang <nglaive-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org,
	vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	shenwenbo-Y5EWUtBUdg4nDS1+zs4M5A@public.gmane.org
Subject: Re: [PATCH] memcg: charge semaphores and sem_undo objects
Date: Thu, 15 Jul 2021 18:49:04 +0100	[thread overview]
Message-ID: <YPB1EPaunr5587h5@casper.infradead.org> (raw)
In-Reply-To: <1626333284-1404-1-git-send-email-nglaive-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Thu, Jul 15, 2021 at 03:14:44AM -0400, Yutian Yang wrote:
> This patch adds accounting flags to semaphores and sem_undo allocation
> sites so that kernel could correctly charge these objects. 
> 
> A malicious user could take up more than 63GB unaccounted memory under 
> default sysctl settings by exploiting the unaccounted objects. She could 
> allocate up to 32,000 unaccounted semaphore sets with up to 32,000 
> unaccounted semaphore objects in each set. She could further allocate one 
> sem_undo unaccounted object for each semaphore set.

Do we really have to account every object that's allocated on behalf of
userspace?  ie how seriously do we take this kind of thing?  Are memcgs
supposed to be a hard limit, or are they just a rough accounting thing?

There could be a very large stream of patches turning GFP_KERNEL into
GFP_KERNEL_ACCOUNT.  For example, file locks (fs/locks.c) are only
allocated with GFP_KERNEL and you can allocate one lock per byte of a
file.  I'm sure there are hundreds more places where we do similar things.

  parent reply	other threads:[~2021-07-15 17:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-15  7:14 [PATCH] memcg: charge semaphores and sem_undo objects Yutian Yang
2021-07-15  7:14 ` Yutian Yang
2021-07-15 17:05 ` Shakeel Butt
2021-07-15 17:05   ` Shakeel Butt
2021-07-16  3:57   ` Vasily Averin
2021-07-16  3:57     ` Vasily Averin
2021-07-15 17:49 ` Matthew Wilcox [this message]
2021-07-15 17:49   ` Matthew Wilcox
2021-07-15 18:22   ` Shakeel Butt
2021-07-15 18:22     ` Shakeel Butt

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=YPB1EPaunr5587h5@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=nglaive@gmail.com \
    --cc=shenwenbo@zju.edu.cn \
    --cc=vdavydov.dev@gmail.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.