Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp1261824iof; Tue, 7 Jun 2022 01:53:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwcTR/MEQw2LdJnytawFOooAsZWMy/iRwA6L8zbyZHWM2x4iR3PuUg8+sdaxukFyDqwM1Rh X-Received: by 2002:a17:90a:6b41:b0:1e0:e082:14c7 with SMTP id x1-20020a17090a6b4100b001e0e08214c7mr65463934pjl.92.1654592015668; Tue, 07 Jun 2022 01:53:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654592015; cv=none; d=google.com; s=arc-20160816; b=o5eQatm0r2goe7oZwsdRc8zxl0NEbK8RsIHsvuPEQN2K8TMta4yH0GH6XxZou607pD b7+CbOlI5lqVhbA7TPQLSk9JU2G+ymrvwfiZ7caC3TgH3rpa4f+CQCS6vnxJ5noF4GTV KrlUiEQUDFiCdwx/0WQQslgT04PzKc3EfjYwlVzwL6Q/do+1Zf+eBDkyBcCv3fhRJfSD T1tbOlInjUeZSETrr+PNtIU9aFey5UTJsbjpxKwe3FjBEOJC9dmh4Ug9niQtH5qlf1r6 gBlLHKLb8NETXNZ6yWZii8vtJYuwokUDZi2MFrfidN/Re+rmCh+0LovUfRAWGHDKC6jd EP9A== 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=vhyeByqESMejGx5K1JZDwSGtodZB7YcNJdkA/XZ0nhs=; b=OswXakusLPHQJHou+zKDfVG6E77Lkwp3AD5LvqJYyBSA3Cj3JeEgV0RBcT7EpqSjBW a+6O7UsI+GOAl+ynEMkE+wGPsOr/4rZucpHEUIfzQ0jf7SpAEzlaz2CSbEm0qL8GlFZe AifWMugnyPHIJOTnPCElVxBNTs10NsB7psVo5ofKbQz9ph4Mc0BTcohthDj/1s5Fk2yg YJphWEbcyEaMPOmQpoYJYucT8weKoKVJ3utG67NmYSz0EZJjXco1IAoKLhUozbcx7ahE JMUAe6fWl/M76JU+CDYbK6spDko/e88OY/mB4xv1ET8jOCaWOzIHFkp3rC270glgIav8 NUQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=kJEPNwOx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pf5-20020a17090b1d8500b001e34551c962si24866909pjb.80.2022.06.07.01.53.21; Tue, 07 Jun 2022 01:53:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=kJEPNwOx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S236881AbiFGF7A (ORCPT + 99 others); Tue, 7 Jun 2022 01:59:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236879AbiFGF66 (ORCPT ); Tue, 7 Jun 2022 01:58:58 -0400 Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18D48522DE for ; Mon, 6 Jun 2022 22:58:57 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id e11so14593746pfj.5 for ; Mon, 06 Jun 2022 22:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vhyeByqESMejGx5K1JZDwSGtodZB7YcNJdkA/XZ0nhs=; b=kJEPNwOx4uW/m0EmGEFbJCpF8utS8wjUtlPoQt/S+v3DQr6KNVz4SgD0N03AKsEJcX SO2IryPIeU/NYudxkDqQlve5MgWVNEd/UXTv4cQqyk1Xzg3ZqII+PMM+EuXOg1NIjJ4V jN7s5HxeykfvrWLOjcbQLVgsfbgmfTztwpMbAhaLNSeYFu4K1h3uX8J4o9hWA8ieYllK xdufyQ5KNBtOtIG80GB/m9OHwp8pxjZMmYG+HQsZiZNpZO5SvgjTSYceofuW/EpV1qLZ d8zB/sQ5OLtm52akYLt52jq1fouG4Dac89ykzUVvMKJVmu9w6rMtBvbq8X3+G+NZYOLg Jf+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vhyeByqESMejGx5K1JZDwSGtodZB7YcNJdkA/XZ0nhs=; b=FJfl9A13p6L2Me7xs4FcOblF7UnkU+5iYNyyUf9l6SvKKj4cxSg8T9w/gq8OoxnBre QlkLZ6urhl2T9SUOCHPMQxGqsi0twekCJVUJ+epkOWaQGJF4KA7JogU1FCG1oZmm0Ufm 68PFOa1Dp/GOKvP6npOnA456AbXGfGiEK544SwTQyB5KhB8/fL9U+/r5nTKisedwd2zc TD4TtPuHmP6hk4vzCK6AceagR+rn0rk1vM80pD3PKFJYHboI/z8ghYYQ1Q3kqZSo576d tUq+dByWFyB0EkFmUkPsBWGfvBUWQssyGj95yBOxPJD57IBHftCyspdUocaxPFMhfrqG W2Ig== X-Gm-Message-State: AOAM530W+HPKrQ5O5Uv8zGpxPSRIyVOiTqsCO4lpCs5R3RyMNd8qLLWm stTYIl1p9JDolDhAYkEc+iz+wy28W42xnVOKi4YcLA== X-Received: by 2002:a63:4c09:0:b0:3fc:a85f:8c07 with SMTP id z9-20020a634c09000000b003fca85f8c07mr24071397pga.509.1654581536373; Mon, 06 Jun 2022 22:58:56 -0700 (PDT) MIME-Version: 1.0 References: <6b362c6e-9c80-4344-9430-b831f9871a3c@openvz.org> <360a2672-65a7-4ad4-c8b8-cc4c1f0c02cd@openvz.org> In-Reply-To: <360a2672-65a7-4ad4-c8b8-cc4c1f0c02cd@openvz.org> From: Shakeel Butt Date: Mon, 6 Jun 2022 22:58:45 -0700 Message-ID: Subject: Re: [PATCH memcg v6] net: set proper memcg for net_init hooks allocations To: Vasily Averin Cc: Qian Cai , Roman Gushchin , Andrew Morton , kernel@openvz.org, LKML , Linux MM , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Vlastimil Babka , Michal Hocko , Florian Westphal , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Eric Dumazet , Cgroups Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 6, 2022 at 11:45 AM Vasily Averin wrote: > [...] > > As far as I understand this report means that 'init_net' have incorrect > virtual address on arm64. So, the two call stacks tell the addresses belong to the kernel modules (nfnetlink and nf_tables) whose underlying memory is allocated through vmalloc and virt_to_page() does not work on vmalloc() addresses. > > Roman, Shakeel, I need your help > > Should we perhaps verify kaddr via virt_addr_valid() before using virt_to_page() > If so, where it should be checked? I think virt_addr_valid() check in mem_cgroup_from_obj() should work but I think it is expensive on the arm64 platform. The cheaper and a bit hacky way to avoid such addresses is to directly use is_vmalloc_addr() directly.