It turns out the gcc option -Wframe-larger-than=<size> which I recently
added to the build system is not supported in older versions of gcc.
Since this is just a flag to ensure I keep stack usage under control
I've added a configure check to detect if gcc supports it. If it's
available we use it in the proper places, if it's not we don't.
For all module/library functions ensure so stack frame exceeds 1024
bytes. Ideally this should be set lower to say 512 bytes but there
are still numerous functions which exceed even this limit. For now
this is set to 1024 to ensure we catch the worst offenders.
Additionally, set the limit for ztest to 1024 bytes since the idea
here is to catch stack issues in user space before we find them by
overrunning a kernel stack. This should also be reduced to 512
bytes as soon as all the trouble makes are fixed.
Finally, add -fstack-check to gcc build options when --enable-debug
is specified at configure time. This ensures that each page on the
stack will be touched and we will generate a segfault on stack
overflow.
Over time we can gradually fix the following functions:
536 zfs:dsl_deadlist_regenerate
536 zfs:dsl_load_sets
536 zfs:zil_parse
544 zfs:zfs_ioc_recv
552 zfs:dsl_deadlist_insert_bpobj
552 zfs:vdev_dtl_sync
584 zfs:copy_create_perms
608 zfs:ddt_class_contains
608 zfs:ddt_prefetch
608 zfs:__dprintf
616 zfs:ddt_lookup
648 zfs:dsl_scan_ddt
696 zfs:dsl_deadlist_merge
736 zfs:ddt_zap_walk
744 zfs:dsl_prop_get_all_impl
872 zfs:dnode_evict_dbufs
This include updating all the Makefile.am to have the correct
include paths and libraries. In addition, the zlib m4 macro was
updated to more correctly integrate with the Makefiles. And I
added two new macros libblkid and libuuid which will be needed by
subsequent commits for blkid and uuid support respectively. The
blkid support is optional, the uuid support is mandatory for libefi.
Brian Behlendorf