From nobody Sat Oct 4 13:41:28 2025 X-Original-To: freebsd-net@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 4cf6Bf0kCFz6BdnW for ; Sat, 04 Oct 2025 13:41:30 +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 4cf6Bd4h4bz3tHv for ; Sat, 04 Oct 2025 13:41:29 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759585289; 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=BN8Kr76C/YmifbLMPje7w2FqCteENJSHzwRWQQx+0Ag=; b=x8dDyYquaLCyWnT53H0gdWJ/mvKSQ6tR9H4cUf26GRtOTXWpZ+L/uJUxul96kTXy2JoJ4H ozTv8vPXrNZCLyJOv9LYQcvK/vcRoWg3ou+FqJoOVDggQWEGXjlQ2AUbBCjRHShhtpHgB2 /oodPoUwZG22LawLXkbLi8Ph11+VOWIvdVMNvvAoVdnTKcTOjlD2b9fVGzRyfjV6uTUihv JK8aSSJKx/bXRp+XI1A5Mpd9us1VjgcH/8xg7RF9d5tpob7nRRNzTpqxnPCe1a/8b+ejI+ 5dibrqUy0ZCNB3XgJETUyiTLC+uBkzT1v+XlhmrAxONUHC8lPZhndu3ljLLDhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759585289; 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=BN8Kr76C/YmifbLMPje7w2FqCteENJSHzwRWQQx+0Ag=; b=A/6/rGDqit1QkDvnGf70uTFfhdPR3R97v5A3I91YbWShTLTgETeXZk1FF4Y1iN+CSldkHZ EEa3LYit5UOaAIafzHBV708v6rgqg9oXQi2CNr2dCPwxm24WGyfcbkzy1k76Ob4JeNXYwh la06GN9Bj/eimkaLyBsLOSMMfyTtih3xumAzLDA/Xdk8H7pY8+CaX+dJdjrPgN3tQLAlXm RrAYWYvLUHOeDFefyfMdIkj+jTiKKy3nTAdX89PIgVo5otrIR773gAV5cyORJxlLAse2CL mHJvoSCYIFBrgir9a39yurxAC5q8ZFAHiEMBSoZyuSzAMiuXnb8DA9jXoPd2Dw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1759585289; a=rsa-sha256; cv=none; b=jeZ942Cipd/OgzDBCGMtJujljjluIqhhS+TG/GsO5HOvwizK9apCiyos8yVtDWvzdt9cND Z7y5fTwXhj8iG7IKAfZ6KKQiPs3iG21D4eojWiG17KCjix3NVwqKIBbTQIKdshCkI2k9lk vWwumFTR214CQ8SNkZLeFpUg24YtcTt9StvHK9I++hpGPZBSB9XEnwUNFuvtf8f4FE1fEx OqTOD1cA+CiZR7vFb+DrJ9zd0En/LjBx3d4dPPyiNkeE0X+eFiKBJimQUo0ceLbEVjsRNt zzKB0C+NL5/+kL9csAyfMf95a4asCV63fwnehMbKEvfAtTGIGmKq4KZT6gMQpw== 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 4cf6Bd38qqznJX for ; Sat, 04 Oct 2025 13:41:29 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <87a30461-e2ee-4251-bad7-5bb900e85164@FreeBSD.org> Date: Sat, 4 Oct 2025 08:41:28 -0500 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ifconfig(8) on trying to destroy tap(4) interface used by a process To: freebsd-net@freebsd.org References: Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/4/25 07:55, Roman Bogorodskiy wrote: > Hi, > > Accidentally noticed ifconfig(8) and tap(4) behavior that seems strange > to me: when I have a process using tap(4) and call ifconfig(8) destroy > on this interface, ifconfig hangs. > > For example, in Python I do: > >>>> open('/dev/tap') > <_io.TextIOWrapper name='/dev/tap' mode='r' encoding='UTF-8'> >>>> > > And then: > > tap1: flags=1008842 metric 0 mtu 1500 > options=4080000 > ether 58:9c:fc:10:5b:26 > groups: tap > media: Ethernet 1000baseT > status: active > nd6 options=29 > Opened by PID 5409 > (14:45) novel@tulp:~ %> sudo ifconfig tap1 destroy > load: 0.08 cmd: ifconfig 5620 [tun_condvar] 50.80r 0.00u 0.00s 0% 3576k > mi_switch+0x172 sleepq_switch+0x109 sleepq_catch_signals+0x276 sleepq_wait_sig+0x9 _cv_wait_sig+0x165 tun_destroy+0x96 if_clone_destroyif_flags+0x69 if_clone_destroy+0x100 ifioctl+0xa0a kern_ioctl+0x286 sys_ioctl+0x12f amd64_syscall+0x169 fast_syscall_common+0xf8 > > ifconfig keeps hanging like that and exits only when the process that > owns the tap(4) interface releases it. > > I don't seem to find anything about that in manual pages for both > tap(4) and ifconfig(8) (probably missed something), but generally, I'd > expect ifconfig to immediately exit with an error and non-zero exit > code. > I agree that it should be documented, but historically tun/tap have hung on destroy if the cdev was still opened by a process. I made it interruptible[0] somewhat recently, and also added a mode where tun/tap can be configured as transient[1] so that they just naturally get destroyed on last close. Neither of those have made it back to stable/14, but I don't think there's a reason off-hand that they couldn't go back. > Additionally, while trying to reproduce and document that, I've got a > panic: > > FreeBSD tulp 16.0-CURRENT FreeBSD 16.0-CURRENT #6 main-n280778-f45608124286: Tue Sep 30 22:25:58 CEST 2025 root@tulp:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > panic: deadlres_td_sleep_q: possible deadlock detected for 0xfffff80022425780 (ifconfig), blocked for 1802579 ticks > > I was able to reproduce this ifconfig(8) behavior on 14.3-RELEASE-p1 > too. > > Is it expected? > I think so, yeah. > Thanks, > Roman > [0] https://cgit.freebsd.org/src/commit/sys/net/if_tuntap.c?id=274bf7c8ae7e7b51853cd541481985f0e687f10e [1] https://cgit.freebsd.org/src/commit/sys/net/if_tuntap.c?id=a1174b3b1174754b1f69406bff4456d002e8f583