Re: ramdisk corruption problems - was: RE: pivot_root and initrd kern el panic woes

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == 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