From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752586AbaBMWpP (ORCPT ); Thu, 13 Feb 2014 17:45:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:63304 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751937AbaBMWpM (ORCPT ); Thu, 13 Feb 2014 17:45:12 -0500 Message-ID: <52FD4AC0.7090502@redhat.com> Date: Thu, 13 Feb 2014 23:44:16 +0100 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "H. Peter Anvin" CC: Alexei Starovoitov , Ingo Molnar , "David S. Miller" , Steven Rostedt , Peter Zijlstra , Thomas Gleixner , Masami Hiramatsu , Tom Zanussi , Jovi Zhangwei , Eric Dumazet , Linus Torvalds , Andrew Morton , Frederic Weisbecker , Arnaldo Carvalho de Melo , Pekka Enberg , Arjan van de Ven , Christoph Hellwig , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters References: <1391649046-4383-1-git-send-email-ast@plumgrid.com> <52F3670D.5090608@redhat.com> <52FD47F9.2090907@zytor.com> In-Reply-To: <52FD47F9.2090907@zytor.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/13/2014 11:32 PM, H. Peter Anvin wrote: > On 02/06/2014 05:20 PM, Alexei Starovoitov wrote: >> >> I believe that old BPF outlived itself and BPF64 should >> replace it in all current use cases plus a lot more. >> It just cannot happen at once. >> BPF64 can come in. bpf32->bpf64 converter functioning. >> JIT from bpf64->aarch64 and may be sparc64 needs to be in place. >> Then old bpf can fade away. > > I don't think that is doable any time soon. Right now pretty much all > mobile devices, for example, are 32 bits and they really want to use > syscall filtering for security. Performance matters greatly there. Well, if that would be the case, then seccomp would have had JIT support long ago. ;-) Right now BPF filters with seccomp are not JIT compiled for _any_ architecture. > As such, 32-bit JIT support is going to be very important for a long > time to come. True, I think that pretty much depends if we can manage to find a way to cleanly integrate it into net/core/filter.c while still supporting the old instructions as I've mentioned earlier. > -hpa > >