From: Mike Rapoport <rppt@linux.ibm.com> To: Mark Rutland <mark.rutland@arm.com> Cc: Qian Cai <cai@lca.pw>, 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, guro@fb.com, cgroups@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH -next] arm64/mm: fix a bogus GFP flag in pgd_alloc() Date: Tue, 4 Jun 2019 17:54:22 +0300 [thread overview] Message-ID: <20190604145422.GG8417@rapoport-lnx> (raw) In-Reply-To: <20190604142338.GC24467@lakrids.cambridge.arm.com> On Tue, Jun 04, 2019 at 03:23:38PM +0100, Mark Rutland wrote: > 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? I was under impression that all allocations are going through __memcg_kmem_charge() which does the bypass. Apparently, it's not the case :( > > > > 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 <cai@lca.pw> > > --- > > 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. Me neither. > Do we need a separate pgd_alloc_kernel()? I'd like to take a closer look at memcg paths once again before adding pgd_alloc_kernel(). Johannes, Roman, can you please advise anything? > Thanks, > Mark. > > [1] https://lkml.kernel.org/r/20190505061956.GE15755@rapoport-lnx > -- Sincerely yours, Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com> To: Mark Rutland <mark.rutland@arm.com> Cc: catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, mhocko@kernel.org, linux-mm@kvack.org, Qian Cai <cai@lca.pw>, vdavydov.dev@gmail.com, hannes@cmpxchg.org, cgroups@vger.kernel.org, akpm@linux-foundation.org, guro@fb.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH -next] arm64/mm: fix a bogus GFP flag in pgd_alloc() Date: Tue, 4 Jun 2019 17:54:22 +0300 [thread overview] Message-ID: <20190604145422.GG8417@rapoport-lnx> (raw) In-Reply-To: <20190604142338.GC24467@lakrids.cambridge.arm.com> On Tue, Jun 04, 2019 at 03:23:38PM +0100, Mark Rutland wrote: > 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? I was under impression that all allocations are going through __memcg_kmem_charge() which does the bypass. Apparently, it's not the case :( > > > > 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 <cai@lca.pw> > > --- > > 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. Me neither. > Do we need a separate pgd_alloc_kernel()? I'd like to take a closer look at memcg paths once again before adding pgd_alloc_kernel(). Johannes, Roman, can you please advise anything? > Thanks, > Mark. > > [1] https://lkml.kernel.org/r/20190505061956.GE15755@rapoport-lnx > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-04 14:54 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-04 14:00 [PATCH -next] arm64/mm: fix a bogus GFP flag in pgd_alloc() Qian Cai 2019-06-04 14:00 ` Qian Cai 2019-06-04 14:23 ` Mark Rutland 2019-06-04 14:23 ` Mark Rutland 2019-06-04 14:30 ` Mark Rutland 2019-06-04 14:30 ` Mark Rutland 2019-06-05 21:33 ` Mike Rapoport 2019-06-05 21:33 ` Mike Rapoport 2019-06-04 14:54 ` Mike Rapoport [this message] 2019-06-04 14:54 ` Mike Rapoport 2019-06-10 11:43 ` Will Deacon 2019-06-10 11:43 ` Will Deacon 2019-06-10 17:26 ` Qian Cai 2019-06-10 17:26 ` Qian Cai 2019-06-10 17:26 ` Qian Cai 2019-06-11 10:03 ` Mark Rutland 2019-06-11 10:03 ` Mark Rutland 2019-06-11 12:41 ` Mike Rapoport 2019-06-11 12:41 ` Mike Rapoport 2019-06-11 12:46 ` Qian Cai 2019-06-11 12:46 ` Qian Cai 2019-06-12 6:57 ` Mike Rapoport 2019-06-12 6:57 ` Mike Rapoport 2019-06-12 18:35 ` Qian Cai 2019-06-12 18:35 ` Qian Cai 2019-06-12 18:35 ` Qian Cai 2019-06-11 13:02 ` Mark Rutland 2019-06-11 13:02 ` Mark Rutland 2019-06-13 12:11 ` Mike Rapoport 2019-06-13 12:11 ` Mike Rapoport 2019-06-13 12:11 ` Mike Rapoport 2019-06-13 13:22 ` Qian Cai 2019-06-13 13:22 ` Qian Cai 2019-06-13 13:22 ` Qian Cai 2019-06-13 19:44 ` Mike Rapoport 2019-06-13 19:44 ` Mike Rapoport 2019-06-17 15:12 ` Mike Rapoport 2019-06-17 15:12 ` Mike Rapoport 2019-06-17 16:36 ` Will Deacon 2019-06-17 16:36 ` Will Deacon 2019-06-18 6:12 ` Mike Rapoport 2019-06-18 6:12 ` Mike Rapoport 2019-06-18 6:12 ` Mike Rapoport 2019-06-18 6:54 ` Will Deacon 2019-06-18 6:54 ` Will Deacon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190604145422.GG8417@rapoport-lnx \ --to=rppt@linux.ibm.com \ --cc=akpm@linux-foundation.org \ --cc=cai@lca.pw \ --cc=catalin.marinas@arm.com \ --cc=cgroups@vger.kernel.org \ --cc=guro@fb.com \ --cc=hannes@cmpxchg.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mark.rutland@arm.com \ --cc=mhocko@kernel.org \ --cc=vdavydov.dev@gmail.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.