Date: Wed, 12 May 1999 07:59:44 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: dg@root.com Cc: Cliff Skolnick <cliff@steam.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: <199905121459.HAA27314@cwsys.cwsent.com> In-Reply-To: Your message of "Wed, 12 May 1999 00:55:29 PDT." <199905120755.AAA01361@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905121459.HAA27314>