> > + tmp_off = uio->uio_offset + uio->uio_resid;
> > + mtx_lock(&nmp->nm_mtx);
> > + if (tmp_off > nmp->nm_maxfilesize || tmp_off < uio->uio_offset) {
> > + mtx_unlock(&nmp->nm_mtx);
> > return (EFBIG);
> > + }
> > + mtx_unlock(&nmp->nm_mtx);
>
> I don't think you need the lock to protect nm_maxfilesize. Can it
> change
> from under us? My guess is that it is set on mount time and is not
> modified afterwards.
>
Good question.
For NFSv3 - it is only modified by the first fsinfo RPC and that normally
happens at mount time, as you guessed above. (This is consistent with
RFC1813, which defines the fsinfo RPC as getting non-volatile information.)
For NFSv4 - it gets it each time VFS_STATFS() happens. I am not sure that
this is correct, but I don't know of anywhere in RFC3530 where it states
that this attribute will not change. In practice, I suspect that servers
seldom, if ever, change it.
So, it is unlikely to change and I'd be comfortable taking the mutex lock
off the check for it, if others are? (As you might be aware, I started a
thread on hackers-freebsd@ where my question was basically "do you need to
mutex lock when you read a global variable". My main concern there was a
case that I'm working on w.r.t. forced dismounts. jhb@ suggested that he
thinks it is good practice to always lock, to play it safe. At least that
was my interpretation?)
rick
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
