Re: Oops at lis_qdetach

You might try this just to allow qdetach to go ahead and execute. -- Dave


Version diff for head.c, version 2.192
--- /tmp/sccsdiff.6659/head.c   2005-03-02 10:14:21.000000000 -0600
+++ /rsys/linux/LiS/head/head.c 2005-03-02 10:13:21.000000000 -0600
@@ -51,7 +51,7 @@
   *
   */

-#ident "@(#) LiS head.c 2.192 01/24/05 15:24:12 "
+#ident "@(#) LiS head.c %R%.%L% %G% %U% "


  /*  -------------------------------------------------------------------  */
@@ -1960,7 +1960,7 @@
      wq = WR(q);
      rq = RD(q) ;

-    if (!((rq->q_flag | wq->q_flag) & (QENAB | QSCAN | QRUNNING)))
+    if (!hd || !((rq->q_flag | wq->q_flag) & (QENAB | QSCAN | QRUNNING)))
         return(0) ;

      lis_sem_init(&wakeup_sem, 0);
@@ -2076,7 +2076,7 @@
       * We may be simply popping a module off of one end of a pipe.  That
       * case is treated normally since it might be just an I_POP.
       */
-    if (rq == hd->sd_rq && (hd_peer = hd->sd_peer) && hd_peer != hd)
+    if (hd && rq == hd->sd_rq && (hd_peer = hd->sd_peer) && hd_peer != hd)
      {
         closing_pipe = 1 ;
         if (LIS_DEBUG_CLOSE)
@@ -2305,13 +2305,14 @@
      {
         CP(unfreeze_q,unfreeze_q->q_str) ;
         lis_unfreezestr(unfreeze_q) ;   /* will balance lis_freezestr */
-       if (F_ISSET(hd->sd_flag, STRFROZEN))
+       if (hd && F_ISSET(hd->sd_flag, STRFROZEN))
         {
             CLR_SD_FLAG(hd, STRFROZEN) ;
             lis_head_put(hd) ;          /* balance lis_freezestr */
         }
      }
      else
+    if (hd)
      {
         CP(hd,0) ;
         lis_head_put(hd) ;              /* balance lis_freezestr */


At 05:48 AM 3/2/2005, [email protected] wrote:
>Hallo we need some help.
>
>We have an Oops at lis_qdetach.  As far as we understand lis_qdetach was
>called in some context before. We do not know which. Possible popping a
>module?
>At this call the associated control block struct stdata was freed and
>some magic number is changed to make this visible to all, who try to
>access this freed memory area.
>
>Later on, in the context of a close, lis_qdetach is called again for the
>same queue. At the beginning of lis_qdetach is checked, if the
>controlblock is already freed. Finding the magic number corrupted, there
>is a Debug Entry and the pointer hd is set to NULL. Setting hd to NULL
>forces a crash some lines later.
>
>We can reproduce the error as often as needed.
>
>Detailed information is available at the attached file.
>
>The whole thing happens in this context:
>We use SUSE SLES8 at a SMP 586. LiS-2.18; strxnet-0.9.2-4 (with some
>changes); After sending two or three data, the XTI-application decides
>to stop of some unknown reason. Closing the devices forces the panic.
>The protocoll-stack:
>timod
>rfc1006 /* our module */
>inet
>tcp
>...
>
>
>
>It looks like, as if somebody has inserted this trick with the
>magic-number to detect this "happening". The solution for this
>"happening" seemed not clear to him at that moment, otherwise he would
>have fixed the possible problem.
>So for us it looks, as if it would be more complicate to solve this bug.
>
>Just leaving the function after detecting, that the controlblock was
>freed, is only a dirty solution and may leave things not finished. (To
>get on with our tests, we changed lisqdetach to leave, if magic is
>clobbered. This seems to results in other Oops at kmem_cache_create
>called by lis_init_queues.)
>
>We do also not know, if it was planned, that lis_qdetach runs two times
>for one queue-pair.
>
>A solution or hints to find the real cause of that Oops are welcome.
>Also questions concerning more information are welcome. We can inspect
>the dump or reproduce the crash.
>
>
>Klaus Golbach
>
>
>Klaus Golbach
>FSC EP SW RT 3
>Fujitsu Siemens Computers
>
>Telephone:      089 636 48835
>Telefax:        089 636 48976
>Email:  mailto:[email protected]