On Thu, Jul 15, 2021 at 10:50 AM Matthew Wilcox [off-list ref] wrote:

On Thu, Jul 15, 2021 at 03:14:44AM -0400, Yutian Yang wrote:

quoted

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?

The memcgs are used for providing isolation between different
workloads running on the system and not just rough accounting
estimation. So, if there is an unbound allocation which can be
triggered by userspace than it should be accounted.

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.

We used to do opt-out kmem memcg accounting but switched to opt-in
with a9bb7e620efdf ("memcg: only account kmem allocations marked as
__GFP_ACCOUNT") with the reason that number of allocations which
should not be charged are larger than the allocations which should be
charged.

Personally I would prefer we go back to the opt-out accounting
specially after we have switched to reparenting the kmem charges and
shared kmem caches.