From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: GFS2: Add atomic_open support
Date: Thu, 6 Jun 2013 18:53:12 +0100
Message-ID: <20130606175312.GG13110@ZenIV.linux.org.uk>
References: <1370530212.2744.34.camel@menhir>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: cluster-devel@redhat.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, jlayton@redhat.com,
	"J. Bruce Fields" <bfields@fieldses.org>
To: Steven Whitehouse <swhiteho@redhat.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <1370530212.2744.34.camel@menhir>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Thu, Jun 06, 2013 at 03:50:12PM +0100, Steven Whitehouse wrote:
> 
> The following patch implements atomic_open for GFS2. This is mostly
> straightforward, however there is one corner case which I've had to
> deal with, beyond what would normally be expected for a local
> filesystem.

Broken - what will happen if you hit a symlink, for starters?  On everything
handled locally you should just return finish_no_open(file, dentry) and
let the caller deal with that; the only cases that might make sense to
handle in ->atomic_open() are regular files and directories.  For gfs2 it
should be just regular files.  While we are at it, do you even need
->private_data for gfs2 directories?