linux-kernel - atomic open (was Re: [RFC 01/10] Split up struct nameidata)

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: <E1IJ3LG-0005HX-00@dorka.pomaz.szeredi.hu>
Date:	Thu, 09 Aug 2007 10:26:02 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	hch@...radead.org
CC:	agruen@...e.de, linux-kernel@...r.kernel.org, jjohansen@...e.de,
	jblunck@...e.de, ezk@...sunysb.edu, jsipek@...sunysb.edu
Subject: atomic open (was Re: [RFC 01/10] Split up struct nameidata)

> On Wed, Aug 08, 2007 at 07:16:23PM +0200, Andreas Gruenbacher wrote:
> > Split up struct nameidata into struct vfs_lookup with the lookup result
> > and intent and the remaining fields for performing an actual lookup.
> 
> Looks good as a start, but please don't put a struct path in there,
> as the vfsmount will go away from the lookup intent as soon as we have
> a new inode operation for atomic create + open, and not having it in the
> struct path will make that removal a lot less painfull.

Btw, is the atomic open/create/truncate operation any further than
conceptual phase?  Have we worked out what to do with the ugly "create
follows symlink" case?

I'm just about to add another hack to the VFS to enable atomic
open+truncate for fuse, and have a feeling that it will provoke some
not so positive reactions ;)

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