Bug 111511 - Potentially invalid TPM 2.0 mapping
Summary: Potentially invalid TPM 2.0 mapping
Alias: None
Product: Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_other
Depends on:
Reported: 2016-01-29 23:08 UTC by Jethro Beekman
Modified: 2016-10-06 12:43 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.4.0
Tree: Mainline
Regression: No


Description Jethro Beekman 2016-01-29 23:08:32 UTC
Saw the following show up in my dmesg:

resource sanity check: requesting [mem 0xfed40040-0xfed4103f], which spans more than MSFT0101:00 [mem 0xfed40000-0xfed4087f]
------------[ cut here ]------------
WARNING: CPU: 1 PID: 201 at arch/x86/mm/ioremap.c:198 __ioremap_caller+0x234/0x390()
Info: mapping multiple BARs. Your kernel is fine.
Modules linked in:
 tpm_crb(+) processor_thermal_device int3400_thermal snd_hwdep intel_soc_dts_iosf snd_pcm video snd_timer snd rfkill dell_smo8800 pinctrl_sunrisepoint shpchp pinctrl_intel soundcore battery ac acpi_thermal_rel iosf_mbi i2c_i801 i2c_algo_bit acpi_pad button tpm_tis tpm acpi_als kfifo_buf industrialio processor int3402_thermal int340x_thermal_zone fjes sch_fq_codel ip_tables x_tables ext4 crc16 mbcache jbd2 hid_multitouch hid_sensor_hub usbhid hid sd_mod atkbd libps2 ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore usb_common i8042 serio
CPU: 1 PID: 201 Comm: systemd-udevd Tainted: G        W       4.4.0-4-ARCH #1
Hardware name: Dell Inc. Inspiron 13-7359/0JTM4R, BIOS 01.00.00 08/07/2015
 0000000000000000 00000000bef8f678 ffff88007e1bf9a0 ffffffff812c8a99
 ffff88007e1bf9e8 ffff88007e1bf9d8 ffffffff810771c2 00000000fed40040
 ffffc90000690040 0000000000001000 0000000000000040 ffff88007ddb2ac0
Call Trace:
 [<ffffffff812c8a99>] dump_stack+0x4b/0x72
 [<ffffffff810771c2>] warn_slowpath_common+0x82/0xc0
 [<ffffffff8107725c>] warn_slowpath_fmt+0x5c/0x80
 [<ffffffff8107d837>] ? iomem_map_sanity_check+0x97/0xd0
 [<ffffffff81064a84>] __ioremap_caller+0x234/0x390
 [<ffffffff81064bf7>] ioremap_nocache+0x17/0x20
 [<ffffffff812e15e2>] devm_ioremap_nocache+0x42/0x80
 [<ffffffffa02c1238>] crb_acpi_add+0x108/0x2d0 [tpm_crb]
 [<ffffffff8134c214>] acpi_device_probe+0x4f/0xf5
 [<ffffffff813ec1b2>] driver_probe_device+0x222/0x4a0
 [<ffffffff813ec4b4>] __driver_attach+0x84/0x90
 [<ffffffff813ec430>] ? driver_probe_device+0x4a0/0x4a0
 [<ffffffff813e9dec>] bus_for_each_dev+0x6c/0xc0
 [<ffffffff813eb96e>] driver_attach+0x1e/0x20
 [<ffffffff813eb4bb>] bus_add_driver+0x1eb/0x280
 [<ffffffffa0006000>] ? 0xffffffffa0006000
 [<ffffffff813ecdc0>] driver_register+0x60/0xe0
 [<ffffffff8134c0e3>] acpi_bus_register_driver+0x3b/0x43
 [<ffffffffa0006010>] crb_acpi_driver_init+0x10/0x1000 [tpm_crb]
 [<ffffffff81002123>] do_one_initcall+0xb3/0x200
 [<ffffffff81162537>] do_init_module+0x5f/0x1e8
 [<ffffffff810fcb8f>] load_module+0x219f/0x27e0
 [<ffffffff810f9a80>] ? symbol_put_addr+0x50/0x50
 [<ffffffff810fd31e>] SyS_init_module+0x14e/0x190
 [<ffffffff815925ae>] entry_SYSCALL_64_fastpath+0x12/0x71
