cv_wait

[Kamal R. Prasad]

i implemented your suggestion nd when system ws going down, i got this
stack trace

lock order reversal: (sleepable after non-sleepable)

 1st 0xffff000001302990 umtxql (umtxql) @
/b/kamal/stable11/src/sys/kern/kern_umtx.c:499

 2nd 0xffff000001c656a0 allproc (allproc) @
/b/kamal/stable11/src/sys/kern/kern_proc.c:399

stack backtrace:

#0 0xffff0000001d54d0 at witness_debugger+0x58

#1 0xffff000000181514 at _sx_slock+0x6c

#2 0xffff000000163efc at pget+0x38

#3 0xffff00000018ce54 at kern_clock_gettime+0x3cc

#4 0xffff00000019c2bc at do_sem2_wait+0x494

#5 0xffff00000019cc7c at __umtx_op_sem2_wait_compat32+0x80

#6 0xffff0000002e2f90 at do_el0_sync+0x9c8

#7 0xffff0000002c8200 at handle_el0_sync+0x84


thanks

-kamal



On Fri, Jul 3, 2020 at 1:15 AM Ian Lepore <ian at freebsd.org> wrote:

> 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 <ian at freebsd.org> 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 at freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > > To unsubscribe, send any mail to "
> > > freebsd-arm-unsubscribe at freebsd.org"
> > >
>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>