Date: Fri, 14 Nov 2014 07:43:20 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: Hans Petter Selasky <hps@selasky.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Questions about locking; turnstiles and sleeping threads Message-ID: <CAJ-Vmo=%2B33LqeAPsW_TQhtswkGdjO82U7BumKa6MuGWaoJv97g@mail.gmail.com> In-Reply-To: <DC176710-B259-4857-BC62-A0ACEAB291C1@freebsd.org> References: <CAJ-VmomrauhCMoF_dZfMWWhZp0EgwfE9RmxL5Pc37PhLSzZ6Qg@mail.gmail.com> <20141112212613.21037929@kan> <CAJ-Vmok-8znyycyOBS_ZQU275zFy%2BzuZ2C-jt4N3DnuEVS=PWg@mail.gmail.com> <CAJ-Vmo=R4ayAn-d986TC3CzZ4y23jnDW=uTyo4O=x4Ae1wB60A@mail.gmail.com> <CAJ-Vmok40-W%2B%2BdUJPcfO74%2BuudCgbs3tR5nwrR-aNuCy=5o0HQ@mail.gmail.com> <546472DA.3080006@freebsd.org> <CAJ-VmomQdNDWqdC7o-nuGfypDDgDsJX9ouhx%2Br7ckZptgzQ10Q@mail.gmail.com> <5464764E.9080308@freebsd.org> <CAJ-VmonbrB3s5SsABo1Kotfz1Dn3cpvbnRMu4J9ikPmyS_aTgQ@mail.gmail.com> <54647D1E.9010904@freebsd.org> <CAJ-VmonbEfxz9Bgw9O9f-5%2Bb=UM1b1nzPK9zfAAnmYKVumOKkQ@mail.gmail.com> <54648483.5060107@freebsd.org> <CAJ-VmokOSLtZWDwVRVw581d9=GMQrrTESrxt2GwprGE-mQNKmw@mail.gmail.com> <DC176710-B259-4857-BC62-A0ACEAB291C1@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 November 2014 01:31, Alfred Perlstein <alfred@freebsd.org> wrote: > > On Nov 13, 2014, at 9:31 AM, Adrian Chadd wrote: > >> On 13 November 2014 02:14, Alfred Perlstein <alfred@freebsd.org> wrote: >>> Would need more context to help on this. >>> >>> I can't tell based on your description which thread is holding which lo= ck. >>> >>> If A is waiting for callout C to stop AND there exists a thread B that = is >>> contending against C for a lock, you should be fine so long as there is= no >>> lock cycle against A. >>> >>> Would be best if you pointed at some code and gave descriptions. >> >> I haven't dug into the USB side of things ,but on the atheros side I >> gave the description above. >> >> Thread A grabs lock X and tries to drain callout, which involves >> grabbing lock Y to do the dirty work. Lock Y isn't held at this point >> - the callout is about to run or is running, so it enters the sleepq >> call to finish the drain. >> >> Thread B wants to grab lock X, but can't because thread A holds lock X >> and is in a sleepq due to callout_drain(). Hence panic. >> >> I'll poke people on IRC today and see if I can get a better >> description of what/where the WITNESS_WARN() should be placed in >> callout_drain(). Then we'll see what's left triggering it. > > > Yes, this is exactly how one is not supposed to use callout_drain(). > > From the context of the caller of callout_drain() you are better off doin= g a stop() under the lock, then dropping the lock and doing the drain. Typ= ically one sets a "dying" or "going away" type flag in the softc to prevent= more callouts from being scheduled. Right. Well, I'll see about getting a WITNESS check inserted there so no other badly behaving code creeps in. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=%2B33LqeAPsW_TQhtswkGdjO82U7BumKa6MuGWaoJv97g>