Messages in this thread | | | Date | Tue, 23 Jul 2002 17:06:15 +0200 | From | Olaf Kirch <> | Subject | Re: [NFS] Locking patches (generic & nfs) |
| |
On Tue, Jul 23, 2002 at 04:56:32PM +0200, Trond Myklebust wrote: > I disagree. As it stands, NLM_NEVER == (~(unsigned long)0), and "when" > is unsigned long, so the only thing we need to protect against is if > we hit the 'magic value' NLM_NEVER. Note that the time_before_eq() > comparison ensures that we cope well with jiffy wraparound etc, so the > entry should *not* in fact get put at the end of the list as you > claimed. > > With the above change (plus your change to set NLM_NEVER=0x7fffffff), > we end up never retrying locks that just happen to have been put on > the list at a time when the value of 'jiffies' happens to be > 0x7fffffff.
But as it is today, all blocked locks get inserted at the end of the list because time_before_eq does a signed comparison! With the unpatched code, when you have a blocked lock, and the conflicting lock is removed, lockd will never send out a GRANTED_MSG. Because the blocked lock is at the end of the list, and never picked up.
That's the real reason for changing NLM_NEVER to the largest _signed_ quantity. And if you do that, you need to deal with jiffy wraparound. Maybe the way I did it is not optiomal, I concede. But you can't leave it at ~0UL.
> Patrice Dumas recently did some work on implementing this both for > NLMv1,2,3 and NLM4, so I was planning on integrating his changes into > 2.4.20.
As you can see from the patch, it's not really much you need to add. The functionality is all there, one only needs to decode the GRANTED_RES call rather than dropping it.
Olaf -- Olaf Kirch | Anyone who has had to work with X.509 has probably okir@suse.de | experienced what can best be described as ---------------+ ISO water torture. -- Peter Gutmann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |