[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221209131357.5e4f6d01@gandalf.local.home>
Date: Fri, 9 Dec 2022 13:13:57 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Ross Zwisler <zwisler@...gle.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@...r.kernel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] ring-buffer: Handle resize in early boot up
On Fri, 9 Dec 2022 09:57:48 -0700
Ross Zwisler <zwisler@...gle.com> wrote:
> > + if (cpu_id == smp_processor_id()) {
> > + rb_update_pages(cpu_buffer);
> > + migrate_enable();
> > + } else {
> > + migrate_enable();
> > + schedule_work_on(cpu_id,
> > + &cpu_buffer->update_pages_work);
> > + wait_for_completion(&cpu_buffer->update_done);
>
> I ran with this patch on my test VM and hit the same Oops from the original
> report.
>
> I think the problem is that we're still trying to enable interrupts via
> wait_for_completion():
>
> wait_for_completion()
> wait_for_common()
> __wait_for_common()
> raw_spin_unlock_irq()
> _raw_spin_unlock_irq()
> __raw_spin_unlock_irq()
> local_irq_enable()
>
> I'm testing on a QEMU VM with 4 virtual CPUs, if that helps WRT where work is
> being scheduled (cpu_id == smp_processor_id).
Can you show the backtrace with that. Because when I triggered it, the
other CPUs were not up and running. I'm testing this on a VM with 8 CPUs.
-- Steve
Powered by blists - more mailing lists