From patchwork Mon Oct 24 11:31:42 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 9705 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp544659wru; Mon, 24 Oct 2022 09:32:37 -0700 (PDT) X-Google-Smtp-Source: AMsMyM44zW/QxIyYIAa6wZQm8rhHFdif6Uyowf28Xc2x75JZxFk8c72jdT8JALJUW5ZeMu34VXsp X-Received: by 2002:a17:907:7d90:b0:78d:bc5a:913c with SMTP id oz16-20020a1709077d9000b0078dbc5a913cmr27987921ejc.390.1666629157005; Mon, 24 Oct 2022 09:32:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666629157; cv=none; d=google.com; s=arc-20160816; b=R5RlNGw7rJMz9daPPOEyPMNbe1gFiTceoT0cgsAwPZ1amA+8pOUIq0ZqbvFVyfY0cs 2YcsvQCnf0Ez3WhyBsTa+BhQdmb+2YlUEGCriAvgQnJp8CteytQ8k2D4wy6d6YCH3CXV vyAhl82QII3dM97hku9tZLUxxZLQsg5sb081D6LnPYuiPG/E3i+eDds7gwVcIUwA4OPC jeIBiFZu6xh9MepR4hsi240pU8PCHc4CwkDx6AnuYymc9VcXseMBJkBiOXu0rJa+6NNR 489YL2ev3YQZlQWFQKtRq7SjaT5gv0PwqDbJCaLZrEr6gGUvzVzzPBtEK2yzMasOEnWk Nohw== 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=jcNNBwm0hHxcEBvS88EjS6FZhN+FB/gdRHYIVuiaVXo=; b=ySjP4sTM5GW8GRxVCL1Rjt/Bf323NciSQ2FnGA9YxBKIxKZP0Wgi4aGLUEsAvazlN9 d0tgNPd4rHyDM5chCWpwZ3/LvonP2+oidLXwnf0JbhPrGWtbrlSVYNXEY2zLeEaDDlF9 TvhNcrM855fSXpBm7J2NVErIpnMktMSGPPvyRBNaSY7xsVzbtUXxnF9Gn6x4IMIAUci9 CPbnePdTz1rL2Azt6yCVz5HdAr3/FkfLhvRbm29Zx/WATtp0T5Yf9/SdUhaGIyjhfao8 VDyOtmy7bZiyfxuYbdY7z22Q286sTs2IdaFivhPI4lxPa7Z1vzXDQObr23vBpjbKNSvO 5PbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=MmLkCL+C; 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 c16-20020a0564021f9000b00456662097dasi210411edc.69.2022.10.24.09.32.13; Mon, 24 Oct 2022 09:32:36 -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=MmLkCL+C; 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 S234101AbiJXQNt (ORCPT + 99 others); Mon, 24 Oct 2022 12:13:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232556AbiJXQMG (ORCPT ); Mon, 24 Oct 2022 12:12:06 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 272F113E3F; Mon, 24 Oct 2022 08:01:39 -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 ams.source.kernel.org (Postfix) with ESMTPS id 52273B81612; Mon, 24 Oct 2022 12:14:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E777C433C1; Mon, 24 Oct 2022 12:14:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666613664; bh=ZrB31+NJNwQic7KGl2gvkCCBKpq/6mExqiYHUP8iVO4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MmLkCL+C2WKcEXWeBYOlvRhySTyQheX+LkX94v/6sxPuQhNNuNtTKQgOt++b6L6nx nDquEiZhLKO+1dNbOksWsjCsy3EjDgjTmBrbmuklEqQH9jnqbT8Eg7uz2QXVEgBmnQ FG+3WDFj2I6b3ZTssbp7z520wk9OeKN2QKt3S2Nk= 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.4 192/255] bpftool: Clear errno after libcaps checks Date: Mon, 24 Oct 2022 13:31:42 +0200 Message-Id: <20221024113009.358175984@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221024113002.471093005@linuxfoundation.org> References: <20221024113002.471093005@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?1747587334824782922?= X-GMAIL-MSGID: =?utf-8?q?1747587334824782922?= 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 4b03983acbef..35984bd354cb 100644 --- a/tools/bpf/bpftool/main.c +++ b/tools/bpf/bpftool/main.c @@ -364,6 +364,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;