From mboxrd@z Thu Jan 1 00:00:00 1970 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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 DBA2EC47409 for ; Fri, 14 Feb 2020 22:48:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7B4F92081E for ; Fri, 14 Feb 2020 22:48:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MhgOWYPo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B4F92081E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 00C056B06B7; Fri, 14 Feb 2020 17:48:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EFF196B06B9; Fri, 14 Feb 2020 17:48:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E16BD6B06BA; Fri, 14 Feb 2020 17:48:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0173.hostedemail.com [216.40.44.173]) by kanga.kvack.org (Postfix) with ESMTP id C67F96B06B7 for ; Fri, 14 Feb 2020 17:48:58 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4F5772470 for ; Fri, 14 Feb 2020 22:48:58 +0000 (UTC) X-FDA: 76490224356.08.wrist12_4e4a770536023 X-HE-Tag: wrist12_4e4a770536023 X-Filterd-Recvd-Size: 4504 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Fri, 14 Feb 2020 22:48:57 +0000 (UTC) Received: by mail-oi1-f194.google.com with SMTP id z2so10987959oih.6 for ; Fri, 14 Feb 2020 14:48:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TgoIP7Jshrn2duDl/cLkfq4CVlTeMc4BWp5pc4aKy4o=; b=MhgOWYPob9S6aZV6qa2b7vLLaVDvt275tODnygTV/CKd8wZi8f724KWNlUCRxs5mjH DCM690tw83yBr2LORN0E+j9ll5bD4HHOlWoWsl86QrhEuZIsmxOjBealBDm00d5vtezR vUaYfoe/EyPW0Yufblun637lPw3LqF5RI0rMvLWN47ZAf9ujyHXOjVyP4Qfo2c271JS9 7rUY48zxABcoVUIkQPtg+0T4o5KmUJuvDUzJxKTBOgxeCBg2ZxJDuziggGbCQ9scH07Z 1lMwyvU0Aa05SCjGeSZN7Mw6D5wbI4rvxo452JwFeUFIe8Ry6FtSz9LrvBReh5+rLGI4 jBsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TgoIP7Jshrn2duDl/cLkfq4CVlTeMc4BWp5pc4aKy4o=; b=g3RalEHZwzCU8QuCAg4q9FnoVyQ+qGmFXMg/wf7X4eqLSxFfOVLvpWb68JlcCPp0BV 4JK3F0Xt6EGlzsx6wtV1M/m3VdMu5Wmc0oSypzr931b75ZW1QR2bBsKyktAy6IB5iZM6 shLxsUfSV7gZCR2x/6SkTM0+Ki9jTfryUweu8ocljIbLoN04uaTTD+NJIK0pViYWepvk sHeu0ghujPtHeSIuR79FOhJgXY1YgYq65wxjWHQX9QQY0Ma4tkAq+5eF2LIPhtGSrN+Q UZu1WGRoAz+Z65ZuPpy+Xljptk46dduphe0WGW0aRTujy/y+siq9SNWNFavHBCN7RZ66 nFiw== X-Gm-Message-State: APjAAAVCSdnUbU9qxJn557T8NKZOqdtLmrp9RrgsN/hMoE57AUNN6dWD eGoBERGgGDDTaSNqKB3KJQmNXQzjHxDEHdCyR4sAYQ== X-Google-Smtp-Source: APXvYqxFBb2HQnzGcPUG6cOYpfmJqP7PlimlMr1+iPFrbiJ4dnvduE/oWnmZgKQGPbeT3ha1e9ByvWDejgMmMZKdE+Y= X-Received: by 2002:aca:6542:: with SMTP id j2mr3470435oiw.69.1581720536963; Fri, 14 Feb 2020 14:48:56 -0800 (PST) MIME-Version: 1.0 References: <20200214222415.181467-1-shakeelb@google.com> In-Reply-To: From: Shakeel Butt Date: Fri, 14 Feb 2020 14:48:46 -0800 Message-ID: Subject: Re: [PATCH v2] cgroup: memcg: net: do not associate sock with unrelated cgroup To: Eric Dumazet Cc: Johannes Weiner , Tejun Heo , Greg Thelen , Michal Hocko , Vladimir Davydov , Andrew Morton , Cgroups , linux-mm , Roman Gushchin , LKML Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 14, 2020 at 2:38 PM Eric Dumazet wrote: > > On Fri, Feb 14, 2020 at 2:24 PM Shakeel Butt wrote: > > > > We are testing network memory accounting in our setup and noticed > > inconsistent network memory usage and often unrelated cgroups network > > usage correlates with testing workload. On further inspection, it > > seems like mem_cgroup_sk_alloc() and cgroup_sk_alloc() are broken in > > irq context specially for cgroup v1. > > > > mem_cgroup_sk_alloc() and cgroup_sk_alloc() can be called in irq context > > and kind of assumes that this can only happen from sk_clone_lock() > > and the source sock object has already associated cgroup. However in > > cgroup v1, where network memory accounting is opt-in, the source sock > > can be unassociated with any cgroup and the new cloned sock can get > > associated with unrelated interrupted cgroup. > > > > Cgroup v2 can also suffer if the source sock object was created by > > process in the root cgroup or if sk_alloc() is called in irq context. > > The fix is to just do nothing in interrupt. > > So, when will the association be done ? > At accept() time ? > Is it done already ? > I think in the current code if the association is skipped at allocation time then the sock will remain unassociated for its lifetime. Maybe we can add the association in the later stages but it seems like it is not a simple task i.e. edbe69ef2c90f ("Revert "defer call to mem_cgroup_sk_alloc()""). Shakeel