Bug 1285348
| Summary: | systemtap compile fail, reason __GFP_WAIT removed in kernel 4.4-rc1 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jesper Brouer <jbrouer> |
| Component: | systemtap | Assignee: | Frank Ch. Eigler <fche> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | bmr, brolley, dsmith, fche, jistone, lberk, mjw, scox, steubens, wcohen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-30 17:27:26 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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) ^