From patchwork Tue Mar 17 10:54:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 229218 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4750C18E5B for ; Tue, 17 Mar 2020 11:19:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9CC2E20658 for ; Tue, 17 Mar 2020 11:19:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584443985; bh=fnrkN7VzjhmTohozM6jmw+I9R7OtBze2rTNvN3MSHr4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=WRHhk0n2gkgwLxtXIkHgEo4roDOWcILFOwMsTDh0SfFGa2oDc2dVoa8S+gsxnebqW A+oVW39MukdAHWAqAXdvWhiMgyrEQ4fz9DLlFsgWINq2mOdMrIa5f9EuLCVgGtbjxI 6sxvWNLkv2bvUiD62GoJzflMbgHtVTqr2yyMTaS4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727361AbgCQLDT (ORCPT ); Tue, 17 Mar 2020 07:03:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:43298 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728086AbgCQLDS (ORCPT ); Tue, 17 Mar 2020 07:03:18 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 90538205ED; Tue, 17 Mar 2020 11:03:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584442998; bh=fnrkN7VzjhmTohozM6jmw+I9R7OtBze2rTNvN3MSHr4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hxyxJ3WF0GXNNnjuZt9jIAR3g272UasLGfCTBw9PR4U9kNnaq8QvqZJXJKAuf4fJr qvFfcnnWU4txm3BaRntVu7xrN2xn6UZIw8/64c3W3SypWlOOo6Tteh4/zEn9YwoFQP k+jhjLKyD9Gr0XpT9DRB0sNJ1aWUdiGm1rlgLlsI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Shakeel Butt , Eric Dumazet , "David S. Miller" Subject: [PATCH 5.4 034/123] net: memcg: late association of sock to memcg Date: Tue, 17 Mar 2020 11:54:21 +0100 Message-Id: <20200317103311.380796544@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200317103307.343627747@linuxfoundation.org> References: <20200317103307.343627747@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Shakeel Butt [ Upstream commit d752a4986532cb6305dfd5290a614cde8072769d ] If a TCP socket is allocated in IRQ context or cloned from unassociated (i.e. not associated to a memcg) in IRQ context then it will remain unassociated for its whole life. Almost half of the TCPs created on the system are created in IRQ context, so, memory used by such sockets will not be accounted by the memcg. This issue is more widespread in cgroup v1 where network memory accounting is opt-in but it can happen in cgroup v2 if the source socket for the cloning was created in root memcg. To fix the issue, just do the association of the sockets at the accept() time in the process context and then force charge the memory buffer already used and reserved by the socket. Signed-off-by: Shakeel Butt Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- mm/memcontrol.c | 14 -------------- net/core/sock.c | 5 ++++- net/ipv4/inet_connection_sock.c | 20 ++++++++++++++++++++ 3 files changed, 24 insertions(+), 15 deletions(-) --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -6792,20 +6792,6 @@ void mem_cgroup_sk_alloc(struct sock *sk if (!mem_cgroup_sockets_enabled) return; - /* - * Socket cloning can throw us here with sk_memcg already - * filled. It won't however, necessarily happen from - * process context. So the test for root memcg given - * the current task's memcg won't help us in this case. - * - * Respecting the original socket's memcg is a better - * decision in this case. - */ - if (sk->sk_memcg) { - css_get(&sk->sk_memcg->css); - return; - } - /* Do not associate the sock with unrelated interrupted task's memcg. */ if (in_interrupt()) return; --- a/net/core/sock.c +++ b/net/core/sock.c @@ -1832,7 +1832,10 @@ struct sock *sk_clone_lock(const struct atomic_set(&newsk->sk_zckey, 0); sock_reset_flag(newsk, SOCK_DONE); - mem_cgroup_sk_alloc(newsk); + + /* sk->sk_memcg will be populated at accept() time */ + newsk->sk_memcg = NULL; + cgroup_sk_alloc(&newsk->sk_cgrp_data); rcu_read_lock(); --- a/net/ipv4/inet_connection_sock.c +++ b/net/ipv4/inet_connection_sock.c @@ -482,6 +482,26 @@ struct sock *inet_csk_accept(struct sock } spin_unlock_bh(&queue->fastopenq.lock); } + + if (mem_cgroup_sockets_enabled) { + int amt; + + /* atomically get the memory usage, set and charge the + * sk->sk_memcg. + */ + lock_sock(newsk); + + /* The sk has not been accepted yet, no need to look at + * sk->sk_wmem_queued. + */ + amt = sk_mem_pages(newsk->sk_forward_alloc + + atomic_read(&sk->sk_rmem_alloc)); + mem_cgroup_sk_alloc(newsk); + if (newsk->sk_memcg && amt) + mem_cgroup_charge_skmem(newsk->sk_memcg, amt); + + release_sock(newsk); + } out: release_sock(sk); if (req)