[committed hurd] libports: avoid acquiring global lock in message dispatch

[Justus Winter]

* libports/interrupt-operation.c (ports_S_interrupt_operation): Update
`cancel_threshold' using atomic operations.
* libports/manage-multithread.c (internal_demuxer): Avoid taking the lock.
* libports/ports.h (struct port_info): Mention that one needs atomic
operations to access `cancel_threshold'.
---
 libports/interrupt-operation.c | 14 ++
 libports/manage-multithread.c  |  8 +---
 libports/ports.h   |  2 +-
 3 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/libports/interrupt-operation.c b/libports/interrupt-operation.c
index 943bd4f..5d4b0b7 100644
--- a/libports/interrupt-operation.c
+++ b/libports/interrupt-operation.c
@@ -27,12 +27,18 @@ kern_return_t
 ports_S_interrupt_operation (struct port_info *pi,
 mach_port_seqno_t seqno)
 {
+  mach_port_seqno_t old;
+
   if (!pi)
 return EOPNOTSUPP;
-  pthread_mutex_lock (&_ports_lock);
-  if (pi->cancel_threshold < seqno)
-pi->cancel_threshold = seqno;
-  pthread_mutex_unlock (&_ports_lock);
+
+ retry:
+  old = __atomic_load_n (&pi->cancel_threshold, __ATOMIC_SEQ_CST);
+  if (old < seqno
+  && ! __atomic_compare_exchange_n (&pi->cancel_threshold, &old, seqno,
+   0, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST))
+   goto retry;
+
   ports_interrupt_rpcs (pi);
   return 0;
 }
diff --git a/libports/manage-multithread.c b/libports/manage-multithread.c
index ad22991..58814d2 100644
--- a/libports/manage-multithread.c
+++ b/libports/manage-multithread.c
@@ -178,10 +178,12 @@ ports_manage_port_operations_multithread (struct 
port_bucket *bucket,
}
  else
{
- pthread_mutex_lock (&_ports_lock);
- if (inp->msgh_seqno < pi->cancel_threshold)
+ mach_port_seqno_t cancel_threshold =
+   __atomic_load_n (&pi->cancel_threshold, __ATOMIC_SEQ_CST);
+
+ if (inp->msgh_seqno < cancel_threshold)
hurd_thread_cancel (link.thread);
- pthread_mutex_unlock (&_ports_lock);
+
  status = demuxer (inp, outheadp);
  ports_end_rpc (pi, &link);
}
diff --git a/libports/ports.h b/libports/ports.h
index a625b47..f02edb4 100644
--- a/libports/ports.h
+++ b/libports/ports.h
@@ -48,7 +48,7 @@ struct port_info
   struct port_class *class;
   refcounts_t refcounts;
   mach_port_mscount_t mscount;
-  mach_msg_seqno_t cancel_threshold;
+  mach_msg_seqno_t cancel_threshold;   /* needs atomic operations */
   int flags;
   mach_port_t port_right;
   struct rpc_info *current_rpcs;
-- 
2.1.4

Re: Server delegation (fsys_forward)

[Samuel Thibault]

Hello,

Justus Winter, le Sat 14 Feb 2015 01:21:16 +0100, a écrit :
> I was wondering what you think about the server delegation mechanism.
> What are the pros or the original motivation (memory footprint
> maybe?), what are the cons (reduced robustness?).

I don't know the initial intention, so I'm just guess here.  I guess
it's meant to avoid having dozens and dozens of the same translator
(e.g. run ls -l /dev/, and you'll get a flurry of term processes).

Samuel

Static binaries and nss (dlopen actually)

[Samuel Thibault]

Hello,

Static binaries currently can't make use of nss functions
(or more generally really use dlopen-ed libraries).  What
happens is that when the nss plugin library gets loaded, e.g.
/lib/i386-gnu/libnss_files.so.2, by dependency libc.so gets loaded, i.e.
a *second* libc (the first being the one statically linked into the
binary).  When the nss plugin tries to e.g. open /etc/passwd, it calls
open() from that second libc, which ends up calling _hurd_ports_use(),
which returns EGRATUITOUS because _hurd_ports is NULL: indeed the second
libc has not called _hurd_init to initialize itself.

So basically the concern is that the second libc hasn't initialized
its structures.  Should we really do it?  It'd notably mean a second
set of file descriptors, and thus plugin functions must not return
file descriptors since they'll not be in the same space as the
statically-linked application...  Should we then rather manage that the
loaded libc.so accesses the statically-linked _hurd_ports etc?

This issue notably makes the busybox build abort.

Samuel

Re: [committed mig] Do not generate code dereferencing type-punned pointers

[David Michael]

On Sun, Feb 15, 2015 at 11:09 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> * utils.c (WriteFieldDeclPrim): Generate a union with an additional
> pointer field for variable-length arrays.

This makes GDB's awk script go haywire because it doesn't know how to
deal with unions.  The following is a workaround to get it building
again, but I'm not sure of its correctness.  Can someone more
knowledgeable than me check on this?

Thanks.

David

--- gdb/reply_mig_hack.awk
+++ gdb/reply_mig_hack.awk
@@ -68,6 +68,11 @@
   print; next;
 }

+parse_phase == 4 && /^[ \t]*union {/ {
+  parse_phase = 4.5;
+  print; next;
+}
+
 parse_phase == 4 {
   # The value field for an argument.
   arg_name[num_args] = $2;
@@ -78,6 +83,22 @@
   print; next;
 }

+parse_phase == 4.5 {
+  arg_name[num_args] = $2;
+  sub (/[][0-9;]*$/, "", arg_name[num_args]);
+  arg_type[num_args] = "data_t";
+  arg_name[num_args + 1] = arg_name[num_args] "Cnt";
+  arg_type[num_args + 1] = "mach_msg_type_number_t";
+  num_args += 2;
+  parse_phase = 4.6;
+  print; next;
+}
+
+parse_phase == 4.6 && /}/ {
+  parse_phase = 3;
+  print; next;
+}
+
 parse_phase == 5 && /^[ \t]*(auto |static |)const mach_msg_type_t/ {
   # The type check structure for an argument.
   arg_check_name[num_checks] = $(NF - 2);