> On Mon, Jun 20, 2022 at 6:44 PM Uladzislau Rezki <urezki@xxxxxxxxx> wrote: > > > > > > > > > > > Is it easy to reproduce? If so could you please describe the steps? As i see > > > > the freeing of the "vb" is RCU safe whereas vb->va is not. But from the first > > > > glance i do not see how it can accessed twice. Hm.. > > > It was raised from a monkey test on A13_k515 system and got 1/20 pcs > > > failed. IMO, vb->va which out of vmap_purge_lock protection could race > > > with a concurrent ra freeing within __purge_vmap_area_lazy. > > > > > Do you have exact steps how you run "monkey" test? > There are about 30+ kos inserted during startup which could be a > specific criteria for reproduction. Do you have doubts about the test > result or the solution? > > I do not have any doubt about your test results, so if you can trigger it then there is an issue at least on the 5.4.161-android12 kernel. 1. With your fix we get expanded mutex range, thus the worst case of vmalloc allocation can be increased when it fails and repeat. Because it also invokes the purge_vmap_area_lazy() that access the same mutex. 2. You run 5.4.161-android12 kernel what is quite old. Could you please retest with latest kernel? I am asking because on the latest kernel with CONFIG_KASAN i am not able to reproduce it. I do a lot of: vm_map_ram()/vm_unmap_ram()/vmalloc()/vfree() in parallel by 64 kthreads on my 64 CPUs test system. Could you please confirm that you can trigger an issue on the latest kernel? Thanks! -- Uladzislau Rezki
