From patchwork Fri Jun 4 15:17:29 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 454039 Delivered-To: patch@linaro.org Received: by 2002:a02:735a:0:0:0:0:0 with SMTP id a26csp508270jae; Fri, 4 Jun 2021 08:18:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzziW5kIO9sWDtZqn/f+zCm7CDGQGIJoFSUBebdk8PG6b8MZ9mMqq2e9/l1zlIj7nw3BoAm X-Received: by 2002:a17:906:cd27:: with SMTP id oz39mr4666239ejb.429.1622819924603; Fri, 04 Jun 2021 08:18:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622819924; cv=none; d=google.com; s=arc-20160816; b=XRk/lN2NpOb2evYQHfnTI4S6BagYLnRMi5MLBL1ioGU4OeqM0sh1suWYY/2DeMynmL EMhEKiJ9T3AiPRqVxG4gY8qKTU6mDCY3J1+IxMbUapDPay2tgHlsGM5aOkrOJl8XCKVs a7kdnXoRezzrmkfYlQ0MazcT0qH53yWSkSdL3YRa+61WWFSDPkzvbmo6MBT+moeYLXUm iZ7WbNL4RiUthtc3B6JcqyS1PrFpM/qiBCR+99vyqSwO5r34D1jTVpvcia9ZmsztdFMV HME+6d4g7TzqSw5Qq+3mdM3osiL6W8SFC96hf8aNJBSI3uFH9A6zm1e7q1abYXCiWIKF Gv5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=AwZdjbKF9le8V5qhs73EANVyYrWlAg30LtOuAvG4ItM=; b=oNFblwQFTPvYbPJ/9+ezz1cC1UowCQILgcPVqXV0PPAEuVT4ygrwaWGtp337A401aV VyuDl3OlS18y//dn/AaCNYeqqHr6tHay2+y9Tvtxr/mSLGyF3y+Bc3bmjgSw9wfesp5M Qby7IAAzFS9ZWmf8bFJqQkzda8GqUX9Mm91xL8ULtngcHptzyi+cq5kREhVahaudmbZN OGi/yqiX60LeAq7G1amrgiy/zCrfrjF1MK8Tt1yuaBwHN0z7q0zTi/ShsE28RGi/g55V POOW5TAeNBBsMILgPuSsDD2E7rLYLD/0E2skzUf0f6wqDIBRca6J4KvJQ53nIQzK1HNd yTIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=VYsc8Jos; spf=pass (google.com: domain of netdev-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=netdev-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zx2c4.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l15si4894987ejc.521.2021.06.04.08.18.44; Fri, 04 Jun 2021 08:18:44 -0700 (PDT) Received-SPF: pass (google.com: domain of netdev-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=VYsc8Jos; spf=pass (google.com: domain of netdev-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=netdev-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zx2c4.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230104AbhFDPTp (ORCPT + 8 others); Fri, 4 Jun 2021 11:19:45 -0400 Received: from mail.zx2c4.com ([104.131.123.232]:54916 "EHLO mail.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229692AbhFDPTp (ORCPT ); Fri, 4 Jun 2021 11:19:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1622819873; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=AwZdjbKF9le8V5qhs73EANVyYrWlAg30LtOuAvG4ItM=; b=VYsc8JosvXcUOT+DhAv6ASfQ4Ux0hsDfv29GqNOg0g01mv+k2sr09+MylzEDn5aVyxqC3Y ei6T/YIZGvCCmukIC+wx18t6Xgc3lkmKS3orUXRb7ffeQPokH4CnF2DxGT4h21jAbEUUfz gbkCV2e1kEZmfgxutnTBX5NCQf2Ybws= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id db6e493e (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 4 Jun 2021 15:17:52 +0000 (UTC) From: "Jason A. Donenfeld" To: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org Cc: "Jason A. Donenfeld" Subject: [PATCH net 0/9] wireguard fixes for 5.13-rc5 Date: Fri, 4 Jun 2021 17:17:29 +0200 Message-Id: <20210604151738.220232-1-Jason@zx2c4.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Dave/Jakub, Here are bug fixes to WireGuard for 5.13-rc5: 1-2,6) These are small, trivial tweaks to our test harness. 3) Linus thinks -O3 is still dangerous to enable. The code gen wasn't so much different with -O2 either. 4) We were accidentally calling synchronize_rcu instead of synchronize_net while holding the rtnl_lock, resulting in some rather large stalls that hit production machines. 5) Peer allocation was wasting literally hundreds of megabytes on real world deployments, due to oddly sized large objects not fitting nicely into a kmalloc slab. 7-9) We move from an insanely expensive O(n) algorithm to a fast O(1) algorithm, and cleanup a massive memory leak in the process, in which allowed ips churn would leave danging nodes hanging around without cleanup until the interface was removed. The O(1) algorithm eliminates packet stalls and high latency issues, in addition to bringing operations that took as much as 10 minutes down to less than a second. Thanks, Jason