From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Westphal Subject: Re: [RFC PATCH v2 net-next 07/12] net: ipv4: listified version of ip_rcv Date: Wed, 27 Jun 2018 14:32:25 +0200 Message-ID: <20180627123225.kxtkncoygl4sgalj@breakpoint.cc> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-net-drivers@solarflare.com, netdev@vger.kernel.org, davem@davemloft.net To: Edward Cree Return-path: Received: from Chamillionaire.breakpoint.cc ([146.0.238.67]:39336 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753209AbeF0Mc2 (ORCPT ); Wed, 27 Jun 2018 08:32:28 -0400 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Edward Cree wrote: > Also involved adding a way to run a netfilter hook over a list of packets. > Rather than attempting to make netfilter know about lists (which would be > a major project in itself) we just let it call the regular okfn (in this > case ip_rcv_finish()) for any packets it steals, and have it give us back > a list of packets it's synchronously accepted (which normally NF_HOOK > would automatically call okfn() on, but we want to be able to potentially > pass the list to a listified version of okfn().) okfn() is only used during async reinject in NFQUEUE case, skb is queued in kernel and we'll wait for a verdict from a userspace process. If thats ACCEPT, then okfn() gets called to reinject the skb into the network stack. A normal -j ACCEPT doesn't call okfn in the netfilter core, which is why this occurs on '1' retval in NF_HOOK(). Only other user of okfn() is bridge netfilter, so listified version of okfn() doesn't make too much sense to me, its not used normally (unless such listified version makes the code simpler of course). AFAICS its fine to unlink/free skbs from the list to handle drops/queueing etc. so a future version of nf_hook() could propagate the list into nf_hook_slow and mangle the list there to deal with hooks that steal/drop/queue skbs. Later on we can pass the list to the hook functions themselves. We'll have to handle non-accept verdicts in-place in the hook functions for this, but fortunately most hookfns only return NF_ACCEPT so I think it is manageable. I'll look into this once the series makes it to net-next.