backport-4.7.c fails due to missing rhashtable.h for target < 3.17

backport-4.7.c fails due to missing rhashtable.h for target < 3.17

[Peter Huewe]

Hi,
playing around with backports,
unfortunately the backport code for 4.7 fails to compile if the target kernel is < 3.18.

make allyesconfig
make 
...
  CC [M]  /home/peter/linux-3-backport/compat/backport-4.7.o
In file included from /home/peter/linux-3-backport/backport-include/linux/rhashtable.h:3:0,
                 from /home/peter/linux-3-backport/compat/backport-4.7.c:14:
/home/peter/linux-3-backport/include/linux/rhashtable.h:3:35: fatal error: linux/rhashtable.h: No such file or directory.
compilation terminated.


The linux/rhashtable was introduced in 3.17,

The backport-4.7 has however
#include <linux/export.h>
#include <linux/list.h>
#include <linux/rcupdate.h>
#include <linux/rhashtable.h>
#include <linux/slab.h>
#include <linux/spinlock.h>

#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,1,0)



Does the rhashtable.h need to be include-guarded somehow ? (e.g. moving the if LINUX_VERSION_CODE up and maybe even changing it to 3.17?).

Or do we have to add rhashtable.h to the copy-list?

Thanks,
Peter
--
To unsubscribe from this list: send the line "unsubscribe backports" in

re: backport-4.7.c fails due to missing rhashtable.h for target < 3.17

[Peter Huewe]

ckmake says the same

1   3.0.101             [  FAIL  ]
2   3.1.10              [  FAIL  ]
3   3.2.81              [  FAIL  ]
4   3.3.8               [  FAIL  ]
5   3.4.112             [  FAIL  ]
6   3.5.7               [  FAIL  ]
7   3.6.11              [  FAIL  ]
8   3.7.10              [  FAIL  ]
9   3.8.13              [  FAIL  ]
10  3.9.11              [  FAIL  ]
11  3.10.102            [  FAIL  ]
12  3.11.10             [  FAIL  ]
13  3.12.61             [  FAIL  ]
14  3.13.11             [  FAIL  ]
15  3.14.73             [  FAIL  ]
16  3.15.10             [  FAIL  ]
17  3.16.36             [  FAIL  ]
18  3.17.8              [  OK  ]
19  3.18.36             [  OK  ]
20  3.19.8              [  OK  ]
21  4.0.9               [  OK  ]
22  4.1.27              [  OK  ]
23  4.2.8               [  OK  ]
24  4.3.6               [  OK  ]
25  4.4.14              [  OK  ]
26  4.5.7               [  OK  ]
27  4.6.3               [  OK  ]
28  4.7-rc6             [  OK  ]



Was this all green for you?


Do you think it makes sense to set up a small per-commit based build/compile test (e.g. with travis) to see whether commits really work?
(I probably could do something like that)

Thanks,
Peter
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: backport-4.7.c fails due to missing rhashtable.h for target < 3.17

[Luis R. Rodriguez]

On Thu, Aug 11, 2016 at 09:52:37AM +0200, Peter Huewe wrote:
> Hi,
> playing around with backports,
> unfortunately the backport code for 4.7 fails to compile if the target kernel is < 3.18.
> 
> make allyesconfig
> make 
> ...
>   CC [M]  /home/peter/linux-3-backport/compat/backport-4.7.o
> In file included from /home/peter/linux-3-backport/backport-include/linux/rhashtable.h:3:0,
>                  from /home/peter/linux-3-backport/compat/backport-4.7.c:14:
> /home/peter/linux-3-backport/include/linux/rhashtable.h:3:35: fatal error: linux/rhashtable.h: No such file or directory.
> compilation terminated.
> 
> 
> The linux/rhashtable was introduced in 3.17,
> 
> The backport-4.7 has however
> #include <linux/export.h>
> #include <linux/list.h>
> #include <linux/rcupdate.h>
> #include <linux/rhashtable.h>
> #include <linux/slab.h>
> #include <linux/spinlock.h>
> 
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,1,0)
> 
> 
> 
> Does the rhashtable.h need to be include-guarded somehow ? (e.g. moving the
> if LINUX_VERSION_CODE up and maybe even changing it to 3.17?).
> 
> Or do we have to add rhashtable.h to the copy-list?

The commit that added the backport is:

