From owner-cvs-all Wed Dec 12 0: 2:30 2001 Delivered-To: cvs-all@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 1681637B417; Wed, 12 Dec 2001 00:02:25 -0800 (PST) Received: (from alfred@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id fBC82Pb43408; Wed, 12 Dec 2001 00:02:25 -0800 (PST) (envelope-from alfred) Message-Id: <200112120802.fBC82Pb43408@freefall.freebsd.org> From: Alfred Perlstein Date: Wed, 12 Dec 2001 00:02:25 -0800 (PST) To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/lib/libc_r/uthread uthread_sendfile.c X-FreeBSD-CVS-Branch: HEAD Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG alfred 2001/12/12 00:02:25 PST Modified files: lib/libc_r/uthread uthread_sendfile.c Log: Fix a number of subtle and evil bugs in the libc_r wrapping of sendfile(2). o) Since we unwrap the sendfile syscall, check the return value of writev(2) to see if it didn't complete all the data. Previously if only a partial writev() succeeded, it would proceed to sendfile(2) even though the headers weren't completely sent. o) Properly adjust the "bytes to send" to take into account sendfile(2)'s behaviour of counting the headers against the bytes to be transfered from the file. o) Correct the problem where EAGAIN was being returned from _sys_sendfile(2) however the wrapper didn't update the 'sent bytes' parameter to take into account for it. This is because sendfile can return EAGAIN even though it has actually transfered data. Special thanks to Justin Erenkrantz for bringing this to my attention and giving an excellent way to reproduce the problem. PR: kern/32684 MFC After: 1 week Revision Changes Path 1.6 +51 -5 src/lib/libc_r/uthread/uthread_sendfile.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message