Description of problem: SystemTap cannot compile on kernel 4.4-rc1 due to: commit 71baba4b92d ("mm, page_alloc: rename __GFP_WAIT to __GFP_RECLAIM") https://git.kernel.org/torvalds/c/71baba4b92d Version-Release number of selected component (if applicable): Issue seen on both RHEL7.2 and Fedora 22 How reproducible: 100% Steps to Reproduce: 1. Compile and install a kernel >= version 4.4-rc1 2. Run stab 3. See compile failure Actual results: Compile error In file included from /usr/share/systemtap/runtime/linux/runtime.h:207:0, from /usr/share/systemtap/runtime/runtime.h:24, from /tmp/stapvikZbq/stap_43db91fb0a675d433d4d903abbdc04ef_3737_src.c:25: /usr/share/systemtap/runtime/linux/alloc.c: In function ‘_stp_kmalloc’: /usr/share/systemtap/runtime/linux/alloc.c:19:8: error: ‘__GFP_WAIT’ undeclared (first use in this function) & ~__GFP_WAIT) ^ /usr/share/systemtap/runtime/linux/alloc.c:283:32: note: in expansion of macro ‘STP_ALLOC_FLAGS’ return _stp_kmalloc_gfp(size, STP_ALLOC_FLAGS); ^ /usr/share/systemtap/runtime/linux/alloc.c:19:8: note: each undeclared identifier is reported only once for each function it appears in & ~__GFP_WAIT) ^
My workaround is to add the following text to /usr/share/systemtap/runtime/linux/runtime_defines.h: ==== #ifndef __GFP_WAIT #define __GFP_WAIT __GFP_RECLAIM #endif ==== On RHEL7, I'm also adding the workaround mentioned in Bug 1240682 comment #2
Looks like __GFP_WAIT was removed in the following kernel commit: ==== commit 71baba4b92dc1fa1bc461742c6ab1942ec6034e9 Author: Mel Gorman <mgorman> Date: Fri Nov 6 16:28:28 2015 -0800 mm, page_alloc: rename __GFP_WAIT to __GFP_RECLAIM __GFP_WAIT was used to signal that the caller was in atomic context and could not sleep. Now it is possible to distinguish between true atomic context and callers that are not willing to sleep. The latter should clear __GFP_DIRECT_RECLAIM so kswapd will still wake. As clearing __GFP_WAIT behaves differently, there is a risk that people will clear the wrong flags. This patch renames __GFP_WAIT to __GFP_RECLAIM to clearly indicate what it does -- setting it allows all reclaim activity, clearing them prevents it. ==== In addition, GFP_IOFS was removed by the following kernel commit: ==== commit 40113370836e8e79befa585277296ed42781ef31 Author: Mel Gorman <mgorman> Date: Fri Nov 6 16:28:25 2015 -0800 mm: page_alloc: remove GFP_IOFS GFP_IOFS was intended to be shorthand for clearing two flags, not a set of allocation flags. There is only one user of this flag combination now and there appears to be no reason why Lustre had to be protected from reclaim stalls. As none of the sites appear to be atomic, this patch simply deletes GFP_IOFS and converts Lustre to using GFP_KERNEL, GFP_NOFS or GFP_NOIO as appropriate. ==== The following upstream commit seems to fix both problems: 3d01029 <https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=3d010295efd215cf83a7d07eecf89137973c154a> I tested this on rawhide (4.4.0-0.rc2.git2.1.fc24.x86_64). Thanks for the bug report and fix.
hi, this is also happening on f23; what's NEXTRELEASE referring to, next release of fedora or next release of systemtap?
steubens, this being a fedora/rhel bug tracker, we ensure that released version of the systemtap packages work with the released versions of the kernel. For newer-than-released kernels, such as in rawhide, one should use the rawhide (pre-release) version of systemtap, which does work.
ah, i see; i'm using a kernel from updates-testing, it is 4.4.2; but the one in updates is 4.2.3 thanks
Are there plans to push an updated systemtap package for f23? kernel-4.4.5-300 is now in updates-testing for this release and there does not appear to be a corresponding systemtap package in that repo yet. I can test with a rawhide/f24 build but it would be good to get this into updates some time; happy to file an f23 bug if needed.
Unfortunately using f24 packages in f23 is not an option as the versions of libdyninstAPI, libncurses, libsymtabAPI, and libtinfo are not compatible: error: Failed dependencies: libdyninstAPI.so.9.1()(64bit) is needed by systemtap-runtime-3.0-0.20160208git40ae3a7.fc24.x86_64 libncurses.so.6()(64bit) is needed by systemtap-runtime-3.0-0.20160208git40ae3a7.fc24.x86_64 libsymtabAPI.so.9.1()(64bit) is needed by systemtap-runtime-3.0-0.20160208git40ae3a7.fc24.x86_64 libtinfo.so.6()(64bit) is needed by systemtap-runtime-3.0-0.20160208git40ae3a7.fc24.x86_64
We're expecting to release a systemtap version next week. The rawhide systemtap.src rpm - a pre-release git snapshot - would work fine on f23/f24 users in the interim. I'll send a -testing-only build into koji.
Duh.. Thanks. Didn't spot the full release tag & didn't realise the current f24 builds were using an unreleased systemtap snapshot. I've rebuilt the f24 dist-git branch for f23's libs, for x86_64 and i686: https://koji.fedoraproject.org/koji/taskinfo?taskID=13367970 Light local testing hasn't revealed any problems.