From owner-freebsd-current@freebsd.org Tue Oct 8 23:22:28 2019 Return-Path: Delivered-To: freebsd-current@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 D644513A1C0 for ; Tue, 8 Oct 2019 23:22:28 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46ntfr4Q7Fz4f4C for ; Tue, 8 Oct 2019 23:22:28 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 977A513A1BF; Tue, 8 Oct 2019 23:22:28 +0000 (UTC) Delivered-To: current@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 973B113A1BE for ; Tue, 8 Oct 2019 23:22:28 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 46ntfr3XbNz4f4B; Tue, 8 Oct 2019 23:22:28 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-qt1-x832.google.com with SMTP id c4so668185qtn.10; Tue, 08 Oct 2019 16:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ki0QKeyimA7MUHsK6x7XaRQTV7HH0fqIKFmiJKTPNqI=; b=fzB9TODZiItlQqxnLSf9fapVYErzlhG1yzaZXqeqO8z7OJeGD7QwlMyhLXCmDE/VHF /CdVn9PqYwszZGaWq/ifgqkrHTUOVB3myryJ+QgWCt+oIhjcQPC+xoVVzVLuR0AizUfI 8w7bJEffucEK8ERtuR14EJzeBzJQ9ZnLxKGTl1kPmaXwz79RRW1ihJSELuLITQDTT6t9 1NpgXUDvFiTnvu/7djVbLe8LRtK3oWOCGE9MumytOwXPiyu0JWRxxD6cVVuEM06ejtcP JOp1fQILqlUbKtmUCBMzjKwTV743Ze6hlJX1gx1X5zFkJ5lvT1QGZ3FO6CnlsTXyRZxR kp5A== 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:from:date :message-id:subject:to:cc; bh=ki0QKeyimA7MUHsK6x7XaRQTV7HH0fqIKFmiJKTPNqI=; b=YByiz6cr6gF/De2lLT9u1YIvxfBiPMinBkURD8GOD10Vq+faWu7b/1bmGWWs7L9lrt RQbCqIjr9thZM1xEyNXglwIwgxVc2YrrN3FZIJvy2KgOgEnmF5QWlzq9yJO5wNJdlTd+ MNabQsfOQaMBlancDs59iq6FMaJlOuq43Q03gc30aldLwaGWZYek6RdJNPof4TJaJ5ys 0nyIl0s2IP6GoTzbH8Vv4kUjPuDNNhkpwNNGVs6zySY+VNNy8MrGainCblE1tBDBcUaO XC9sTmF+F3YhWTz1gqk8dm01vX/RttgqOZOIXllYJHT+ZBvYbl96yrv0DPJzcl97QQOT s5hg== X-Gm-Message-State: APjAAAUAZBwBPPthHy97cgWpKMVWo/S0dKUs/QYU3bkZCxY355N87WCx i+uW3S2lfMLVB2bIm7vxHXWkdEJVLFKFaK8WO1peXw== X-Google-Smtp-Source: APXvYqxKj8nzDRuphwctC5UxuLL2ptx6yeAX9C/eVSmJPJycmitcvnHIxTHpU6ykG4M+tG9LpA67cjWogoFWm6BG4oE= X-Received: by 2002:a05:6214:1812:: with SMTP id o18mr729147qvw.157.1570576946872; Tue, 08 Oct 2019 16:22:26 -0700 (PDT) MIME-Version: 1.0 References: <20191008121519.GS1263@albert.catwhisker.org> In-Reply-To: From: Ryan Stone Date: Tue, 8 Oct 2019 19:22:15 -0400 Message-ID: Subject: Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694 To: Julian Elischer Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 46ntfr3XbNz4f4B X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 23:22:28 -0000 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.