summaryrefslogtreecommitdiffstats
path: root/config/kernel-bio-end-io-t-args.m4
Commit message (Collapse)AuthorAgeFilesLines
* Eliminate runtime function pointer mods in autotools checksRichard Yao2013-03-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PaX/GrSecurity patched kernels implement a dialect of C that relies on a GCC plugin for enforcement. A basic idea in this dialect is that function pointers in structures should not change during runtime. This causes code that modifies function pointers at runtime to fail to compile in many instances. The autotools checks rely on whether or not small test cases compile against a given kernel. Some autotools checks assume some default case if other cases fail. When one of these autotools checks tests a PaX/GrSecurity patched kernel by modifying a function pointer at runtime, the default case will be used. Early detection of such situations is possible by relying on compiler warnings, which are compiler errors when --enable-debug is used. Unfortunately, very few people build ZFS with --enable-debug. The more common situation is that these issues manifest themselves as runtime failures in the form of NULL pointer exceptions. Previous patches that addressed such issues with PaX/GrSecurity compatibility largely relied on rewriting autotools checks to avoid runtime function pointer modification or the addition of PaX/GrSecurity specific checks. This patch takes the previous work to its logical conclusion by eliminating the use of runtime function pointer modification. This permits the removal of PaX-specific autotools checks in favor of ones that work across all supported kernels. This should resolve issues that were reported to occur with PaX/GrSecurity-patched Linux 3.7.5 kernels on Gentoo Linux. https://bugs.gentoo.org/show_bug.cgi?id=457176 We should be able to prevent future regressions in PaX/GrSecurity compatibility by ensuring that all changes to ZFSOnLinux avoid runtime function pointer modification. At the same time, this does not solve the issue of silent failures triggering default cases in the autotools check, which is what permitted these regressions to become runtime failures in the first place. This will need to be addressed in a future patch. Reported-by: Marcin MirosÅ‚aw <[email protected]> Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #1300
* Use -Werror for all kernel configure tests.Etienne Dechamps2013-02-241-3/+0
| | | | | | | | | | | | | As a matter of fact, we're already using -Werror for most tests because of a bug in kernel-bio-empty-barrier.m4 which sets -Werror without reverting it afterwards. This meant that all tests which ran after this one was using -Werror. This patch simply makes it clear that we're using -Werror and makes the code more readable and more predictable. Signed-off-by: Brian Behlendorf <[email protected]> Closes #1317
* Fix gcc configure warningsBrian Behlendorf2011-04-191-1/+1
| | | | | | | | | | | | | | | | | | Newer versions of gcc are getting smart enough to detect the sloppy syntax used for the autoconf tests. It is now generating warnings for unused/undeclared variables. Newer version of gcc even have the -Wunused-but-set-variable option set by default. This isn't a problem except when -Werror is set and they get promoted to an error. In this case the autoconf test will return an incorrect result which will result in a build failure latter on. To handle this I'm tightening up many of the autoconf tests to explicitly mark variables as unused to suppress the gcc warning. Remember, all of the autoconf code can never actually be run we just want to get a clean build error to detect which APIs are available. Never using a variable is absolutely fine for this. Closes #176
* Add build systemBrian Behlendorf2010-08-311-0/+29
Add autoconf style build infrastructure to the ZFS tree. This includes autogen.sh, configure.ac, m4 macros, some scripts/*, and makefiles for all the core ZFS components.