Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 May 1999 19:51:32 -0700 (PDT)
From:      Cliff Skolnick <cliff@steam.com>
To:        Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
Cc:        dg@root.com, Mike Tancsa <mike@sentex.net>, freebsd-stable@FreeBSD.ORG, luoqi@FreeBSD.ORG, Matthew Dillon <dillon@apollo.backplane.com>
Subject:   Re: vm_fault deadlock and PR 8416 ... NOT fixed! 
Message-ID:  <Pine.BSF.4.10.9905121942190.40655-100000@lazlo.internal.steam.com>
In-Reply-To: <199905121459.HAA27314@cwsys.cwsent.com>

next in thread | previous in thread | raw e-mail | index | archive | help

I've added "options DEBUG_LOCKS" to my kernel, and added the following code.
I'll post any interesting log messages that I see over the next day or so.

If I've done something terribly wrong that will hose my system, please email
me!  Hacking locking code makes me a bit nervous.


Here's the diff to kern_lock.c I just added - someone in the know please
review this, and email if I need to add more instrumentation:

*** kern_lock.c-orig	Tue May 11 22:53:19 1999
--- kern_lock.c	Wed May 12 19:45:59 1999
***************
*** 229,236 ****
  					     LK_WANT_UPGRADE
  					);
  			}
! 			if (error)
! 				break;
  			sharelock(lkp, 1);
  			COUNT(p, 1);
  			break;
--- 229,248 ----
  					     LK_WANT_UPGRADE
  					);
  			}
! 
! /* we will fall through and grant the lock after printing info */
! 			if (error) {
! 				if ((lkp->lk_flags & LK_SHARE_NONZERO) != 0 &&
! 					(flags & LK_CANRECURSE) != 0) {
! 					printf("deadlocktreat=%d, flags=0x%x\n",
! 						p->p_flag & P_DEADLKTREAT,
! 						extflags);
! 					lockmgr_printinfo(lkp);
! 					/* fall through to grant lock */
! 				} else {
! 					break;
! 				}
! 			}
  			sharelock(lkp, 1);
  			COUNT(p, 1);
  			break;


On Wed, 12 May 1999, Cy Schubert - ITSD Open Systems Group wrote:

> Would plan B risk corruption of any data?  Could itself be the likely 
> cause of any potential panics?
> 
> Assuming plan B has no major risks, this might be a temporary 
> workaround until we can wrap our minds around this one.  It's just a 
> rework of Luoqi's patch, just in case we want to try plan B again.
> 
> --- kern_lock.c.orig	Tue May 11 08:34:52 1999
> +++ kern_lock.c	Wed May 12 05:38:52 1999
> @@ -215,7 +215,9 @@
>  		 * lock itself ).
>  		 */
>  		if (lkp->lk_lockholder != pid) {
> -			if (p->p_flag & P_DEADLKTREAT) {
> +			if ((p->p_flag & P_DEADLKTREAT) ||
> +			    ((lkp->lk_flags & LK_SHARE_NONZERO) != 0 &&
> +			    (flags & LK_CANRECURSE) != 0) {
>  				error = acquire(
>  					    lkp,
>  					    extflags,
> 
> If this workaround doesn't work, then setting error = 0 and allowing 
> the code to fall through to the subsequent sharelock may be our only 
> choice for now.
> 
> The other point I wish to make for all on this list is that Matt's 
> patch fixes a read()/mmap() deadlock.  It doesn't fix a write()/mmap() 
> deadlock.
> 
> 
> Regards,                       Phone:  (250)387-8437
> Cy Schubert                      Fax:  (250)387-5766
> Open Systems Group          Internet:  Cy.Schubert@uumail.gov.bc.ca
> ITSD                                   Cy.Schubert@gems8.gov.bc.ca
> Province of BC
>                       "e**(i*pi)+1=0"
> 
> In message <199905120755.AAA01361@implode.root.com>, David Greenman 
> writes:
> > >Well a few minutes ago my system went into deadlock - and this is with the
> > >kern_lock.c dated 5/11.  This patch is different than the one in 8416 that
> > >solved my problem before.  I'd say this the problem is still there.
> > 
> >    Time is very short for getting this fixed before the release deadline. I
> > think Luoqi's patch that was in the PR was suseptible to a priority inversion
> > problem and has risks associated with using it. The fix that Matt Dillion
> > made for -current that I back-ported to -stable was an attempt to fix the
> > problem while minimizing the side effects. If it doesn't fix the problem
> > then we'll proceed with plan B which is probably to just go with Luoqi's
> > fix or to possibly troubleshoot Matt's fix (but as I said, time is short).
> > 
> > >Once again my server is useless, deadlocked.  No panic, responding to pings,
> > >no ability to do disk I/O or any VM related stuff.
> > >
> > >An unhappy freebsd user once again,
> > 
> >    Is this really necessary? It sure doesn't help the debugging process.
> > 
> > -DG
> > 
> > David Greenman
> > Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
> > Creator of high-performance Internet servers - http://www.terasolutions.com
> > 
> > 
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-stable" in the body of the message
> > 
> 
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
> 

--
Cliff Skolnick          | "They that can give up essential liberty to obtain
Steam Tunnel Operations |  a little temporary safety deserve neither liberty
cliff@steam.com         |  nor safety."
http://www.steam.com/   |                   -- Benjamin Franklin, 1759




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9905121942190.40655-100000>