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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

Hi Al,

Today's linux-next merge of the vfs tree got conflicts in fs/cifs/dir.c,
fs/nfs/dir.c, fs/nfs/nfs4proc.c, ipc/mqueue.c, fs/open.c and fs/namei.c
between commits from the nfs tree and commits from the vfs tree.

These were all caused by the rebase of the vfs tree after it had been
merged into the nfs tree.  This is one reason you should not rebase a
published tree (especially so close to the merge window).

I fixed up all the conflicts which meant taking some files from one tree
and some from the other.  Now, unless the nfs tree is rebuilt (and tested
etc) we will have duplicates of a large number of patches in Linus'
tree :-(
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

Hi Al,

Today's linux-next merge of the vfs tree got a conflict in:

  fs/nfs/nfs4file.c

between commit:

  926ea40a7ee2 ("NFSv4: Fix a compile warning about no prototype for nfs4_ioctl()")

from the nfs tree and commit:

  04b38d601239 ("vfs: pull btrfs clone API to vfs layer")

from the vfs tree.

I fixed it up (the latter removed the code fixed in the former) and can
carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]

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@canb.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);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]