From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 05:43:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B270E16A420 for ; Thu, 16 Jun 2005 05:43:58 +0000 (GMT) (envelope-from apachexm@hotmail.com) Received: from hotmail.com (bay19-f19.bay19.hotmail.com [64.4.53.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 263F943F42 for ; Thu, 16 Jun 2005 05:39:36 +0000 (GMT) (envelope-from apachexm@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 Jun 2005 22:39:35 -0700 Message-ID: Received: from 218.76.42.20 by by19fd.bay19.hotmail.msn.com with HTTP; Thu, 16 Jun 2005 05:39:35 GMT X-Originating-IP: [218.76.42.20] X-Originating-Email: [apachexm@hotmail.com] X-Sender: apachexm@hotmail.com In-Reply-To: <42ADCC4F.4090201@elischer.org> From: "Apache Xie" To: freebsd-hackers@freebsd.org Date: Thu, 16 Jun 2005 05:39:35 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 Jun 2005 05:39:35.0960 (UTC) FILETIME=[C7B9C180:01C57235] Subject: Re: contigmalloc() and mmap() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2005 05:43:59 -0000 >I'm unsure about this usage of the timer (callout(?) ) >how does the timer know which buffer pages to remove? >and if each userspace process does an ioctl to allocate a different buffer, >are >the new pages also visible to other processes? Use mmap() we can ensure different process access different buffer in user space without interference. > >in FreeBSD your driver can register with at_exit() in 4.x >and with eventhandler_register() in 5.x or 6.x to have stuff done >when the process exits. Yes, I use this macro and register my handler. > >(there are also at_fork and at_exec handlers too.) >see man at_exit (etc.) in 4.x >and man 9 EVENTHANDLER in 5.x and 6.x > >You could also make a hash table on the PID so that you keep different >information >available for different processes and look them up >using curproc->p_pid (for 4.x) and curthhread->td_proc->p_pid for 5.x and >6.x >to look up the > >Using these primatives you should be able to simulate what you need I >believe. > >>In FreeBSD, the driver works in the same pattern, but when a user process >>mmap driver's buffer (allocated by contigmalloc()) and is killed, then >>when >>another process mmap the same buffer again, sometimes it cannot get >>correct >>data from the mmaped pages, which means the user space virtual aderess may >>not point to the correct physical page of driver's buffer, sometimes the >>OS >>even panic with some information such as "Trap 12, Page not present" etc. > > >sounds like you are getting the buffers confused.. >are you doing correc treference counting on the buffers? > In Linux, before kernel memory is mmap to user space, memory pages must be set a reserved flag, no corresponding operations in FreeBSD, is it right? >> >>And recently, I modified my driver, I allocated a big chunk of contiguous >>physical memory using contigmalloc() in the driver's _attach() function, >>and I use a simple first-fit algorithm to manage this memory myself, which >>mean in ioctl() I use my allocate/deallocate functions instead of >>contigmalloc(), >>in _detach() function contigfree() is called to free the big chunk of >>memory, >>no panic again, but sometimes, process cannot get the correct data from >>the mmaped memory. I don't know why. > > > >it does sound a bit like you are not keeping the information >separated between processes enough. > I find a bug in my test program, because the big chunk memory in my driver is reused by new process, but it don't zero it before using it, so some data last process set interfere the new process. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/