Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752367AbdLKHFx (ORCPT ); Mon, 11 Dec 2017 02:05:53 -0500 Received: from mail-yb0-f170.google.com ([209.85.213.170]:45104 "EHLO mail-yb0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751274AbdLKHFv (ORCPT ); Mon, 11 Dec 2017 02:05:51 -0500 X-Google-Smtp-Source: AGs4zMbj2WcYQoP5P3fvKueWF7fbutMQlVk5GGhDFwig/amJsivr3vikkUxwL8rZEX/AvQcjtgPkulJtB1qR8M9mjHs= MIME-Version: 1.0 In-Reply-To: References: <151297214390.7818.7216826079527521005.stgit@noble> <151297224512.7818.18333908109878259066.stgit@noble> From: Amir Goldstein Date: Mon, 11 Dec 2017 09:05:50 +0200 Message-ID: Subject: Re: [PATCH 1/4] fs/notify: fdinfo can report unsupported file handles. To: NeilBrown , Pavel Emelyanov Cc: Linus Torvalds , Al Viro , linux-fsdevel , Linux NFS Mailing List , lkml , Lennart Poettering Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1615 Lines: 40 On Mon, Dec 11, 2017 at 8:41 AM, 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(). > And this change need a clause about not breaking userspace. Pavel, Will this break any version of criu in the wild? Amir.