On Fri, Dec 02, 2016 at 02:07:46AM +0000, Ben Hutchings wrote: > Thanks for this; I've applied it to the master branch for Debian.
Cool! Alas, it is enough only for x86. The merge that caused these issues was 84d6984 (pulling in 22823ab4^..590abbdd), you can see it does the same to a number of other archs. These are: x86 alpha m68k s390 arm ppc sparc ia64 Mainline does include fixes for ppc and arm. For extant Debian architectures this means these need to be checked: * first class: s390x * second class: alpha m68k sparc64 Second-class ports don't care that much for stable kernels as they don't have stables, thus waiting for whatever comes up in 4.10 might be an option, but porters deserve a heads-up at the very least. This leaves s390x. I don't happen to own a s390 machine, porterboxes are no good for testing module loading, I hear setting it up on qemu-system is not trivial. Ben, I don't imagine you not having some kind of a test setup -- could you check whether modules load with CONFIG_MODVERSIONS=y? It's not the kind of problem we'd want to face even in unstable. As for archs not on the above list, I've checked[1] that at least arm64 appears to work fine as of v4.9-rc7. > After comparing all the symbols potentially exported from assembly with > those declared in asm-prototypes.h, I found that cmpxchg8b_emu is > missing. This is only defined when building for 486 so it doesn't > affect Debian, but you may want to add that if you resubmit this > upstream. Thanks for noticing! I looked at, and tested, only amd64 -- and 486 are not exactly in wide use anymore. Meow! [1]. For the values of "checked" of: built it on unstable on Pine64 (my only arm64 machine, a crap little SoC that's not mainlined yet -- Icenowy's patch set allows running modern kernels) and loaded a bunch of random modules. -- The bill declaring Jesus as the King of Poland fails to specify whether the addition is at the top or end of the list of kings. What should the historians do?