cleanup i386 pmap_fork()

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

cleanup i386 pmap_fork()

Vladimir Kirillov-2
Hello tech@!

I guess there's no need to acquire pmap locks when there's nothing
to do (USER_LDT unset). s/if defined/ifdef/ for consistency.

Index: pmap.c
===================================================================
RCS file: /cvs/src/sys/arch/i386/i386/pmap.c,v
retrieving revision 1.151
diff -u -p -r1.151 pmap.c
--- pmap.c 30 Nov 2010 19:28:59 -0000 1.151
+++ pmap.c 24 Dec 2010 16:40:47 -0000
@@ -1567,7 +1567,7 @@ pmap_reference(struct pmap *pmap)
  simple_unlock(&pmap->pm_obj.vmobjlock);
 }
 
-#if defined(PMAP_FORK)
+#ifdef PMAP_FORK
 /*
  * pmap_fork: perform any necessary data structure manipulation when
  * a VM space is forked.
@@ -1576,10 +1576,10 @@ pmap_reference(struct pmap *pmap)
 void
 pmap_fork(struct pmap *pmap1, struct pmap *pmap2)
 {
+#ifdef USER_LDT
  simple_lock(&pmap1->pm_obj.vmobjlock);
  simple_lock(&pmap2->pm_obj.vmobjlock);
 
-#ifdef USER_LDT
  /* Copy the LDT, if necessary. */
  if (pmap1->pm_flags & PMF_USER_LDT) {
  union descriptor *new_ldt;
@@ -1597,10 +1597,10 @@ pmap_fork(struct pmap *pmap1, struct pma
  pmap2->pm_flags |= PMF_USER_LDT;
  ldt_alloc(pmap2, new_ldt, len);
  }
-#endif /* USER_LDT */
 
  simple_unlock(&pmap2->pm_obj.vmobjlock);
  simple_unlock(&pmap1->pm_obj.vmobjlock);
+#endif /* USER_LDT */
 }
 #endif /* PMAP_FORK */

Reply | Threaded
Open this post in threaded view
|

Re: cleanup i386 pmap_fork()

Ted Unangst-2
On Fri, Dec 24, 2010 at 11:42 AM, Vladimir Kirillov <[hidden email]> wrote:
> Hello tech@!
>
> I guess there's no need to acquire pmap locks when there's nothing
> to do (USER_LDT unset). s/if defined/ifdef/ for consistency.

PMAP_FORK and USER_LDT are only ever set together, and the
simple_locks don't do anything anyway.  I guess we could just delete
the USERLDT checks if we wanted to clean it up.

Reply | Threaded
Open this post in threaded view
|

Re: cleanup i386 pmap_fork()

Mark Kettenis
> Date: Fri, 24 Dec 2010 16:45:59 -0500
> From: Ted Unangst <[hidden email]>
>
> On Fri, Dec 24, 2010 at 11:42 AM, Vladimir Kirillov <[hidden email]> wrote:
> > Hello tech@!
> >
> > I guess there's no need to acquire pmap locks when there's nothing
> > to do (USER_LDT unset). s/if defined/ifdef/ for consistency.
>
> PMAP_FORK and USER_LDT are only ever set together, and the
> simple_locks don't do anything anyway.  I guess we could just delete
> the USERLDT checks if we wanted to clean it up.

I don't think that would be a good idea.

Reply | Threaded
Open this post in threaded view
|

Re: cleanup i386 pmap_fork()

Philip Guenther-2
On Fri, Dec 24, 2010 at 2:00 PM, Mark Kettenis <[hidden email]>
wrote:
>> Date: Fri, 24 Dec 2010 16:45:59 -0500
>> From: Ted Unangst <[hidden email]>
>>
>> On Fri, Dec 24, 2010 at 11:42 AM, Vladimir Kirillov <[hidden email]>
wrote:

>> > Hello tech@!
>> >
>> > I guess there's no need to acquire pmap locks when there's nothing
>> > to do (USER_LDT unset). s/if defined/ifdef/ for consistency.
>>
>> PMAP_FORK and USER_LDT are only ever set together, and the
>> simple_locks don't do anything anyway.  I guess we could just delete
>> the USERLDT checks if we wanted to clean it up.
>
> I don't think that would be a good idea.

I agree with Mark.  If something is going to be deleted, it should be
those misleading simple_locks.


Philip