Skip site navigation (1)Skip section navigation (2)
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 dire=
ctlyby 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 use=
r=20
processand a kernel module. I'm having some problems with shm_map and there=
=20
doesn't seem to be much info on it.
> Im not sure what happened to the memory when the user process that create=
s=20
it terminates.=A0 I have some questions.
> 1) Does the kernel mapping keep the segment from being garbage collected=
=20
when the use process that creates it terminated? I've experienced shm_unmap=
()=20
panic when tryingto unmap a segment
> scenario:=A0=20
> User process Maps SegmentKernel maps it=A0 with shm_map()User Process=20
TerminatesKernel tries to shm_unmap() and it panics.

The kernel mapping bumps the refcount on the underlying vm object, so it wi=
ll
not go away.=A0 OTOH, you should be keeping your own reference count on the
associated fd so that you can call shm_unmap().=A0 That is, the model shoul=
d be
something like:

struct mydata *foo;

foo->fp =3D 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 ha=
s=20
goneaway? A ref count?

You can install a process_exit EVENTHANDLER if you want to destroy this whe=
n a
process goes away.=A0 I have used shm_map/unmap for other objects that alre=
ady
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, o=
r=20
doesit get garbage collected when the creating user process terminates?

It goes away when the backing 'struct file' goes away.=A0 If you follow the=
=20
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=
=20
userprocess?
> Example:
> User process creates shm segment with path /fooKernel Maps shm segment wi=
th=20
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.=A0 Multiple proces=
ses
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.

--=20
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>