From: Ian Kent <raven@themaw.net>
To: Sage Weil <sage@newdream.net>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
Al Viro <viro@ZenIV.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
Andreas Dilger <adilger@sun.com>,
Yehuda Saheh <yehuda@newdream.net>,
Jim Garlick <garlick@llnl.gov>
Subject: Re: [RFC PATCH 00/11] autofs4 - update autofs4 to deal with VFS locking change
Date: Mon, 28 Sep 2009 15:53:40 +0800 [thread overview]
Message-ID: <4AC06B84.9010004@themaw.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0909240835390.25940@cobra.newdream.net>
Sage Weil wrote:
> 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).
Yes, after checking, the patch I was using is functionally the same as
the combination of the two you re-posted. So all is good for may part.
Ian
prev parent reply other threads:[~2009-09-28 7:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-24 8:21 [RFC PATCH 00/11] autofs4 - update autofs4 to deal with VFS locking change Ian Kent
2009-09-24 8:21 ` [RFC PATCH 01/11] Subject: [PATCH] vfs: make real_lookup do dentry revalidation with i_mutex held Ian Kent
2009-09-24 8:21 ` [RFC PATCH 02/11] autofs4 - use macros for active list handling Ian Kent
2009-09-24 8:21 ` [RFC PATCH 03/11] autofs4 - use macros for expiring list Ian Kent
2009-09-24 8:21 ` [RFC PATCH 04/11] autofs4 - use macro for need mount check Ian Kent
2009-09-24 8:21 ` [RFC PATCH 05/11] autofs4 - use autofs_info for pending flag Ian Kent
2009-09-24 8:21 ` [RFC PATCH 06/11] autofs4 - renamer unhashed to active in autofs4_lookup() Ian Kent
2009-09-24 8:22 ` [RFC PATCH 07/11] autofs4 - cleanup active and expire lookup Ian Kent
2009-09-24 8:22 ` [RFC PATCH 08/11] autofs4 - eliminate d_unhashed in path walk checks Ian Kent
2009-09-24 8:22 ` [RFC PATCH 09/11] autofs4 - rename dentry to active in autofs4_lookup_active() Ian Kent
2009-09-24 8:22 ` [RFC PATCH 10/11] autofs4 - rename dentry to expiring in autofs4_lookup_expiring() Ian Kent
2009-09-24 8:22 ` [RFC PATCH 11/11] autofs4 - always use lookup for lookup Ian Kent
2009-09-24 9:19 ` [RFC PATCH 00/11] autofs4 - update autofs4 to deal with VFS locking change Ian Kent
2009-09-24 16:10 ` Sage Weil
2009-09-28 7:41 ` Ian Kent
2009-09-28 7:53 ` Ian Kent [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AC06B84.9010004@themaw.net \
--to=raven@themaw.net \
--cc=adilger@sun.com \
--cc=garlick@llnl.gov \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sage@newdream.net \
--cc=viro@ZenIV.linux.org.uk \
--cc=yehuda@newdream.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.