Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2366092imm; Tue, 10 Jul 2018 19:25:45 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcxVkF1gAiztGnHsLlW3HvSrUWKaK9GDoldpIlzoHVrWb7RIvaJH3JSHIOTpQALX60oQuOv X-Received: by 2002:a17:902:b785:: with SMTP id e5-v6mr27080169pls.339.1531275945118; Tue, 10 Jul 2018 19:25:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531275945; cv=none; d=google.com; s=arc-20160816; b=RNE3nZ8w/Ir9IafqrfN0jLHBQ3Zy9SUvzm7OyQJ1QmZBgcoNDBmNwXapyA5WsrW826 3BkcvZfrp5M5d0+hg0aTQikja8bp/NaaXljE9G/BdeaNUWQDj0CnNbZ2WfSk/aeWInZL 9TGLz7nNMGDt4g/w9jjCGzM7Nbc9Ir1/usKi6S0Td0vQQ9iG9avPt9bRGeokQ8o8ICWU cW6mQUR4+dq/NtrJVTptACkvyU7A3hQaC5JgrSb/+BOVgGtTUsjgV4dLJKQtWzfIKiMj ei3EOUkZKqtgnAYltXRvJ4UngVgUBaR7N6eyNrgb6EI4/hpuoHItEiDmNDpltJOGIEuy 7p+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=rhLUg/AqsNmMOQ+Sj400aIrVevOB+5L0EirzVI8Abi4=; b=ts5xJt2BMtyzNAo/XCjVUlOg7Dxo1G8yOqdryJLuVBHY0DtWfHCA1ModN6XCJYEzVC A9co3V+zd/INy/9QYVUoH1SHrDoV3ZGCmTgubhdpe9QTtwC7vHxhipfHgQ8bC0/VDrGO rp02ulzzHlenVi8ujscBbf6C3g/1D61A3O9vzzVxVY0kp8E9hia/du+YrbIjQJsM79nO iSRg/exHb6QkrSOgL0UZcfGPzcSdnxW1i0b9RhStJsDCqFKpAfp/T3axL6JYG+o4PyPm 1fyMF+TXGHDalckllowVvzZbK3Xssvep4coeeYU/q0O/HBstz/0l0ktyhYYlXIdfhmND 1kxg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b8-v6si18651270plb.125.2018.07.10.19.25.29; Tue, 10 Jul 2018 19:25:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732801AbeGKC0K (ORCPT + 99 others); Tue, 10 Jul 2018 22:26:10 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:45634 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732482AbeGKCYG (ORCPT ); Tue, 10 Jul 2018 22:24:06 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fd4lc-0003K4-SI; Wed, 11 Jul 2018 02:22:08 +0000 From: Al Viro To: Linus Torvalds Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Miklos Szeredi Subject: [RFC][PATCH 25/42] document ->atomic_open() changes Date: Wed, 11 Jul 2018 03:21:49 +0100 Message-Id: <20180711022206.12571-25-viro@ZenIV.linux.org.uk> X-Mailer: git-send-email 2.9.5 In-Reply-To: <20180711022206.12571-1-viro@ZenIV.linux.org.uk> References: <20180711021136.GN30522@ZenIV.linux.org.uk> <20180711022206.12571-1-viro@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Al Viro Signed-off-by: Al Viro --- Documentation/filesystems/Locking | 2 +- Documentation/filesystems/porting | 8 ++++++++ Documentation/filesystems/vfs.txt | 18 ++++++++++-------- 3 files changed, 19 insertions(+), 9 deletions(-) diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 2c391338c675..04c867981375 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -64,7 +64,7 @@ prototypes: void (*update_time)(struct inode *, struct timespec *, int); int (*atomic_open)(struct inode *, struct dentry *, struct file *, unsigned open_flag, - umode_t create_mode, int *opened); + umode_t create_mode); int (*tmpfile) (struct inode *, struct dentry *, umode_t); locking rules: diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index 17bb4dc28fae..c68ea9294b5f 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -602,3 +602,11 @@ in your dentry operations instead. dentry separately, and it now has request_mask and query_flags arguments to specify the fields and sync type requested by statx. Filesystems not supporting any statx-specific features may ignore the new arguments. +-- +[mandatory] + ->atomic_open() calling conventions have changed. Gone is int *opened, + along with FILE_OPENED/FILE_CREATED. In place of those we have + FMODE_OPENED/FMODE_CREATED, set in file->f_mode. Additionally, return + value for 'called finish_no_open(), open it yourself' case has become + 0, not 1. Since finish_no_open() itself is returning 0 now, that part + does not need any changes in ->atomic_open() instances. diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 829a7b7857a4..d564cc44397e 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -386,7 +386,7 @@ struct inode_operations { ssize_t (*listxattr) (struct dentry *, char *, size_t); void (*update_time)(struct inode *, struct timespec *, int); int (*atomic_open)(struct inode *, struct dentry *, struct file *, - unsigned open_flag, umode_t create_mode, int *opened); + unsigned open_flag, umode_t create_mode); int (*tmpfile) (struct inode *, struct dentry *, umode_t); }; @@ -496,13 +496,15 @@ otherwise noted. atomic_open: called on the last component of an open. Using this optional method the filesystem can look up, possibly create and open the file in - one atomic operation. If it cannot perform this (e.g. the file type - turned out to be wrong) it may signal this by returning 1 instead of - usual 0 or -ve . This method is only called if the last component is - negative or needs lookup. Cached positive dentries are still handled by - f_op->open(). If the file was created, the FILE_CREATED flag should be - set in "opened". In case of O_EXCL the method must only succeed if the - file didn't exist and hence FILE_CREATED shall always be set on success. + one atomic operation. If it wants to leave actual opening to the + caller (e.g. if the file turned out to be a symlink, device, or just + something filesystem won't do atomic open for), it may signal this by + returning finish_no_open(file, dentry). This method is only called if + the last component is negative or needs lookup. Cached positive dentries + are still handled by f_op->open(). If the file was created, + FMODE_CREATED flag should be set in file->f_mode. In case of O_EXCL + the method must only succeed if the file didn't exist and hence FMODE_CREATED + shall always be set on success. tmpfile: called in the end of O_TMPFILE open(). Optional, equivalent to atomically creating, opening and unlinking a file in given directory. -- 2.11.0