linux-kernel - Re: GFS2: Add atomic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1370602469.2768.25.camel@menhir>
Date:	Fri, 07 Jun 2013 11:54:29 +0100
From:	Steven Whitehouse <swhiteho@...hat.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	cluster-devel@...hat.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, jlayton@...hat.com,
	"J. Bruce Fields" <bfields@...ldses.org>
Subject: Re: GFS2: Add atomic_open support

Hi,

On Thu, 2013-06-06 at 18:53 +0100, Al Viro wrote:
> 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?

I'm brewing up another version of the patch at the moment, which I will
post shortly. I don't understand why GFS2 specifically would not want to
do this with both files and directories? Why would it be different to
other filesystems in that respect?

We do need private data for gfs2 directories because that is required
for flock which should work equally well on directories as on regular
files. Potentially we might allocate it later, on the first call to
flock for example, but it has been done at open time so that we don't
have to test for it on every flock call. Also I was hoping to put some
info in there to assist with directory readahead at some stage too,

Steve.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/