From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ACF7CC43387 for ; Sun, 6 Jan 2019 17:56:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7934C20868 for ; Sun, 6 Jan 2019 17:56:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546797374; bh=LkJFDt3FzVKUsJm+sZSZB+V2+xg76xEqyqpVyz31SBs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=QHtl9Hp1KEaAjq1FMQgmJLv/Aq9PIEWjJ+OeVa9DU4PT2A55dcxONx7ssXjDeAXkj WBpgKOODO5ZPfa7cImaqZS9GcPIA1Eu7RCVVI9KT5+JNyuJgEvc8xnkblxi5XZvnSh hZlgFB3brw5kk3v+rvFMdb+lin8cZ9tnPICjQfUs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726041AbfAFR4N (ORCPT ); Sun, 6 Jan 2019 12:56:13 -0500 Received: from mail.kernel.org ([198.145.29.99]:36554 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726012AbfAFR4N (ORCPT ); Sun, 6 Jan 2019 12:56:13 -0500 Received: from localhost (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B870F20859; Sun, 6 Jan 2019 17:56:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546797372; bh=LkJFDt3FzVKUsJm+sZSZB+V2+xg76xEqyqpVyz31SBs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bJ/rI4fyXnHxcU34hTdku/oWUqXIG6vMt05G9GVvFdtUIBOjMe/J1YEeRaZeRQtCb aZWrhg5utkv3/O71G2MKf6fDR+P4qdg6TjPK0iIocJs6XKRBOIiarEF/rhRzXJqkIs iaVftx9jvSCDijcmwddtBRXrBvEE1ClOU9xctyew= Date: Sun, 6 Jan 2019 12:56:10 -0500 From: Sasha Levin To: Mauricio Faria de Oliveira Cc: stable@vger.kernel.org, netdev@vger.kernel.org, Florian Westphal , Alakesh Haloi , nivedita.singhvi@canonical.com, Pablo Neira Ayuso , Jozsef Kadlecsik , "David S. Miller" , Yi-Hung Wei Subject: Re: [PATCH v2 4.14 0/5] netfilter: xt_connlimit: backport upstream fixes for race in connection counting Message-ID: <20190106175610.GE166797@sasha-vm> References: <20190102204204.12389-1-mfo@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20190102204204.12389-1-mfo@canonical.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Wed, Jan 02, 2019 at 06:41:59PM -0200, Mauricio Faria de Oliveira wrote: >From: Ubuntu > >[changelog] > - v2: include patch 5/5 (a very recent fix to patch 4/5) which is > not yet in Linus's tree but it's in nf.git + linux-next.git, > thus should make it shortly. Test results still consistent. > Thanks Florian Westphal for reviewing and pointing that out. > >Recently, Alakesh Haloi reported the following issue [1] with stable/4.14: > > """ > An iptable rule like the following on a multicore systems will result in > accepting more connections than set in the rule. > > iptables -A INPUT -p tcp -m tcp --syn --dport 7777 -m connlimit \ > --connlimit-above 2000 --connlimit-mask 0 -j DROP > """ > >And proposed a fix that is not in Linus's tree. The discussion went on to >confirm whether the issue was still reproducible with mainline/nf.git tip, >and to either identify the upstream fix or re-submit the non-upstream fix. > >Alakesh eventually was able to test with upstream, and reported that issue >was still reproducible [2]. >On that, our findinds diverge, at least in my test environment: > >First, I verified that the suggested mainline fix for the issue [3] indeed >fixes it, by testing with it applied and reverted on v4.18, a clean revert. >(The issue is reproducible with the commit reverted). > >Then, with a consistent reproducer, I moved to nf.git, with HEAD on commit >a007232 ("netfilter: nf_conncount: fix argument order to find_next_bit"), >and the issues was not reproducible (even with 20+ threads on client side, >the number Alakesh reported to achieve 2150+ connections [4], and I tried >spreading the network interface IRQ affinity over more and more CPUs too.) > >Either way, the suggested mainline fix does actually fix the issue in 4.14 >for at least one environment. So, it might well be the case that Alakesh's >test environment has differences/subtleties that leads to more connections >accepted, and more commits are needed for that particular environment type. > >(v2 update: see Florian's reply to v1 thread [1]; these different results > are probably explained by very recent fixes still missing back then.) > >But for now, with one bare-metal environment (24-core server, 4-core client) >verified, I thought of submitting the patches for review/comments/testing, >then looking for additional fixes for that environment separately. > >The fix is PATCH 4 (needs fix in PATCH 5), and PATCHes 1-3 are helpers for >a cleaner backport. >All backports are simple, and essentially consist of refresh context lines >and use older struct/file names. > >Reviews from netfilter maintainers are very appreciated, as I've no previous >experience in this area, and although the backports look simple and build/run >correctly, there's usually stuff that only more experienced people may notice. Queued for 4.14, thank you. -- Thanks, Sasha