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 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@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@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@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
_______________________________________________
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 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?pr5974
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1381868726.83793.YahooMailNeo>