Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3617839pxb; Mon, 24 Jan 2022 13:37:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJzCMpW2XrA8HM05kyC99XMa0QjqcPYKFhUCN0eSSA1bukL3Fitfu/Ftop2RwlAtR7Mg+HWg X-Received: by 2002:a17:90a:428f:: with SMTP id p15mr288611pjg.132.1643060269742; Mon, 24 Jan 2022 13:37:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643060269; cv=none; d=google.com; s=arc-20160816; b=QTtYdl8X84MSHDi+Ic4eTzboX6VwneErAeHS8XdJ96rcxbl72nAE1jZwVzo551aV9v vyAYbrTB4RDMwWbiwrOdvKYjLGBE6tn5ScIyfNwAlPCv2xq8HB+vqvqtA2gDJJ1HGXqM lediDOT5jLGK85u9AFAcscrIIzRHEaLsAthH0pi3hCBPqhdSmQ8QxgR/E0Nm83xCNmZd UDnUDLsL0DmtyUdFP0vXNCVYh4cH1hsZ0SkbL5TK5l+IWBQtWyrGV/vf6b6c0cwe1eCR NPOazrna5bGMhMp0pv2m+z5VKafiQijbxqE0DqKChwzNIIkfeG/9Up6uZfKtuVyHBK3j LSGA== 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=2ccrN5+6MAVg2fsOQrr80wfcLZxCwlv7Sv0nHMsVcZo=; b=m7tTbclT0/jWQk72jiHd1GWZTkhyg9eiu6HYweoXfjDV1e7UmgP4Ev93OsHJYDYisy 9m42AHKLXYXytTbBREwF2FSJO8zWl2MyaZq2uNTVTW8ziHCP1OIH/1G7d5OnsPPPt27S mdpnZ4XS73jguUb1Tk+hsHEpifI39CGTEilatMvkaRMYNnNl0ioPK7ZOuXmoNYNp9KLQ 5zZerdf72JzoXaAqvzN0J9KVP1Ow8cs2UciZWKlea+fNWvcQ1awIu2s+7LfDaNUg416q brUpgYCG+1i2h5nOPuuUwRVuR3bowP60fye3/R6+hFlIAOReRTxCDZyij9pJoKMnZaFt vbcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=NCd0Y4mO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q9si16461300plx.119.2022.01.24.13.37.38; Mon, 24 Jan 2022 13:37:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=NCd0Y4mO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1449453AbiAXVPe (ORCPT + 99 others); Mon, 24 Jan 2022 16:15:34 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:42206 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1391637AbiAXUsQ (ORCPT ); Mon, 24 Jan 2022 15:48:16 -0500 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 7824D60C39; Mon, 24 Jan 2022 20:48:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D846FC340E5; Mon, 24 Jan 2022 20:48:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643057294; bh=alN1nGi9d01VTi67hSzdh6Vdn9Sl4cPFqezMOL+KxcI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NCd0Y4mOqUU5kYq9kf6aDvlrqp9c3KBtLXrrzQASSXguZtOeYu/QnnyxY614SVAoP UO9E/pyyuPoTut4HRTLzavBJvVRJwtP8TE5NLp7R5oxi4olun11przFxzMWdr4dRwQ od/W1CNBZQwf1bFoA8Le7DG3JpJ/3UC3F+YXgd4w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Daniel Borkmann , Yafang Shao , Christian Brauner , David Howells , Al Viro Subject: [PATCH 5.15 766/846] bpf: Fix mount source show for bpffs Date: Mon, 24 Jan 2022 19:44:43 +0100 Message-Id: <20220124184127.381781059@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220124184100.867127425@linuxfoundation.org> References: <20220124184100.867127425@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Yafang Shao commit 1e9d74660d4df625b0889e77018f9e94727ceacd upstream. We noticed our tc ebpf tools can't start after we upgrade our in-house kernel version from 4.19 to 5.10. That is because of the behaviour change in bpffs caused by commit d2935de7e4fd ("vfs: Convert bpf to use the new mount API"). In our tc ebpf tools, we do strict environment check. If the environment is not matched, we won't allow to start the ebpf progs. One of the check is whether bpffs is properly mounted. The mount information of bpffs in kernel-4.19 and kernel-5.10 are as follows: - kernel 4.19 $ mount -t bpf bpffs /sys/fs/bpf $ mount -t bpf bpffs on /sys/fs/bpf type bpf (rw,relatime) - kernel 5.10 $ mount -t bpf bpffs /sys/fs/bpf $ mount -t bpf none on /sys/fs/bpf type bpf (rw,relatime) The device name in kernel-5.10 is displayed as none instead of bpffs, then our environment check fails. Currently we modify the tools to adopt to the kernel behaviour change, but I think we'd better change the kernel code to keep the behavior consistent. After this change, the mount information will be displayed the same with the behavior in kernel-4.19, for example: $ mount -t bpf bpffs /sys/fs/bpf $ mount -t bpf bpffs on /sys/fs/bpf type bpf (rw,relatime) Fixes: d2935de7e4fd ("vfs: Convert bpf to use the new mount API") Suggested-by: Daniel Borkmann Signed-off-by: Yafang Shao Signed-off-by: Daniel Borkmann Acked-by: Christian Brauner Cc: David Howells Cc: Al Viro Link: https://lore.kernel.org/bpf/20220108134623.32467-1-laoar.shao@gmail.com Signed-off-by: Greg Kroah-Hartman --- kernel/bpf/inode.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/kernel/bpf/inode.c +++ b/kernel/bpf/inode.c @@ -648,12 +648,22 @@ static int bpf_parse_param(struct fs_con int opt; opt = fs_parse(fc, bpf_fs_parameters, param, &result); - if (opt < 0) + if (opt < 0) { /* We might like to report bad mount options here, but * traditionally we've ignored all mount options, so we'd * better continue to ignore non-existing options for bpf. */ - return opt == -ENOPARAM ? 0 : opt; + if (opt == -ENOPARAM) { + opt = vfs_parse_fs_param_source(fc, param); + if (opt != -ENOPARAM) + return opt; + + return 0; + } + + if (opt < 0) + return opt; + } switch (opt) { case OPT_MODE: