Attachment 148245 Details for Bug 227249 – respun patch that just includes the bit for nfs_proc_link

[patch] respun patch that just includes the bit for nfs_proc_link

linux-2.6.9-nfs-proc-link-reval.patch (text/plain), 2.67 KB, created by Jeff Layton on 2007-02-16 21:08:44 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jeff Layton

Created: 2007-02-16 21:08:44 UTC

Size: 2.67 KB

patch

obsolete

>From: Jeff Layton <jlayton@redhat.com>
>To: rhkernel-list@redhat.com
>Subject: Re: [RHEL4.6 PATCH] NFS: add some missing post-op inode revalidations (BZ 227249)
>
>Peter Staubach wrote:
>> Jeff Layton wrote:
>>> Peter Staubach wrote:
>>>> Jeff Layton wrote:
>>>>> This problem was noticed at Connectathon when running the 
>>>>> connectathon test
>>>>> suite against a (particularly fast) Solaris 10 NFS server. Most of 
>>>>> the time,
>>>>> after creating a hardlink, it would fail to notice that the i_nlink 
>>>>> had been
>>>>> incremented.
>>>>>
>>>>> The issue is due to a missing nfs_mark_for_revalide in 
>>>>> nfs_proc_link. The
>>>>> upstream patch below adds that plus some other missing 
>>>>> nfs_mark_for_revalidate
>>>>> calls in nfs_rename, nfs_sillyrename, and nfs_safe_remove. They may 
>>>>> add some
>>>>> extra calls on the wire, but I'm thinking they shouldn't add many, 
>>>>> and these
>>>>> are calls that should be getting done anyway.
>>>>>
>>>>> This was tested by me at Connectathon against the same server where 
>>>>> I saw
>>>>> the problem and with a simple reproducer I came up with locally. It 
>>>>> fixes
>>>>> BZ 227249.
>>>>>
>>>>>   
>>>>
>>>> A few comments --
>>>>
>>>> Would you mind attaching the actual RHEL-4 patch which was tested?
>>>> This patch may apply, but with a great deal of fuzz at best.
>>>>
>>>> What are the symptoms of the problem with renaming a file?
>>>>
>>>>    Thanx...
>>>>
>>>>       ps
>>>>
>>>
>>> That is the actual patch that was tested. It applies with some offset
>>> but no fuzz.
>>>
>> 
>> Sorry, okay, I think that I would prefer if you would post the RHEL-4
>> patch and not the upstream patch.
>> 
>> Posting the actual changes which were tested is generally a good
>> policy, I think.
>> 
>>> I had no problems with renaming the file, but figured it was best to
>>> pull down the entire upstream patch that contained the fix we needed.
>>> I had been told in the past that that was preferable to cherry-picking
>>> just the parts we needed. Do you think I should just do that instead?
>>
>> I don't see the value that those portions bring and including things
>> like that seems questionable to me.  Unless we can find some value
>> in those new lines, than I would prefer to not include them.
>> 
>>    Thanx...
>> 
>>       ps
>> 
>
>Ok, that makes sense. How about this patch instead? I just did a quick test
>and this also corrects the reproducer.
>
>--- linux-2.6.9/fs/nfs/proc.c.linkreval
>+++ linux-2.6.9/fs/nfs/proc.c
>@@ -375,6 +375,7 @@ nfs_proc_link(struct inode *inode, struc
> 
> 	dprintk("NFS call  link %s\n", name->name);
> 	status = rpc_call(NFS_CLIENT(inode), NFSPROC_LINK, &arg, NULL, 0);
>+	nfs_mark_for_revalidate(inode);
> 	nfs_mark_for_revalidate(dir);
> 	dprintk("NFS reply link: %d\n", status);
> 	return status;

Actions: View | Diff

Attachments on bug 227249: 147289 | 148245