Date: Wed, 5 Mar 2003 12:42:54 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 26390 for review Message-ID: <200303052042.h25Kgs3f092012@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=26390 Change 26390 by jhb@jhb_laptop on 2003/03/05 12:42:02 Bail out of lock order checking for try lock operations after doing the check for recursion. This fixes a bug with witness and sx_try_slock() (I think) and will make witness properly handle forthcoming changes to mtx_trylock(). Affected files ... .. //depot/projects/smpng/sys/kern/subr_witness.c#77 edit Differences ... ==== //depot/projects/smpng/sys/kern/subr_witness.c#77 (text+ko) ==== @@ -583,14 +583,6 @@ lock_list = PCPU_PTR(spinlocks); /* - * Try locks do not block if they fail to acquire the lock, thus - * there is no danger of deadlocks or of switching while holding a - * spin lock if we acquire a lock via a try operation. - */ - if (flags & LOP_TRYLOCK) - goto out; - - /* * Is this the first lock acquired? If so, then no order checking * is needed. */ @@ -636,6 +628,14 @@ } /* + * Try locks do not block if they fail to acquire the lock, thus + * there is no danger of deadlocks or of switching while holding a + * spin lock if we acquire a lock via a try operation. + */ + if (flags & LOP_TRYLOCK) + goto out; + + /* * Check for duplicate locks of the same type. Note that we only * have to check for this on the last lock we just acquired. Any * other cases will be caught as lock order violations. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200303052042.h25Kgs3f092012>