Re: [Crash-utility] Fwd: s390x fixes

With respect to the 3rd "vm -p" bug, I did some cursory debugging, and here's what I found. In all cases, the readmem() failure occurs in _kl_pg_table_deref_s390x() as a result of transitioning from one page of PTEs to the next, because the pointer to the "next" page of PTES contains 0x20, which looks to be _SEGMENT_ENTRY_INV or _REGION_ENTRY_INV? (not sure of the s390x nomenclature...) So you'll see something like this in the page table that points to the pages of PTEs: ... c6386e0: 0000000000000020 0000000000000020 ....... ....... c6386f0: 000000001608c800 0000000000000020 ............... c638700: 0000000000000020 0000000000000020 ....... ....... ... The vaddr's in the page of PTEs pointed to by c6386f0 (at 000000001608c800) all resolve as expected, but when the virtual address bumps it to c6386f8, it reads the 0x20, and passes it to _kl_pg_table_deref_s390x(). The user vaddr(s) that resolve to that next page of PTEs are legitimate, given that they are in the virtual region defined by the vm_area_struct. But they certainly may not be mapped. Anyway, it seems that there should be something that catches the invalid entry in s390x_vtop() -- prior to calling _kl_pg_table_deref_s390x()-- and return FALSE at that point. So if I make this kludge: ... /* Check if this is a large page. */ if (entry & 0x400ULL) { /* Add the 1MB page offset and return the final value. */ *phys_addr = table + (vaddr & 0xfffffULL); return TRUE; } ======> if (entry == 0x20) return FALSE; /* Get the page table entry */ entry = _kl_pg_table_deref_s390x(vaddr, entry & ~0x7ffULL); if (!entry) return FALSE; /* Isolate the page origin from the page table entry. */ paddr = entry & ~0xfffULL; /* Add the page offset and return the final value. */ *phys_addr = paddr + (vaddr & 0xfffULL); return TRUE; } then everything seems to work OK. So unless the calculation of the next page of PTEs is incorrect, which seems unlikely, it seems that the 0x20 is legitimate, and should be recognized? What do you think?