Messages in this thread | | | Date | Thu, 6 Aug 2020 15:57:26 -0400 | From | Tejun Heo <> | 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
| |