Have a "test" function change the value it is testing can
be confusing, particularly as a future patch will be calling
this function twice.

So move the update for 'last_used' to avoid repeat expiry
to the place where the final determination on what to expire is known.

Reviewed-by: Ian Kent <ra...@themaw.net>
Tested-by: Ian Kent <ra...@themaw.net>
Signed-off-by: NeilBrown <ne...@suse.de>
---
 fs/autofs4/expire.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index bee939efca2b..af09dada91bc 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -30,12 +30,6 @@ static inline int autofs4_can_expire(struct dentry *dentry,
                /* Too young to die */
                if (!timeout || time_after(ino->last_used + timeout, now))
                        return 0;
-
-               /* update last_used here :-
-                  - obviously makes sense if it is in use now
-                  - less obviously, prevents rapid-fire expire
-                    attempts if expire fails the first time */
-               ino->last_used = now;
        }
        return 1;
 }
@@ -541,6 +535,8 @@ int autofs4_expire_run(struct super_block *sb,
 
        spin_lock(&sbi->fs_lock);
        ino = autofs4_dentry_ino(dentry);
+       /* avoid rapid-fire expire attempts if expiry fails */
+       ino->last_used = now;
        ino->flags &= ~AUTOFS_INF_EXPIRING;
        complete_all(&ino->expire_complete);
        spin_unlock(&sbi->fs_lock);
@@ -567,6 +563,8 @@ int autofs4_do_expire_multi(struct super_block *sb, struct 
vfsmount *mnt,
                ret = autofs4_wait(sbi, dentry, NFY_EXPIRE);
 
                spin_lock(&sbi->fs_lock);
+               /* avoid rapid-fire expire attempts if expiry fails */
+               ino->last_used = now;
                ino->flags &= ~AUTOFS_INF_EXPIRING;
                complete_all(&ino->expire_complete);
                spin_unlock(&sbi->fs_lock);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to