linux-kernel - Re: ioremap panic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <871w0kyp6i.fsf@basil.nowhere.org>
Date:	Wed, 20 Aug 2008 12:08:05 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"Yinghai Lu" <yhlu.kernel@...il.com>,
	"Ingo Molnar" <mingo@...e.hu>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: ioremap panic

Andrew Morton <akpm@...ux-foundation.org> writes:
>
> Please work out what address qla2x00_probe_one() passed into ioremap(),

Note that ioremap doesn't get a virtual address, but a bus/phys one.
The virtual address checked in the BUG above comes internally
out of vmalloc's address space allocation.

> then see if you can work out what was already at that virtual address
> (/proc/iomem, dmesg output, etc).

The bug is more likely that either the kernel page tables or the 
vmalloc vmlist are inconsistent somehow. In particularly it looks
like vmalloc gave out an address for ioremap on which there was
already a mapping.

I doubt it is qla2x00's fault.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/