Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5488876ybi; Tue, 4 Jun 2019 07:25:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqzrz2IWYX5cAntBpH4aUQSjxRXnBs4UNXjpl/SLxcBro70OhGetrY2S8lJLCgMKaAqGutfa X-Received: by 2002:a62:61c2:: with SMTP id v185mr23218497pfb.0.1559658325795; Tue, 04 Jun 2019 07:25:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559658325; cv=none; d=google.com; s=arc-20160816; b=iwtun6c+Hxu8VK5bOtZWshOlDxgYzBqitXRUoJmwKOeLxgRk8OTaJgxVtKaGi31OZI aji3071N4r0v+fOmwLXofd/o3U7EfEW+S4LbPNVZdal8ClJQyx94oZdeuRujWaBHmYz9 ZUobxsHlpvPQ9z1yBd92maf/n07LvOwjMTL6ehIgVks97OkmMOblNkRAvZhl1/Kiqt2a nEEgkh7jC5uf85PO8X6nPzjZkHp7GHaJl3XkVNbyhlz35SPRk+a4567XZ8fAhyHCW7TL e7P9CKFlkne6femSrWSnxa2gw3Y7KWfNEXpEBHZxXdQsps+l+nuz2lXDFpPwRR/46wKX gAxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=vc7rfhl9mcfSYNUSIEYNBXnL4l/81GoOn3cs7pdaQ8s=; b=nb2Bfn0wihUvP0uwaYAaLMXi2j9W17q781IW6lEz0GUhlcBrqJkoiriBUJEHP9KoZC W5ks1/0AvQ70K95cIxL84rbyaQ5mp44+sBOJ/BxHnM5MrGxDBjtfMOMygqkos1NlNayT yxxKLHrSUwNjmtAnQh6nluAgXLyh6dQTfpz2C8SmkLnubZelf7vIqHi5TlqpCfu4fTk0 bAonhrGY7CkoHS+OV9KJvPpBQJ6Txlj/yELrKFd2SnufUvTiNPFIqSLGQsLESw+iS4v8 JE88VL9/ujaNTp740xykPnl3rkYkmr3D+xGLxVjTQt9+3kfozL4OOSzNWkMhrO4xEGWT UT/A== 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 x1si5215152pfa.253.2019.06.04.07.25.09; Tue, 04 Jun 2019 07:25:25 -0700 (PDT) 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 S1727541AbfFDOXo (ORCPT + 99 others); Tue, 4 Jun 2019 10:23:44 -0400 Received: from foss.arm.com ([217.140.101.70]:45136 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727137AbfFDOXn (ORCPT ); Tue, 4 Jun 2019 10:23:43 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0E423341; Tue, 4 Jun 2019 07:23:43 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EDBD23F690; Tue, 4 Jun 2019 07:23:40 -0700 (PDT) Date: Tue, 4 Jun 2019 15:23:38 +0100 From: Mark Rutland To: Qian Cai , rppt@linux.ibm.com Cc: akpm@linux-foundation.org, catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, mhocko@kernel.org, linux-mm@kvack.org, vdavydov.dev@gmail.com, hannes@cmpxchg.org, cgroups@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH -next] arm64/mm: fix a bogus GFP flag in pgd_alloc() Message-ID: <20190604142338.GC24467@lakrids.cambridge.arm.com> References: <1559656836-24940-1-git-send-email-cai@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1559656836-24940-1-git-send-email-cai@lca.pw> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 04, 2019 at 10:00:36AM -0400, Qian Cai wrote: > The commit "arm64: switch to generic version of pte allocation" > introduced endless failures during boot like, > > kobject_add_internal failed for pgd_cache(285:chronyd.service) (error: > -2 parent: cgroup) > > It turns out __GFP_ACCOUNT is passed to kernel page table allocations > and then later memcg finds out those don't belong to any cgroup. Mike, I understood from [1] that this wasn't expected to be a problem, as the accounting should bypass kernel threads. Was that assumption wrong, or is something different happening here? > > backtrace: > kobject_add_internal > kobject_init_and_add > sysfs_slab_add+0x1a8 > __kmem_cache_create > create_cache > memcg_create_kmem_cache > memcg_kmem_cache_create_func > process_one_work > worker_thread > kthread > > Signed-off-by: Qian Cai > --- > arch/arm64/mm/pgd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/mm/pgd.c b/arch/arm64/mm/pgd.c > index 769516cb6677..53c48f5c8765 100644 > --- a/arch/arm64/mm/pgd.c > +++ b/arch/arm64/mm/pgd.c > @@ -38,7 +38,7 @@ pgd_t *pgd_alloc(struct mm_struct *mm) > if (PGD_SIZE == PAGE_SIZE) > return (pgd_t *)__get_free_page(gfp); > else > - return kmem_cache_alloc(pgd_cache, gfp); > + return kmem_cache_alloc(pgd_cache, GFP_PGTABLE_KERNEL); This is used to allocate PGDs for both user and kernel pagetables (e.g. for the efi runtime services), so while this may fix the regression, I'm not sure it's the right fix. Do we need a separate pgd_alloc_kernel()? Thanks, Mark. [1] https://lkml.kernel.org/r/20190505061956.GE15755@rapoport-lnx