staging: lustre: llite: Trust creates in revalidate too.
authorOleg Drokin <oleg.drokin@intel.com>
Sun, 29 Jan 2017 00:04:54 +0000 (19:04 -0500)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 3 Feb 2017 12:01:37 +0000 (13:01 +0100)
By forcing creates to always go via lookup we lose some
important caching benefits too.
Instead let's trust creates with positive cached entries.

Then we have 3 possible outcomes:
1. Negative dentry - we go via atomic_open and do the create
   by name there.
2. Positive dentry, no contention - we just go straight to
   ll_intent_file_open and open by fid.
3. positive dentry, contention - by the time we reach the server,
   the inode is gone. We get ENOENT which is unacceptable to return
   from create. But since we know it's a create, we substitute it
   with ESTALE and VFS retries again with LOOKUP_REVAL set, we catch
   that in revalidate and force a lookup (same path as before this
   patch).

Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8371
Reviewed-on: http://review.whamcloud.com/21168
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/staging/lustre/lustre/llite/dcache.c
drivers/staging/lustre/lustre/llite/file.c

index 65bf0c401b445852fe289f249200c4286053d6fe..966f580e26fb80be368540fc61cd5ba8eec1cf63 100644 (file)
@@ -247,17 +247,14 @@ static int ll_revalidate_dentry(struct dentry *dentry,
                return 1;
 
        /*
-        * if open&create is set, talk to MDS to make sure file is created if
-        * necessary, because we can't do this in ->open() later since that's
-        * called on an inode. return 0 here to let lookup to handle this.
+        * VFS warns us that this is the second go around and previous
+        * operation failed (most likely open|creat), so this time
+        * we better talk to the server via the lookup path by name,
+        * not by fid.
         */
-       if ((lookup_flags & (LOOKUP_OPEN | LOOKUP_CREATE)) ==
-           (LOOKUP_OPEN | LOOKUP_CREATE))
+       if (lookup_flags & LOOKUP_REVAL)
                return 0;
 
-       if (lookup_flags & (LOOKUP_PARENT | LOOKUP_OPEN | LOOKUP_CREATE))
-               return 1;
-
        if (!dentry_may_statahead(dir, dentry))
                return 1;
 
index a1e51a54779e0dd1ed832a3ccd112089df480632..9870901195595a6afb371c10e3abc289c5c3031e 100644 (file)
@@ -417,6 +417,17 @@ out:
        ptlrpc_req_finished(req);
        ll_intent_drop_lock(itp);
 
+       /*
+        * We did open by fid, but by the time we got to the server,
+        * the object disappeared. If this is a create, we cannot really
+        * tell the userspace that the file it was trying to create
+        * does not exist. Instead let's return -ESTALE, and the VFS will
+        * retry the create with LOOKUP_REVAL that we are going to catch
+        * in ll_revalidate_dentry() and use lookup then.
+        */
+       if (rc == -ENOENT && itp->it_op & IT_CREAT)
+               rc = -ESTALE;
+
        return rc;
 }