From patchwork Mon Oct 24 11:31:43 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 9185 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp458431wru; Mon, 24 Oct 2022 06:37:34 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6jIt8GpIuoRHm9Jgn/qKFKvVf94Bc2eBZQkUoPy7KzH/u/S2WTGuhA7kT+s0pI2TquYkKs X-Received: by 2002:a17:906:4795:b0:794:8b93:2e43 with SMTP id cw21-20020a170906479500b007948b932e43mr22357053ejc.184.1666618654509; Mon, 24 Oct 2022 06:37:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666618654; cv=none; d=google.com; s=arc-20160816; b=F8qLOYmkkxG0y0cXUU6wopK7Su2bLPbAyYEQzM82wFMf7kcJuKyLkuv7YVzE3OQMCj 4W7+psMG0wDHtgQcCiNzN4TBWUR8suyIpOPFLSDtr1fdLUIylU1zLDXKbxw2/Jc1lcI0 AQf0J+858zouCtwWnfiHzmrWRUGhzexe/qxUoLj6KOrIjECN/s4JHuhsf2aaHFOHTLtL lNiCeTkrt5STmEunV2rq1rTgRPoARfOs6A5VQgoAMFFn0F1ww4z8j/NK0F0MwWXO9J4Z eF/5GHePQlVFJ/grzvURz9q1gb+ROEFTKefpasu7v93wv/HgbhjV/f6M1cOyeFciQhwO XhpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=NJmes5OrMH2AXwGSap2+LdmlgToHLw6Lh1KT8dfYTxM=; b=etbstbOnXjop8cVXMvz36C0ZUyE3JYiHcn+VgbrjIG7F7W0gFqxSUfeQfnIme3R35X plkREKlIDpFKKBDEm7BSc9OLy5WlyQY/zoKX5BGlaxS5B27bonwyZtAXYrj1gWwWG0Wy md45Qa4ugP+94TE8Jb9qM3jFAMQDzlDKnrT8MLqh7l+zEtFOo0PjKisPM8wCQnzDICyU Ohm1OQbkDU+u1a+7AKftUUB9ypRlUyi9Iky63BtdL9JMV0Nz+CwdfKlY2gfZ4X7V0n6I 3YWhlSo6YotCtcp054OiOGmbR4hHDcGVg99aYpABjKz6XqF43F3RT2XQ06JP4o2L+qnn SCpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=dCdCVu3O; 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=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dr2-20020a170907720200b0078dbec2e632si30836862ejc.620.2022.10.24.06.37.01; Mon, 24 Oct 2022 06:37:34 -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=@linuxfoundation.org header.s=korg header.b=dCdCVu3O; 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=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233609AbiJXN1X (ORCPT + 99 others); Mon, 24 Oct 2022 09:27:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236253AbiJXNYv (ORCPT ); Mon, 24 Oct 2022 09:24:51 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 766E088A06; Mon, 24 Oct 2022 05:30:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0BFCF61330; Mon, 24 Oct 2022 12:29:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 208E2C433D6; Mon, 24 Oct 2022 12:29:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666614557; bh=s/TgH2cZHDS2UeT0O4dRQAweALS5Vjeej9+FSzcTV9Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dCdCVu3OAUtfAGnxHeFcvJ6NEEYb7p7A3Yg5um20KOgcjY7C40ED99oVgTpRrFHOB U/T9SGL8oOVEw6drLtDP+QK1bCdwgN5WI39gzR8Grxc+bJcizqVrpvjf9q3CwZHrPi dXm3+2mnSucz/AwIjVfcUKDQSCA6lYDFMDTy/HCo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Quentin Monnet , Daniel Borkmann , Sasha Levin Subject: [PATCH 5.10 306/390] bpftool: Clear errno after libcaps checks Date: Mon, 24 Oct 2022 13:31:43 +0200 Message-Id: <20221024113036.032845428@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221024113022.510008560@linuxfoundation.org> References: <20221024113022.510008560@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747576322286903708?= X-GMAIL-MSGID: =?utf-8?q?1747576322286903708?= From: Quentin Monnet [ Upstream commit cea558855c39b7f1f02ff50dcf701ca6596bc964 ] When bpftool is linked against libcap, the library runs a "constructor" function to compute the number of capabilities of the running kernel [0], at the beginning of the execution of the program. As part of this, it performs multiple calls to prctl(). Some of these may fail, and set errno to a non-zero value: # strace -e prctl ./bpftool version prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1 prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = 1 prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument) ** fprintf added at the top of main(): we have errno == 1 ./bpftool v7.0.0 using libbpf v1.0 features: libbfd, libbpf_strict, skeletons +++ exited with 0 +++ This has been addressed in libcap 2.63 [1], but until this version is available everywhere, we can fix it on bpftool side. Let's clean errno at the beginning of the main() function, to make sure that these checks do not interfere with the batch mode, where we error out if errno is set after a bpftool command. [0] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/libcap/cap_alloc.c?h=libcap-2.65#n20 [1] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=f25a1b7e69f7b33e6afb58b3e38f3450b7d2d9a0 Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220815162205.45043-1-quentin@isovalent.com Signed-off-by: Sasha Levin --- tools/bpf/bpftool/main.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c index 1854d6b97860..4fd4e3462ebc 100644 --- a/tools/bpf/bpftool/main.c +++ b/tools/bpf/bpftool/main.c @@ -398,6 +398,16 @@ int main(int argc, char **argv) setlinebuf(stdout); +#ifdef USE_LIBCAP + /* Libcap < 2.63 hooks before main() to compute the number of + * capabilities of the running kernel, and doing so it calls prctl() + * which may fail and set errno to non-zero. + * Let's reset errno to make sure this does not interfere with the + * batch mode. + */ + errno = 0; +#endif + last_do_help = do_help; pretty_output = false; json_output = false;