[Crash-utility] crash-4.0-3.14-sym.3.patch (was: modules and data /bss initialization)

Castor Fu castor.fu at 3pardata.com
Thu Dec 28 01:24:07 UTC 2006 

Hi Dave!
 
Sorry about the regression.
 
I looked further through the code, and have modified it to only add the
symbols
for which it has actually identified a matching section, and to do it in
a way
which supports whatever sections are defined.
 
This doesn't explain why a match isn't being found in the ia64 case, but
should
at least avoid the regression in the s390x case.
 
I've also attached a test which one could run which dumps output which
might
help me fix things by tracing through loading the 'md5' module.  
 
By default the new code is off, as requested, and can be forced with
a '-l' option to 'mod', e.g.
 
crash> mod -l -s md5
 
Thanks again for the testing, and hopefully this will work for most
people.
 
It would be great if someone could send me output from the rarer
platforms like ppc64 or 390 if it doesn't work.
 
Happy New Year!
 
    -castor
 
 

________________________________

From: crash-utility-bounces at redhat.com
[mailto:crash-utility-bounces at redhat.com] On Behalf Of Dave Anderson
Sent: Tuesday, December 19, 2006 7:44 AM
To: crash-utility at redhat.com; Castor Fu
Subject: [Crash-utility] crash-4.0-3.14-sym.3.patch (was: modules and
data /bss initialization)


  
Hi Castor, 

While I have had some success with this patch on x86 and 
x86_64 machines, I haven't been so fortunate with other 
architectures. 

On ia64 machines for example, it quite often is unable 
to determine the .data segment address of a module, leaving 
it as 0, so there is no improvement over the current way it works. 

On the s390x, it actually causes a pretty serious regression. 
For example without the patch, here are the data addresses 
of the ext3 module before and after it gets loaded: 

$ /usr/bin/crash -s vmlinux-2.6.18-1.2767.el5 
crash> sym -m ext3 | grep "([dD])" 
208bfea0 (d) ext3_dir_operations 
208bff88 (d) ext3_file_operations 
208c0070 (d) ext3_ordered_aops 
208c00e0 (d) ext3_writeback_aops 
208c0150 (d) ext3_journalled_aops 
208c01c0 (d) ext3_xattr_handler_map 
208c01f8 (d) ext3_file_inode_operations 
208c02a0 (d) ext3_dir_inode_operations 
208c0348 (d) ext3_special_inode_operations 
208c03f0 (d) ext3_fs_type 
208c0430 (d) ext3_sops 
208c04d8 (d) ext3_export_ops 
208c0508 (d) ext3_qctl_operations 
208c0560 (d) ext3_quota_operations 
208c05c0 (d) ext3_symlink_inode_operations 
208c0668 (d) ext3_fast_symlink_inode_operations 
208c0710 (d) ext3_xattr_handlers 
208c0740 (d) tokens 
208c0a40 (d) ext3_xattr_user_handler 
208c0a60 (d) ext3_xattr_trusted_handler 
208c0a80 (d) ext3_xattr_acl_access_handler 
208c0aa0 (d) ext3_xattr_acl_default_handler 
208c0ac0 (d) ext3_xattr_security_handler 
208c0b00 (d) __this_module 
crash> mod -s ext3 
     MODULE       NAME                  SIZE  OBJECT FILE 
        208c0b00  ext3                200208
/lib/modules/2.6.18-1.2767.el5/kernel/fs/ext3/ext3.ko 
crash> sym -m ext3 | grep "([dD])" 
208bfea0 (d) ext3_dir_operations 
208bff88 (d) ext3_file_operations 
208c0070 (d) ext3_ordered_aops 
208c00e0 (d) ext3_writeback_aops 
208c0150 (d) ext3_journalled_aops 
208c01c0 (d) ext3_xattr_handler_map 
208c01f8 (d) ext3_file_inode_operations 
208c02a0 (d) ext3_dir_inode_operations 
208c0348 (d) ext3_special_inode_operations 
208c03f0 (d) ext3_fs_type 
208c0430 (d) ext3_sops 
208c04d8 (d) ext3_export_ops 
208c0508 (d) ext3_qctl_operations 
208c0560 (d) ext3_quota_operations 
208c05c0 (d) ext3_symlink_inode_operations 
208c0668 (d) ext3_fast_symlink_inode_operations 
208c0710 (d) ext3_xattr_handlers 
208c0740 (d) tokens 
208c0a40 (d) ext3_xattr_user_handler 
208c0a60 (d) ext3_xattr_trusted_handler 
208c0a80 (d) ext3_xattr_acl_access_handler 
208c0aa0 (d) ext3_xattr_acl_default_handler 
208c0ac0 (d) ext3_xattr_security_handler 
208c0b00 (d) __this_module 
crash> 

