RE: File locking via fcntl() broken for NFS mounts in RHEL4u2

["Marc Mondragon" <marcmo foxriver com>]

Good to see your still alive ....

Marc Mondragon
 
Fox River Financial Resources/Ritchie Capital Investments, Ltd.
2100 Enterprise Avenue
Geneva, IL  60134
marcmo foxriver com

-----Original Message-----
From: Steve Dickson [mailto:SteveD redhat com] 
Sent: Wednesday, March 08, 2006 9:52 AM
To: Stowell Davison
Cc: Red Hat Enterprise Linux 4 (Nahant) Discussion List
Subject: Re: File locking via fcntl() broken for NFS mounts in RHEL4u2

Stowell Davison wrote:
> 
> Steve Dickson wrote:
> 
>> Stowell Davison wrote:
>>
>>> We rebuilt kernel-2.6.9-30.EL.src.rpm with the patch from
>>> comment 2 of bz 182137 incorporated into it (i686, smp).
>>> It did not help -- the test script exhibits the same failure
>>> behavior as before.
>>
>>
>> Well in my testing the patch in bz182137 did indeed fix
>> the problem so I'm a little surprised it didn't fix it
>> in your world...
>>
>> The problem (that I was seeing) was the GRANT messages being send
>> by the server are not making to the client do to a bug in
>> the RPC code. The patch in bz182137 fixes that bug...
>>
>> So if possible could you please post a bzip2 binary
>> tethereal network trace capturing the network traffic
>> when you run your test script. Something similar to:
>>
>>     tethereal -w /tmp/data.pcap host <server> ; bzip2 /tmp/data.pcap
>>
> I'm not sure we can do that -- we have installed kernel.org 2.6.15 so
Ok.. but note there has been a very recent upstream patch that has
to do with two thread unlocking the same lock... This will be
in our kernels very soon... so you might want to make sure you
kernel has that patch as well...

> we can proceed with application testing pending receipt of a fixed
> Red Hat kernel, but let me be sure I understand what you're asking
> for and I will pass on the request to our sysadmin.  He may have
> a system he can provision especially to get the test data.
> 
> We would do the following:
> 1.  Rebuild kernel-2.6.9-30.EL.src.rpm with the patch from
> comment 2 of bz 182137 on the NFS client.
Or I can supply one for you...

> 2.  Install it on the NFS client.
> 3.  Start up tethereal on the NFS client.  If our NFS server is, for 
> example,
> 192.168.5.17 then we would issue the command:
> tethereal -w /tmp/data.pcap host 192.168.5.17
> 4.  Execute the python test script on the NFS client.
> 5.  After the python test script finishes, kill the
> tethereal process with "kill" or ctrl-c, compress
> data.pcap, and post it.
Make sure you bzip2 the data.cap file before posting and/or
send it to me directly...
> 
> Is that right?
Yes...

> Does the tethereal data have to be from a system with the
> patched 2.6.9.30 kernel, or would data from a system
> with the stock rhel4u2 (2.6.9.22) tell you what you need
> to know?  We still have some systems with that stock
> kernel.
Well for tethereal to be able to "see" traffic the client
is generating, you'll probably have to run it on the either
the patched client or the server your running against...
Most network traces can not "see" past network switches...

steved.