shm_map questions

Barney Cordoba barney_cordoba at yahoo.com
Tue Oct 15 20:25:29 UTC 2013 

The FD is RDWR. It's the same code that works on a 64bit build. It fails here:

int
vm_fault(vm_map_t map, vm_offset_t vaddr, vm_prot_t fault_type, int fault_flags)
{
        struct thread *td;
        int result;
 
        td = curthread;
        if ((td->td_pflags & TDP_NOFAULTING) != 0)
                return (KERN_PROTECTION_FAILURE);
....


Laurie



On Tuesday, October 15, 2013 4:22 PM, Barney Cordoba <barney_cordoba at yahoo.com> wrote:
 
The FD is RDWR. It's the same code that works on a 64bit build. It fails here:

int
vm_fault(vm_map_t map, vm_offset_t vaddr, vm_prot_t fault_type, int fault_flags)
{
        struct thread *td;
        int result;
 
        td = curthread;
        if ((td->td_pflags & TDP_NOFAULTING) != 0)
                return (KERN_PROTECTION_FAILURE);
....


Laurie



On Tuesday, October 15, 2013 3:48 PM, John Baldwin <jhb at freebsd.org> wrote:
 
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 at freebsd.org> wrote:
> 
>  Subject: Re: shm_map questions
>  To: freebsd-net at freebsd.org
>  Cc: "Laurie Jennings" <laurie_jennings_1977 at 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 at freebsd.org>
>  wrote:
>  > 
>  > From: John Baldwin <jhb at freebsd.org>
>  > Subject: Re: shm_map questions
>  > To: freebsd-net at freebsd.org
>  > Cc: "Laurie Jennings" <laurie_jennings_1977 at 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 at freebsd.org
>  mailing list
>  > http://lists.freebsd.org/mailman/listinfo/freebsd-net
>  > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>  > _______________________________________________
>  > freebsd-net at freebsd.org
>  mailing list
>  > http://lists.freebsd.org/mailman/listinfo/freebsd-net
>  > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"

>  > 
>  
>  -- 
>  John Baldwin
>  _______________________________________________
>  freebsd-net at freebsd.org
>  mailing list
>  http://lists.freebsd.org/mailman/listinfo/freebsd-net
>  To unsubscribe, send
 any mail to "freebsd-net-unsubscribe at freebsd.org"
>  
> 

-- 
John Baldwin
_______________________________________________
freebsd-net at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"

More information about the freebsd-net mailing list