[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-nfsv4
Subject:    Cthon-04 errors
From:       bfields () fieldses ! org (J !  Bruce Fields)
Date:       2005-04-13 22:09:56
Message-ID: 20050414020953.GB21552 () fieldses ! org
[Download RAW message or body]

On Wed, Apr 13, 2005 at 06:55:06PM -0700, Marc Eshel wrote:
> If we are on the subject of cthon-04 let me add a problem that I saw while 
> testing nfsv4 locks.
> - running on linux 2.6.12-rc2-CITI_NFS4_ALL-1
> - test 7.1 gets EIO error for a read operation which got translated from 
> EBADF on the server side.
> Tracing the problem it turns out that if the underling file system doesn't 
> support sendfile(), which is true in my case, than vfs_readv() checks for 
> FMODE_READ and returns EBADF if it is not on. (see inclused code 
> segments). I think that it is a problem in the nfsv4 code that is doing a 
> read operation without  FMOD_READ being set.

Interesting.  So an open determines a (client, open_owner, inode) tuple
(where the open_owner is a client-provided string identifying the
"opener"--process id or whatever).  The first time we see such a tuple
we do a vfs open and save the resulting struct file.  Subsequent opens
and open_downgrades may change the access (allow read, allow write,
etc.), but we keep using the same struct file.

That may mean we end up, for example, doing reads with a struct file
originally opened for write only.  I'd wondered whether that could be a
problem.  I guess so....  I'll work on a patch.

--b.

[prev in list] [next in list] [prev in thread] [next in thread]