Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5139640pxb; Wed, 26 Jan 2022 05:46:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJyttNoJ3FUzrcWyq/TPPnjUqsQv4XlNHYYjg1CgOGQH0sMDW2YGUYA0hEgiBA6x0j1i79QL X-Received: by 2002:a63:171a:: with SMTP id x26mr18914845pgl.447.1643204806871; Wed, 26 Jan 2022 05:46:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643204806; cv=none; d=google.com; s=arc-20160816; b=oc0gbUfVQkU57nEBHZhjdluj5b7lQfguZNvGFsHzu3mmjnr9de8GVPdUtIJ9TrGY0B ohwcphaD/nPh7grZIGbBPxsb4+dAUK0D8ohJ+xTG2OAbsxdvNn6Hic6PIkmYIL0A8MCz vQxCS2KzFjHbdF5yhD3nribPm2V3+rStCEhRVuB4C7vgyGa9U59WTGm1OInu1uZd0hpJ mgsunuO7sN2Q4V4dtMkjlVNkpC+EZDSe7nEQteyRPMndpRFPqsYfpVyYeCV17ugYED+Z nHkFhS5C3YZFQEfmaqnhZjf38o/58FQbn7WO0j/ktx+7id8Rn8AKfvYRxfFL7KXWngXE Trng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=jWJKsjEg2FAQWE7F2aJw1hFat+BKcDx6urcZqeZPvkw=; b=KHHZDlMUTPu6ENi1WjYxctU+dt9RriU7hcVJwgKjAs+csGW6JGZcfOVhkzD7akERuC a3lcc/6HlVqOf+nwsbdu09WrOfbK8tLf40si1LrtnjjdpLqfsM4XGi6cgrM6I3YlAdl6 Uduppa5U1+JXo/zzrQtWUqTr6oP7diDtSNHmsqZWByZTomblUssDCWCbfPBn0zep6sLU co1gcx0Kp3iBI/09+i19wIC74L2NrYpOAS8G5RKXKwizm0xAJAFCmbtSNmuPf4bICGuX LCOVGI1ML+e+Ravtq8P+Kkj0NctxtCqKL6ZktuOd4KBE4Sb7k8pZsmbWgFkWxwLErFvs xl2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y143si1568757pfb.63.2022.01.26.05.46.33; Wed, 26 Jan 2022 05:46:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235436AbiAZAvw (ORCPT + 99 others); Tue, 25 Jan 2022 19:51:52 -0500 Received: from mail.netfilter.org ([217.70.188.207]:46010 "EHLO mail.netfilter.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234910AbiAZAvw (ORCPT ); Tue, 25 Jan 2022 19:51:52 -0500 Received: from netfilter.org (unknown [78.30.32.163]) by mail.netfilter.org (Postfix) with ESMTPSA id 9719B60254; Wed, 26 Jan 2022 01:48:47 +0100 (CET) Date: Wed, 26 Jan 2022 01:51:45 +0100 From: Pablo Neira Ayuso To: Jakub Kicinski Cc: menglong8.dong@gmail.com, rostedt@goodmis.org, mingo@redhat.com, davem@davemloft.net, yoshfuji@linux-ipv6.org, dsahern@kernel.org, kadlec@netfilter.org, fw@strlen.de, imagedong@tencent.com, edumazet@google.com, alobakin@pm.me, paulb@nvidia.com, pabeni@redhat.com, talalahmad@google.com, haokexin@gmail.com, keescook@chromium.org, memxor@gmail.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, cong.wang@bytedance.com Subject: Re: [PATCH net-next 1/6] net: netfilter: use kfree_drop_reason() for NF_DROP Message-ID: References: <20220124131538.1453657-1-imagedong@tencent.com> <20220124131538.1453657-2-imagedong@tencent.com> <20220125153214.180d2c09@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220125153214.180d2c09@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 25, 2022 at 03:32:14PM -0800, Jakub Kicinski wrote: > On Mon, 24 Jan 2022 21:15:33 +0800 menglong8.dong@gmail.com wrote: > > From: Menglong Dong > > > > Replace kfree_skb() with kfree_skb_reason() in nf_hook_slow() when > > skb is dropped by reason of NF_DROP. > > Netfilter folks, does this look good enough to you? > > Do you prefer to take the netfilter changes via your tree? I'm asking > because enum skb_drop_reason is probably going to be pretty hot so if > the patch is simple enough maybe no point dealing with merge conflicts. I also think it's easier if you take it through net.git. Thanks for asking.