From owner-freebsd-hackers Tue Apr 13 5:35:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id D2F8214BFA for ; Tue, 13 Apr 1999 05:35:14 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 10215 invoked by uid 1001); 13 Apr 1999 12:32:54 -0000 To: hackers@freebsd.org Cc: thorpej@nas.nasa.gov, dillon@apollo.backplane.com Subject: Re: read() and pread() syscalls References: <199904121916.MAA07413@lestat.nas.nasa.gov> <86zp4d0y16.fsf@not.demophon.com> From: Ville-Pertti Keinonen Date: 13 Apr 1999 15:32:39 +0300 In-Reply-To: will@iki.fi's message of "13 Apr 1999 10:40:11 +0300" Message-ID: <86yajw1z14.fsf@not.demophon.com> Lines: 42 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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