Messages in this thread | | | Date | Mon, 4 May 2020 15:10:06 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH] percpu: Sync vmalloc mappings in pcpu_alloc() and free_percpu() |
| |
On Mon, 4 May 2020 20:38:32 +0200 Joerg Roedel <jroedel@suse.de> wrote:
> Fair point, but this just shows how problematic it is to call something > like vmalloc_sync_mappings() from a lower-level kernel API function. > The obvious fix for this would be to make pgd_lock irq-safe, but this is > getting more and more ridiculous.
Yeah, it's just getting more deeper into the rabbit hole.
> > I know you don't like to have a vmalloc_sync_mappings() call in the > tracing code, but can you live with it until we get rid of this broken > interface?
I'm fine with adding it to the tracing code (with that ridiculous comment! ;-)
I'll even tag is as stable, but again, it's uncertain what commit that it "fixes".
> > My plan for this is to use a small bitmap to track in the vmalloc and > the (x86-)ioremap code at which levels of the page-tables the code made > changes and combine that with an architecture-dependend mask to decide > whether anything needs to be synced. > > On x86-64 the sync would be necessary at most 64 times after boot, so I > think this will only have a very small performance impact, even with > VMAP_STACKS. And as a bonus it would also get rid of vmalloc faulting on > x86, fixing the issue with tracing too.
Just because tracing get's a workaround, let's hopefully not get distracted and forgot to add this. It looks like the best solution is to not need the vmalloc_sync_mappings() call in the future. But, as we are about to release trace-cmd with a feature that reliably triggers the bug, I can't wait for the proper fix.
-- Steve
| |