Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Greg Ungerer <gerg@kernel.org>
To: "open list:MIPS" <linux-mips@vger.kernel.org>
Subject: "virt_to_phys used for non-linear address" warnings
Date: Fri, 1 Jul 2022 17:24:22 +1000	[thread overview]
Message-ID: <1e4f33d7-7eb5-3fb5-e44d-c4652e7cb8c6@kernel.org> (raw)

Hi,

I am debugging a strange memory problem on a Mediatek MT7621 SoC based
hardware platform. That problem leads to rare and somewhat random
oops that are mostly within vma and generic memory functions (often in
kmem_cache_alloc(), but sometimes other places like unlink_anon_vmas() or
anon_vma_interval_tree_remove() or vma_interval_tree_remove()).

To help track this down I enabled a few of the kernels hacking memory
debug config options. Now this immediately leads to getting this on
every process fork/exec:

   ------------[ cut here ]------------
   WARNING: CPU: 0 PID: 1 at arch/mips/mm/physaddr.c:38 __virt_to_phys+0x50/0x84
   virt_to_phys used for non-linear address: c443e370 (0xbfbd0000)
   Modules linked in:
   CPU: 0 PID: 1 Comm: init Not tainted 5.17.0-ac0 #1
   Stack : 81c70000 7ffbd000 77de5000 81086784 00000000 00000004 00000000 d95b60c8
           80441c84 81c43654 81b70000 81b60000 804583d8 00000001 80441c28 8045cd00
           00000000 00000000 81aaf3b4 80441a70 00000187 80441adc 00000000 20306361
           203a6d6d 81c4d2f5 81c4d31c 74696e69 81b60000 00000001 80441d3c 81b6dbf0
           82070040 8066f240 81c70000 7ffbd000 00000000 814ff0f4 00000000 81c40000
           ...
   Call Trace:
   [<81008ed0>] show_stack+0x38/0x118
   [<8198f9e4>] dump_stack_lvl+0x5c/0x7c
   [<81989300>] __warn+0xc0/0xf4
   [<819893c0>] warn_slowpath_fmt+0x8c/0xb8
   [<81025480>] __virt_to_phys+0x50/0x84
   [<8100bb30>] arch_setup_additional_pages+0x120/0x230
   [<81239280>] load_elf_binary+0xacc/0x14e0
   [<811d6788>] bprm_execve+0x288/0x5dc
   [<811d7240>] kernel_execve+0x130/0x1b4
   [<81988154>] try_to_run_init_process+0x14/0x4c
   [<81995e40>] kernel_init+0xe4/0x118
   [<81003398>] ret_from_kernel_thread+0x14/0x1c
   
   ---[ end trace 0000000000000000 ]---

This is caused by this code in arch/mips/kernel/vdso.c, function
arch_setup_additional_pages():

         /* Map GIC user page. */
         if (gic_size) {
                 gic_base = (unsigned long)mips_gic_base + MIPS_GIC_USER_OFS;
                 gic_pfn = virt_to_phys((void *)gic_base) >> PAGE_SHIFT;

                 ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
                                          pgprot_noncached(vma->vm_page_prot));
                 if (ret)
                         goto out;
         }

That virt_to_phys() is being passed a value assigned from an ioremap().
According to the comments in io.h, this is not a correct usage of it:

  *     The returned physical address is the physical (CPU) mapping for
  *     the memory address given. It is only valid to use this function on
  *     addresses directly mapped or allocated via kmalloc.

So the debug warning is consistent with this comment.

It is trivial to fix this by using __pa() directly here instead of
virt_to_phys(). So simply doing this fixes it:

--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -159,7 +159,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
         /* Map GIC user page. */
         if (gic_size) {
                 gic_base = (unsigned long)mips_gic_base + MIPS_GIC_USER_OFS;
-               gic_pfn = virt_to_phys((void *)gic_base) >> PAGE_SHIFT;
+               gic_pfn = __pa(gic_base) >> PAGE_SHIFT;
  
                 ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
                                          pgprot_noncached(vma->vm_page_prot));

I am wondering if that is the right approach or if there is a more correct way?

Regards
Greg


             reply	other threads:[~2022-07-01  7:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-01  7:24 Greg Ungerer [this message]
2022-07-05 17:42 ` "virt_to_phys used for non-linear address" warnings Serge Semin
2022-07-06  5:47   ` Greg Ungerer
2022-07-06 12:05     ` Serge Semin
2022-07-07  4:49       ` Greg Ungerer
2022-07-07 11:40         ` Serge Semin
2022-07-07 16:59           ` Florian Fainelli
2022-07-07 19:42             ` Serge Semin
2022-07-07 20:53               ` Florian Fainelli
2022-07-08  2:06           ` Greg Ungerer

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=1e4f33d7-7eb5-3fb5-e44d-c4652e7cb8c6@kernel.org \
    --to=gerg@kernel.org \
    --cc=linux-mips@vger.kernel.org \
    /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