That looks fine... 

However, with the patch applied, I get the following behavior: 

$ crash*14/crash -s vmlinux-2.6.18-1.2767.el5 
crash> sym -m ext3 | grep "([dD])" 
208bfea0 (d) ext3_dir_operations 
208bff88 (d) ext3_file_operations 
208c0070 (d) ext3_ordered_aops 
208c00e0 (d) ext3_writeback_aops 
208c0150 (d) ext3_journalled_aops 
208c01c0 (d) ext3_xattr_handler_map 
208c01f8 (d) ext3_file_inode_operations 
208c02a0 (d) ext3_dir_inode_operations 
208c0348 (d) ext3_special_inode_operations 
208c03f0 (d) ext3_fs_type 
208c0430 (d) ext3_sops 
208c04d8 (d) ext3_export_ops 
208c0508 (d) ext3_qctl_operations 
208c0560 (d) ext3_quota_operations 
208c05c0 (d) ext3_symlink_inode_operations 
208c0668 (d) ext3_fast_symlink_inode_operations 
208c0710 (d) ext3_xattr_handlers 
208c0740 (d) tokens 
208c0a40 (d) ext3_xattr_user_handler 
208c0a60 (d) ext3_xattr_trusted_handler 
208c0a80 (d) ext3_xattr_acl_access_handler 
208c0aa0 (d) ext3_xattr_acl_default_handler 
208c0ac0 (d) ext3_xattr_security_handler 
208c0b00 (d) __this_module 
crash> mod -s ext3 
     MODULE       NAME                  SIZE  OBJECT FILE 
        208c0b00  ext3                200208
/lib/modules/2.6.18-1.2767.el5/kernel/fs/ext3/ext3.ko 
crash> sym -m ext3 | grep "([dD])" 
0 (D) __this_module 
0 (D) ext3_dir_operations 
0 (D) ext3_file_inode_operations 
0 (d) tokens 
a8 (D) ext3_dir_inode_operations 
e8 (D) ext3_file_operations 
150 (D) ext3_special_inode_operations 
1d0 (d) ext3_ordered_aops 
1f8 (d) ext3_fs_type 
238 (d) ext3_sops 
240 (d) ext3_writeback_aops 
2b0 (d) ext3_journalled_aops 
2e0 (d) ext3_export_ops 
300 (D) ext3_xattr_user_handler 
310 (d) ext3_qctl_operations 
320 (d) ext3_xattr_handler_map 
320 (D) ext3_xattr_trusted_handler 
340 (D) ext3_xattr_acl_access_handler 
360 (D) ext3_xattr_acl_default_handler 
368 (d) ext3_quota_operations 
380 (D) ext3_xattr_security_handler 
3c8 (D) ext3_symlink_inode_operations 
470 (D) ext3_fast_symlink_inode_operations 
518 (D) ext3_xattr_handlers 
crash> 

I haven't been able to test it on a ppc64 or s390.  (That's 
why I asked for help from others on the mailing list to test 
it out, but I didn't get any takers...) 

In any case, as much as I like what the patch wants to do, 
I can't accept it given such a serious regression.  Perhaps 
it could be made an experimental run-time option that could 
be turned on prior to doing any "mod" commands, leaving the 
current behaviour in place by default? 

Thanks, 
  Dave 
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20061227/65270803/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash-4.0-3.16-sym.patch
Type: application/octet-stream
Size: 18316 bytes
Desc: crash-4.0-3.16-sym.patch
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20061227/65270803/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: symtest
Type: application/octet-stream
Size: 359 bytes
Desc: symtest
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20061227/65270803/attachment-0001.obj>

More information about the Crash-utility mailing list