On Tue, Jun 7, 2022 at 5:37 AM Vasily Averin <vvs@xxxxxxxxxx> wrote: > > On 6/7/22 08:58, Shakeel Butt wrote: > > On Mon, Jun 6, 2022 at 11:45 AM Vasily Averin <vvs@xxxxxxxxxx> wrote: > >> > > [...] > >> > >> As far as I understand this report means that 'init_net' have incorrect > >> virtual address on arm64. > > > > So, the two call stacks tell the addresses belong to the kernel > > modules (nfnetlink and nf_tables) whose underlying memory is allocated > > through vmalloc and virt_to_page() does not work on vmalloc() > > addresses. > > However in both these cases get_mem_cgroup_from_obj() -> mem_cgroup_from_obj() -> > virt_to_folio() -> virt_to_page() -> virt_to_pfn() -> __virt_to_phys() > handles address of struct net taken from for_each_net(). > The only net namespace that exists at this stage is init_net, > and dmesg output confirms this: > "virt_to_phys used for non-linear address: ffffd8efe2d2fe00 (init_net)" > > >> Roman, Shakeel, I need your help > >> > >> Should we perhaps verify kaddr via virt_addr_valid() before using virt_to_page() > >> If so, where it should be checked? > > > > I think virt_addr_valid() check in mem_cgroup_from_obj() should work > > but I think it is expensive on the arm64 platform. The cheaper and a > > bit hacky way to avoid such addresses is to directly use > > is_vmalloc_addr() directly. > > I do not understand why you mean that processed address is vmalloc-specific. > As far as I understand it is valid address of static variable, and for some reason > arm64 does not consider them valid virtual addresses. > Indeed you are right as we are using the addresses of net namespaces and the report already has the information on the address ffffd8efe2d2fe00 which is init_net. I don't know what is the right way to handle such addresses on arm64. BTW there is a separate report on this issue and arm maintainers are also CCed. Why not ask this question on that report?
