Date: Tue, 8 Oct 2019 18:49:56 -0700 From: Julian Elischer <julian@freebsd.org> To: Ryan Stone <rysto32@gmail.com> Cc: FreeBSD Current <current@freebsd.org> Subject: Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694 Message-ID: <f76e5829-5fef-e17d-489e-01b01439ab25@freebsd.org> In-Reply-To: <CAFMmRNyQqf48O_vj3ps1GRN=TON8SiN2Cw-onPWm6raOEXCBqA@mail.gmail.com> References: <20191008121519.GS1263@albert.catwhisker.org> <c1e4374a-019e-5f5f-a7d0-bea5b18136f5@freebsd.org> <CAFMmRNyQqf48O_vj3ps1GRN=TON8SiN2Cw-onPWm6raOEXCBqA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/8/19 4:22 PM, Ryan Stone wrote: > I haven't found any good references on the subject, but here's my understanding: > > - epoch_enter() and epoch_exit() are very inexpensive operations > (cheaper than mtx, rw_lock or rm_lock operations) that are use to mark > read-only critical sections > - epoch_wait() guarantees that no threads that were in the critical > section when it was first called are still in the critical section > when it completes > > With this guarantee, you can safely destroy an object with the > following procedure: > > 1. Atomically remove all global pointers to the object (e.g. remove it > from any lists that the critical sections might look it up in). This > must be done atomically because read-only threads can be concurrently > running in the critical section. This guarantees that no more threads > can get a pointer to it. > 2. Call epoch_wait() to drain all threads that already held pointers > to it before step 1. > 3. You now hold the only pointer to the object, so you are free to > destroy it as you please. Ok thanks. Gottit. thanks for the description.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f76e5829-5fef-e17d-489e-01b01439ab25>