On Tue, Jun 21, 2022 at 5:27 PM Uladzislau Rezki <urezki@xxxxxxxxx> wrote: > > > 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. I am not sure I get your point. _vm_unmap_aliases calls _purge_vmap_area_lazy instead of purge_vmap_area_lazy. Do you have any other solutions? I really don't think my patch is the best way as I don't have a full view of vmalloc mechanism. > > 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. The failure generates at 20s from starting up, I think it is a rare timing. > > Could you please confirm that you can trigger an issue on the latest kernel? Sorry, I don't have an available latest kernel for now. > > Thanks! > > -- > Uladzislau Rezki
