[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200806195726.GI4520@mtj.thefacebook.com>
Date: Thu, 6 Aug 2020 15:57:26 -0400
From: Tejun Heo <tj@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Joerg Roedel <jroedel@...e.de>, Ingo Molnar <mingo@...nel.org>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86/mm changes for v5.9
On Thu, Aug 06, 2020 at 12:42:23PM -0700, Linus Torvalds wrote:
> that admittedly odd sequence is get_work_pwq(work)
>
> And then the faulting instruction is:
>
> > 2a:* 49 8b 46 08 mov 0x8(%r14),%rax <-- trapping instruction
>
> and this is the "->wq" dereference.
>
> So it's the pwq->wq that traps, with 'pwq' being the trapping base
> pointer, and clearly being in the vmalloc space.
>
> I think pwq may a percpu allocation, so not _directly_ vmalloc().
> Adding Tejun to the cc in case he can clarify ("No, silly Linus, it's
> allocated here..").
Hey, silly Linus, yeap, they're per-cpu allocations and will be in vmalloc
address space for per-cpu workqueues. For unbound workqueues, they're
regular kmallocs. The per-cpu allocation happens in alloc_and_link_pwqs():
static int alloc_and_link_pwqs(struct workqueue_struct *wq)
{
bool highpri = wq->flags & WQ_HIGHPRI;
int cpu, ret;
if (!(wq->flags & WQ_UNBOUND)) {
wq->cpu_pwqs = alloc_percpu(struct pool_workqueue);
if (!wq->cpu_pwqs)
return -ENOMEM;
Thanks.
--
tejun
Powered by blists - more mailing lists