Date: Mon, 14 Oct 2013 17:40:28 -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: <1381797628.75337.YahooMailBasic@web125802.mail.ne1.yahoo.com> In-Reply-To: <201304221143.54205.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John,=20 I got this working thanks to your help. I have to run my app on an old syst= em and I can't get shm_map to work on a 32-bit build. I've traced it to vm_fault_wire() r= eturning 2 (KERN_PROTECTION_FAILURE). This stuff is above my pay grade. Is there some option that I'm missing? I = need to make this work and it's driving me crazy! Laurie -------------------------------------------- On Mon, 4/22/13, John Baldwin <jhb@freebsd.org> wrote: Subject: Re: shm_map questions To: freebsd-net@freebsd.org Cc: "Laurie Jennings" <laurie_jennings_1977@yahoo.com> Date: Monday, April 22, 2013, 8:43 AM =20 On Saturday, April 20, 2013 9:18:24 pm Laurie Jennings wrote: > That does help. Is there a way for the kernel to access the memory map=20 directlyby segment name? =20 There is not, no.=A0 It wouldn't be hard to add, but the issue there is that the existing shm_map/unmap API assumes you have an open file descriptor and is tailored to having a userland process provide memory rather than having the kernel provide a SHM to userland, so even if you added a shm_open() that gave you a reference on the underlying shm object (struct shmfd *), you would need a slightly different shm_map/unmap that took that object directly rather than an fd. =20 > Laurie >=20 > --- On Thu, 4/18/13, John Baldwin <jhb@freebsd.org> wrote: >=20 > 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 >=20 > 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=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 creates=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=20 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. >=20 > The kernel mapping bumps the refcount on the underlying vm object, so it=20 will > 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 should=20 be > something like: >=20 > struct mydata *foo; >=20 > foo->fp =3D fget(fd); > shm_map(fp, &foo->p); > /* Don't call fdrop */ >=20 > and then when unmapping: >=20 > struct mydata *foo; >=20 > shm_unmap(foo->fp, foo->p); > fdrop(foo->fp); >=20 > > 2) Is there a way for the kernel process to know when the user process has=20 > goneaway? A ref count? >=20 > You can install a process_exit EVENTHANDLER if you want to destroy this when=20 a > process goes away.=A0 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. >=20 > > 3) Does a SHM_ANON segment persist as long as the kernel has it mapped, or=20 > doesit get garbage collected when the creating user process terminates? >=20 > 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. >=20 > > 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=20 with=20 > shm_map()User process terminates.User process runs again, opening segment=20 /foo > > Does the kernel need to re-map, or is the original mapping valid? >=20 > 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 processes > can shm_open /foo and mmap it and they will all share the same memory. >=20 > You could even share a SHM_ANON fd among multiple processes by passing it > across a UNIX domain socket. >=20 > Hope this helps. >=20 > --=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" > _______________________________________________ > 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" >=20 =20 --=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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1381797628.75337.YahooMailBasic>