Bug 1285348 - systemtap compile fail, reason __GFP_WAIT removed in kernel 4.4-rc1
systemtap compile fail, reason __GFP_WAIT removed in kernel 4.4-rc1
Product: Fedora
Classification: Fedora
Component: systemtap (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Frank Ch. Eigler
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-11-25 07:44 EST by Jesper Brouer
Modified: 2016-03-16 11:23 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-30 12:27:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jesper Brouer 2015-11-25 07:44:09 EST
Description of problem:

SystemTap cannot compile on kernel 4.4-rc1 due to:

 commit 71baba4b92d ("mm, page_alloc: rename __GFP_WAIT to __GFP_RECLAIM")

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)
Comment 1 Jesper Brouer 2015-11-25 07:55:57 EST
My workaround is to add the following text to

#ifndef __GFP_WAIT

On RHEL7, I'm also adding the workaround mentioned in Bug 1240682 comment #2
Comment 2 David Smith 2015-11-30 12:27:26 EST
Looks like __GFP_WAIT was removed in the following kernel commit:

commit 71baba4b92dc1fa1bc461742c6ab1942ec6034e9
Author: Mel Gorman <mgorman@techsingularity.net>
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@techsingularity.net>
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


I tested this on rawhide (4.4.0-0.rc2.git2.1.fc24.x86_64).

Thanks for the bug report and fix.
Comment 3 steubens 2016-02-26 21:26:00 EST
hi, this is also happening on f23; what's NEXTRELEASE referring to, next release of fedora or next release of systemtap?
Comment 4 Frank Ch. Eigler 2016-02-27 08:29:15 EST
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.
Comment 5 steubens 2016-02-27 13:44:06 EST
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

Comment 6 Bryn M. Reeves 2016-03-16 10:08:49 EDT
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.
Comment 7 Bryn M. Reeves 2016-03-16 10:23:21 EDT
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
Comment 8 Frank Ch. Eigler 2016-03-16 10:26:40 EDT
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.
Comment 9 Bryn M. Reeves 2016-03-16 11:23:32 EDT
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:


Light local testing hasn't revealed any problems.

Note You need to log in before you can comment on or make changes to this bug.