tree 869ce6a2a51581d09011aeb5e804b0d1ab39a7b9
parent 8fafa90082ab18859d97627fc454edf12f7efbff
author J. Bruce Fields <bfields@citi.umich.edu> 1205881219 -0400
committer J. Bruce Fields <bfields@citi.umich.edu> 1222726390 -0400

lockd: don't depend on lockd main loop to end grace

End lockd's grace period using schedule_delayed_work() instead of a
check on every pass through the main loop.

After a later patch, we'll depend on lockd to end its grace period even
if it's not currently handling requests; so it shouldn't depend on being
woken up from the main loop to do so.

Also, Nakano Hiroaki (who independently produced a similar patch)
noticed that the current behavior is buggy in the face of jiffies
wraparound:

	"lockd uses time_before() to determine whether the grace period
	has expired. This would seem to be enough to avoid timer
	wrap-around issues, but, unfortunately, that is not the case.
	The time_* family of comparison functions can be safely used to
	compare jiffies relatively close in time, but they stop working
	after approximately LONG_MAX/2 ticks. nfsd can suffer this
	problem because the time_before() comparison in lockd() is not
	performed until the first request comes in, which means that if
	there is no lockd traffic for more than LONG_MAX/2 ticks we are
	screwed.

	"The implication of this is that once time_before() starts
	misbehaving any attempt from a NFS client to execute fcntl()
	will be received with a NLM_LCK_DENIED_GRACE_PERIOD message for
	25 days (assuming HZ=1000). In other words, the 50 seconds grace
	period could turn into a grace period of 50 days or more.

	"Note: This bug was analyzed independently by Oda-san
	<oda@valinux.co.jp> and myself."

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Cc: Nakano Hiroaki <nakano.hiroaki@oss.ntt.co.jp>
Cc: Itsuro Oda <oda@valinux.co.jp>