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=-7.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_PASS,USER_AGENT_MUTT 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 6B3EDC282C3 for ; Fri, 25 Jan 2019 01:22:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 34D07218B0 for ; Fri, 25 Jan 2019 01:22:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728196AbfAYBWe (ORCPT ); Thu, 24 Jan 2019 20:22:34 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:56248 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726015AbfAYBWd (ORCPT ); Thu, 24 Jan 2019 20:22:33 -0500 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0P1EMuF028843 for ; Thu, 24 Jan 2019 20:22:32 -0500 Received: from e11.ny.us.ibm.com (e11.ny.us.ibm.com [129.33.205.201]) by mx0b-001b2d01.pphosted.com with ESMTP id 2q7n1ksqg9-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 24 Jan 2019 20:22:32 -0500 Received: from localhost by e11.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 25 Jan 2019 01:22:31 -0000 Received: from b01cxnp23032.gho.pok.ibm.com (9.57.198.27) by e11.ny.us.ibm.com (146.89.104.198) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Fri, 25 Jan 2019 01:22:26 -0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x0P1MP6524117408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 25 Jan 2019 01:22:25 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9E839B2068; Fri, 25 Jan 2019 01:22:25 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5D17CB2064; Fri, 25 Jan 2019 01:22:25 +0000 (GMT) Received: from paulmck-ThinkPad-W541 (unknown [9.85.128.179]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 25 Jan 2019 01:22:25 +0000 (GMT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id 714FA16C64CE; Thu, 24 Jan 2019 17:22:24 -0800 (PST) Date: Thu, 24 Jan 2019 17:22:24 -0800 From: "Paul E. McKenney" To: Alexei Starovoitov Cc: Peter Zijlstra , 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, jannh@google.com Subject: Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock Reply-To: paulmck@linux.ibm.com References: <20190124041403.2100609-1-ast@kernel.org> <20190124041403.2100609-2-ast@kernel.org> <20190124180109.GA27771@hirez.programming.kicks-ass.net> <20190124185652.GB17767@hirez.programming.kicks-ass.net> <20190124234232.GY4240@linux.ibm.com> <20190125000515.jizijxz4n735gclx@ast-mbp.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190125000515.jizijxz4n735gclx@ast-mbp.dhcp.thefacebook.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 19012501-2213-0000-0000-00000344662E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00010472; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000277; SDB=6.01151333; UDB=6.00600070; IPR=6.00931673; MB=3.00025277; MTD=3.00000008; XFM=3.00000015; UTC=2019-01-25 01:22:29 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19012501-2214-0000-0000-00005D1ABDEF Message-Id: <20190125012224.GZ4240@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-24_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=878 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901250008 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Jan 24, 2019 at 04:05:16PM -0800, Alexei Starovoitov wrote: > On Thu, Jan 24, 2019 at 03:42:32PM -0800, Paul E. McKenney wrote: > > On Thu, Jan 24, 2019 at 07:56:52PM +0100, Peter Zijlstra wrote: > > > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote: > > > > > > > > Thanks for having kernel/locking people on Cc... > > > > > > > > On Wed, Jan 23, 2019 at 08:13:55PM -0800, Alexei Starovoitov wrote: > > > > > > > > > Implementation details: > > > > > - on !SMP bpf_spin_lock() becomes nop > > > > > > > > Because no BPF program is preemptible? I don't see any assertions or > > > > even a comment that says this code is non-preemptible. > > > > > > > > AFAICT some of the BPF_RUN_PROG things are under rcu_read_lock() only, > > > > which is not sufficient. > > > > > > > > > - on architectures that don't support queued_spin_lock trivial lock is used. > > > > > Note that arch_spin_lock cannot be used, since not all archs agree that > > > > > zero == unlocked and sizeof(arch_spinlock_t) != sizeof(__u32). > > > > > > > > I really don't much like direct usage of qspinlock; esp. not as a > > > > surprise. > > > > Substituting the lightweight-reader SRCU as discussed earlier would allow > > use of a more generic locking primitive, for example, one that allowed > > blocking, at least in cases were the context allowed this. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > > branch srcu-lr.2019.01.16a. > > > > One advantage of a more generic locking primitive would be keeping BPF > > programs independent of internal changes to spinlock primitives. > > Let's keep "srcu in bpf" discussion separate from bpf_spin_lock discussion. > bpf is not switching to srcu any time soon. > If/when it happens it will be only for certain prog+map types > like bpf syscall probes that need to be able to do copy_from_user > from bpf prog. Hmmm... What prevents BPF programs from looping infinitely within an RCU reader, and as you noted, preemption disabled? If BPF programs are in fact allowed to loop infinitely, it would be very good for the health of the kernel to have preemption enabled. And to be within an SRCU read-side critical section instead of an RCU read-side critical section. Thanx, Paul