>>>>> " " == Andrew Morton <akpm@zip.com.au> writes:
> out_ok:
> if ((IS_SETLK(cmd) || IS_SETLKW(cmd)) && fl->fl_type
> != F_UNLCK) {
> - filemap_fdatasync(inode->i_mapping);
> + status2 = filemap_fdatasync(inode->i_mapping);
> + if (status2 && !status)
> + status = status2;
> down(&inode->i_sem);
> - nfs_wb_all(inode); /* we may have slept */
> + status2 = nfs_wb_all(inode); /* we may have slept */
> + if (status2 && !status)
> + status2 = status;
> up(&inode->i_sem);
> - filemap_fdatawait(inode->i_mapping);
> + status2 = filemap_fdatawait(inode->i_mapping);
> + if (status2 && !status)
> + status = status2;
> nfs_zap_caches(inode);
> } return status;
Hmm. I'm not sure about this hunk...
At this point in the code, we already know that we've been granted a
lock by the server. All we are doing is to try to sync any data that
may have been committed while we were waiting on the lock, in order to
ensure that the act of locking provides a cache coherency point.
IMHO it would be wrong to signal that the lock itself has failed just
because some other process has lost data in the filemap_fdata* calls.
It's a different matter with the nfs_wb_all() call: that indicates
that the process has been signalled, so it may indeed make sense to
return that particular error.
Cheers,
Trond
-
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/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:28 EST