Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755731AbdIGS0G (ORCPT ); Thu, 7 Sep 2017 14:26:06 -0400 Received: from mx0a-00190b01.pphosted.com ([67.231.149.131]:51302 "EHLO mx0a-00190b01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751385AbdIGS0E (ORCPT ); Thu, 7 Sep 2017 14:26:04 -0400 Subject: Re: xt_hashlimig build error (was Re: [RFC 01/17] x86/asm/64: Remove the restore_c_regs_and_iret label) To: Linus Torvalds , Ingo Molnar , Igor Lubashev , Josh Hunt , Pablo Neira Ayuso Cc: Borislav Petkov , Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , Brian Gerst , Andrew Cooper , Juergen Gross , Boris Ostrovsky , Kees Cook , Andrew Morton , "David S. Miller" , Pablo Neira Ayuso References: From: Vishwanath Pai Message-ID: <69b38985-e094-ddcc-6f7e-d6e5cc2c657e@akamai.com> Date: Thu, 7 Sep 2017 14:25:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-07_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709070271 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-07_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709070270 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1802 Lines: 51 On 09/07/2017 01:51 PM, Linus Torvalds wrote: > On Thu, Sep 7, 2017 at 3:29 AM, Ingo Molnar 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