>>>>> >>>>> Nope, it's vm_map_ram() not being handled >>>> >>>> >>>> Another suspicious one. Related to kasan/vmalloc? >>> >>> Very likely the same as with ion: >>> >>> # git grep vm_map_ram|grep xfs >>> fs/xfs/xfs_buf.c: * vm_map_ram() will allocate auxiliary structures (e.g. >>> fs/xfs/xfs_buf.c: bp->b_addr = vm_map_ram(bp->b_pages, bp->b_page_count, >> >> Aaargh, that's an embarassing miss. >> >> It's a bit intricate because kasan_vmalloc_populate function is >> currently set up to take a vm_struct not a vmap_area, but I'll see if I >> can get something simple out this evening - I'm away for the first part >> of next week. For crashes in XFS, binder etc that implicate vm_map_ram, see: https://lore.kernel.org/linux-mm/20191129154519.30964-1-dja@xxxxxxxxxx/ The easiest way I found to repro the bug is sudo modprobe i915 mock_selftest=-1 For lock warns, one that goes through the percpu alloc path, the patch is already queued in mmots. For Dmitry's latest one where there's an allocation in the purge_vmap_area_lazy path that triggers a locking warning, you'll have to wait until next week, sorry. Regards, Daniel
