stack bloat after stackprotector changes

Eric Sandeen sandeen at sandeen.net
Mon Oct 5 16:01:36 CDT 2009


It seems that after:

commit 5d707e9c8ef2a3596ed5c975c6ff05cec890c2b4
Author: Tejun Heo <tj at kernel.org>
Date:   Mon Feb 9 22:17:39 2009 +0900

    stackprotector: update make rules

xfs stack usage jumped up a fair bit;

before:
376 xfs_bmapi
328 xfs_bulkstat
296 _xfs_trans_commit
264 xfs_iomap_write_delay
248 xlog_do_recovery_pass
248 xfs_symlink
248 xfs_file_ioctl
232 xfs_bunmapi
224 xfs_trans_unreserve_and_mod_sb
216 xfs_file_compat_ioctl
216 xfs_cluster_write
216 xfs_bmap_del_extent
200 xfs_probe_cluster
200 xfs_page_state_convert
200 xfs_iomap_write_direct
200 xfs_getbmap
...

after:

408 xfs_bmapi
344 xfs_bulkstat
312 _xfs_trans_commit
312 xfs_file_ioctl
296 xfs_file_compat_ioctl
280 xfs_iomap_write_delay
264 xlog_do_recovery_pass
264 xfs_symlink
264 xfs_bunmapi
248 xfs_bmap_del_extent
248 xfs_bmap_add_extent_delay_real
240 xfs_trans_unreserve_and_mod_sb
232 xfs_iomap_write_direct
232 xfs_cluster_write
216 xfs_probe_cluster
216 xfs_bmap_extents_to_btree
...

Not a lot in each case but could be significant as it accumulates.

I'm not familiar w/ the gcc stack protector feature; would this be an
expected result?

Thanks,
-Eric




More information about the xfs mailing list