From patchwork Tue Nov 21 21:15:13 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: NeilBrown X-Patchwork-Id: 10068889 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 740146038F for ; Tue, 21 Nov 2017 21:15:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6156B29996 for ; Tue, 21 Nov 2017 21:15:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5511F299FF; Tue, 21 Nov 2017 21:15:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_TVD_MIME_EPI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 622D629996 for ; Tue, 21 Nov 2017 21:15:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751284AbdKUVPY (ORCPT ); Tue, 21 Nov 2017 16:15:24 -0500 Received: from mx2.suse.de ([195.135.220.15]:33540 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751229AbdKUVPX (ORCPT ); Tue, 21 Nov 2017 16:15:23 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de X-Amavis-Alert: BAD HEADER SECTION, Header field occurs more than once: "Cc" occurs 3 times Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B15AAAEAF; Tue, 21 Nov 2017 21:15:21 +0000 (UTC) From: NeilBrown To: "Michael Kerrisk \(man-pages\)" Date: Wed, 22 Nov 2017 08:15:13 +1100 Cc: linux-man@vger.kernel.org, "linux-nfs\@vger.kernel.org" , "linux-fsdevel\@vger.kernel.org" Cc: Lennart Poettering Cc: Peng Tao Subject: [manpages PATCH] open_by_handle_at: clarifications needed due to NFS reexport Message-ID: <87wp2j1ggu.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The recent addition of NFS re-export and the possibility of using name_to_handle_at() on an NFS filesystem raises issues with name_to_handle_at() which have not been properly documented. Getting the filehandle for an untriggered automount point is arguably meaningless and in certainly not supported by NFS. name_to_handle_at() will return -EOVERFLOW even though the requested "handle_bytes" is large enough. This is an unfortunate overloading of the error code, but is manageable. So clarify this and also note that the mount_id is returned when EOVERFLOW is reported. Thought: it would be nice if mount_id were returned in the EOPNOTSUPP case too. I guess it is too late to fix that (?). Link: https://github.com/systemd/systemd/issues/7082 Signed-off-by: NeilBrown --- man2/open_by_handle_at.2 | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/man2/open_by_handle_at.2 b/man2/open_by_handle_at.2 index 91300e80fe24..9a30dd2ed476 100644 --- a/man2/open_by_handle_at.2 +++ b/man2/open_by_handle_at.2 @@ -109,6 +109,12 @@ and is set to indicate the required size; the caller can then use this information to allocate a structure of the correct size (see EXAMPLE below). +Some care is needed here as +.BR EOVERFLOW +can also indicate that no filehandle is available for this particular +name in a filesystem which does normally support filehandle lookup. +This case can be detected when EOVERFLOW is returned without +handle_bytes being increased. .PP Other than the use of the .IR handle_bytes @@ -193,6 +199,10 @@ Opening the pathname in the fifth field of that record yields a file descriptor for the mount point; that file descriptor can be used in a subsequent call to .BR open_by_handle_at (). +.I mount_id +is returned both for a successful call and for a call that results +in the error +.BR EOVERFLOW . .PP By default, .BR name_to_handle_at () @@ -206,6 +216,21 @@ is specified in .I pathname is dereferenced if it is a symbolic link (so that the call returns a handle for the file referred to by the link). +.PP +.BR name_to_handle_at ) +does not trigger a mount when the final component of the path is an +automount point. When a filesystem supports both filehandles and +automount points, a +.BR name_to_handle_at () +call on an automount point will return with error +.BR EOVERFLOW +without having increased +.IR handle_bytes . +This can happen since Linux 4.13 with NFS when accessing a directory +which is on a separate filesystem on the server. +.\" commit 20fa19027286983ab2734b5910c4a687436e0c31 +In this case the automount can be triggered by adding a "/" to the end +of the path. .SS open_by_handle_at() The .BR open_by_handle_at ()