Re: ftrace 'failed to modify' bug when loading reiserfs.ko

[Dave Jones]

On Fri, Sep 06, 2013 at 09:32:52AM -0400, Steven Rostedt wrote:
 > On Thu, 5 Sep 2013 23:58:27 -0400
 > Dave Jones <davej@xxxxxxxxxx> wrote:
 > 
 > > On Thu, Sep 05, 2013 at 09:51:54PM -0400, Steven Rostedt wrote:
 > >  > On Thu, 5 Sep 2013 21:48:59 -0400
 > >  > Dave Jones <davej@xxxxxxxxxx> wrote:
 > >  > 
 > >  > > On Thu, Sep 05, 2013 at 09:44:55PM -0400, Steven Rostedt wrote:
 > >  > >  > On Thu, 5 Sep 2013 21:34:55 -0400
 > >  > >  > Dave Jones <davej@xxxxxxxxxx> wrote:
 > >  > >  > 
 > >  > >  > > On Thu, Sep 05, 2013 at 09:28:34PM -0400, Steven Rostedt wrote:
 > >  > 
 > >  > >  > Did you change a config option, or update your gcc?
 > >  > > 
 > >  > > Yeah, changed CONFIG_DEBUG_KOBJECT, which rebuilt the world.
 > >  > 
 > >  > Still doesn't explain why it gave you that splat there.
 > >  > 
 > >  > Do you still have that binary module, and can you show me what's at
 > >  > reiserfs_init_bitmap_cache+0x0 with objdump?
 > > 
 > > I didn't, but it turns out I can recreate this. A little convoluted but..
 > > 
 > > disable DEBUG_KOBJECT_RELEASE
 > > build, install and boot into kernel
 > > 
 > > enable DEBUG_KOBJECT_RELEASE
 > > build kernel
 > > install -> boom
 > 
 > Did it report failing on the same function as before?
 
Yes.

 > > 00000000000028b0 <reiserfs_init_bitmap_cache>:
 > > 
 > >         return bh;
 > > }
 > > 
 > > int reiserfs_init_bitmap_cache(struct super_block *sb)
 > > {
 > >     28b0:       e8 00 00 00 00          callq  28b5 <reiserfs_init_bitmap_cache+0x5>
 > 
 > That looks to be the call to fentry, but without being resolved. What
 > we saw in the previous report wasn't 0xe8 but 0x14, and it was
 > unresolved after loading!
 > 
 > I'm surprised that the module built with a different
 > DEBUG_KOBJECT_RELEASE config would load. Does it not affect module
 > versions?
 
# CONFIG_MODVERSIONS is not set


	Dave

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