From nobody Sat Oct 4 12:55:58 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 4cf5CD6VBHz6BYHv for ; Sat, 04 Oct 2025 12:56:56 +0000 (UTC) (envelope-from bogorodskiy@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cf5CC6HR0z3mhq for ; Sat, 04 Oct 2025 12:56:55 +0000 (UTC) (envelope-from bogorodskiy@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Y+nEJIY2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bogorodskiy@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=bogorodskiy@gmail.com Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b3b3a6f4dd4so603170466b.0 for ; Sat, 04 Oct 2025 05:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759582609; x=1760187409; darn=freebsd.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=BJpOLswzTkxC9zgP0z3ckWLIYqjhtMIUN83tlO1rhEA=; b=Y+nEJIY2t5nb/NaAK6tIsbcZs6yrsxhwDcuyipmoT6kWl6oeYL17MkLz4AQrlsc/kI N46eX1ds10Sb4Qc3F2MWQmQuIcUCHx2w1FBPtM5aS/PVtDsSR1+6eLRWdjNL4xCoKqth kSNhQ8+gPWB/jxYLFSf+ZfQ7CYxnO8pFDC8JFdW17Nl0Uq5u/hzYSEp3HaSTOp5om3HR /wz+O/HklUmAlZTFFEyjQHEiTzveTEhYid2Sb84alkJDIQ2wNYG0PdF7TrkJnBb6Reob mNFzuoBFKGgkB4U3RP29JW0BRUCfny5yi4B2CzFlfUQmHorhUEfMQQ+CSQ9Kz6oOzw7N liHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759582609; x=1760187409; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BJpOLswzTkxC9zgP0z3ckWLIYqjhtMIUN83tlO1rhEA=; b=mcTw96+oxU+rZzLf2O9m9nsobiQUF6Pg7WgsFgaAk8cyd7QhDlSu4AeYVZwzxzcnS0 HTuMjg0xIuBFnq1qFVAd52f9So+6KjKgdpfyYMIAyj7chGqssz072nJQA6r/v1ACuQag e/7wykG24xZxdD4ZsgfRqSD5pvahvVa5os9feVCDGZ+HnFu+MMe6KLPJDcKXbDzIEn8F rnJBjEyFHrZt7cwh4l2Tc1yz0v6f+QWRXR98yXCthQw/KeI7SXn7IXk0UQFbzWqbWIri /ndWXwrj9E8kWzcBlqJrOeaY6sCky86NChxtEXLyIPvNZnOZXcNaAXTK9naFFAlRiEpM yWCA== X-Gm-Message-State: AOJu0YwdLsqFfMH2dcypm1I5hr6+EEDiJ6i6TuSrRT9ToUQxrfzuCkje U4kLwhi/Tg4ISO0jK6QOlxhKYb+rrRZqi+BsW4rpEVDHH/NupKxWdu7HA6Zwd0JmnEGsWA== X-Gm-Gg: ASbGncsLtsUlYk1FwNiRoteGxdhRMA94H7Bgkhzt5B16FWGUCvr77SxuSdU7igYud+Q RvfGzVE1SulcFZ52QtMiMOYhtuNeYEZrbXS6ghVKHoeSaXIK2VvBOSZvhW13olEIxeyVqr6vVuP +xKf3bHjeeVOmYiqqI2TdE792xTvZIMpGJQ2IHxolb+yLgrSE/w5lL6TYLAUY2j7MlAk9WXkYdR vly7hx4BDZ94h1PT8Qnw79nWyqxXIsEeufrI4Y0px18ZB/iOmvhGC3Nd8F0QH41Pd3PR9zRuwAl eptos3EE6HEtp5P16bdDa/2ryJ69Ei5OBhUGvwfHgko1YuBIXf4QyE1eyerqEJOq/3yTO94oO1J EIdH6jglJcX8WUoDTg9T/dp7p3u+Va13tLxKfmUniPqOBWHl8sXXFPFbuKnwddYDGkKRC8XEBPY bmRETNfOCv3iWRoA== X-Google-Smtp-Source: AGHT+IH/TdW3IFrWHIf9Pl0NtztpvXENtkmFqu9ep1m0lirdhQ6yWBaGZjOvt9OHQ55gZQtCo5wcZA== X-Received: by 2002:a17:907:988:b0:b41:3c27:e3ca with SMTP id a640c23a62f3a-b49c1d60cf4mr693797566b.7.1759582609102; Sat, 04 Oct 2025 05:56:49 -0700 (PDT) Received: from tulp (84-25-144-101.cable.dynamic.v4.ziggo.nl. [84.25.144.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b4865e75dcasm680019766b.34.2025.10.04.05.56.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Oct 2025 05:56:48 -0700 (PDT) Date: Sat, 4 Oct 2025 14:55:58 +0200 From: Roman Bogorodskiy To: freebsd-net@freebsd.org Subject: ifconfig(8) on trying to destroy tap(4) interface used by a process Message-ID: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.02 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.904]; NEURAL_HAM_MEDIUM(-0.61)[-0.612]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from] X-Rspamd-Queue-Id: 4cf5CC6HR0z3mhq 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. 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? Thanks, Roman