Received: by 10.223.176.5 with SMTP id f5csp698741wra; Fri, 9 Feb 2018 05:54:09 -0800 (PST) X-Google-Smtp-Source: AH8x225/Sgw1XeuIcAsBm07hH67b+i9WlWDTh0SvWKxj07sLHzBRGGWNtdhC0ChjyefCPB/Ppa5k X-Received: by 10.99.120.203 with SMTP id t194mr2438089pgc.39.1518184449361; Fri, 09 Feb 2018 05:54:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518184449; cv=none; d=google.com; s=arc-20160816; b=nF4496W5OHZ5Evan8nsV/Q0QRZQBB08ehm6FOPDfMWml4mZXoldOTNP2LZXQIonm+5 w55ygloL+oD2e3szZme9a9NwKhJpODHkJ0E/mU5LrnGfyAbXwlUDlfg7KBnPZgmW6/XT tqgGsEiF6g4KJLEeJak7UtsFfjRornUDJDRP7i5CH2IYjQLWIZ8NaR3pjWnWGxWUePJs GcWG+mkN2zAVFgQEeUDBWmPBOYVkXzB3A1nmT2akpKuAH2h3Pg5q70E6NL/JvcjszAAW l0G2xk6sOcPPCVojHzdLIsHndvb1OXmZQTnQ9lBHpwskycTtqpoEwZDYjQUTPrmHdvfB Fw2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=L21fMNiuIjyoIGxqd0IYrR9gnPVPlFTgV1AqkzxKw9o=; b=Ex5jLDoUX/yAVLD3eO765ThmcsRniRrU4V7WhvfvH6a4wPEpB4k61aiEr9+ZbB0kXJ 5Vpun029CQaccoftW0EHCVk0A0dhqzVBJZMYbnf4ZQ7TdQU5zhVfaBbkwuKa0cOmG5B4 nmFGhTigXCQWoSdc4Su0m02qfNCNmzIsquVNwB9viMxM8lYKv49lE9ksSXLDvmkT3qXG 0mS9qR23ifwQjhe1prNfOMzIEGq0OUTDnBwXQcgjK27Yy9pnsKBWzEyBtsnhccSRf62X dXZ7+kwqdzcFmW9WL99p/fSafQ6IJLw7GT4d3LcCxVRVb2OzlOW4QT772hbxEIjWKHbG QsoQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h18si1648907pfi.167.2018.02.09.05.53.55; Fri, 09 Feb 2018 05:54:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753763AbeBINqO (ORCPT + 99 others); Fri, 9 Feb 2018 08:46:14 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:52572 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753360AbeBINqL (ORCPT ); Fri, 9 Feb 2018 08:46:11 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id CE7DA1130; Fri, 9 Feb 2018 13:46:10 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Roman Gushchin , Eric Dumazet , "David S. Miller" , Johannes Weiner , Tejun Heo Subject: [PATCH 4.15 10/23] Revert "defer call to mem_cgroup_sk_alloc()" Date: Fri, 9 Feb 2018 14:40:08 +0100 Message-Id: <20180209133938.897550194@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180209133938.366024920@linuxfoundation.org> References: <20180209133938.366024920@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Roman Gushchin [ Upstream commit edbe69ef2c90fc86998a74b08319a01c508bd497 ] This patch effectively reverts commit 9f1c2674b328 ("net: memcontrol: defer call to mem_cgroup_sk_alloc()"). Moving mem_cgroup_sk_alloc() to the inet_csk_accept() completely breaks memcg socket memory accounting, as packets received before memcg pointer initialization are not accounted and are causing refcounting underflow on socket release. Actually the free-after-use problem was fixed by commit c0576e397508 ("net: call cgroup_sk_alloc() earlier in sk_clone_lock()") for the cgroup pointer. So, let's revert it and call mem_cgroup_sk_alloc() just before cgroup_sk_alloc(). This is safe, as we hold a reference to the socket we're cloning, and it holds a reference to the memcg. Also, let's drop BUG_ON(mem_cgroup_is_root()) check from mem_cgroup_sk_alloc(). I see no reasons why bumping the root memcg counter is a good reason to panic, and there are no realistic ways to hit it. Signed-off-by: Roman Gushchin Cc: Eric Dumazet Cc: David S. Miller Cc: Johannes Weiner Cc: Tejun Heo 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 | 1 - 3 files changed, 15 insertions(+), 5 deletions(-) --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5828,6 +5828,20 @@ 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; + } + rcu_read_lock(); memcg = mem_cgroup_from_task(current); if (memcg == root_mem_cgroup) --- a/net/core/sock.c +++ b/net/core/sock.c @@ -1675,16 +1675,13 @@ struct sock *sk_clone_lock(const struct newsk->sk_dst_pending_confirm = 0; newsk->sk_wmem_queued = 0; newsk->sk_forward_alloc = 0; - - /* sk->sk_memcg will be populated at accept() time */ - newsk->sk_memcg = NULL; - atomic_set(&newsk->sk_drops, 0); newsk->sk_send_head = NULL; newsk->sk_userlocks = sk->sk_userlocks & ~SOCK_BINDPORT_LOCK; atomic_set(&newsk->sk_zckey, 0); sock_reset_flag(newsk, SOCK_DONE); + mem_cgroup_sk_alloc(newsk); cgroup_sk_alloc(&newsk->sk_cgrp_data); rcu_read_lock(); --- a/net/ipv4/inet_connection_sock.c +++ b/net/ipv4/inet_connection_sock.c @@ -475,7 +475,6 @@ struct sock *inet_csk_accept(struct sock } spin_unlock_bh(&queue->fastopenq.lock); } - mem_cgroup_sk_alloc(newsk); out: release_sock(sk); if (req)