On 09/07/2017 01:51 PM, Linus Torvalds wrote: > On Thu, Sep 7, 2017 at 3:29 AM, Ingo Molnar <[email protected]> wrote: >> >> not the best of kernels, 32-bit allyesconfig doesn't even appear to build: >> >> net/netfilter/xt_hashlimit.o: In function `hashlimit_mt_common.isra.6': >> xt_hashlimit.c:(.text+0x1146): undefined reference to `__udivdi3' > > I think this is due to commit bea74641e378 ("netfilter: xt_hashlimit: > add rate match mode"). > > It adds a 64-bit divide in user2rate_bytes() afaik, and to make things > worse it seems to be a really stupid one too. > > Although I guess "worse" is not bad when the stupidity of it should > mean that it's easy to avoid the 64-bit issue. > > Oddly, user2rate() that actually *does* need a 64-bit divide, seems to > do it right and use "div64_u64()" to do so. > > But user2rate_bytes() could easily avoid any 64-bit issues, since it > divides the max 32-bit (unsigned) number with a 64-bit unsigned > number. > > It would be easy to just say > > - "if high 32 bits are set, result is 0" > > - else do a 32-bit divide > > or just use "div64_u64()" in that code too. > > But honestly, that math is odd in other ways too (is that "r-1" > _supposed_ to underflow to -1 for large 'user' counts?), so somebody > needs to look at that logic. > > And there might be some other 64-bit divide I missed, so please, > netfilter people, check the 32-bit build. > > Linus >
Sorry about the build failure, we have already queued up a fix for this: https://patchwork.ozlabs.org/patch/810772/ I agree, this could've been easily avoided, I happened to overlook this particular line. There are other places in xt_hashlimit where we use 64bit division and I believe we have already covered those cases using div64_u64. - Vishwanath
