Subject: [PATCH] print v9fs module address
From: Latchesar Ionkov <[email protected]>
Date: 1141313037 -0500
This patch prints v9fs module address when the module is initialized. It is
useful to have it in the logs -- if the kernel crashes the address can be
used together with the oops print to find out the exact place (presumably in
the v9fs code) that cause the oops.
Signed-off-by: Latchesar Ionkov <[email protected]>
Signed-off-by: Eric Van Hensbergen <[email protected]>
---
fs/9p/v9fs.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
3e12299e1cd1582b67aa57ff9b445e9af61a4701
diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index daf623c..321989a 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -455,10 +455,15 @@ extern int v9fs_error_init(void);
static int __init init_v9fs(void)
{
int ret;
+ void *mcore;
+
+ mcore = NULL;
+ if (THIS_MODULE)
+ mcore = THIS_MODULE->module_core;
v9fs_error_init();
- printk(KERN_INFO "Installing v9fs 9P2000 file system support\n");
+ printk(KERN_INFO "Installing v9fs 9P2000 file system support %p\n", mcore);
ret = v9fs_mux_global_init();
if (!ret)
--
1.1.0
On Fri, Mar 17, 2006 at 07:09:14PM +0000, Eric Van Hensbergen wrote:
> Subject: [PATCH] print v9fs module address
> From: Latchesar Ionkov <[email protected]>
> Date: 1141313037 -0500
>
> This patch prints v9fs module address when the module is initialized. It is
> useful to have it in the logs -- if the kernel crashes the address can be
> used together with the oops print to find out the exact place (presumably in
> the v9fs code) that cause the oops.
NACK.
This just clutters the log. The information is provided in /proc/modules
for all modules.
Christoph Hellwig <[email protected]> wrote:
>
> On Fri, Mar 17, 2006 at 07:09:14PM +0000, Eric Van Hensbergen wrote:
> > Subject: [PATCH] print v9fs module address
> > From: Latchesar Ionkov <[email protected]>
> > Date: 1141313037 -0500
> >
> > This patch prints v9fs module address when the module is initialized. It is
> > useful to have it in the logs -- if the kernel crashes the address can be
> > used together with the oops print to find out the exact place (presumably in
> > the v9fs code) that cause the oops.
>
> NACK.
>
> This just clutters the log. The information is provided in /proc/modules
> for all modules.
But it's not printed out in an oops record and it can be hard to read
/proc/modules when the kernel is dead.
That being said...
If we really want this info then it should be printed out by the oops code,
where it prints the names of all the loaded modules - add "(0xc0123456)"
after each module name.
But I can't say I've ever felt a need for this feature - the symbolic info
in the oops trace tells you function_name+0xoffset/0xsize [*] which is
sufficient info for debugging.
IOW: what's the use case here, Eric?
[*] unless it's x86_64, which randomly prints some of these things in
decimal or sanskrit or something.
Yes, it looks like funciton_name+0xoffset is enough for debugging. We can
even calculate the module address if we need it.
You can ignore the patch.
Thanks,
Lucho
On Fri, Mar 17, 2006 at 01:03:11PM -0800, Andrew Morton said:
> Christoph Hellwig <[email protected]> wrote:
> >
> > On Fri, Mar 17, 2006 at 07:09:14PM +0000, Eric Van Hensbergen wrote:
> > > Subject: [PATCH] print v9fs module address
> > > From: Latchesar Ionkov <[email protected]>
> > > Date: 1141313037 -0500
> > >
> > > This patch prints v9fs module address when the module is initialized. It is
> > > useful to have it in the logs -- if the kernel crashes the address can be
> > > used together with the oops print to find out the exact place (presumably in
> > > the v9fs code) that cause the oops.
> >
> > NACK.
> >
> > This just clutters the log. The information is provided in /proc/modules
> > for all modules.
>
> But it's not printed out in an oops record and it can be hard to read
> /proc/modules when the kernel is dead.
>
> That being said...
>
> If we really want this info then it should be printed out by the oops code,
> where it prints the names of all the loaded modules - add "(0xc0123456)"
> after each module name.
>
> But I can't say I've ever felt a need for this feature - the symbolic info
> in the oops trace tells you function_name+0xoffset/0xsize [*] which is
> sufficient info for debugging.
>
> IOW: what's the use case here, Eric?
>
>
>
> [*] unless it's x86_64, which randomly prints some of these things in
> decimal or sanskrit or something.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> V9fs-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/v9fs-developer