linux-kernel - Re: [RFC PATCH 00/11] autofs4 - update autofs4 to deal with VFS locking change

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

Message-ID: <Pine.LNX.4.64.0909240835390.25940@cobra.newdream.net>
Date:	Thu, 24 Sep 2009 09:10:01 -0700 (PDT)
From:	Sage Weil <sage@...dream.net>
To:	Ian Kent <raven@...maw.net>
cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	Christoph Hellwig <hch@...radead.org>,
	Andreas Dilger <adilger@....com>,
	Yehuda Saheh <yehuda@...dream.net>,
	Jim Garlick <garlick@...l.gov>
Subject: Re: [RFC PATCH 00/11] autofs4 - update autofs4 to deal with VFS
 locking change

On Thu, 24 Sep 2009, Ian Kent wrote:

> A change to the VFS path walk locking is needed to resolve an issue
> identified by Sage Weil. This locking change requires significant
> changes to the autofs4 module to allow it to callback to userspace
> without introducing a deadlock.
> 
> To cope with the change the autofs4 module needs to redirect mount
> requests from ->d_revalidate() to ->lookup() if the directory
> inode mutex is held when a callback needs to be done. Note that we
> cannot redirect these requests when the mutex is not held because,
> to function correctly, the mutex must be held over both revalidate
> and lookup.
> 
> Of the patches in the series most are cleanups and refactoring done
> to keep the real change in "autofs4 - always use lookup for lookup"
> as clean as possible. Unfortuneately, there is still quite a bit
> left in it.
> 
> Also, I need confirmation that the patch that changes the VFS path
> walk locking is in fact correct, or at least like for like to what
> will be submitted. I had some difficulty with the original patches
> that were paosted. The patch in question below is "vfs: make
> real_lookup do dentry revalidation with i_mutex held".

It looks identical to be the original two folded into one patch.  I'll 
repost those two now, freshened against Linus' tree.  The first has just 
the functional change, and the cleanup is in the second (as per 
Christoph's review).

> I've done quite a bit of fairly heavy stress testing of the patch
> series and they (finally) hold up to it. Although I have also
> managed to uncover a locking bug in the user space daemon as a
> result, ;)

I'm glad some other good has come of it.  Thanks, Ian, for carrying this 
through!

sage

 
> 
> ---
> 
> Ian Kent (10):
>       autofs4 - always use lookup for lookup
>       autofs4 - rename dentry to expiring in autofs4_lookup_expiring()
>       autofs4 - rename dentry to active in autofs4_lookup_active()
>       autofs4 - eliminate d_unhashed in path walk checks
>       autofs4 - cleanup active and expire lookup
>       autofs4 - renamer unhashed to active in autofs4_lookup()
>       autofs4 - use autofs_info for pending flag
>       autofs4 - use macro for need mount check
>       autofs4 - use macros for expiring list
>       autofs4 - use macros for active list handling
> 
> Sage Weil (1):
>       Subject: [PATCH] vfs: make real_lookup do dentry revalidation with i_mutex held
> 
> 
>  fs/autofs4/autofs_i.h |   38 +++
>  fs/autofs4/expire.c   |    8 -
>  fs/autofs4/inode.c    |    2 
>  fs/autofs4/root.c     |  616 ++++++++++++++++++++++++++++++++-----------------
>  fs/namei.c            |   58 ++---
>  5 files changed, 480 insertions(+), 242 deletions(-)
> 
> -- 
> Ian
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/