From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81D98C433E6 for ; Wed, 3 Feb 2021 14:29:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 33A6564F8C for ; Wed, 3 Feb 2021 14:29:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232713AbhBCO26 (ORCPT ); Wed, 3 Feb 2021 09:28:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232931AbhBCO2t (ORCPT ); Wed, 3 Feb 2021 09:28:49 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 316C3C061573; Wed, 3 Feb 2021 06:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=2Ge18xC9FLXty9oYdiqbqe+rDGvC8RbA/BrkeMW4ybk=; b=WeekyKtyxO/B1D02xzTYO8MP4G t+Ii2u3OoQ5Ke0xDP+/mVbosBl/fg0nDLi/1jhnocaGsO+7OpjplSu2W8Z/Qb8nqf8HERZ+08h9IH gHFpEfAcXm3ecPMBRSVEBVlEhjrbflhRjxZiVPF2Om2Tsy2Fy/yo8rU5CPuRdkIUi1qvGSXnOYZse PNqYT2s0bCgeA4i7ffSxhUsoK7zzryYoGUY8k53pLZ6dud3563tfuu9AL+db8Bb3ozo3SOL9Rfeiy 09qX5U/OC5Zmmg6BYo4pnQGVOqzwPrzWINQ6o51ldBgGwb4wPm5CfVQhrnPgZTFWFyhXCkWmOqTkd bPRjCuoQ==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1l7J8U-00H1Wg-F5; Wed, 03 Feb 2021 14:28:03 +0000 Date: Wed, 3 Feb 2021 14:28:02 +0000 From: Matthew Wilcox To: Miklos Szeredi Cc: Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Al Viro , Andreas Dilger , Andreas Gruenbacher , Christoph Hellwig , "Darrick J . Wong" , Dave Kleikamp , David Sterba , Jaegeuk Kim , Jan Kara , Joel Becker , Matthew Garrett , Mike Marshall , Richard Weinberger , Ryusuke Konishi , Theodore Ts'o , Tyler Hicks Subject: Re: [PATCH 00/18] new API for FS_IOC_[GS]ETFLAGS/FS_IOC_FS[GS]ETXATTR Message-ID: <20210203142802.GA308988@casper.infradead.org> References: <20210203124112.1182614-1-mszeredi@redhat.com> <20210203130501.GY308988@casper.infradead.org> <20210203135827.GZ308988@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 03, 2021 at 03:13:29PM +0100, Miklos Szeredi wrote: > On Wed, Feb 3, 2021 at 2:58 PM Matthew Wilcox wrote: > > > Network filesystems frequently need to use the credentials attached to > > a struct file in order to communicate with the server. There's no point > > fighting this reality. > > IDGI. Credentials can be taken from the file and from the task. In > this case every filesystem except cifs looks at task creds. Why are > network filesystem special in this respect? I don't necessarily mean 'struct cred'. I mean "the authentication that the client has performed to the server". Which is not a per-task thing, it's stored in the struct file, which is why we have things like int (*write_begin)(struct file *, struct address_space *mapping, loff_t pos, unsigned len, unsigned flags, struct page **pagep, void **fsdata); disk filesystems ignore the struct file argument, but network filesystems very much use it.