On 7.1.2020 17.35, Paul Menzel wrote:
Dear Mathias, dear Mika,
On 2020-01-07 13:09, Mathias Nyman wrote:
On 3.1.2020 13.04, Mika Westerberg wrote:
On Thu, Jan 02, 2020 at 03:10:14PM +0100, Paul Menzel wrote:
Mika, as you fixed the other leak, any idea, how to continue from the
kmemleak log below?
```
unreferenced object 0xffff8c207a1e1408 (size 8):
comm "systemd-udevd", pid 183, jiffies 4294667978 (age 752.292s)
hex dump (first 8 bytes):
34 01 05 00 00 00 00 00 4.......
backtrace:
[<00000000aea7b46d>] xhci_mem_init+0xcfa/0xec0 [xhci_hcd]
There are probably better ways for doing this but you can use objdump
for example:
$ objdump -l --prefix-addresses -j .text --disassemble=xhci_mem_init drivers/usb/host/xhci-hcd.ko
then find the offset xhci_mem_init+0xcfa. It should show you the line
numbers as well if you have compiled your kernel with debug info. This
should be close to the line that allocated the memory that was leaked.
Thank you. I actually remembered `script/f2addr2line`.
$ scripts/faddr2line drivers/usb/host/xhci-hcd.o xhci_mem_init+0xcfa
xhci_mem_init+0xcfa/0xec0:
xhci_add_in_port at /mnt/drivers/usb/host/xhci-mem.c:2161
(inlined by) xhci_setup_port_arrays at /mnt/drivers/usb/host/xhci-mem.c:2309
(inlined by) xhci_mem_init at /mnt/drivers/usb/host/xhci-mem.c:2538
Paul, it possible that your xhci controller has several
supported protocol extended capabilities for usb 3 ports, each
with their own custom protocol speed ID table.
xhci driver assumes there is only one custome PSI table per roothub,
and we will end up allocating the second PSI table on top of the first,
leaking the first.
Could you boot with xhci dynamic debug enabled, and show dmesg after boot, add:
xhci_hcd.dyndbg=+p
to you kernel cmdline.
Or as an alternative, show output of:
sudo cat /sys/kernel/debug/usb/xhci/*/reg-ext-protocol*
`/sys/kernel/debug/` cannot be read by unprivileged users, so the wildcard does
not work with `sudo`.
```
$ sudo ls /sys/kernel/debug/usb/xhci
0000:12:00.0 0000:26:00.3 0000:26:00.4
# cat /sys/kernel/debug/usb/xhci/*/reg-ext-protocol*
problematic xhci:
capability for first four USB 2 ports
EXTCAP_REVISION = 0x02000402
EXTCAP_NAME = 0x20425355
EXTCAP_PORTINFO = 0x00180401
EXTCAP_PORTTYPE = 0x00000000
capability for one USB 3.1 port (5th port)
EXTCAP_REVISION = 0x03100802
EXTCAP_NAME = 0x20425355
EXTCAP_PORTINFO = 0x10000105
EXTCAP_PORTTYPE = 0x00000000
EXTCAP_MANTISSA1 = 0x00050134
capability for one USB 3.1 port (6th port)
EXTCAP_REVISION = 0x03100802
EXTCAP_NAME = 0x20425355
EXTCAP_PORTINFO = 0x10000106
EXTCAP_PORTTYPE = 0x00000000
EXTCAP_MANTISSA1 = 0x00050134
capability for one USB 3.1 port (7th port)
EXTCAP_REVISION = 0x03100802
EXTCAP_NAME = 0x20425355
EXTCAP_PORTINFO = 0x10000107
EXTCAP_PORTTYPE = 0x00000000
EXTCAP_MANTISSA1 = 0x00050134
capability for one USB 3.1 port (8th port)
EXTCAP_REVISION = 0x03100802
EXTCAP_NAME = 0x20425355
EXTCAP_PORTINFO = 0x10000108
EXTCAP_PORTTYPE = 0x00000000
EXTCAP_MANTISSA1 = 0x00050134
It has eight ports. last four of them are USB 3.1 ports.
It has a very odd setup where each 3.1 port has their own
supported protocol capability with a custom PSI, but all the PSI's are similar,
telling the port only support a 5Gbps speed.
We leak all the custom PSI tables for USB 3.1 ports except the last,
these would be the EXTCAP_MANTISSA1 = 0x00050134, which is the same as
the hex dump of the unreferenced object you posted earlier (considering byte order):
hex dump (first 8 bytes):
34 01 05 00 00 00 00 00 4.......
I'm working on a patch for this
-Mathias
