linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anatol Pomozov <anatol.pomozov@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: avid@redhat.com, hch@lst.de, namit@vmware.com,
	tglx@linutronix.de, delvare@suse.de, rrichter@marvell.com,
	rppt@linux.vnet.ibm.com
Subject: dmesg spammed with "caller memremap+0x64/0x160 mapping multiple BARs"
Date: Thu, 5 Dec 2019 13:18:52 -0800	[thread overview]
Message-ID: <CAOMFOmXU8RoeAOEjP=gkkiZdPS8Ok_wzXcgUZxL11u1zMSEtMQ@mail.gmail.com> (raw)

Hi folks

We have several servers that run on kernel 4.14.12 and their logs
spammed with following messages:

 [20633911.311910] caller memremap+0x64/0x160 mapping multiple BARs
 [20633911.318577] resource sanity check: requesting [mem
0x000eb570-0x000edc34], which spans more than PCI Bus 0000:00 [mem
0x000e8000-0x000ebfff window]
 [20633911.333650] caller memremap+0x64/0x160 mapping multiple BARs
 [20633911.340412] resource sanity check: requesting [mem
0x000eb570-0x000edc34], which spans more than PCI Bus 0000:00 [mem
0x000e8000-0x000ebfff window]
 [20633911.355481] caller memremap+0x64/0x160 mapping multiple BARs

After some debugging I've found that the warning is printed when I open the file
/sys/firmware/dmi/entries/*/raw The stacktrace is

[   14.839284] Call Trace:
[   14.839289]  dump_stack+0x46/0x59
[   14.839293]  iomem_map_sanity_check+0xb8/0xc0
[   14.839296]  __ioremap_caller+0x225/0x2f0
[   14.839302]  memremap+0x113/0x170
[   14.856703]  ? dmi_name_in_serial+0x30/0x30
[   14.856705]  dmi_walk+0x30/0x70
[   14.856706]  find_dmi_entry+0x46/0x80
[   14.856708]  ? dmi_entry_free+0x10/0x10
[   14.856710]  dmi_entry_raw_read+0x3a/0x60
[   14.856712]  kernfs_fop_read+0xa1/0x170
[   14.856714]  __vfs_read+0x36/0x170
[   14.856717]  vfs_read+0x89/0x130
[   14.856719]  SyS_read+0x52/0xc0
[   14.856721]  do_syscall_64+0x60/0x110
[   14.856723]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[   14.856725] RIP: 0033:0x7f60aceedf70

As it turned out the root of the problem is BIOS region mapping. Here
are ACPI mappings:

000e0000-000fffff : Reserved
  000e0000-000e3fff : PCI Bus 0000:00
  000e4000-000e7fff : PCI Bus 0000:00
  000e8000-000ebfff : PCI Bus 0000:00
  000ec000-000effff : PCI Bus 0000:00
  000f0000-000fffff : PCI Bus 0000:00

Or the same mapping from IASL tool:

DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed,
Cacheable, ReadWrite,
    0x00000000,         // Granularity
    0x000E8000,         // Range Minimum
    0x000EBFFF,         // Range Maximum
    0x00000000,         // Translation Offset
    0x00004000,         // Length
    ,, , AddressRangeMemory, TypeStatic)
DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed,
Cacheable, ReadWrite,
    0x00000000,         // Granularity
    0x000EC000,         // Range Minimum
    0x000EFFFF,         // Range Maximum
    0x00000000,         // Translation Offset
    0x00004000,         // Length
    ,, , AddressRangeMemory, TypeStatic)


SMBIOS table is located at 0x000eb570-0x000edc34 address range. When
find_dmi_entry() tries to map SMBIOS to kernel address space the
warning above is printed.



So I have a few questions here:
 - What exactly kernel tries to tell us here? Why mapping SMBIOS over
multiple PCI mappings is bad. Sorry I am not familiar with this
codepath and I am trying to understand the issue.
 - Is the warning really bad? The code works just fine despite the
warnings. Can the warning be turned into info/debug()?
 - Is the mapping need to be fixed in BIOS? What other possible
problems can happen due to such BIOS mapping misconfiguration?
 - Why SMBIOS table mapped for every sysfs file read? Would it make
sense to map SMBIOS only once at the kernel boot?
 - Does it make sense to ratelimit the warning? I will be glad to send
the path for it.

                 reply	other threads:[~2019-12-05 21:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOMFOmXU8RoeAOEjP=gkkiZdPS8Ok_wzXcgUZxL11u1zMSEtMQ@mail.gmail.com' \
    --to=anatol.pomozov@gmail.com \
    --cc=avid@redhat.com \
    --cc=delvare@suse.de \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namit@vmware.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=rrichter@marvell.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).