---[ end trace a386ec65af3d81c3 ]---


Linux ... 4.4.0-4-ARCH #1 SMP PREEMPT Wed Jan 20 07:42:27 CET 2016 x86_64 GNU/Linux

Possibly related to https://bugzilla.kernel.org/show_bug.cgi?id=98181 . I will email Jarkko my ACPI dump.
Comment 1 jarkko.sakkinen 2016-01-30 18:24:14 UTC
Thanks for the dumps and reporting this!
Comment 2 jarkko.sakkinen 2016-02-02 23:31:28 UTC
Root cause identified with 90% certainty. This should not be a critical bug or risk the driver stability. I'll test my assumption before stating anything further.
Comment 3 jarkko.sakkinen 2016-02-04 18:51:03 UTC
In machines that I've tested 4.4 driver this does not occur although buffers that the driver maps do interleave. The reason for this is that in Linux 4.4 tpm_crb does not use devm_ioremap_resource() and therefore it does not add anything to iomem_resource tree.
Comment 4 jarkko.sakkinen 2016-02-11 07:46:00 UTC
As we discussed in the ML control area falsely maps 0x1000 and surpasses a resource boundary.
Comment 5 jarkko.sakkinen 2016-02-11 07:47:23 UTC
Jethro, is it too much trouble to you to test a fix I push it to my master branch?

I don't have hardware where the mappings go like they go on your hardware.
Comment 6 Jethro Beekman 2016-02-11 07:50:26 UTC
$ lsmod|grep tpm
tpm_crb                16384  0
tpm_tis                20480  0
tpm                    36864  2 tpm_crb,tpm_tis

If I can test the fix with building just a module for my current kernel I'm happy to test it in the near future. If I need to build a full kernel it might be a while before I can get to it.
Comment 7 jarkko.sakkinen 2016-02-11 11:22:00 UTC
(In reply to Jethro Beekman from comment #6)
> $ lsmod|grep tpm
> tpm_crb                16384  0
> tpm_tis                20480  0
> tpm                    36864  2 tpm_crb,tpm_tis
> If I can test the fix with building just a module for my current kernel I'm
> happy to test it in the near future. If I need to build a full kernel it
> might be a while before I can get to it.

Thank you, appreciate this!

I have this project that is still WiP:


The idea is to take my subsystem tree and bundle simple user space to initramfs and produce an image that you can write an USB stick.

For this bug module compilation should be sufficient but in future this BR environment should provide much more convenient environment for peer testing so that one does not have hose her host environment...
Comment 8 Yuval Adam 2016-02-11 12:07:51 UTC
Chiming in here, would be happy to test any fix as it becomes available. I already have a setup for testing 4.5-rcX tree, so any patch on top of that would be easy for me to test.

Although the buildroot-based option sounds nice and cozy as well :)
Comment 9 Jethro Beekman 2016-08-14 02:03:52 UTC
This went from "working but potentially broken" in 4.4 to "doesn't work at all" in 4.7:

tpm_crb MSFT0101:00: can't request region for resource [mem 0xfed40040-0xfed4103f]
tpm_crb: probe of MSFT0101:00 failed with error -16

Building the 4.4 driver on 4.7 continues to work without issue (but does emit the original error message). Let me know if you need more information.
Comment 10 jarkko.sakkinen 2016-08-18 13:00:14 UTC
It's actually a different regression even though the output looks the same :) Anyway, it looks like that the commit 422eac3f7dea did not make into 4.7.

I really hope I had authority to close these bugs so that they don't get reused for different bugs. Anyway, thank you for your bug report. I'll try to get this fixed.
Comment 11 jarkko.sakkinen 2016-08-24 12:02:56 UTC
I sent some days ago commit IDs to stable@vger.kernel.org for the fixes. Hopefully come to next 4.7 update.
Comment 12 jarkko.sakkinen 2016-09-05 16:24:10 UTC
Comment 13 jarkko.sakkinen 2016-10-06 12:43:04 UTC

Note You need to log in before you can comment on or make changes to this bug.