Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2368393pxb; Mon, 20 Sep 2021 20:21:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxysMLwUVIakQz7hSxM4HHlbE/SjhePNnB4BvH2T20ptX79QZ/1eN8kqLT8GRjvPilK5eBl X-Received: by 2002:a02:7818:: with SMTP id p24mr22031243jac.72.1632194473390; Mon, 20 Sep 2021 20:21:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632194473; cv=none; d=google.com; s=arc-20160816; b=x8bIMI1/GRjzgRaFAaTNu4IBt7X1/lxyQVJdSi8vfdC+jTQa+RVZ8SJ5OeWWqS+JTb P7AmZ7ZOayE+CL8jyXxnfXWTD1k+3Zw03sTnfwXsAgZUijxQYDsgw7AQ7gXTPykmDU32 bIM0jJVk4oQ8RAMqjjkjel5M0fSWNgL6uIU+zt/PqNCvhXrbRmNwb0IpSxnbMRcT1awT LPsCuKia0V+b8hv+m4RRHgD5kraxJwzOr8EEXA8fC7uHb6jBWl+N9VAB7Lj2/fyH8DcV qp/2R/mfzfsQC9A7V5bsaGnjpKPcsag2/0/9Um0733N8jWrDi3DFkM/KzP7D4FBZgx9D BqnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=LCKx0c7XHl6FJpkD3+v8n56i4iT5mqMC4cXmR+9wFtY=; b=vwcH5J8Q1+ALFD+AyqK9PUpZJlIsqAcDZvp44EivJHd2vMHhwdJ88VrMk/wPAMFupD kd3FLY0B4QmCDXdBfutVqZ0pD1B8ChxeLY5LO8vaDoS7iMYSUzuD55R+8tiESpe0cvSN jXTX9gumpawv4Ifz0vpsJptEKhQOlinG8gfZvEjCVhKI0lHbLfOWFb9xl+qLzjis/uNQ w+HWTMDRpcxF6N1YXMeC1wfC4josVbsUkbVuW1dKqelWK2n/rQu3WY7kFxzIO12HretM dVQdZ1JkJBlAsdn7VtgBjNj/LAOu9ZhQ9ki2y/txyV/Ae0OlAH0XDOt5xE//P1Wl4pHp OKhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AmZYnor3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d7si14793408ila.10.2021.09.20.20.21.01; Mon, 20 Sep 2021 20:21:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AmZYnor3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376853AbhITSWr (ORCPT + 99 others); Mon, 20 Sep 2021 14:22:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:36231 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376852AbhITSOu (ORCPT ); Mon, 20 Sep 2021 14:14:50 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C1FB960EE4; Mon, 20 Sep 2021 17:21:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632158499; bh=v20QQcURcpcNS3G1sFZ/ZLQ59gjDrOIr9tYfVPep7To=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AmZYnor3rouoBKcwyj4Q9HIODcj3lahtER24pIvLelDG3RHaNsyzZiHWQbnJs5Zhv N5DtGcNdHEOKsTuDyYvqdHg1V2bij5YQbKvPDGs67b+aXUUNJbgGhpPFQCKtdjsXsa oBl0if1FfFCY6ieHjwlgxTZCSradkUn0QC0rVuJw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vasily Averin , =?UTF-8?q?Michal=20Koutn=C3=BD?= , Shakeel Butt , Christian Brauner , Roman Gushchin , Michal Hocko , Johannes Weiner , Andrew Morton , Linus Torvalds Subject: [PATCH 5.4 183/260] memcg: enable accounting for pids in nested pid namespaces Date: Mon, 20 Sep 2021 18:43:21 +0200 Message-Id: <20210920163937.334911953@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210920163931.123590023@linuxfoundation.org> References: <20210920163931.123590023@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vasily Averin commit fab827dbee8c2e06ca4ba000fa6c48bcf9054aba upstream. Commit 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") enabled memcg accounting for pids allocated from init_pid_ns.pid_cachep, but forgot to adjust the setting for nested pid namespaces. As a result, pid memory is not accounted exactly where it is really needed, inside memcg-limited containers with their own pid namespaces. Pid was one the first kernel objects enabled for memcg accounting. init_pid_ns.pid_cachep marked by SLAB_ACCOUNT and we can expect that any new pids in the system are memcg-accounted. Though recently I've noticed that it is wrong. nested pid namespaces creates own slab caches for pid objects, nested pids have increased size because contain id both for all parent and for own pid namespaces. The problem is that these slab caches are _NOT_ marked by SLAB_ACCOUNT, as a result any pids allocated in nested pid namespaces are not memcg-accounted. Pid struct in nested pid namespace consumes up to 500 bytes memory, 100000 such objects gives us up to ~50Mb unaccounted memory, this allow container to exceed assigned memcg limits. Link: https://lkml.kernel.org/r/8b6de616-fd1a-02c6-cbdb-976ecdcfa604@virtuozzo.com Fixes: 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") Cc: stable@vger.kernel.org Signed-off-by: Vasily Averin Reviewed-by: Michal Koutný Reviewed-by: Shakeel Butt Acked-by: Christian Brauner Acked-by: Roman Gushchin Cc: Michal Hocko Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- kernel/pid_namespace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/kernel/pid_namespace.c +++ b/kernel/pid_namespace.c @@ -53,7 +53,8 @@ static struct kmem_cache *create_pid_cac mutex_lock(&pid_caches_mutex); /* Name collision forces to do allocation under mutex. */ if (!*pkc) - *pkc = kmem_cache_create(name, len, 0, SLAB_HWCACHE_ALIGN, 0); + *pkc = kmem_cache_create(name, len, 0, + SLAB_HWCACHE_ALIGN | SLAB_ACCOUNT, 0); mutex_unlock(&pid_caches_mutex); /* current can fail, but someone else can succeed. */ return READ_ONCE(*pkc);