From owner-freebsd-arch Sat Dec 2 10: 6:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id BD31D37B6A1 for ; Sat, 2 Dec 2000 10:06:10 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G4Y0066FCY87W@falla.videotron.net> for arch@FreeBSD.ORG; Sat, 2 Dec 2000 13:06:09 -0500 (EST) Date: Sat, 02 Dec 2000 13:06:54 -0500 (EST) From: Bosko Milekic Subject: Re: zero copy code review In-reply-to: <14888.9802.415926.434956@grasshopper.cs.duke.edu> To: Andrew Gallatin Cc: "Kenneth D. Merry" , arch@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 1 Dec 2000, Andrew Gallatin wrote: > I'm still not sure I understand your objection. There's some code in > socow_cowsetup() which uses sf bufs. Prior to allocating the sf_buf, it > does some of its own fiddling with the page and introduces some state > the sf_buf_free() wouldn't know how to clear. socow_iodone() undoes > that fiddling and then calls sf_buf_free() to free the sfbuf. Isn't > it better to call sf_buf_free() than to cut & paste the code? > > <...> Yeah, you're right. I overlooked things when I posted that. > I see your point. This was copied, (bug for bug ;-), from sendfile itself. > Look at line 1700 or so of kern/uipc_syscalls.c.. This bug should > probaby be fixed there too.. Yep. You're right. This is a bug that is the result of some of my code, actually (a while back, before I got the commit bit). When the wait code was first introduced, I had to go around the code looking for places previously expecting that M_WAIT will never return NULL and make them deal with the possibility. As we see now, I overlooked the fact that the sf_buf has to be freed in the case of failure, in the sendfile(2) case. Good thing we caught this now, and David Greenman was extremely quick to roll a diff. > The nfs sf_buf_alloc() calls will be made from either a process > context (when doing a zero-copy send over a socket) or from the > context of an nfsiod for the NFS code, so I think this should > be safe. Excellent. > Thanks! > > Drew Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message