[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080131003901.763449fb@daedalus.pq.iki.fi>
Date: Thu, 31 Jan 2008 00:39:01 +0200
From: Pekka Paalanen <pq@....fi>
To: tglx@...utronix.de
Cc: Pekka Paalanen <pq@....fi>, mingo@...hat.com,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] x86: mmiotrace - trace memory mapped IO
On Sun, 27 Jan 2008 19:55:36 +0200
Pekka Paalanen <pq@....fi> wrote:
> The following is a copy of the patch description:
...
> Mmiotrace works by wrapping the ioremap family of kernel functions and
> marking the returned pages as not present. Access to the IO memory
> triggers a page fault, which will be handled by mmiotrace's custom page
> fault handler. This will single-step the faulted instruction with the
> MMIO page marked as present. Access logs are directed to user space via
> relay and debug_fs.
Hi,
a test user found a problem with mmiotrace (ported to x86/mm git tree).
The symbol 'init_mm' is undefined, but required when building the 32-bit
mmiotrace kernel module.
commit 3abf024d2abb79614d8c4cb25a70d5596f77d0ad
Author: Thomas Gleixner <tglx@...utronix.de>
Date: Wed Jan 30 13:30:28 2008 +0100
x86: nuke a ton of unused exports
This commit removes EXPORT_SYMBOL(init_mm). Apparently mmiotrace requires
this symbol, but I do not know why. I do not use init_mm myself, so
apparently some function I call is inlined and requires it. Page table or
attribute handling stuff maybe?
Is it possible to simply put back this export or should I dig deeper into
why it seems to be required?
I can provide the simple patch to put it back in my next patch set, if
this is the right solution.
I will post the patch set after this issue is solved. In the mean time,
for the interested, the current patches are here:
http://jumi.lut.fi/~paalanen/scratch/mmio25/
Ps. I tested x86/mm version of mmiotrace on my 64-bit system and it seems
to work ok. I had to write a simple test module because I did not have any
drivers that a) called ioremap, b) were not broken on x86/mm, and c) I
had the hardware to actually use it. So this testing is very light.
--
Pekka Paalanen
http://www.iki.fi/pq/
--
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/
Powered by blists - more mailing lists