Date: Tue, 15 Oct 2013 15:21:25 -0400 From: John Baldwin <jhb@freebsd.org> To: Laurie Jennings <laurie_jennings_1977@yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: shm_map questions Message-ID: <201310151521.25231.jhb@freebsd.org> In-Reply-To: <1381797628.75337.YahooMailBasic@web125802.mail.ne1.yahoo.com> References: <1381797628.75337.YahooMailBasic@web125802.mail.ne1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, October 14, 2013 8:40:28 pm Laurie Jennings wrote: > John, > > I got this working thanks to your help. I have to run my app on an old system and I can't > get shm_map to work on a 32-bit build. I've traced it to vm_fault_wire() returning 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! The fd you pass into the kernel has to be the result of a shm_open() with O_RDWR or I think the mapping can end up being read-only which might cause this. > 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 > > 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 > directlyby segment name? > > There is not, no. 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. > > > 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" > > _______________________________________________ > > 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" > > > > -- > 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" > > -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201310151521.25231.jhb>