From nobody Mon Jun 30 17:17:24 2025 X-Original-To: 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 4bWCXH1gstz60hvB for ; Mon, 30 Jun 2025 17:17:35 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bWCXG2jV6z49wt; Mon, 30 Jun 2025 17:17:34 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id EC678A64806; Mon, 30 Jun 2025 17:17:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1751303843; bh=Z/XZF6Dq83t4SBerzuF4oIAT2ZUPxlIO7huijHnyi5k=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=frb+8ssdQZAAMW3mVNdVoE+qWhw4eE9mo/DEOazTE9NeVzQCXXIoHjBN7l/z+4Ju1 av6NU+C2XJ0MdCmFWW9JXAgR6WmcQ+WskLp8b9i8O/2WXldyNuZLWVXsYLJ1KKzYdD rBo8pk48ufEea1XpPqmgKCaqQbgAiioFeeVADn7Wm4BnCWdQIqD5IP0u6ENF/LIutK TfpDYk54SKyxPIdPZUeL1XN6b+6LADWJzT0Ovgw387rOh2bxMg63qB5QviWSfw5s5O HWjRXVAYkpWT5eFsd5utqppblQB8yuzQEc2AgCQWupguWT4kX0aE9K3M2WTRVwXwiH NYBOfb3TWQpg9EVUfVGa3cAboF17xIAXnAIOzZhkLK30MeNDWnqTILQ7oOSFRGNF3v TKiPfHfXpaK59zelMlRheYWNRXk38to6Z+OZWLav7J4SwHCMfJLHNw7hDVecYnYf7x WUl4VJ+mlnBq4CjJEa7poCaxYMxK6coZCiNSHnAiVquHerSes0KpC0zu3BPPGjccEP XW/OjZyoCHWQ146Z98u7tOK2Go1WOA5rdLQI4ThGRg4/mvYJVbxnD39q7goRk8nWx0 yssXfU26ecE2vhrFFp6rlbglgWL0cHXY0y7RyFjNYxOMOWVEzuWQkf/j6iIUbf5+y7 KK9Rr0DkWEgXpCCxl91M7Ovo= Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A5D932D029E1; Mon, 30 Jun 2025 17:17:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id jMjDnUwBRcRA; Mon, 30 Jun 2025 17:17:24 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:a66b:b6ff:fe40:39a9]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B21E62D029D8; Mon, 30 Jun 2025 17:17:24 +0000 (UTC) Date: Mon, 30 Jun 2025 17:17:24 +0000 (UTC) From: "Bjoern A. Zeeb" To: John Baldwin cc: Zhenlei Huang , FreeBSD Current , Olivier Certner Subject: Re: regression: memory issues on main/arm64 over sched/runq changes In-Reply-To: <274774b0-9137-4fa7-a0a5-a0ce8976dc27@FreeBSD.org> Message-ID: <2qp0845s-p0oq-qsr9-0n64-3snn4466s139@yvfgf.mnoonqbm.arg> References: <43005447-2rq0-6nn2-pnr5-4939s112npr4@yvfgf.mnoonqbm.arg> <0A01B9F5-C49C-41D8-BAB7-4378DEDBF647@FreeBSD.org> <28o26o81-so5r-qq79-6q6n-0q6746o7oo79@yvfgf.mnoonqbm.arg> <6A003013-415A-4594-AB04-AF5A9B2D660D@FreeBSD.org> <23n1773o-10o2-5p5o-25s4-r623rnn44649@yvfgf.mnoonqbm.arg> <907D042E-AE8A-4818-A807-AD45F36354FD@FreeBSD.org> <274774b0-9137-4fa7-a0a5-a0ce8976dc27@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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 Content-Type: multipart/mixed; boundary="1098556516-212062285-1751303844=:4774" X-Rspamd-Queue-Id: 4bWCXG2jV6z49wt X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE] This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-212062285-1751303844=:4774 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 30 Jun 2025, John Baldwin wrote: > On 6/28/25 11:35, Zhenlei Huang wrote: >> I boot from disk. >> >> Updates on this locking issue, >> >> I think I finally figured out why. More stack trace from my video: >> >> ``` >> shared lock of (sx) ifnet_sx @/usr/home/zlei/freebsd-src/sys/net/if.c:1467 >> while exclusively locked from /usr/home/zlei/freebsd-src/sys/net/if.c:1416 >> panic: excl->share >> ... >> witness_checkorder() at ... >> _sx_slock_int() at _sx_slock_int+0x64/frame .... >> if_addgroup() at ... >> if_attach_internal() at ... >> ether_ifattach() at ... >> iflib_device_register() at ... >> iflib_device_attach() at ... >> device_attach() at ... >> ... >> root_bus_configure() at ... >> configure() at ... >> mi_startup() at ... >> ``` >> >> The ifnet_sx has flag bit SX_RECURSE then it can be recursively locked. >> >> iflib_device_register() acquired ifnet_sx exclusively and then calls >> ethernet_ifattach() which will then calls if_addgroup(). It is prohibited >> to re-acquire the same lock shared so the witness blames. >> >> I think the witness should show the first file location of the exclusively >> lock, i.e. sys/net/iflib.c rather than the sys/net/if.c:1416 . So that it >> is more straight forward to figure out how that happens. CC John to see if >> that can be improved. > > Hmm, I think we have stopped at the first lle we found walking > back up the lle list (find_instance() always works this way). > > You could add a 'find_last_instance' and use it in a few places > perhaps. I guess both the share->excl and excl->share are places > where you would maybe use it. Alternatively, you could have a > 'find_next_instance' and maybe output all of them before the > panic? Having the full chain would be really nice :) +1 from me for that. /bz -- Bjoern A. Zeeb r15:7 --1098556516-212062285-1751303844=:4774--