linux-kernel - Re: [PATCH 06/25] vfs: add i_op->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]

Date:	Sat, 24 Mar 2012 10:14:58 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	Christoph Hellwig <hch@...radead.org>, viro@...IV.linux.org.uk,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Trond.Myklebust@...app.com, sfrench@...ba.org, sage@...dream.net,
	ericvh@...il.com
Subject: Re: [PATCH 06/25] vfs: add i_op->atomic_create()

On Tue, Mar 13, 2012 at 03:08:59PM +0100, Miklos Szeredi wrote:
> >> Btw, is there any good reason to keep ->atomic_open and ->atomic_create
> >> separate?  It seems like the instances in general share code anyway.
> >
> > ->atomic_open is called before lookup, ->atomic_create after lookup.
> >
> > How would we differentiate between the two if they were common?  We
> > could have a filesystem flag, but for example CEPH does weird things
> > like using ->atomic_open for !O_CREAT and ->atomic_create for O_CREAT.
> 
> Or let the filesystem do the lookup in ->atomic_open if it wants (and
> pass the need_lookup flag to the filesystem).

That sounds like a much better approch.  And as mentioned by Sarge a lot
of the odd fs behaviour currently probably is because the current atomic
open interface is so awkward that no one really understands it.  We'll
probably be able to clean up a lot of that, but I'd suggest to not try
to cram everything into the initial atomic open support.

--
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/