Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp4832932pxv; Tue, 20 Jul 2021 12:29:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwQlvlxAVyCvVUBw2pxUTI1Lbxlzq4Fk2FAsME9+/17/QW5Jt6CqGQSm2G3BUYSMB0TwF1/ X-Received: by 2002:a17:906:22d0:: with SMTP id q16mr34953135eja.248.1626809390018; Tue, 20 Jul 2021 12:29:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626809390; cv=none; d=google.com; s=arc-20160816; b=GH4xd/gqz5cqAWB+Exqnu2n8DWy7qGPJ/Rze30rTiBZzBvfbjvZCkypRQgBTvq3Yk+ uv0Vep4yXXr79d8tQzgIdn178AnG49LADX/dIyin11aOpgxCkx6rEgOUAuGDn2sjUeRW Bk+D+H2WzKQTdIGrLQ0pr0OnuxLGF39EuNP+PPl3+gG7/w8qz17H4ErFGjdunXBCPEwm X6tZjuDPDjUF0Kvgu9cjo+PfjnID3LNHp81XRiae0FsfPSHnA/Vx5ehpeiuDLD+pdvks LF+1cZNUCbALaPVPt8bB4C3GIu2kf73HPUZJ2h8AF2E2vsPzO69yfvuV5+jYY2HCnDuj +bYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=EI2a6CePBuQR5Qmt/hIAg9BsSGRZLvCH1L7dvlW0uiw=; b=IbKzNF3g5cSwEkwsNnWD0Qn1L5iUstKni+LlpKQXRn9dJmJ9alhsLSkdVF3WQ+Ur75 E8mk7cDSN+9u56SMqZR8Rkh8oVe8EhZowBFm5LGdZMjEHjnKpRqbE+/x+naoNAREzbb2 SvARPaHZ1Q5b7CJ7XSs+yFrn1s2Q9gm9rTsVAJO8jey2NLFTY7VrkSbXfvqnb5HRRHpE EDwM3mpZfEJTjV+4GCvrMtx0Y8sNLr2JisIfHAVj7zIeAnhGGVQJEI07e0w3FC04Q7Bx Dq1+29HIsUK1MU2XQ9W6ELH7YR+JTqTfIgnd7xqTn4fQuvfhXxoHgCxnr1FpddwiB2SV oRqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="C/IMoejL"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g13si25449495eds.419.2021.07.20.12.29.24; Tue, 20 Jul 2021 12:29:49 -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=@google.com header.s=20161025 header.b="C/IMoejL"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230030AbhGTSqh (ORCPT + 99 others); Tue, 20 Jul 2021 14:46:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229750AbhGTSq3 (ORCPT ); Tue, 20 Jul 2021 14:46:29 -0400 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D9C3C061767 for ; Tue, 20 Jul 2021 12:27:02 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id t3so2320308ljc.3 for ; Tue, 20 Jul 2021 12:27:02 -0700 (PDT) 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=EI2a6CePBuQR5Qmt/hIAg9BsSGRZLvCH1L7dvlW0uiw=; b=C/IMoejLQ3TpAwWYMjgZegIoM3Ljsd0fchCpMbLPN0uYHEs1jmSCEBv6KPLLzExal4 0LbYsqLNPRLzA3+wLI5TdzUtmrYg6vZAes3ebz8vsJgXKaIBilRm2/xQWyTTGjN5PzDK cMPnwUPZDMkvN5llO6UyNuK/a5D5WQectAgzehBqPkcz/Ac4EsX30+MR84+gFOaI1gzR 4J2I88iq7Y2E2mq4ewAltFyL+qCLUXcBCmbCKDitSeGnYei1G843MWztVnuwFXYr6gX2 2woprX0y3Iar4L4M24OgoI/JiMLIH+m199zJtJF6zCHRfxY5ijhU1s3YEHwnYB7coF6M Hxwg== 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=EI2a6CePBuQR5Qmt/hIAg9BsSGRZLvCH1L7dvlW0uiw=; b=DusirgD/RtcHB3ZjDHF72eMiswGscobx2h9kFOCHzxoZjQN1VKAvw3RMTdxKr3TvJg wwAn6G9p+wlDM6szbDxOoC4SRilXVfCLw13rBu9rDVr2rF0jKtHmLu1iToHAvNQ4UwgL YiLh8poxxFgvHnujmoAjs8ygF8VTbWQFPPsU227EvHQnj7EQ8/32vAI88aWArkdenbQw LGgFxpm5WlH6FT/wiPevBc5KHNrz4qRLJcSL7R264R8pDUXIwYNU403/2nx10yBYqB9e wQiGn7ekikqGScjCBtX7YF4HNc0qlzPvZFEhZur/ue9dvw/R1QRxABLyQG+bPC+wwklj tAcA== X-Gm-Message-State: AOAM533WXja2F0j0qFyMcegscXJ8w+/g2K/ovZHlvgfsIhOOXIfPmTK1 Lk7Dg0lfCrrv09CGyQaihRd9XqfrU27KR5laSMukKw== X-Received: by 2002:a05:651c:1213:: with SMTP id i19mr22636901lja.81.1626809220205; Tue, 20 Jul 2021 12:27:00 -0700 (PDT) MIME-Version: 1.0 References: <9123bca3-23bb-1361-c48f-e468c81ad4f6@virtuozzo.com> In-Reply-To: <9123bca3-23bb-1361-c48f-e468c81ad4f6@virtuozzo.com> From: Shakeel Butt Date: Tue, 20 Jul 2021 12:26:48 -0700 Message-ID: Subject: Re: [PATCH v5 02/16] memcg: enable accounting for IP address and routing-related objects To: Vasily Averin Cc: Andrew Morton , Cgroups , Michal Hocko , Johannes Weiner , Vladimir Davydov , Roman Gushchin , "David S. Miller" , Jakub Kicinski , Hideaki YOSHIFUJI , David Ahern , netdev , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 19, 2021 at 3:44 AM Vasily Averin wrote: > > An netadmin inside container can use 'ip a a' and 'ip r a' > to assign a large number of ipv4/ipv6 addresses and routing entries > and force kernel to allocate megabytes of unaccounted memory > for long-lived per-netdevice related kernel objects: > 'struct in_ifaddr', 'struct inet6_ifaddr', 'struct fib6_node', > 'struct rt6_info', 'struct fib_rules' and ip_fib caches. > > These objects can be manually removed, though usually they lives > in memory till destroy of its net namespace. > > It makes sense to account for them to restrict the host's memory > consumption from inside the memcg-limited container. > > One of such objects is the 'struct fib6_node' mostly allocated in > net/ipv6/route.c::__ip6_ins_rt() inside the lock_bh()/unlock_bh() section: > > write_lock_bh(&table->tb6_lock); > err = fib6_add(&table->tb6_root, rt, info, mxc); > write_unlock_bh(&table->tb6_lock); > > In this case it is not enough to simply add SLAB_ACCOUNT to corresponding > kmem cache. The proper memory cgroup still cannot be found due to the > incorrect 'in_interrupt()' check used in memcg_kmem_bypass(). > > Obsoleted in_interrupt() does not describe real execution context properly. > From include/linux/preempt.h: > > The following macros are deprecated and should not be used in new code: > in_interrupt() - We're in NMI,IRQ,SoftIRQ context or have BH disabled > > To verify the current execution context new macro should be used instead: > in_task() - We're in task context > > Signed-off-by: Vasily Averin > --- > mm/memcontrol.c | 2 +- > net/core/fib_rules.c | 4 ++-- > net/ipv4/devinet.c | 2 +- > net/ipv4/fib_trie.c | 4 ++-- > net/ipv6/addrconf.c | 2 +- > net/ipv6/ip6_fib.c | 4 ++-- > net/ipv6/route.c | 2 +- > 7 files changed, 10 insertions(+), 10 deletions(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index ae1f5d0..1bbf239 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -968,7 +968,7 @@ static __always_inline bool memcg_kmem_bypass(void) > return false; > > /* Memcg to charge can't be determined. */ > - if (in_interrupt() || !current->mm || (current->flags & PF_KTHREAD)) > + if (!in_task() || !current->mm || (current->flags & PF_KTHREAD)) > return true; > > return false; Can you please also change in_interrupt() in active_memcg() as well? There are other unrelated in_interrupt() in that file but the one in active_memcg() should be coupled with this change.