From owner-freebsd-arm@freebsd.org Thu Jul 2 19:23:01 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 C2B5035E2FB for ; Thu, 2 Jul 2020 19:23:01 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49ySfs2xp3z4Dn4; Thu, 2 Jul 2020 19:23:01 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: by mail-il1-x130.google.com with SMTP id r12so18020160ilh.4; Thu, 02 Jul 2020 12:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=kDPLCJtSliJYZFy5wWYoh3ZYpgCITr3fGgfghRxmdhg=; b=NQ2kE0TI323RYqGFPYnFjnvOU9YVwXVoVphR5caclhNoZ0RhLj53rwAcU5Xz4NKHyJ VD/eAikyoiL0h7lBaSQP2lu4oUs8DVo5icrVdTH4kTsJXRZUQVLrZ2prajq+ZvZGFmyB 15lmlohq+4uYG4KwnsbnnUSX3Q+Ag9B97OtAnLrfu8FDyGoLzYe3zp/JuDTKKs5UOVQV pybgikuvbuknmsdfx9xW3/WJP3NJgEum3ob2gqUDREpwN4pXqy1fl6D+h5q3GdFyNJSm 38apAh3+kdWlPWSY8AbVFEyZbDxyNpojjo5zlHWIrhK0Ug+RzkhGm4Os4uWlq0UDz5mG iU8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=kDPLCJtSliJYZFy5wWYoh3ZYpgCITr3fGgfghRxmdhg=; b=B/8BnjpZhn3J46ZtLZFuS/1GhD3BjcQ+t2ezODaOy9Qax++qQUKXOrsiSMp+ZtBkoh nNuqOfFVorH14k2GSTZ+lTSxABXoBlb+tJp6H4z9rHdLohpEa0k8h0A5tCvICl8+LyWG X57Jhs7ymJq+3YWnXkw7ehDlDZjVZKBfSXAIcY0mcRv9AC+BjAOYHlNSBgBBxXvJhc9j mYAY3Jra4o9KjGr2Ar8OjaBy+53i18dukP5aXfz9iSoN0+GdVN8w5NYv8ZOXko8D29hE H3FtmQGM69/BUc6pPQsVlakEV/0v/b2rEJVkbroNeOyTZe/xsOijWOOxiLag/dzrj1dT giiA== X-Gm-Message-State: AOAM5333VXmOTMoM7zGWrvf8/pveDjWrc8LOn5xTmKHReWdYTeBtewCG HsYkkdKzoR0B4AcNMN9Dvk3x5yI86qJKmOmJ9x2Q/iDLeA== X-Google-Smtp-Source: ABdhPJyhghmxz4rybRzwekk9E2za4SGuPmodmyWNBzPFUnWer7dyLyEsp5fmNI6yHgM0kMOmUt6YFL/9Dkx4NFcCvpA= X-Received: by 2002:a92:cacf:: with SMTP id m15mr13622361ilq.34.1593717779749; Thu, 02 Jul 2020 12:22:59 -0700 (PDT) MIME-Version: 1.0 References: <28698f3e3db608dceee910a8ba62ad7b6be0769f.camel@freebsd.org> In-Reply-To: <28698f3e3db608dceee910a8ba62ad7b6be0769f.camel@freebsd.org> Reply-To: kamalp@acm.org From: "Kamal R. Prasad" Date: Fri, 3 Jul 2020 00:52:49 +0530 Message-ID: Subject: Re: cv_wait To: Ian Lepore Cc: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 49ySfs2xp3z4Dn4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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:23:01 -0000 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 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" >