Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp946075rwb; Thu, 4 Aug 2022 14:06:38 -0700 (PDT) X-Google-Smtp-Source: AA6agR7t8Qj/vzXcu/eEGd3IJ2FWCisG8HNuTGXcZzBZKptMetZxTAuE8ax8HBfd0NZwf+Oqx1TX X-Received: by 2002:a17:907:75c1:b0:72f:248d:5259 with SMTP id jl1-20020a17090775c100b0072f248d5259mr2787316ejc.227.1659647197876; Thu, 04 Aug 2022 14:06:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659647197; cv=none; d=google.com; s=arc-20160816; b=CNZjbQEbu+2WoGWzbJyWlR3Lkl7kHmBOGt0WTvnO5uz2wPAvrocj6Ald0Ct5GPKqjR k1Z3Vbeb9k/ZhvnUDqm+7NFuTvBtJ5BF98KhQGPGSeGmcv1z1QVEFnTjyKsfia68B/Zb y+DEGy03hH0LTIG8kFJvAzRowAsn2TZAjjRy4LdF/D6tq63OnD+LgWc7DLQfC7T5lMCe xPfLERtL93OqYht4Y3UwpIBnnKC0fKchzvTPjM6cuipUa6mmlLytjSg3AWkSrFv/ft2a Eda6TjXuOX6jW32SVHnKaX+Ri6fHZQIgeut2y8ayKS4Lb37+klJ+dn9xn23G9g7p8E77 OTdA== 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=IRiMxNbXrc+JNPj6jAzlN/4D6lsjKm+nRyRjn4MsJWg=; b=YZndaY5tBfvs5erEeCC2PmHmVifjAMqmt7yVBhI7/tMhwySEDMOZATuoKrfsUOpaI3 EMD4j3c+tiqE4QnZ1EhrHw2W7HUDsDIlnRPOpuG17nRhWoUkbCr6e3ux3SeUY+qy7PAl geaUxzsGdQKBhUzdk5UUPow1mF+FktTgOqgd6/StEeULdLclo1vlqM5ATMjoExtnS9G3 KtzhF1mHDxzLM3ZGaJPwLfQN4l+8Cv3NcfTmzKZhpMPiIpqBn/7Xsk89Ifvm6m5V1eu3 6XannZhbR59SQArl7VkESGy2uZUDBpPH9HMR2H8mOMJj6XldlLAErXYbSs8nSBFWi1Ug Qzug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=abpFYpzU; 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 bo19-20020a0564020b3300b0043cea48785csi1986443edb.192.2022.08.04.14.06.12; Thu, 04 Aug 2022 14:06:37 -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=abpFYpzU; 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 S239704AbiHDUmK (ORCPT + 99 others); Thu, 4 Aug 2022 16:42:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235054AbiHDUmI (ORCPT ); Thu, 4 Aug 2022 16:42:08 -0400 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BFEA26D573; Thu, 4 Aug 2022 13:42:06 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id y13so1322118ejp.13; Thu, 04 Aug 2022 13:42:06 -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=IRiMxNbXrc+JNPj6jAzlN/4D6lsjKm+nRyRjn4MsJWg=; b=abpFYpzUFF/Czb5Du5GtOLlV3sZXrSns2VbpUGYCJQ0JDibFZgdL/U37QcxRzO+GIH zOYFWFmt3AO8B1j8+4Q2BR08CQ8ll/ZZpN25qERHBiQEq+87H/Yx4bbnvpsN9zeZSLMA 42eVHNvDQeupN/AGdCE4Af8GklFhOwF1S4/avRBNICFp25XGuKLs6ZSEQ6ss8JSLqcPl m2VXl2MQrFGzVaq6M7SomtIIY6REqOxgbRkNz7pvd9n+cNoJPGEF+1dXCn+H860ZqmsG FClTlAa9JR7jEGygdGx+e1yh5sLa8ewY0aVdYz0Ze7W8/qH2dJmbpotI+8fxmyAsnVqi R/rA== 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=IRiMxNbXrc+JNPj6jAzlN/4D6lsjKm+nRyRjn4MsJWg=; b=jvkynrh1FfV7SC6ubU09rKI1JFV94HdxZTiQ3yoJkloIB/lU0Wqg7ZxcosBOWcbqyH 2Y2D1+7+QJbXFg5OFkAVQq5928Esu7TeklBJv3YpmXU3qleCtvgzLObsUC9U20BnzDJ2 GIGrhU9fvC7teImtd8M0T2xTP9k5L7h36ucEpB4b0tJViMGcrYchyt2xsVTHFNDxtEzw rOX9u99YXRU8woRUX+YIf9gbwIjvX+iA3GhRlQH7S+gQr2TPUcWFgdj8jrgW4h84LInd FhbaSMKGI0TtQkePCmAKPX9kdoQU63BFQg5FpQkuxITvFFA9hTg/98TV4hw1uT3TO2D1 UkZg== X-Gm-Message-State: ACgBeo3nzzvFu0/svBnh1PilGxzgdsyDi5QWG3txpiiciaRAvMpn+IB4 ib1Y183tOVxNGzUcvBqxXO60We0NfkUo3sM8Eq8= X-Received: by 2002:a17:907:971c:b0:72b:83d2:aa7a with SMTP id jg28-20020a170907971c00b0072b83d2aa7amr2629773ejc.633.1659645725255; Thu, 04 Aug 2022 13:42:05 -0700 (PDT) MIME-Version: 1.0 References: <20220802091030.3742334-1-asavkov@redhat.com> <20220802091030.3742334-3-asavkov@redhat.com> In-Reply-To: <20220802091030.3742334-3-asavkov@redhat.com> From: Alexei Starovoitov Date: Thu, 4 Aug 2022 13:41:53 -0700 Message-ID: Subject: Re: [PATCH bpf-next v2 2/3] bpf: export crash_kexec() as destructive kfunc To: Artem Savkov Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , bpf , Network Development , LKML , Andrea Arcangeli , Daniel Vacek , Jiri Olsa , Song Liu , Daniel Xu 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, Aug 2, 2022 at 2:10 AM Artem Savkov wrote: > > Allow properly marked bpf programs to call crash_kexec(). > > Signed-off-by: Artem Savkov > --- > kernel/kexec_core.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > index 4d34c78334ce..9259ea3bd693 100644 > --- a/kernel/kexec_core.c > +++ b/kernel/kexec_core.c > @@ -39,6 +39,8 @@ > #include > #include > #include > +#include > +#include > > #include > #include > @@ -1238,3 +1240,22 @@ void __weak arch_kexec_protect_crashkres(void) > > void __weak arch_kexec_unprotect_crashkres(void) > {} > + > +#ifdef CONFIG_DEBUG_INFO_BTF_MODULES > +BTF_SET8_START(kexec_btf_ids) > +BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE) > +BTF_SET8_END(kexec_btf_ids) > + > +static const struct btf_kfunc_id_set kexec_kfunc_set = { > + .owner = THIS_MODULE, > + .set = &kexec_btf_ids, > +}; > + > +static int __init crash_kfunc_init(void) > +{ > + register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING, &kexec_kfunc_set); > + return 0; > +} > + > +subsys_initcall(crash_kfunc_init); > +#endif It feels there will be a bunch of such boiler plate code in different .c files in many places in the kernel if we go with this approach. Maybe we should do one call: register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING from kernel/bpf/helper.c to register all tracing kfuncs ? And gate BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE) with #ifdef CONFIG_KEXEC_CORE. We have such a pattern in verifier.c already.