Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1814890rwb; Sat, 19 Nov 2022 04:11:38 -0800 (PST) X-Google-Smtp-Source: AA0mqf7KrDwDEn6LMxiW71hb5vhdXB8rcuD14gnyajwX5kNRTqNwHaF7dguZWoYOaM+Lxt7j7a0p X-Received: by 2002:a05:6402:3719:b0:461:4f34:d8f4 with SMTP id ek25-20020a056402371900b004614f34d8f4mr9792127edb.144.1668859897889; Sat, 19 Nov 2022 04:11:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668859897; cv=none; d=google.com; s=arc-20160816; b=U5bsn67cbfnF7C6fllcTF2tPBT8ULCseT4O8cIwRxl+C0p6e0tX/mLbFmKVpwyvr9R 6YuazMFIMWhgfoJ0WYAJjQ6BbqBxbEB0dBGWpf9Cj4hVJySRG0jnfr2kRxwrOTtux4CG ERYVXv767u89zhruzAmVROOeGi2gFyx54hMlmHPtpGTQcR8G5CPMZGwj6q4k4Ce7g7Dj TgvohGzPMuMsrOPC/lDfb6hDmtjqAI1RKy26rH9dxLjYm8igNprHlNGXDT4bUxFreupY OetJ0M6dKFTB0jKZ6XTtii8UqaRcGwIJh027DAeTjviVg8l75+yFmW404XGRDD891TID 7pNQ== 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=v2vriSPhwlIRIwA8q8kmuwZnhzDR1Kb20Wd5eK2znEk=; b=tIhoTKz1ILlDF8ZsPZfF8oecxxUCNpRMwyxXRaJ89dwtw8pwA/f2t8yc0nDjzI8vFt N2Xt8Fo9ynVA3U9NVgxiJ6NWjgcPmJLXbDij6pQuTFvlfTuBfHibPeeHSdR9IZayWMi0 sPvKYAijBjM5r0EWn6uAsHEjdUJ5v6V1Zp8PoFuPxD02YIcBTbhjVsPCzNL4zxWC4mBK b/XfMBu4+jwFA1T5IqI6D5DULbfAQtHR+igTmR1zQiPPBWHC36X+zIutrIsqOibtvMGs Gb9P4Z/EXmHfhOntWWbRB4MrmP+wW6yVJxyJD2bdS5TunnAeOC2UK4/NQUpdCqDyK9Sr ZOEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=IMrv0gHV; 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 d12-20020aa7d68c000000b004691547f6besi3253128edr.280.2022.11.19.04.11.13; Sat, 19 Nov 2022 04:11:37 -0800 (PST) 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=IMrv0gHV; 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 S232544AbiKSMBX (ORCPT + 90 others); Sat, 19 Nov 2022 07:01:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229470AbiKSMBV (ORCPT ); Sat, 19 Nov 2022 07:01:21 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86AED97AAA; Sat, 19 Nov 2022 04:01:20 -0800 (PST) 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 2159460B72; Sat, 19 Nov 2022 12:01:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D295C433C1; Sat, 19 Nov 2022 12:01:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668859279; bh=88gsDwKEYpSXJAj8eqiYfmf/h0e4AlZEIfT5yZJhdII=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IMrv0gHVzHZxWOHVq12gYx6mrKUXVZk9OyBH9p0ocn2G4hrFEoJ2vnle34tZ2W2Dr sRETnqMRdayQe8zmYCRbL/Sf1d+aCzX4ziTcos9cP7r9gG4jGJJeN6WWv4nNLtTRMC HWzdWsG6wuIvlhraPgsNsYybrP7D6ec1A2N76F1QUOf3HkqS+fWek18624Ag4AzVwT RALFi5MJ7ZL4O1fnj8g+hvBT4sEmQn/VJHrQd15Mh4IsKbkVMujkXnyzyycG0k+9aM zlIk4G5VM4eCyCg8u2fkJE40JH4d+us/+b8euvdN5yHhvDo+jCpth9Mo/Xm8kfgsAr j0OEi9mmjAFNA== Date: Sat, 19 Nov 2022 13:01:11 +0100 From: Christian Brauner To: Brian Foster Cc: Ivan Babrou , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@cloudflare.com, Alexey Dobriyan , Al Viro , Theodore Ts'o , David Laight , Jonathan Corbet , Andrew Morton , David Hildenbrand , Johannes Weiner , Christoph Anton Mitterer , Mike Rapoport , Paul Gortmaker , Kalesh Singh Subject: Re: [PATCH v4] proc: report open files as size in stat() for /proc/pid/fd Message-ID: <20221119120111.2dh3tomoawwpyjrg@wittgenstein> References: <20221024173140.30673-1-ivan@cloudflare.com> 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 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 Fri, Nov 18, 2022 at 02:33:27PM -0500, Brian Foster wrote: > On Fri, Nov 18, 2022 at 11:18:36AM -0800, Ivan Babrou wrote: > > On Fri, Nov 18, 2022 at 11:10 AM Brian Foster wrote: > > > > +static int proc_fd_getattr(struct user_namespace *mnt_userns, > > > > + const struct path *path, struct kstat *stat, > > > > + u32 request_mask, unsigned int query_flags) > > > > +{ > > > > + struct inode *inode = d_inode(path->dentry); > > > > + int rv = 0; > > > > + > > > > + generic_fillattr(&init_user_ns, inode, stat); > > > > + > > > > > > Sorry I missed this on v3, but shouldn't this pass through the > > > mnt_userns parameter? > > > > The mnt_userns parameter was added in 549c729 (fs: make helpers idmap > > mount aware), and it's not passed anywhere in fs/proc. > > > > Looking at other uses of generic_fillattr, all of them use "init_user_ns": > > > > Interesting. It looks like this would have used mnt_userns from > vfs_getattr_nosec() before proc_fd_getattr() is wired up, right? I'm not > familiar enough with that change to say whether /proc should use one > value or the other, or perhaps it just doesn't matter.? > > Christian? Hey Brian, This should pass init_user_ns. So it is correct the way it is done now. The init_user_ns is used to indicate that no idmappings are used and since procfs doesn't support the creation of idmapped mounts and doesn't need to, passing it here makes the most sense. Technically passing down mnt_userns would work too but that would make it look like procfs could support idmapped mounts which isn't the case and so we don't do it this way. Starting soon this will be a lot clearer too since we're about to introduce struct mnt_idmap and replace passing around userns here. That'll make things also safer as the helpers that currently could be passed a mnt_userns - which could be any userns - will now only be able to take mnt_idmap which is a different type. Long story short, the way your patch does it is correct. Thanks! Christian