From nobody Fri Oct 24 15:17:24 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ctRNC0VNdz6DgwH for ; Fri, 24 Oct 2025 15:17:31 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ctRNB7341z3M5D for ; Fri, 24 Oct 2025 15:17:30 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1761319051; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QvDfVUqzc+hABRAfKZSqbfy0u7jY/pxadnkfbldH9kg=; b=JuvTO+tPwB4CngiicGyx248cEd6XSvJyswa1i0redN/JcIywe/QCDVsMWLV+0SogwxVjhn xrXVCiD8q7RocHPc+/zk1cwO3ui50qMwKI9V6O1ZPpOKg/GSKx+46i+/hlU4dFvIzIk+Ve si8eGIgZxKapTHlB35L3GcKcyFZlHb5t39Sl8voZBWaOIljD8dffp1oNB+2NXz1CIcGzXI Yxcpyam99RATCEPlEmn8TML+k9jzC8s5xD0cAsASYr+q+SDOlSiAjrPOVhQ+r+i53bbt4l P9A+Fpkv8r0qsxsOE5PxIUABROQNIYFcRqoQ/TdQUuNzWa29xmZEaNtPks16+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1761319051; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QvDfVUqzc+hABRAfKZSqbfy0u7jY/pxadnkfbldH9kg=; b=spSuKvD2suouSoNfd8h4lAq3Exir7AnK3H7w13riTTjzyemp7QpAHC9Jq5pptEZ/X307cH i81G7wToLDYgAKxT79mjU3d5AEHSsb+sIiT4Ztkaqs9mPwxJM5UrsNKxr5Cwp0uNhQsOSG vQ68FQqEqzHtoadB7uTcoCK8pguUivGF69JKHmyJBVYBVdotr51UhVeGZ52IWAQDax8Urc GLVwBQGsQ9gWsfSq6lVrAqxRcVuAzGMfqHwHx8ucinc1CyxlFT8jbUuUyK2hQA6IykhNFo tqCCxnBZ+zdtlxfh8EoxAZtDL9VLWWhBguWdK+Ov/V6dQmPxiv+WLzdChpqZjA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1761319051; a=rsa-sha256; cv=none; b=KbwDqG4RCN28IDgVlR80vGnRaIkFDTqH8vYqgHSQBSaqYU0oYHST8FqV96ZqIwg3iDkKZ/ btHt8KatEn3rIlDMS1ZgJMKG4QoxGVpvQl04rUZA6R3JsUZB1Fyg0k1Ei8b4qFuixeiaOm 80a0KBKExVmhU/uX3rLezASqKZKVkmt9SLqAC5MbsUo/MYb/PXmTPbN7RVmlRJLekw+B48 KJOSI9bbsaS3iuG+Tx73Q0w4OYcv2MzBCs29nNH3tru0lYcuJ7lzzOGkLGqNi+zHCJxx5X fjd6YtrX8JbpF/PkGaeGo4Ailw0WJHq+dvlRmBLXmU/wdsynT+TkADf7N6JL6A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (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 did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ctRNB5NMjz125V for ; Fri, 24 Oct 2025 15:17:30 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Fri, 24 Oct 2025 10:17:24 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: evdev-induced panic (devfs / destroy_dev race?) From: Kyle Evans To: FreeBSD CURRENT References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/23/25 07:41, Kyle Evans wrote: > Hi, > > Not sure if anyone else has noticed this, but I seem to have scared up an evdev panic: > > [...] >> This was seemingly the result of removing my mouse's USB dongle.  Presumably detach revoked the client and > woke it up, which then triggered the above close() from moused to race with destroy_dev() for invoking the > cdevpriv dtor. > > I spent a few minutes thinking about it and didn't really come to a good idea of what the fix might be, > though I suspect there's nothing evdev can really do about it at the moment and we might need to somehow > coordinate this in destroy_dev(). > > Kyle Evans This thread ended up going largely off-list because I was traveling, but to kind of summarize the remainder of the discussion: cdevpriv bits are properly protected by the cdevpriv_mtx, but I pitched the following scenario: Consider threads (U)ser and (D)river: - (U) has called close(2) and is in the middle of devfs_close_f, maybe has bumped the thread refcount - (D) has initiated destroy_dev, waiting for the thread refcount to drop Let's assume now that (U) releases the thread ref. What stops (D) and (U) from subsequently racing to grab the cdevpriv_mtx? I couldn't immediately see anything that might, so let's pretend that (U) wins and peels the cdevpriv off, so now the cdevpriv list is empty. (D) is free to return from destroy_dev while (U) is in the middle of executing the dtor, where we destroy the sx that (U) is trying to acquire. kib created D53303[0] to have destroy_dev() provide a release barrier for cdevpriv destructors so that callers can safely release state as all destructors have run, either by destroy_dev() itself or a concurrent close(2), which I think is the right balance. Thanks, Kyle Evans [0] https://reviews.freebsd.org/D53303