Ack: [Precise][Quantal][SRU] cifs: don't instantiate new dentries in readdir for inodes that need to be revalidated immediately

[Brad Figg]

On 09/09/2013 09:02 AM, Luis Henriques wrote:
> From: Jeff Layton <jlayton at redhat.com>
> 
> BugLink: http://bugs.launchpad.net/bugs/1222442
> 
> David reported that commit c2b93e06 (cifs: only set ops for inodes in
> I_NEW state) caused a regression with mfsymlinks. Prior to that patch,
> if a mfsymlink dentry was instantiated at readdir time, the inode would
> get a new set of ops when it was revalidated. After that patch, this
> did not occur.
> 
> This patch addresses this by simply skipping instantiating dentries in
> the readdir codepath when we know that they will need to be immediately
> revalidated. The next attempt to use that dentry will cause a new lookup
> to occur (which is basically what we want to happen anyway).
> 
> Cc: <stable at vger.kernel.org>
> Cc: "Stefan (metze) Metzmacher" <metze at samba.org>
> Cc: Sachin Prabhu <sprabhu at redhat.com>
> Reported-and-Tested-by: David McBride <dwm37 at cam.ac.uk>
> Signed-off-by: Jeff Layton <jlayton at redhat.com>
> Signed-off-by: Steve French <smfrench at gmail.com>
> (back ported from commit 757c4f6260febff982276818bb946df89c1105aa)
> Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
> ---
>  fs/cifs/readdir.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c
> index 4c37ed4..52a820a 100644
> --- a/fs/cifs/readdir.c
> +++ b/fs/cifs/readdir.c
> @@ -96,6 +96,14 @@ cifs_readdir_lookup(struct dentry *parent, struct qstr *name,
>  		dput(dentry);
>  	}
>  
> +	/*
> +	 * If we know that the inode will need to be revalidated immediately,
> +	 * then don't create a new dentry for it. We'll end up doing an on
> +	 * the wire call either way and this spares us an invalidation.
> +	 */
> +	if (fattr->cf_flags & CIFS_FATTR_NEED_REVAL)
> +		return NULL;
> +
>  	dentry = d_alloc(parent, name);
>  	if (dentry == NULL)
>  		return NULL;
> 


-- 
Brad Figg brad.figg at canonical.com http://www.canonical.com