Received: by 10.192.165.148 with SMTP id m20csp3236352imm; Mon, 7 May 2018 08:52:31 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoi5FrSnY7HwAghXrfuCaufc+GD2/zHjHAN8+6/EJBwBUr8ZPTu9ToDENlrSc5mlxBKNMVH X-Received: by 2002:a24:45a3:: with SMTP id c35-v6mr1802448itd.125.1525708351592; Mon, 07 May 2018 08:52:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525708351; cv=none; d=google.com; s=arc-20160816; b=G7Jp4WugrsoDuPnawkVDdayYoetLxgM806y1Q9QYzCtIT/G5NRcdGyG9COjsSEKxKY sxvu+2VIkZS8NZEuRS2nFVj86629xsueliDrfO3n0nVoUGsv9fUOKR9KVG1FmPuuDxck j5+dBr0e4vcz/hAUecbrQo7F1iHNoe3dyIKDrioHN10/WUlc3c/UYgmlhKFlImfyn2Vo DDY8YVQXGYJ2Y9kBaQK6X9Jo7CP3RXUwQWJ4nD6HfK3AFkovzfGXKjJQRbKNxG1bMafO adGuP8UTmjXp9aB7EM9XPP0jbEaCH3EHUGR/vXC1bz0JhC7uPmKrhdRHarLINL+QnByg q5hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date :arc-authentication-results; bh=JbSxfk+ikUPh2h6FS2MQiDBHt673XY5Oi2GTIgjvX4A=; b=tlpM1ubGm8HAzksEQGQO5oQO/ucNnFeIG8eYyYVvC54hodxHdViJq1QwU+B4ic9pzA 0xC9cXYImcFjS0mVJQR9MUM+aZ56yZVnYBkLQQwt2Vw8+M8SH6RiISKrI379uuUxtypk q2bprk4VywrtG4WRrNjCEGvcHWvMeyVNzYc3x7d2h/YCOJXWYYthoQMw/DqQUT0uvZad +dk4VwG5wNfUqfrLPHy9bnhAPPKXMLuSFYt+QGbHLNvt69p/krLeprU5fpK6ZcZhLlvL h0JS5UYtPCnWXWBtnkchcVT4XVzEoXU/iMEWnqRqDWrr6MHC/tX4fh8H4srO7x17gONT ay9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y62-v6si7542801itg.127.2018.05.07.08.52.17; Mon, 07 May 2018 08:52:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752545AbeEGPuk (ORCPT + 99 others); Mon, 7 May 2018 11:50:40 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:44214 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752051AbeEGPuj (ORCPT ); Mon, 7 May 2018 11:50:39 -0400 Received: from localhost (67.110.78.66.ptr.us.xo.net [67.110.78.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 1B26E136D5170; Mon, 7 May 2018 08:50:38 -0700 (PDT) Date: Mon, 07 May 2018 11:50:36 -0400 (EDT) Message-Id: <20180507.115036.2237866742963204693.davem@davemloft.net> To: laforge@gnumonks.org Cc: ast@kernel.org, daniel@iogearbox.net, torvalds@linux-foundation.org, gregkh@linuxfoundation.org, luto@amacapital.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module From: David Miller In-Reply-To: <20180507152435.GE19042@nataraja> References: <20180503043604.1604587-1-ast@kernel.org> <20180503043604.1604587-3-ast@kernel.org> <20180507152435.GE19042@nataraja> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Mon, 07 May 2018 08:50:38 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Harald Welte Date: Mon, 7 May 2018 17:24:35 +0200 > But if the ruleset loads but behaves different than before (because e.g. > it's executed from a completely different place in the stack), that's > IMHO an absolute no-go that must be avoided at all cost. That's not what we are doing nor proposing. I'm sorry if you are confused on this matter. The base implementation we strive for will execute the BPF programs from the existing netfilter hook points. However, if semantically the effect is equal if we execute the BPF program from XDP, we will allow that to happen as an optimization. The BPF exection is where it is in these patches for the purposes of bootstrapping the bpfilter project and easy testing/benchmarking/hacking. I hope this clears up your confusion. If you would like to become involved in hacking on bpfilter to help us ensure more accurate compatability between existing iptables and what bpfilter will execute for the same rule sets, we very much look forward to your contributions and expertiece. Thank you.