On 27.09.2012 22:35, Leonardo Chiquitto wrote:
> On Thu, Sep 27, 2012 at 1:35 AM, Ian Kent <raven@xxxxxxxxxx> wrote:
[]
>> I can confirm that there is no directory removal and re-create going on.
>>
>> Checking for that lead me to discover this mistake which fixes the
>> symptom we're seeing:
>>
>> autofs4 - fix reset pending flag on mount fail
>>
>> From: Ian Kent <raven@xxxxxxxxxx>
>>
>> In autofs4_d_automount(), if a mount fail occurs the AUTOFS_INF_PENDING
>> mount pending flag is not cleared.
>>
>> One effect of this is when using the "browse" option, directory entry
>> attributes show up with all "?"s due to the incorrect callback and
>> subsequent failure return (when in fact no callback should be made).
>
> Reported-and-tested-by: Leonardo Chiquitto <lchiquitto@xxxxxxx>
>
> Ian,
>
> I just tested the patch here and confirmed it works perfectly.
Is it a -stable (kernel) material? This and the previous change,
the locking logic fix/rework? Both appears to be needed for all
current 3.x stable trees...
Thanks,
/mjt
>> fs/autofs4/root.c | 6 ++++--
>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>
>>
>> diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
>> index 75e5f1c..8c4292f 100644
>> --- a/fs/autofs4/root.c
>> +++ b/fs/autofs4/root.c
>> @@ -392,10 +392,12 @@ static struct vfsmount *autofs4_d_automount(struct path *path)
>> ino->flags |= AUTOFS_INF_PENDING;
>> spin_unlock(&sbi->fs_lock);
>> status = autofs4_mount_wait(dentry);
>> - if (status)
>> - return ERR_PTR(status);
>> spin_lock(&sbi->fs_lock);
>> ino->flags &= ~AUTOFS_INF_PENDING;
>> + if (status) {
>> + spin_unlock(&sbi->fs_lock);
>> + return ERR_PTR(status);
>> + }
>> }
>> done:
>> if (!(ino->flags & AUTOFS_INF_EXPIRING)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
