[bug #18349] GNU Mach: ``General Protection Trap'' in `ipc_kmsg_enqueue'

[anonymous]

Follow-up Comment #2, bug #18349 (project hurd):

It has been suggested already, and is certain now, that the problem actually
happens under high network load, probably if the network connection is more
or
less saturated: I can reproduce it pretty reliably by running gv with a very
large PS figure ( http://dept-info.labri.fr/~thibault/tmp/graph-radial.ps )
on
a remote X server in my local network.

I also confirmed my guess that the problem is related to the gnumach BPF
patch:
A kernel without the patch works, an otherwise identical kernel with the
patch
(and the updated pfinet) crashes.

With the kernel debugger, I was able to find out that the crash actually
happens in the line

   _last->ikm_next = (kmsg);

in ipc_kmsg_enqueue_macro() (ipc/ipc_kmsg.h), because _last has the value
IKM_BOGUS. It turns out ipc_kmsg_enqueue() is called with a broken
ipc_kmsg_queue as "queue" parameter: It's head points to an element with
"next"
and "prev" pointers both set to IKM_BOGUS.

However, I was not able to find out how this broken ipc_kmsg_queue gets
created. Probably some locking issue in device/net_io.c or so, but that's
just
guessing. One possibility for such a broken queue to be created could be if
ipc_kmsg_rmqueue_first_macro() or ipc_kmsg_rmqueue() is called with a "queue"
parameter which doesn't actually point to the queue in which the kmsg entry
is:
In this case, the "next" and "prev" pointers of the entry would get set to
IKM_BOGUS, but the head pointer of the queue wouldn't get updated
accordingly.

-antrik-


(file #11971)
    _______________________________________________________

Additional Item Attachment:

File name: gnumach-kmsg_assert.diff       Size:4 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?18349>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/