Date: Sat, 20 Apr 2013 18:18:24 -0700 (PDT) From: Laurie Jennings <laurie_jennings_1977@yahoo.com> To: freebsd-net@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: shm_map questions Message-ID: <1366507104.55455.YahooMailClassic@web125804.mail.ne1.yahoo.com> In-Reply-To: <201304180950.18349.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
That does help. Is there a way for the kernel to access the memory map directlyby segment name? Laurie --- On Thu, 4/18/13, John Baldwin <jhb@freebsd.org> wrote: From: John Baldwin <jhb@freebsd.org> Subject: Re: shm_map questions To: freebsd-net@freebsd.org Cc: "Laurie Jennings" <laurie_jennings_1977@yahoo.com> Date: Thursday, April 18, 2013, 6:50 AM On Thursday, April 11, 2013 10:58:14 am Laurie Jennings wrote: > Im working on a simple project that shares a memory segment between a user processand a kernel module. I'm having some problems with shm_map and there doesn't seem to be much info on it. > Im not sure what happened to the memory when the user process that creates it terminates. I have some questions. > 1) Does the kernel mapping keep the segment from being garbage collected when the use process that creates it terminated? I've experienced shm_unmap() panic when tryingto unmap a segment > scenario: > User process Maps SegmentKernel maps it with shm_map()User Process TerminatesKernel tries to shm_unmap() and it panics. The kernel mapping bumps the refcount on the underlying vm object, so it will not go away. OTOH, you should be keeping your own reference count on the associated fd so that you can call shm_unmap(). That is, the model should be something like: struct mydata *foo; foo->fp = fget(fd); shm_map(fp, &foo->p); /* Don't call fdrop */ and then when unmapping: struct mydata *foo; shm_unmap(foo->fp, foo->p); fdrop(foo->fp); > 2) Is there a way for the kernel process to know when the user process has goneaway? A ref count? You can install a process_exit EVENTHANDLER if you want to destroy this when a process goes away. I have used shm_map/unmap for other objects that already had a reference count so I did my shm_unmap when that object was destroyed. > 3) Does a SHM_ANON segment persist as long as the kernel has it mapped, or doesit get garbage collected when the creating user process terminates? It goes away when the backing 'struct file' goes away. If you follow the model above of keeping a reference count on the associated struct file then it won't go away until you fdrop() after the shm_unmap. > 4) When using a named segment, can the kernel "reuse" a mapping for a new userprocess? > Example: > User process creates shm segment with path /fooKernel Maps shm segment with shm_map()User process terminates.User process runs again, opening segment /foo > Does the kernel need to re-map, or is the original mapping valid? The mapping is not per-process, so if you have mapped a shm for /foo and mapped it, it will stay mapped until you call shm_unmap. Multiple processes can shm_open /foo and mmap it and they will all share the same memory. You could even share a SHM_ANON fd among multiple processes by passing it across a UNIX domain socket. Hope this helps. -- John Baldwin _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Apr 21 03:41:56 2013 Return-Path: <owner-freebsd-net@FreeBSD.ORG> Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CAD06E36 for <freebsd-net@freebsd.org>; Sun, 21 Apr 2013 03:41:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 764B21DD for <freebsd-net@freebsd.org>; Sun, 21 Apr 2013 03:41:55 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r3L2aFX0084747 for <freebsd-net@freebsd.org>; Sat, 20 Apr 2013 21:36:16 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Sat Apr 20 21:36:16 2013 Message-ID: <5173509A.905@denninger.net> Date: Sat, 20 Apr 2013 21:36:10 -0500 From: Karl Denninger <karl@denninger.net> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Steven Hartland <killing@multiplay.co.uk> Subject: Re: Odd NAT/IPSEC question -- help! :-) References: <517333A8.7020704@denninger.net> <394C5F1CA58741F9965A5782A1117153@multiplay.co.uk> In-Reply-To: <394C5F1CA58741F9965A5782A1117153@multiplay.co.uk> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>; List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sun, 21 Apr 2013 03:41:56 -0000 I don't think so -- gre is not involved in the config. On 4/20/2013 7:59 PM, Steven Hartland wrote: > ----- Original Message ----- From: "Karl Denninger" <karl@denninger.net> > ... >> My "ordinary" NAT entry is simply "nat 1 ip from any to any via em1", >> which works fine for ordinary "on the client" traffic; no problems with >> that. > ... > > Just a stab in the dark, as I vaguely remember something similar, do you > also need to configure your nat for gre as well as ip? > > Regards > Steve > > > ===============================================> This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > > > %SPAMBLOCK-SYS: Matched [+killing@multiplay.co.uk], message ok -- -- Karl Denninger /The Market Ticker ®/ <http://market-ticker.org>; Cuda Systems LLC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1366507104.55455.YahooMailClassic>