On Mon, 4 May 2020 20:38:32 +0200 Joerg Roedel <jroe...@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