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

Dave Anderson anderson at redhat.com
Tue Dec 19 15:44:17 UTC 2006


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/20061219/f1841ffd/attachment.htm>


More information about the Crash-utility mailing list