Return-Path: Received: from mx2.suse.de ([195.135.220.15]:51347 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752048AbdLKVxK (ORCPT ); Mon, 11 Dec 2017 16:53:10 -0500 From: NeilBrown To: Amir Goldstein Date: Tue, 12 Dec 2017 08:52:59 +1100 Cc: Linus Torvalds , Al Viro , linux-fsdevel , Linux NFS Mailing List , lkml , Lennart Poettering Subject: Re: [PATCH 1/4] fs/notify: fdinfo can report unsupported file handles. In-Reply-To: References: <151297214390.7818.7216826079527521005.stgit@noble> <151297224512.7818.18333908109878259066.stgit@noble> Message-ID: <87609dort0.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-nfs-owner@vger.kernel.org List-ID: --=-=-= Content-Type: text/plain On Mon, Dec 11 2017, Amir Goldstein wrote: > On Mon, Dec 11, 2017 at 8:04 AM, NeilBrown wrote: >> If a filesystem does not set sb->s_export_op, then it >> does not support filehandles and export_fs_encode_fh() >> and exportfs_encode_inode_fh() should not be called. >> They will use export_encode_fh() is which is a default >> that uses inode number generation number, but in general >> they may not be stable. >> >> So change exportfs_encode_inode_fh() to return FILEID_INVALID >> if called on an unsupported Filesystem. Currently only >> notify/fdinfo can do that. >> > > I wish you would leave this check to the caller, maybe add a helper > exportfs_can_decode_fh() for callers to use. > > Although there are no current uses for it in-tree, there is value in > being able to encode a unique file handle even when it cannot be > decoded back to an open file. > > I am using this property in my fanotify super block watch patches, > where the object identifier on the event is an encoded file handle > of the object, which delegates tracking filesystem objects to > userspace and prevents fanotify from keeping elevated refcounts > on inodes and dentries. > > There are quite a few userspace tools out there that are checking > that st_ino hasn't changed on a file between non atomic operations. > Those tools (or others) could benefit from a unique file handle if > we ever decide to provide a relaxed version of name_to_handle_at(). If the filesystem doesn't define ->s_export_op, then you really cannot trust anything beyond the inode number (and maybe not even that), and the inode number is already easily available. What actual value do you think you get from this pretend-file-handle on filesystems that don't support file handles? If there is a demonstrated need for some sort of identifier that is stronger than an inode number, but not strong enough for open_by_handle_at(), then you should explain that need and propose a well defined interface. You shouldn't use a back-door and hope no-one notices. Thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlou/jsACgkQOeye3VZi gbnJzw//U7QXFUacuuezreGL+MJcRP2IqY+SO07erS1/7Sw7ElSmkOxJA0qIOLRh FP2G1JHN8VXa7s+UsL0qtgqkdZ8rtMWbiJLKa5hv3S8dvO//2NpftkCYvDWnnxxn twiGmVbHPh+hH8Dm5XQGf1NJfoIS9vJZOUAadKReHit/8kDlEXllTyhwq0eBsA6O SsrwbUaixazx4JIiDOgtECiIwvXtIh038bEk1UepUnu+1flgdczJOgBYqDX3bhU7 unaEQIx+wc73PQPY2fH6dQ7gCquOSRrrOEBNOyp7V9dV4sEwxc+a6giC8WsbQcpa yyKSqJ3cUGEC8/+ymXCCr/wtvQgk5NM/8bAt5ZrDCzA9xtQTAiWKkrHNKCaTiYII BeaifvEV3r1Jqg08PMZgOZMZz8VwrRFQXMGw2a8iiwxE7hc/nmjB1fPZRGbm96Cu S50u0wtb0QiJ8CUTDQ4Pyio5E29qtYGKHyZskaeUjfrWdQzws2U8m4ph32QpCTfh GosPQns42tSEknt2MScyNYKke+YMZD2B9ukUCCk88JkKcFq/gIHFlhh9tL+Itqfr lhMc+/9wTFw6V/GuC/lmH/eWI463zqhmGqdzO6hK7X38QJ57WfQ36+gvJ93VQI5T KKlYOTWKElspgN0ycIH446CI9X7nKxgkVkiXb/GfLQo2ZUCd/tI= =ygHO -----END PGP SIGNATURE----- --=-=-=--