Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp27845851rwd; Tue, 4 Jul 2023 08:38:08 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5OOITBkCzBWdgYIOGyBOJZ8Xi/MiP1NSHfq0csZJCCmxdGegEAIZmvN8c+GzswPhjZBcq+ X-Received: by 2002:a05:620a:d8a:b0:75b:23a0:d9dc with SMTP id q10-20020a05620a0d8a00b0075b23a0d9dcmr16271241qkl.50.1688485088711; Tue, 04 Jul 2023 08:38:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688485088; cv=none; d=google.com; s=arc-20160816; b=Sq7ZwBJwpUhGQhlbdxSOavrlHFP+gJI7ipIIE3ljHrcL2blaCvBZgPUmeg+Lg9nHtK p7R5BdgvDw+Jra6XX8pCSJI0d2aFfES4v31432RgxOA89SLqDVpInclWfwgVbYmzDDA3 7Z5QJeMjDKubkDHdc7OviKfTLrEqL3FySI7+LTN/fhMNISq40nkli7+goVc+Y0D1kXKG tdVqUG4GhXETnR5hZfOR11UbqvYszuGRQQZBvU111IpNtuwWgO8njXD87940LmwE+XnZ SMGHIo83iHbbqSNGTIULRZ3BIyuydLxvd+vNYPS7cjTtwjZxkTd83Ky3Lrvq88A7lg8b NYuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=zgsbjQEEDFoXyhBvCrIFv+PxRNPhPvFf6Hyv3TyNN9w=; fh=azx71+6rsbI8sznk5DUxkicCsZEe/sUFZOuBabZoRG8=; b=iE9SdGqKbh/D2Clw7Rzuraj83n7+l2liR2enAi7QjWwCqw+c6KpczRU5GE2LebJlQz umhkEyPbh5RhJFDk5pge607qUAFo8la9cfQ8H9fL9ao7+eeO2p+4CL/RGJtg6y2AN0t+ LQ0jj/YwsRGJ8R3tXCEDgnP+ukqLx+pWz4G18FFW5xHu5FX0bRdG2v/svT9Yg1OD/70C Ufm3Hgwsa+ipm22KFjhqlWYReSIRgm/kfpToxcM7OC8YbHjExEOlt3JiHSh9m+yB8zS6 9Y7K72MyGmc8Y3RPxHS27BBNAmO4fJV4shEpqBXRPY7M4H/lAPsXMQvQzKKtMZKRBEnD eW9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TyDsjxUi; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ei49-20020a056a0080f100b0064354230c2asi15955403pfb.367.2023.07.04.08.37.50; Tue, 04 Jul 2023 08:38:08 -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=@kernel.org header.s=k20201202 header.b=TyDsjxUi; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231534AbjGDP3H (ORCPT + 99 others); Tue, 4 Jul 2023 11:29:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231650AbjGDP2e (ORCPT ); Tue, 4 Jul 2023 11:28:34 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6EA8C1712; Tue, 4 Jul 2023 08:28:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DC4B661290; Tue, 4 Jul 2023 15:28:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF0ADC433C8; Tue, 4 Jul 2023 15:28:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688484498; bh=YJkeztYtJHBlga7WOYK+Vsp9QskuLTRhsuPX35DFWRk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TyDsjxUi9BW8G3KudpP+/pGIxrqF9uQh2xklkpKq10C/WJlPemj0joGV/4zZS4TgN LQIDD3zEVoWJKdebWZsrWf/SqoafKAAm/+kXjwYuEMaqyXm3v0DwYRQ7nJAtE9d1N7 zhxHUwRw7P/QvRtCB5XOLVc4L3oEI231BCMGHpdf11ELvtM1YUAqUO3jRdLHkE+oJe 6S8BHXC1EGIPLWcLjoFWpG+nv9NLA+Gpta/M+QBQ0cP/d/oJ4Y0maxAciYvlZKnVKa x1xX2pAdGkIiqiysp8O80qnw20ujxzp/9NhrG/UfZRcXRhcv7vvFMX2UKxMcQV+4Nm UU+tS8FadQg1w== Date: Tue, 4 Jul 2023 17:28:13 +0200 From: Christian Brauner To: Alexey Gladkov Cc: Hou Tao , bpf@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Alexander Viro , Alexei Starovoitov Subject: Re: [PATCH v1] fs: Add kfuncs to handle idmapped mounts Message-ID: <20230704-peitschen-inzwischen-7ad743c764e8@brauner> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 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,T_SCC_BODY_TEXT_LINE 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, Jul 04, 2023 at 05:11:12PM +0200, Alexey Gladkov wrote: > On Tue, Jul 04, 2023 at 07:42:53PM +0800, Hou Tao wrote: > > Hi, > > > > On 6/30/2023 7:08 PM, Alexey Gladkov wrote: > > > Since the introduction of idmapped mounts, file handling has become > > > somewhat more complicated. If the inode has been found through an > > > idmapped mount the idmap of the vfsmount must be used to get proper > > > i_uid / i_gid. This is important, for example, to correctly take into > > > account idmapped files when caching, LSM or for an audit. > > > > Could you please add a bpf selftest for these newly added kfuncs ? > > > > > > Signed-off-by: Alexey Gladkov > > > --- > > > fs/mnt_idmapping.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++ > > > 1 file changed, 69 insertions(+) > > > > > > diff --git a/fs/mnt_idmapping.c b/fs/mnt_idmapping.c > > > index 4905665c47d0..ba98ce26b883 100644 > > > --- a/fs/mnt_idmapping.c > > > +++ b/fs/mnt_idmapping.c > > > @@ -6,6 +6,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include "internal.h" > > > > > > @@ -271,3 +272,71 @@ void mnt_idmap_put(struct mnt_idmap *idmap) > > > kfree(idmap); > > > } > > > } > > > + > > > +__diag_push(); > > > +__diag_ignore_all("-Wmissing-prototypes", > > > + "Global functions as their definitions will be in vmlinux BTF"); > > > + > > > +/** > > > + * bpf_is_idmapped_mnt - check whether a mount is idmapped > > > + * @mnt: the mount to check > > > + * > > > + * Return: true if mount is mapped, false if not. > > > + */ > > > +__bpf_kfunc bool bpf_is_idmapped_mnt(struct vfsmount *mnt) > > > +{ > > > + return is_idmapped_mnt(mnt); > > > +} > > > + > > > +/** > > > + * bpf_file_mnt_idmap - get file idmapping > > > + * @file: the file from which to get mapping > > > + * > > > + * Return: The idmap for the @file. > > > + */ > > > +__bpf_kfunc struct mnt_idmap *bpf_file_mnt_idmap(struct file *file) > > > +{ > > > + return file_mnt_idmap(file); > > > +} > > > > A dummy question here: the implementation of file_mnt_idmap() is > > file->f_path.mnt->mnt_idmap, so if the passed file is a BTF pointer, is > > there any reason why we could not do such dereference directly in bpf > > program ? > > I wanted to provide a minimal API for bpf programs. I thought that this > interface is stable enough, but after reading Christian's answer, it looks > like I was wrong. It isn't even about stability per se. It's unlikely that if we change internal details that types or arguments to these helpers change. That's why we did the work of abstracting this all away in the first place and making this an opaque type. The wider point is that according to the docs, kfuncs claim to have equivalent status to EXPORT_SYMBOL_*() with the added complexity of maybe having to take out of tree bpf programs into account. Right now, we can look at the in-kernel users of is_idmapped_mnt(), convert them and then kill this thing off if we wanted to. As soon as this is a kfunc such an endeavour becomes a measure of "f**** around and find out". That's an entirely avoidable conflict if we don't even expose it in the first place.