commit 0b879b047cd07cdde5bea835493d64c9f214c938
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Sun Jul 10 16:50:27 2016 +0200

    backports: add rhashtable_walk_init()
    
    Since commit 1068c678f "rhashtable: accept GFP flags in
    rhashtable_walk_init" rhashtable_walk_init() takes an additional
    parameter which is also used by the mac80211 code, so backport the
    function. For kernel < 4.1 this is not needed, because we already ship
    a recent version of rhashtable. Add rhashtable_walk_init() instead of
    adding the complete rhashtable to same some space on recent kernel
    versions.
    
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

So this backported only rhashtable_walk_init() with a new additional
argument and does so only for kernels >= 4.1 but not that backport-4.7.c
will not be required to be compiled on 4.7 so this is for [ 4.1..4.6 ].

It says that for kernels older than 4.1 this respective backport is not
needed as we ship a recent version of rhashtable for them. Indeed, this
was added via commit ba78c101455b85c58831c808e0f0cf0a12f2c76:

commit ba78c101455b85c58831c808e0f0cf0a12f2c760
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Apr 1 17:31:35 2015 +0200

    backports: include rhashtable
    
    As mac80211 now needs rhashtable, include it in backports.
    For now, it actually depends on mac80211 and is selected
    for kernels < 4.1 -- it existed in previous kernels but
    with different API, so cannot be used from there easily.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

The trick done via backport/compat/Kconfig to use:

+       #h-file linux/rhashtable.h
+       #c-file lib/rhashtable.c


Copies the header and code. It notes that the "current API"
was introduced as of 4.1, as such it only does this for
kernels which require new code added as of 4.1, so kernels
older than 4.1

If you are stuck in between 4.1 and 4.6 you are going to lack
the new added gfp flag, and that is what Hauke provided. It seems
Johannes work provides a full replacement of the rhash table stuff
for older kernels then, so what you describe and suggest seems to be
already done.

If this is failing to compile, indeed that would be an issue, and
is unexpected if it sin a stable releases, issues at compile time
should really only creep up if you are adding new code or are using
a really odd kernel configuration -- the compilation tests run through
ckmake are done with the config from the distribution, in this case
historically backports just relied on Ubuntu's kernel configuration
as Ubuntu was providing Vanilla kernels built, and that made our lives
easier. By using those kernels we then could just extract the kernel
headers and a sensible distro kernel configuration base.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: backport-4.7.c fails due to missing rhashtable.h for target < 3.17

[Luis R. Rodriguez]

On Thu, Aug 11, 2016 at 10:35:01AM +0200, Peter Huewe wrote:
> ckmake says the same
> 
> 1   3.0.101             [  FAIL  ]
> 2   3.1.10              [  FAIL  ]
> 3   3.2.81              [  FAIL  ]
> 4   3.3.8               [  FAIL  ]
> 5   3.4.112             [  FAIL  ]
> 6   3.5.7               [  FAIL  ]
> 7   3.6.11              [  FAIL  ]
> 8   3.7.10              [  FAIL  ]
> 9   3.8.13              [  FAIL  ]
> 10  3.9.11              [  FAIL  ]
> 11  3.10.102            [  FAIL  ]
> 12  3.11.10             [  FAIL  ]
> 13  3.12.61             [  FAIL  ]
> 14  3.13.11             [  FAIL  ]
> 15  3.14.73             [  FAIL  ]
> 16  3.15.10             [  FAIL  ]
> 17  3.16.36             [  FAIL  ]
> 18  3.17.8              [  OK  ]
> 19  3.18.36             [  OK  ]
> 20  3.19.8              [  OK  ]
> 21  4.0.9               [  OK  ]
> 22  4.1.27              [  OK  ]
> 23  4.2.8               [  OK  ]
> 24  4.3.6               [  OK  ]
> 25  4.4.14              [  OK  ]
> 26  4.5.7               [  OK  ]
> 27  4.6.3               [  OK  ]
> 28  4.7-rc6             [  OK  ]
> 
> 
> 
> Was this all green for you?

I leave it to Hauke and Johannes to respond but I typically
use ckmake per commit.

> Do you think it makes sense to set up a small per-commit based build/compile test (e.g. with travis) to see whether commits really work?
> (I probably could do something like that)

We need to run this prior to integration so the work needs to be done
by the developer. One thing we could do, since compilation tests take a
while is perhaps set up registering trees for testing so that then
something similar to 0-day can fetch and test for you and you get a report
of results. You then can rely on this prior to pushing patches.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe backports" in