Date: 13 Apr 1999 15:32:39 +0300 From: Ville-Pertti Keinonen <will@iki.fi> To: hackers@freebsd.org Cc: thorpej@nas.nasa.gov, dillon@apollo.backplane.com Subject: Re: read() and pread() syscalls Message-ID: <86yajw1z14.fsf@not.demophon.com> In-Reply-To: will@iki.fi's message of "13 Apr 1999 10:40:11 %2B0300" References: <199904121916.MAA07413@lestat.nas.nasa.gov> <86zp4d0y16.fsf@not.demophon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
will@iki.fi (Ville-Pertti Keinonen) writes:
> thorpej@nas.nasa.gov (Jason Thorpe) writes:
> > Geez, how did this get implemented in FreeBSD?! It's certainly not that
> > complicated.
> I don't have a NetBSD machine around, but it might apply to NetBSD, as
> well, unless NetBSD keeps the vnode exclusively locked for the entire
> duration of a VOP_READ, even if it blocks.
I checked the source - the above is true, so NetBSD (and 4.4 BSD-Lite2
in general) should not be affected as severely as recent versions of
FreeBSD (this still doesn't mean that it's safe).
The significant difference is the locking modes given to the vn_lock
call. Unlike NetBSD/Lite2, FreeBSD uses a shared lock in vn_read.
Currently (in releases starting with 3.0) FreeBSD is particularly
unpredictable, e.g. if you have two processes reading large chunks of
data from the same file descriptor, you can end up with results like:
data = a b c d
process 1 reads a, c, process 2 reads a, d
process 1 reads a, b, process 2 reads b, d
process 1 reads a, c, process 2 reads a, c
etc.
In other words, some chunks are returned twice, some are skipped.
Additionally, lseek(2) is free to change the offset in the file
descriptor while read/write operations are blocked. This applies to
all versions of all 4.4 BSD derivatives AFAIK.
If this behavior is considered a bug (in the absence of multithreaded
processes, it isn't necessarily one, shared file descriptors between
processes only strictly need offset consistency for synchronized,
sequential operations), the correct fix is to add a lock to the file
descriptor object (using a lock on the vnode to prevent the
modification of the f_offset of a file would obviously be bogus).
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86yajw1z14.fsf>