Date: Tue, 15 Oct 2013 13:25:26 -0700 (PDT) From: Barney Cordoba <barney_cordoba@yahoo.com> To: John Baldwin <jhb@freebsd.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: shm_map questions Message-ID: <1381868726.83793.YahooMailNeo@web121606.mail.ne1.yahoo.com> In-Reply-To: <1381868572.32631.YahooMailNeo@web121602.mail.ne1.yahoo.com> References: <1381797628.75337.YahooMailBasic@web125802.mail.ne1.yahoo.com> <201310151521.25231.jhb@freebsd.org> <1381868572.32631.YahooMailNeo@web121602.mail.ne1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The FD is RDWR. It's the same code that works on a 64bit build. It fails he=
re:=0A=0Aint=0Avm_fault(vm_map_t map, vm_offset_t vaddr, vm_prot_t fault_ty=
pe, int fault_flags)=0A{=0A=A0 =A0 =A0 =A0 struct thread *td;=0A=A0 =A0 =A0=
=A0 int result;=0A=A0=0A=A0 =A0 =A0 =A0 td =3D curthread;=0A=A0 =A0 =A0 =
=A0 if ((td->td_pflags & TDP_NOFAULTING) !=3D 0)=0A=A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 return (KERN_PROTECTION_FAILURE);=0A....=0A=0A=0ALaurie=0A=0A=0A=0A=
On Tuesday, October 15, 2013 4:22 PM, Barney Cordoba <barney_cordoba@yahoo.=
com> wrote:=0A =0AThe FD is RDWR. It's the same code that works on a 64bit =
build. It fails here:=0A=0Aint=0Avm_fault(vm_map_t map, vm_offset_t vaddr, =
vm_prot_t fault_type, int fault_flags)=0A{=0A=A0 =A0 =A0 =A0 struct thread =
*td;=0A=A0 =A0 =A0 =A0 int result;=0A=A0=0A=A0 =A0 =A0 =A0 td =3D curthread=
;=0A=A0 =A0 =A0 =A0 if ((td->td_pflags & TDP_NOFAULTING) !=3D 0)=0A=A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 return (KERN_PROTECTION_FAILURE);=0A....=0A=0A=0ALa=
urie=0A=0A=0A=0AOn Tuesday, October 15, 2013 3:48 PM, John Baldwin <jhb@fre=
ebsd.org> wrote:=0A =0AOn Monday, October 14, 2013 8:40:28 pm Laurie Jennin=
gs wrote:=0A> John, =0A> =0A> I got this working thanks to your help. I hav=
e to run my app on an old =0Asystem and I can't=0A> get shm_map to work on =
a 32-bit build.=A0 I've traced it to vm_fault_wire() =0Areturning 2 (KERN_P=
ROTECTION_FAILURE).=0A> This stuff is above my pay grade. Is there some opt=
ion that I'm missing? I =0Aneed to make this work and it's=0A> driving me c=
razy!=0A=0AThe fd you pass into the kernel has to be the result of a shm_op=
en() with =0AO_RDWR or I think the mapping can end up being read-only which=
might cause =0Athis.=0A=0A> Laurie=0A> =0A> =0A>=0A ----------------------=
----------------------=0A> On Mon, 4/22/13, John Baldwin <jhb@freebsd.org> =
wrote:=0A> =0A>=A0 Subject: Re: shm_map questions=0A>=A0 To: freebsd-net@fr=
eebsd.org=0A>=A0 Cc: "Laurie Jennings" <laurie_jennings_1977@yahoo.com>=0A>=
=A0 Date: Monday, April 22, 2013, 8:43 AM=0A>=A0 =0A>=A0 On Saturday, April=
20, 2013 9:18:24=0A>=A0 pm Laurie Jennings wrote:=0A>=A0 > That does help.=
Is there a way for the kernel to access=0A>=A0 the memory map =0A>=A0 dire=
ctlyby segment name?=0A>=A0 =0A>=A0 There is not, no.=A0 It wouldn't be har=
d to add, but the=0A>=A0 issue there is that=0A>=A0 the existing shm_map/un=
map API assumes you have an open file=0A>=A0 descriptor and=0A>=A0 is tailo=
red to having a userland process provide memory=0A>=A0 rather than having=
=0A>=A0 the kernel provide a SHM to userland, so even if you added a=0A>=A0=
shm_open() that=0A>=A0 gave you a reference on the underlying shm object (=
struct=0A>=A0 shmfd *), you would=0A>=A0 need a slightly different shm_map/=
unmap that took that=0A>=A0 object directly=0A>=A0 rather than an fd.=0A>=
=A0 =0A>=A0 > Laurie=0A>=A0 > =0A>=A0 > --- On Thu, 4/18/13, John Baldwin <=
jhb@freebsd.org>=0A>=A0 wrote:=0A>=A0 > =0A>=A0 > From: John Baldwin <jhb@f=
reebsd.org>=0A>=A0 > Subject: Re: shm_map questions=0A>=A0 > To: freebsd-ne=
t@freebsd.org=0A>=A0 > Cc: "Laurie Jennings" <laurie_jennings_1977@yahoo.co=
m>=0A>=A0 > Date:=0A Thursday, April 18, 2013, 6:50 AM=0A>=A0 > =0A>=A0 > O=
n Thursday, April 11, 2013 10:58:14 am Laurie Jennings=0A>=A0 wrote:=0A>=A0=
> > Im working on a simple project that shares a=0A>=A0 memory segment bet=
ween a user =0A>=A0 > processand a kernel module. I'm having some problems=
=0A>=A0 with shm_map and there =0A>=A0 > doesn't seem to be much info on it=
.=0A>=A0 > > Im not sure what happened to the memory when the=0A>=A0 user p=
rocess that creates =0A>=A0 > it terminates.=A0 I have some questions.=0A>=
=A0 > > 1) Does the kernel mapping keep the segment from=0A>=A0 being garba=
ge collected =0A>=A0 > when the use process that creates it terminated?=0A =
I've=0A>=A0 experienced =0A>=A0 shm_unmap() =0A>=A0 > panic when tryingto u=
nmap a segment=0A>=A0 > > scenario:=A0 =0A>=A0 > > User process Maps Segmen=
tKernel maps it=A0 with=0A>=A0 shm_map()User Process =0A>=A0 > TerminatesKe=
rnel tries to shm_unmap() and it panics.=0A>=A0 > =0A>=A0 > The kernel mapp=
ing bumps the refcount on the underlying=0A>=A0 vm object, so it =0A>=A0 wi=
ll=0A>=A0 > not go away.=A0 OTOH, you should be keeping your own=0A>=A0 ref=
erence count on the=0A>=A0 > associated fd so that you can call shm_unmap()=
. =0A>=A0 That is, the model should =0A>=A0 be=0A>=A0 >=0A something like:=
=0A>=A0 > =0A>=A0 > struct mydata *foo;=0A>=A0 > =0A>=A0 > foo->fp =3D fget=
(fd);=0A>=A0 > shm_map(fp, &foo->p);=0A>=A0 > /* Don't call fdrop */=0A>=A0=
> =0A>=A0 > and then when unmapping:=0A>=A0 > =0A>=A0 > struct mydata *foo=
;=0A>=A0 > =0A>=A0 > shm_unmap(foo->fp, foo->p);=0A>=A0 > fdrop(foo->fp);=
=0A>=A0 > =0A>=A0 > > 2) Is there a way for the kernel process to know=0A>=
=A0 when the user process has =0A>=A0 > goneaway? A ref count?=0A>=A0 > =0A=
>=A0 > You can install a process_exit EVENTHANDLER=0A if you want=0A>=A0 to=
destroy this when =0A>=A0 a=0A>=A0 > process goes away.=A0 I have used shm=
_map/unmap for=0A>=A0 other objects that already=0A>=A0 > had a reference c=
ount so I did my shm_unmap when that=0A>=A0 object was destroyed.=0A>=A0 > =
=0A>=A0 > > 3) Does a SHM_ANON segment persist as long as the=0A>=A0 kernel=
has it mapped, or =0A>=A0 > doesit get garbage collected when the creating=
user=0A>=A0 process terminates?=0A>=A0 > =0A>=A0 > It goes away when the b=
acking 'struct file' goes=0A>=A0 away.=A0 If you follow the =0A>=A0 > model=
above of keeping a reference count on the=0A>=A0 associated struct=0A file=
then=0A>=A0 > it won't go away until you fdrop() after the=0A>=A0 shm_unma=
p.=0A>=A0 > =0A>=A0 > > 4) When using a named segment, can the kernel=0A>=
=A0 "reuse" a mapping for a new =0A>=A0 > userprocess?=0A>=A0 > > Example:=
=0A>=A0 > > User process creates shm segment with path=0A>=A0 /fooKernel Ma=
ps shm segment =0A>=A0 with =0A>=A0 > shm_map()User process terminates.User=
process runs=0A>=A0 again, opening segment =0A>=A0 /foo=0A>=A0 > > Does th=
e kernel need to re-map, or is the original=0A>=A0 mapping valid?=0A>=A0 > =
=0A>=A0 > The mapping is not per-process, so if you have=0A mapped a=0A>=A0=
shm for /foo and=0A>=A0 > mapped it, it will stay mapped until you call=0A=
>=A0 shm_unmap.=A0 Multiple processes=0A>=A0 > can shm_open /foo and mmap i=
t and they will all share=0A>=A0 the same memory.=0A>=A0 > =0A>=A0 > You co=
uld even share a SHM_ANON fd among multiple=0A>=A0 processes by passing it=
=0A>=A0 > across a UNIX domain socket.=0A>=A0 > =0A>=A0 > Hope this helps.=
=0A>=A0 > =0A>=A0 > -- =0A>=A0 > John Baldwin=0A>=A0 > ____________________=
___________________________=0A>=A0 > freebsd-net@freebsd.org=0A>=A0 mailing=
list=0A>=A0 > http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A>=A0=
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=
=0A>=A0 > _______________________________________________=0A>=A0 > freebsd-=
net@freebsd.org=0A>=A0 mailing list=0A>=A0 > http://lists.freebsd.org/mailm=
an/listinfo/freebsd-net=0A>=A0 > To unsubscribe, send any mail to "freebsd-=
net-unsubscribe@freebsd.org"=0A=0A>=A0 > =0A>=A0 =0A>=A0 -- =0A>=A0 John Ba=
ldwin=0A>=A0 _______________________________________________=0A>=A0 freebsd=
-net@freebsd.org=0A>=A0 mailing list=0A>=A0 http://lists.freebsd.org/mailma=
n/listinfo/freebsd-net=0A>=A0 To unsubscribe, send=0A any mail to "freebsd-=
net-unsubscribe@freebsd.org"=0A>=A0 =0A> =0A=0A-- =0AJohn Baldwin=0A_______=
________________________________________=0Afreebsd-net@freebsd.org mailing =
list=0Ahttp://lists.freebsd.org/mailman/listinfo/freebsd-net=0ATo unsubscri=
be, send any mail to "freebsd-net-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG Wed Oct 16 02:58:21 2013
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@smarthost.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTP id 4D40EDAF;
Wed, 16 Oct 2013 02:58:21 +0000 (UTC)
(envelope-from kevlo@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
[IPv6:2001:1900:2254:206c::16:87])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 22B292987;
Wed, 16 Oct 2013 02:58:21 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9G2wK3l042363;
Wed, 16 Oct 2013 02:58:20 GMT
(envelope-from kevlo@freefall.freebsd.org)
Received: (from kevlo@localhost)
by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9G2wKku042362;
Wed, 16 Oct 2013 02:58:20 GMT (envelope-from kevlo)
Date: Wed, 16 Oct 2013 02:58:20 GMT
Message-Id: <201310160258.r9G2wKku042362@freefall.freebsd.org>
To: swildner@gmail.com, kevlo@FreeBSD.org, freebsd-net@FreeBSD.org
From: kevlo@FreeBSD.org
Subject: Re: bin/175974: ppp(8): logic issue
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: Wed, 16 Oct 2013 02:58:21 -0000
Synopsis: ppp(8): logic issue
State-Changed-From-To: open->closed
State-Changed-By: kevlo
State-Changed-When: Wed Oct 16 02:55:50 UTC 2013
State-Changed-Why:
Fixed. Your assumption is correct. Only protocol numbers 0x21 through 0xFA
would be encrypted.
http://www.freebsd.org/cgi/query-pr.cgi?pr=175974
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1381868726.83793.YahooMailNeo>