In reviewing the nfs writeback logic I'm a little puzzled as to why the
allocation of the wb_args for the request is delayed until the
nfs_wback_lock code is run. This introduces an awkward blocking
operation after the page is locked, and even the possibility of sitting
on the RPC delay queue waiting for memory. In addition, it appears that
an attempt to cancel the write at this point wouldn't work -- setting
the CANCEL flag and calling rpc_exit would not stop the write from
proceeding after the allocation returns. (rpc_exit just clears the
tk_action, but we're already in the action function.)
Unless there's a compelling reason to hold off on the allocation, I
would prefer to either put the args into the nfs write request itself
(the args structure isn't that big), or else allocate it when the
request is first initialized. Do you see any problems with making this
change?
Also, it appears that after canceling a write request the request isn't
awakened, and so a truncated page might sit for quite a while on the
writeback list before being released. I think it would be better for
rpc_exit to awaken the task after setting the action to null, so that
everything would get cleaned up sooner. Does this sound reasonable to
you?
Regards,
Bill