linux-kernel - linux-next: manual merge of the vfs tree with the nfs tree

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>] [day] [month] [year] [list]

Message-Id: <20120702113609.f466f618f983d93de5e167ce@canb.auug.org.au>
Date:	Mon, 2 Jul 2012 11:36:09 +1000
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Miklos Szeredi <mszeredi@...e.cz>,
	Andy Adamson <andros@...app.com>,
	Trond Myklebust <trond.myklebust@....uio.no>
Subject: linux-next: manual merge of the vfs tree with the nfs tree

Hi Al,

Today's linux-next merge of the vfs tree got a conflict in
fs/nfs/nfs4proc.c between commit 6e5b587d2f42 ("NFSv4.1 handle OPEN
O_CREATE mdsthreshold") from the nfs tree and commit 2cca3fbfc12b ("nfs:
clean up ->create in nfs_rpc_ops") from the vfs tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au

diff --cc fs/nfs/nfs4proc.c
index 7d387cb,267be3c..0000000
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@@ -2804,39 -2779,22 +2804,25 @@@ static int nfs4_proc_readlink(struct in
  }
  
  /*
-  * Got race?
-  * We will need to arrange for the VFS layer to provide an atomic open.
-  * Until then, this create/open method is prone to inefficiency and race
-  * conditions due to the lookup, create, and open VFS calls from sys_open()
-  * placed on the wire.
-  *
-  * Given the above sorry state of affairs, I'm simply sending an OPEN.
-  * The file will be opened again in the subsequent VFS open call
-  * (nfs4_proc_file_open).
-  *
-  * The open for read will just hang around to be used by any process that
-  * opens the file O_RDONLY. This will all be resolved with the VFS changes.
+  * This is just for mknod.  open(O_CREAT) will always do ->open_context().
   */
- 
  static int
  nfs4_proc_create(struct inode *dir, struct dentry *dentry, struct iattr *sattr,
-                  int flags, struct nfs_open_context *ctx)
+ 		 int flags)
  {
- 	struct dentry *de = dentry;
+ 	struct nfs_open_context *ctx;
  	struct nfs4_state *state;
- 	struct rpc_cred *cred = NULL;
 +	struct nfs4_threshold **thp = NULL;
- 	fmode_t fmode = 0;
  	int status = 0;
  
- 	if (ctx != NULL) {
- 		cred = ctx->cred;
- 		de = ctx->dentry;
- 		fmode = ctx->mode;
+ 	ctx = alloc_nfs_open_context(dentry, FMODE_READ);
+ 	if (IS_ERR(ctx))
+ 		return PTR_ERR(ctx);
+ 
++	if (ctx != NULL)
 +		thp = &ctx->mdsthreshold;
- 	}
  	sattr->ia_mode &= ~current_umask();
- 	state = nfs4_do_open(dir, de, fmode, flags, sattr, cred, thp);
 -	state = nfs4_do_open(dir, dentry, ctx->mode, flags, sattr, ctx->cred, NULL);
++	state = nfs4_do_open(dir, dentry, ctx->mode, flags, sattr, ctx->cred, thp);
  	d_drop(dentry);
  	if (IS_ERR(state)) {
  		status = PTR_ERR(state);

Content of type "application/pgp-signature" skipped