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 X-Spam-Level: X-Spam-Status: No, score=-3.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D276C282C8 for ; Mon, 28 Jan 2019 20:49:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4A19B214DA for ; Mon, 28 Jan 2019 20:49:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="i1LEetng" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726925AbfA1Utt (ORCPT ); Mon, 28 Jan 2019 15:49:49 -0500 Received: from mail-pg1-f195.google.com ([209.85.215.195]:36526 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726765AbfA1Utt (ORCPT ); Mon, 28 Jan 2019 15:49:49 -0500 Received: by mail-pg1-f195.google.com with SMTP id n2so7735634pgm.3 for ; Mon, 28 Jan 2019 12:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=UikzuymxkVLQPudOy947ExbNZyB5D523zHJzy8MULGk=; b=i1LEetngQkGtky8PCxKlJtT6HbtK+eEpd9YD9WJ+d6G4NEQxFk9AHlZxvItkqpuNF4 y6Z97Cj5YA1dPnYfJEW8KDC5JEoZfGpi2OZWiH2bhuPMYmNASx/jHZBfrT5S9hw+X//3 RJRRvcavOEk3d7PzrtrpfYAY/EDGNbQFouZG7bSMYfKf0k2nA9rmZZchCZOR2aUBJgDZ bPAfnPCiQDe9G7mC5iQo13kjwLdlaWueLXWpwk6TZ7VOKqKS0N+cuNCGSW3Wj1mX47aV EzBGUoPoxhj1x3tC8AzLrx6Bpn6LJybJFgC5urFKQA344whxGDRYXKLyBjCXMN4ERv25 U0yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=UikzuymxkVLQPudOy947ExbNZyB5D523zHJzy8MULGk=; b=FGxmLTRpl0lYnCSwgpVE2wWnvDr1BTRRtil/Z2i+lttMaXN9goiFMXH9FGYznnTvKC 5O6IAH1ecV9X7IWdfRFxgjnBQ0uiO5NsiEb06xQomlCsIQDJ8nMeUS8/BIicRbostA8y J3co69ZbILAElG/Axo+1KxGaGjjDfCE45svN8umlD4A0dRzgSEy3RTv++PW2xHy1QSbP NfYPpm2pLDbFZgSwQHKs8lkEi/OOj5nYQ4dBPLH2nvN2AIcvoTzxL7SkKIkuzBZtaJRZ HIl2w0/nd5PH83XXV9qmBfIiQ891+QP0BCJCzj/Gsau2Oiy2g2O0lGu7Hoydvdga/PsE S75A== X-Gm-Message-State: AJcUukfIiJ27a9WO3wi+9wBoNDodx8wXZdGh+1VpO9wN4k8e3J4um6qD yEfqHtKwOPqXeyIUzcSD6FY= X-Google-Smtp-Source: ALg8bN4BUPbynxBhTzHgQ990yy4Eq6fRgtCEaEODl4tCz7mMKN2Pd9X599a0jRgKTme9EEmuEMJzZg== X-Received: by 2002:a62:61c3:: with SMTP id v186mr23575680pfb.55.1548708588124; Mon, 28 Jan 2019 12:49:48 -0800 (PST) Received: from ast-mbp ([2620:10d:c090:200::4:db56]) by smtp.gmail.com with ESMTPSA id r76sm48033535pfb.69.2019.01.28.12.49.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Jan 2019 12:49:47 -0800 (PST) Date: Mon, 28 Jan 2019 12:49:45 -0800 From: Alexei Starovoitov To: Peter Zijlstra Cc: Alexei Starovoitov , davem@davemloft.net, daniel@iogearbox.net, jakub.kicinski@netronome.com, netdev@vger.kernel.org, kernel-team@fb.com, mingo@redhat.com, will.deacon@arm.com, Paul McKenney , jannh@google.com Subject: Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock Message-ID: <20190128204944.xeaszuzxagg5f3tp@ast-mbp> References: <20190124041403.2100609-1-ast@kernel.org> <20190124041403.2100609-2-ast@kernel.org> <20190124180109.GA27771@hirez.programming.kicks-ass.net> <20190124235857.xyb5xx2ufr6x5mbt@ast-mbp.dhcp.thefacebook.com> <20190125091057.GK17749@hirez.programming.kicks-ass.net> <20190125234241.soomtkrgp2i7m7ul@ast-mbp.dhcp.thefacebook.com> <20190128083123.GB28467@hirez.programming.kicks-ass.net> <20190128083508.GA28878@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190128083508.GA28878@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20180223 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Jan 28, 2019 at 09:35:08AM +0100, Peter Zijlstra wrote: > On Mon, Jan 28, 2019 at 09:31:23AM +0100, Peter Zijlstra wrote: > > On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote: > > > On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote: > > > > On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote: > > > > > > > nmi checks for bpf_prog_active==0. See bpf_overflow_handler. > > > > > > yuck yuck yuck.. That's horrific :-( That means the whole BPF crud is > > > > unreliable and events can go randomly missing. > > > > > > bpf_prog_active is the mechanism to workaround non-reentrant pieces of the kernel. > > > > 'the kernel' or 'bpf' ? > > > > perf has a recursion counter per context (task,softirq,hardirq,nmi) and > > that ensures that perf doesn't recurse in on itself while allowing the > > nesting of these contexts. > > > > But if BPF itself is not able to deal with such nesting that won't work > > of course. > > Ooh, later you say: > > > Also we allow tracing progs to nest with networking progs. > > Which seems to suggest BPF itself can suppord (limited) nesting. well I'm not sure where is the boundary between bpf and the kernel :) By non-reentrant I meant pieces of the kernel that bpf maps or bpf helpers may use. For example kmalloc-style bpf map is using rcu and map update/delete do call_rcu() from inside bpf program. If kprobe or tracepoint bpf prog is called from inner bits of __call_rcu_core and the prog is doing map update we get into recursive __call_rcu_core and things go bad. Hence we disallow such situations when possible. If bpf had its own infrastructure for everything then it would be easy enough to allow proper recursion using mechanism similar to what perf does with get_recursion_context.