On Wed, 20 Apr 2011, Rick Macklem wrote:
Well, its value will be consistent, but not necessarily the "up to date"
value set by another thread, if I understood alc@'s recent post.
If you haven't yet read it, take a look at his post today on freebsd-hackers@
under the Subject
Re: SMP question w.r.
On Wed, 20 Apr 2011, Pawel Jakub Dawidek wrote:
On Wed, Apr 20, 2011 at 08:09:32AM -0400, Rick Macklem wrote:
+ 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);
r
>
> This is not that easy, I'm afraid. You need to ask yourself a question
> what you are trying to protect from. Here, the mutex only guarantees
> to
> have consistent view of the nm_maxfilesize field. For example if this
> field modification wouldn't be atomic you would need the mutex to
> ensur
On Wed, Apr 20, 2011 at 08:09:32AM -0400, Rick Macklem wrote:
> > > + 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);
> > > + }
> >
> > + 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 pro
On Wed, Apr 20, 2011 at 01:15:22AM +, Rick Macklem wrote:
> Author: rmacklem
> Date: Wed Apr 20 01:15:22 2011
> New Revision: 220877
> URL: http://svn.freebsd.org/changeset/base/220877
>
> Log:
> Modify the offset + size checks for read and write in the
> experimental NFS client to take ca
Author: rmacklem
Date: Wed Apr 20 01:15:22 2011
New Revision: 220877
URL: http://svn.freebsd.org/changeset/base/220877
Log:
Modify the offset + size checks for read and write in the
experimental NFS client to take care of overflows for the calls
above the buffer cache layer in a manner simil
