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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 469E5C6FA8E for ; Fri, 3 Mar 2023 00:09:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229552AbjCCAJ3 (ORCPT ); Thu, 2 Mar 2023 19:09:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229487AbjCCAJ3 (ORCPT ); Thu, 2 Mar 2023 19:09:29 -0500 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:237:300::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6803636687 for ; Thu, 2 Mar 2023 16:09:28 -0800 (PST) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1pXszG-0005EU-Np; Fri, 03 Mar 2023 01:09:26 +0100 Date: Fri, 3 Mar 2023 01:09:26 +0100 From: Florian Westphal To: Major =?iso-8859-15?Q?D=E1vid?= Cc: Florian Westphal , netfilter-devel@vger.kernel.org, Pablo Neira Ayuso Subject: Re: CPU soft lockup in a spin lock using tproxy and nfqueue Message-ID: <20230303000926.GC9239@breakpoint.cc> References: <401bd6ed-314a-a196-1cdc-e13c720cc8f2@balasys.hu> <20230302142946.GB309@breakpoint.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org Major Dávid wrote: > Thanks, > > I builded and tested in my Jammy environment, and I could not reproduce > any soft lockups with this patch anymore. Thanks. > But I am also wondering that the inet_twsk_deschedule_put is really > needed in this particular case in tproxy? As I understand it, there > is an other independent mechanism which destroys tw sockets, so no > need do it here? Which one? As far as I can see TCP stack would end up adding a duplicate quadruple to the hash if we only drop the reference and keep the listen sk around. And if we assign the tw socket to the skb TCP stack might not be able to find the correct listener if the service is on a different port than what is in the TCP header. Did I miss anything?