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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 C3854C282C0 for ; Fri, 25 Jan 2019 16:08:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 92A3E218CD for ; Fri, 25 Jan 2019 16:08:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726273AbfAYQIB (ORCPT ); Fri, 25 Jan 2019 11:08:01 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:54114 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726108AbfAYQIB (ORCPT ); Fri, 25 Jan 2019 11:08:01 -0500 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0PG4qTk084481 for ; Fri, 25 Jan 2019 11:08:00 -0500 Received: from e14.ny.us.ibm.com (e14.ny.us.ibm.com [129.33.205.204]) by mx0a-001b2d01.pphosted.com with ESMTP id 2q83ye5nt0-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 25 Jan 2019 11:07:59 -0500 Received: from localhost by e14.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 25 Jan 2019 16:07:58 -0000 Received: from b01cxnp22033.gho.pok.ibm.com (9.57.198.23) by e14.ny.us.ibm.com (146.89.104.201) 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 16:07:53 -0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x0PG7q8G16711742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Jan 2019 16:07:52 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 49249B2065; Fri, 25 Jan 2019 16:07:52 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C221DB2067; Fri, 25 Jan 2019 16:07:51 +0000 (GMT) Received: from paulmck-ThinkPad-W541 (unknown [9.85.144.4]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 25 Jan 2019 16:07:51 +0000 (GMT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id A3D8316C64CE; Fri, 25 Jan 2019 08:02:04 -0800 (PST) Date: Fri, 25 Jan 2019 08:02:04 -0800 From: "Paul E. McKenney" To: Alexei Starovoitov Cc: Alexei Starovoitov , Jann Horn , Peter Zijlstra , Alexei Starovoitov , "David S. Miller" , Daniel Borkmann , "jakub.kicinski@netronome.com" , Network Development , Kernel Team , Ingo Molnar , Will Deacon Subject: Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock Reply-To: paulmck@linux.ibm.com References: <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> <20190125012224.GZ4240@linux.ibm.com> <20190125023816.zolpqls5bcsbqsga@ast-mbp.dhcp.thefacebook.com> <150dc5d3-21c3-bbb6-6e5b-2ab8ab0e3f38@fb.com> <20190125043158.GB4240@linux.ibm.com> <865e3302-6f7f-d20b-07ea-e387b0a7a570@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <865e3302-6f7f-d20b-07ea-e387b0a7a570@fb.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 19012516-0052-0000-0000-0000037E53E8 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00010475; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000277; SDB=6.01151624; UDB=6.00600247; IPR=6.00931968; MB=3.00025286; MTD=3.00000008; XFM=3.00000015; UTC=2019-01-25 16:07:56 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19012516-0053-0000-0000-00005F99519E Message-Id: <20190125160204.GD4240@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-25_10:,, 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901250128 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jan 25, 2019 at 04:47:20AM +0000, Alexei Starovoitov wrote: > On 1/24/19 8:31 PM, Paul E. McKenney wrote: > > On Fri, Jan 25, 2019 at 04:27:02AM +0000, Alexei Starovoitov wrote: > >> On 1/24/19 6:38 PM, Alexei Starovoitov wrote: > >>>> For programs created with CAP_SYS_ADMIN, > >>>> things get more tricky because you can create your own functions and > >>>> call them repeatedly; I'm not sure whether the pessimal runtime there > >>>> becomes exponential, or whether there is some check that catches this. > >>> I think you're referring to bpf-to-bpf calls. > >>> The limit it still the same. 4k per program including all calls. > >>> tail calls are not allowed when bpf-to-bpf is used. So no 32 multiplier. > >> > >> Jann, > >> > >> I think you meant > >> main: > >> call A > >> call A > >> call A > >> exit > >> A: > >> call B > >> call B > >> call B > >> exit > >> B: > >> call C > >> ... > >> > >> scenario when everything fits into 4k? > >> Would be great if you can construct such test while we're fixing > >> the rest of the issues brought up in this thread. > >> It will definitely be no more than BPF_COMPLEXITY_LIMIT_INSNS > >> which is 128k, but I wonder what will be the actual number of > >> executed insns. > >> I think such clever constructed sequence can actually > >> hit 128k executed too. > >> It would be awesome test to add to test_verifier.c > >> We have some of such pushing-the-boundary tests in lib/test_bpf.c > >> that are generated in assembler. > >> The longest takes 23853 nanoseconds, but clever bpf2bpf call hack > >> like above with map_update call in the leaf function should > >> certainly take much longer. > >> I accept Paul's challenge to try to get such fancy bpf prog > >> to take 100 millseconds :) > > > > Fair enough! But once you meet my challenge, the RCU CPU stall warning > > code will challenge you to hit 21 seconds (or only three seconds given > > an appropriately configured kernel). ;-) > > if (till_stall_check < 3) { > WRITE_ONCE(rcu_cpu_stall_timeout, 3); > till_stall_check = 3; > > let's change that limit to 1 ! Heh! It was 1.5 seconds back in DYNIX/ptx. However, taking it below 3 seconds would require some other adjustments. Something about there being a lot more moving parts in the Linux kernel. > Seriously though folks have proposed to teach bpf verifier > to sprinkle cond_resched() automatically into bpf program > when critical path through the program reaches certain insn limit. > The verifier can easily be taught to compute the longest path. Good point, for PREEMPT=n, cond_resched() will help. > Other folks proposed to get rid of 4k limit when prog > is preemptable and executing in user context. > That's when srcu will come into play. OK, please let me know when you get to this point so that I can get the lightweight variant of SRCU moving forward. Thanx, Paul