From owner-freebsd-arm@freebsd.org Thu Jul 2 19:45:23 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8CAA335EB22 for ; Thu, 2 Jul 2020 19:45:23 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49yT8f6cPvz4FLk for ; Thu, 2 Jul 2020 19:45:22 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1593719115; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=wK+yDgH6jqlozpyhxgI/YyelSawkfENci45ms5mpI9i1vaX+sFmun/T+ag7Thc5gI6TeUvepLFXqM zhOLC1N0Z7zZKC6BzsuFEwwELFCuKMNGQOeqZJEKfqoCNRL3geK5WJufsw6PwVHABkS9BZDfm7Yx0W LLD6MiUUZgo2M9o5bog5PM9rOo8M5q2GoCKW9KbaEAoHftnyRPTTCZNMsRw/enPG5x3xQOI+Ewatqn +uyqdj+ol1rriBwy7VdRG6oFXEhAjXdhJHfnaDapFEdfuEwiNugpXvXQizXvEdJVZ0Ia3uypAE0/mo ovbyxNtTt5IRAmxSvGtJDgCHyO3KaUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=bx6qQlEuaxagILqJn0IsXX6E6HBEZvdtxu26Re37cUw=; b=C1LN+GN4o8MK2hAiCM5vZNxHt9qTS/UME1zDeHat1OKn20CIHyytcZgtpjROPqP0/lnOAcLi/iemf EH3n41OZDitT3sNs661xm45qTJkG0jnab4Ay3/BDeV2J5ab6Z0C1dqz9B2DwZi9kx2YsHUcgcCtVaa tFRMgUc4ENIwwwN9uvNHHhnuEvbVHNrlSMcWlyJ3yOwkv/hFT4nv9HBVCl5R7aaQq8SvSTF8yARWJl Hj2/VhaReA5lms2NahIkNNETXbS0PzJMWZSLMHIJ7PrI1UiXONepGGgflHJ6ohDVvLDseCZTmHKPxO MuKMQA9/FKcFeQu1LpxrFPNqne4JdWQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=bx6qQlEuaxagILqJn0IsXX6E6HBEZvdtxu26Re37cUw=; b=mGys5VogonFAvS607snJrpSM7oXTYneiAlI5VLYFMHDrqZE6p9ZasvVG9UYm9yGSi4EoqBU5+FUR5 6Qi6KPzQw5MBYjuTIxEryVMi2Evd6kY67nev3vaTnL8AWQBa9USovVkj4cbif+v5D1uJ/2IwAv3Wk2 ANUtfgKAaS10uIqcmJdcGxKD+Y9F0h01tV48VKCDZiR5oydyJrezYN/GoL5+tgXJcXXZTc6RlcYsZT 3xRSpNv2NCNxwISTSExXUB0TkDZNxHnn6EEPrsLpSvJgzgR5clUSbuO7gdyrOHQpP1+VIrkGqC+vEB lbYE0DQMmIQk0k9WRahrkBOGE++yHuA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 8b9bd7dc-bc9c-11ea-a2ba-9f0c275c2f69 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 8b9bd7dc-bc9c-11ea-a2ba-9f0c275c2f69; Thu, 02 Jul 2020 19:45:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 062JjCob000159; Thu, 2 Jul 2020 13:45:12 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: cv_wait From: Ian Lepore To: kamalp@acm.org Cc: freebsd-arm@freebsd.org Date: Thu, 02 Jul 2020 13:45:12 -0600 In-Reply-To: References: <28698f3e3db608dceee910a8ba62ad7b6be0769f.camel@freebsd.org> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49yT8f6cPvz4FLk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 19:45:23 -0000 On Fri, 2020-07-03 at 00:52 +0530, Kamal R. Prasad wrote: > witness threw a panic saying that there is a potential deadlock. I > dont > have the exact msg as I changed the algo and lost the console logs. > the common code has a mtx_lock() and mtx_unlock() to guard against > race > conditions. > i just want to use a synchrnization primitive that will not hold any > locks > when calling the common code from the cs. > so, pl feel free to suggest any alernativves. > > thanks > -kamal > Maybe an sxlock is what you're looking for. void function1() { sx_xlock(&sc->cs_lock); common_func(); sx_unlock(&sc->cs_lock); } void function2() { sx_xlock(&sc->cs_lock); common_func(); sx_unlock(&sc->cs_lock); } That would ensure that only one caller at a time is in the critical section that calls common_func() (if it's just common_func() that needs protecting, I'd put the sx_xlock in there). But I'm not sure how that's different than using a standard mutex, unless your common code was trying to sleep (or use malloc with WAIT_OK). If using a standard mutex caused witness to warn about an unbounded sleep while holding a mutex, then using the sxlock should fix that. Also, you should look at 'man locking' if you haven't already. -- Ian > > > On Fri, Jul 3, 2020 at 12:37 AM Ian Lepore wrote: > > > On Fri, 2020-07-03 at 00:36 +0530, Kamal R. Prasad wrote: > > > but if i am doing cv_wait() for the first time, should someone be > > > calling cv_signal for it to proceed? > > > my algo is something like this in my driver:- > > > function1() > > > { > > > mtx_lock(&sc->sc_mtx); > > > cv_wait(&sc->sc_cv); > > > mtx_unlock(&sc->sc_mtx); > > > .... > > > critical section > > > .... > > > cv_signal(&sc->sc_cv); > > > } > > > > > > function2() > > > { > > > mtx_lock(&sc->sc_mtx); > > > cv_wait(&sc->sc_cv); > > > mtx_unlock(&sc->sc_mtx); > > > .... > > > critical section > > > .... > > > cv_signal(&sc->sc_cv); > > > } > > > --------------------- > > > i want to protect critical section. The critical section calls a > > > common > > > piece of code which has some locks. if i put in locks to guard > > > the > > > cs, it > > > triggers a call to witness(). > > > > > > Update: i saw an implementation wherein they used a callout to > > > periodically > > > send a cv_signal(). i could do that but the pt of this > > > implementation > > > is > > > that cs in either of these functions should not be eecuting at > > > the > > > same > > > time. > > > > > > thanks > > > -kamal > > > > > > > A condition variable doesn't work the way you're trying to use it. > > > > What is the complaint from witness? What type of locks are used in > > the > > common code that causes a complaint? Are any of these functions > > involved called from interrupt handlers (that also imposes > > restrictions > > on what kind of locking you can do)? > > > > -- Ian > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org" > >