Re: GNU accepted as a mentoring organization in GSOC 2014

2014-03-21 Thread Yue Lu
Hi!

On Fri, Mar 21, 2014 at 12:50 AM, Thomas Schwinge
wrote:

> Yes, that is possible,
> <
> http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page#9._I_am_a_student_who_has_already
> >.
> The requirement, of course, is that you're still a student,
> <
> http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page#2._Whos_eligible_to_participate_as_a
> >.
> The deadline for sending in your project proposal is tomorrow, so don't
> miss that, and it will then be discussed in the following weeks.
>

Thank you! I have submitted  my proposal.


-- 
Yue Lu (陆岳)


libpager fixes

2014-03-21 Thread Justus Winter
Hi ;)

I'm trying to find and fix a deadlock that could very well be in
libpager.  So I came up with this patch, analogous to
901c61a1d25e7c8963e51012760a82730eda1910.  I'm not yet sure I found
"my" deadlock, but not releasing this lock here could very well be
problematic.

I just want to mention that I got an assertion failure in ext2fs once
after I applied this patch.  Not sure if it is related or not.

Justus




[PATCH 1/2] libpager: fix comment of pager_change_attributes

2014-03-21 Thread Justus Winter
* libpager/pager-attr.c: Fix comment.
* libpager/pager.h: Likewise.
---
 libpager/pager-attr.c | 6 +++---
 libpager/pager.h  | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/libpager/pager-attr.c b/libpager/pager-attr.c
index 7629f1d..47da12a 100644
--- a/libpager/pager-attr.c
+++ b/libpager/pager-attr.c
@@ -19,9 +19,9 @@
 #include 
 
 /* Change the attributes of the memory object underlying pager P.
-   Args MAY_CACHE and COPY_STRATEGY are as for 
-   memory_object_change_atributes.  Wait for the kernel to report completion
-   off WAIT is set.*/
+   Arguments MAY_CACHE and COPY_STRATEGY are as for
+   memory_object_change_atributes.  Wait for the kernel to report
+   completion if WAIT is set.  */
 void
 pager_change_attributes (struct pager *p,
 boolean_t may_cache,
diff --git a/libpager/pager.h b/libpager/pager.h
index 75ff108..d0572af 100644
--- a/libpager/pager.h
+++ b/libpager/pager.h
@@ -111,9 +111,9 @@ pager_offer_page (struct pager *pager,
  vm_address_t buf);  
 
 /* Change the attributes of the memory object underlying pager PAGER.
-   Args MAY_CACHE and COPY_STRATEGY are as for
-   memory_object_change_atributes.  Wait for the kernel to report completion
-   off WAIT is set.*/
+   Arguments MAY_CACHE and COPY_STRATEGY are as for
+   memory_object_change_atributes.  Wait for the kernel to report
+   completion if WAIT is set.  */
 void
 pager_change_attributes (struct pager *pager,
 boolean_t may_cache,
-- 
1.9.0




[PATCH 2/2] libpager: fix potential deadlock

2014-03-21 Thread Justus Winter
This patch releases the interlock before doing an rpc call, analogous
to 901c61a1d25e7c8963e51012760a82730eda1910.

* libpager/pager-attr.c (pager_change_attributes): Release interlock
before calling memory_object_change_attributes, to let the callbacks
take it.
---
 libpager/pager-attr.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libpager/pager-attr.c b/libpager/pager-attr.c
index 47da12a..ad1560e 100644
--- a/libpager/pager-attr.c
+++ b/libpager/pager-attr.c
@@ -77,11 +77,14 @@ pager_change_attributes (struct pager *p,
}
 }  
 
+  pthread_mutex_unlock (&p->interlock);
   memory_object_change_attributes (p->memobjcntl, may_cache, copy_strategy,
   wait ? p->port.port_right : MACH_PORT_NULL);
   
   if (wait)
 {
+  pthread_mutex_lock (&p->interlock);
+
   while (ar->attrs_pending)
pthread_cond_wait (&p->wakeup, &p->interlock);
 
@@ -92,7 +95,7 @@ pager_change_attributes (struct pager *p,
ar->next->prevp = ar->prevp;
  free (ar);
}
+
+  pthread_mutex_unlock (&p->interlock);
 }
-  
-  pthread_mutex_unlock (&p->interlock);
 }
-- 
1.9.0




Re: libpager fixes

2014-03-21 Thread Justus Winter
Quoting Justus Winter (2014-03-21 13:57:51)
> Hi ;)
> 
> I'm trying to find and fix a deadlock that could very well be in
> libpager.  So I came up with this patch, analogous to
> 901c61a1d25e7c8963e51012760a82730eda1910.  I'm not yet sure I found
> "my" deadlock, but not releasing this lock here could very well be
> problematic.
> 
> I just want to mention that I got an assertion failure in ext2fs once
> after I applied this patch.  Not sure if it is related or not.

I forgot to mention, it was the assertion I removed here:

http://lists.gnu.org/archive/html/bug-hurd/2014-03/msg00099.html

Justus