Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp69044iob; Mon, 2 May 2022 13:18:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzI8zt0xjrn/CdiLz6B28+8MXd/lJy7UoD0bV6aPd+pzK/P8CjE4Y2NSmSgtqUmovBRlxBr X-Received: by 2002:a63:a06:0:b0:3c2:3345:bf99 with SMTP id 6-20020a630a06000000b003c23345bf99mr4302796pgk.477.1651522710256; Mon, 02 May 2022 13:18:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651522710; cv=none; d=google.com; s=arc-20160816; b=AQ1Ls5w2f2dOfNX+740OGa6Lev5CT3k0yQ/1SYlF/DZte66RRR9xKWAl+DJXw0vwn4 FIOqca/AQlKi0X3TI8i7z/ZVzoD4zupnJT7vGlszChHeJ+/pM2Khw/hcxJg9/lSkcgKP pxPZ+w3nQUFcdCyixPQ32oWJNXEUtJ42mvdeeqWWI0+RyJ+/q8ppHTriKwRPTGEoBQHp 1YF5c4KocNZK4SbVZS11KEwUEnGi8TbfYv4tWu+srAInb14dNFh/lQMxjduF0sKeQYYF UKXWVEfU6vmf7h10vUS2PMZnQf4tcFMqsNSvYs1z29VeP0JqLBWPtUMD60yA4krjivkJ gopQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=LUmNcNsDoCzcF14FceqgfCt2WsRT+h9Jn//RzzgixQg=; b=TYBN4mww0Qh6bL0vMJDYiRY/XggSrUPiciuOSY4063h9mpHir+hnKJvddM+bGGGu9B BUWn8/X5r8O7kqEoGd+hlO0XxeswlWHz6onjqvs5J5VSsx3Y/nkEd0iTj1rZ+HwKMjcF Ap0eImYKHwiufgiarOSqODa0N1FKvSaBToyhb30xBPktRp+I0ATAAu7QP44ABmB3eSrV FQiUYJKzKdTXZtdxjjd8ndxSIapBYZAtP1Nsp1t/RXDPnzLIQPZjWAgDPEweByblXttd x9G+wXcliqQfsv9TOIM5WPCg42n0Vz1NxPJVmB9aeRM7bV8m8RFO4AR6JnNBg3xgpnEF PV/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ovNwRnZQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v19-20020a63f853000000b003aa8fffe77bsi15039525pgj.737.2022.05.02.13.18.12; Mon, 02 May 2022 13:18:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ovNwRnZQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382142AbiD3DdQ (ORCPT + 99 others); Fri, 29 Apr 2022 23:33:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232757AbiD3DdO (ORCPT ); Fri, 29 Apr 2022 23:33:14 -0400 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6D7EC0E68; Fri, 29 Apr 2022 20:29:54 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id d15so8661276plh.2; Fri, 29 Apr 2022 20:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LUmNcNsDoCzcF14FceqgfCt2WsRT+h9Jn//RzzgixQg=; b=ovNwRnZQhd3q2zYaM7FygEnhotz760Al/ruwyRTkj52QSuCz45g4xJzsiHX7WCOdBz edjiZI0mJ+3T8W6iH4tcnj4dAwhggeIAqTYfh3HXvEU6onBiLHKNBh1aFJqzP9mtHBdO tvh1emm+tRTF5drn6eweQ350RW7u/WX70iiuqLKnbpUD6Lq589GzIkI2cDCgzy+FXckK hv2wi+Pcf2G+DS0DL3pthyNkpfRst6pPJmQ7GPHNAHcQeW0KDc7+mQoh6p6vZCRmweZA N60KGOpaTaE1rLbBGzAgZJPY8ZVY7ausZDaYULNdjpMO6XRywNlmJjzZNeqaHzDfgudV 7pQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LUmNcNsDoCzcF14FceqgfCt2WsRT+h9Jn//RzzgixQg=; b=7JXVqmk2ddByvwCDCpJLLB7btsaZgQavin7QOYs3Hiu2akA+o/X6R20D0ah9nvA0zJ iNxVmhmX8ez3Mjxv+3MaVB+qSaLpjZNHYlMEmtRpUvT+WpD3wlGITerdbrklJaOvn5fz DgRK4Avoz8JFnbamA5d9BwnkoNxWnpRtyp4froJhwYguRk/5bRr5Zx1wEgUlxMG5fIBL R8lGi4a24icXG7BQBgFpyBBl8Em066Rvu7MNGNV30cL6rd3kdp2pRp94L6czwIxy/cKL Hyr3oN+mp8YUAXdiUpG8IMZUYq3T1IxHZnb6nK0gDLVzcUnaiua1ZpRvUXwTOyDLvhc0 QNTw== X-Gm-Message-State: AOAM5327uVMQh3vq7bq/a02DAPS8C8Nc3bdlVogph59Y1BbKuj5USN/+ y3KiFivx2ABj5HRsYj0ptMkhT5OioR8XedhYjCQ= X-Received: by 2002:a17:90b:33c8:b0:1d9:9023:1103 with SMTP id lk8-20020a17090b33c800b001d990231103mr2344557pjb.26.1651289394183; Fri, 29 Apr 2022 20:29:54 -0700 (PDT) MIME-Version: 1.0 References: <20220421140740.459558-1-benjamin.tissoires@redhat.com> <20220421140740.459558-4-benjamin.tissoires@redhat.com> <20220426041147.gwnxhcjftl2kaz6g@MBP-98dd607d3435.dhcp.thefacebook.com> In-Reply-To: From: Alexei Starovoitov Date: Fri, 29 Apr 2022 20:29:43 -0700 Message-ID: Subject: Re: [RFC bpf-next v4 3/7] error-inject: add new type that carries if the function is non sleepable To: Benjamin Tissoires Cc: Greg KH , Jiri Kosina , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Tero Kristo , lkml , "open list:HID CORE LAYER" , bpf Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 26, 2022 at 12:52 AM Benjamin Tissoires wrote: > > On Tue, Apr 26, 2022 at 6:11 AM Alexei Starovoitov > wrote: > > > > On Thu, Apr 21, 2022 at 04:07:36PM +0200, Benjamin Tissoires wrote: > > > When using error-injection function through bpf to change the return > > > code, we need to know if the function is sleepable or not. > > > > > > Currently the code assumes that all error-inject functions are sleepable, > > > except for a few selected of them, hardcoded in kernel/bpf/verifier.c > > > > > > Add a new flag to error-inject so we can code that information where the > > > function is declared. > > > > > > Signed-off-by: Benjamin Tissoires > > > > > > --- > > > > > > new in v4: > > > - another approach would be to define a new kfunc_set, and register > > > it with btf. But in that case, what program type would we use? > > > BPF_PROG_TYPE_UNSPEC? > > > - also note that maybe we should consider all of the functions > > > non-sleepable and only mark some as sleepable. IMO it makes more > > > sense to be more restrictive by default. > > > > I think the approach in this patch is fine. > > We didn't have issues with check_non_sleepable_error_inject() so far, > > so I wouldn't start refactoring it. > > OK... though I can't help but thinking that adding a new > error-inject.h enum value is going to be bad, because it's an API > change, and users might not expect NS_ERRNO. Not sure about api concern. This is the kernel internal tag. bpf progs are not aware of them. The functions can change from sleepable to non-sleepable too. allow_error_inject can be removed. And so on. > OTOH, if we had a new kfunc_set, we keep the existing error-inject API > in place with all the variants and we just teach the verifier that the > function is non sleepable. ... > IIUC, the kfunc_set approach would solve that, no? Makes sense. Let's figure out an extensible kfunc_set approach that is not centralized in verifier.c