From nobody Sat Oct 4 16:13:32 2025 X-Original-To: dev-commits-src-main@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 4cf9Z90xrfz69FHk; Sat, 04 Oct 2025 16:13:37 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4cf9Z90M3Rz3G5d; Sat, 04 Oct 2025 16:13:37 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759594417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+S3D8S9uH/5GciGqLYUZpNqhiIIhyzhToUG11SpEYJs=; b=kpnpw6eEKb3LyGTdhwXHhs71iMXcCvO9g3vvwMup20l0K6tATndmfAVskH07Xr7KYUVrNJ gDl+F0Z1ywc7cgYvNggF2I55NgrjlD1GZvKGi205LnUTKFOxdB9Ixrubvk5mS1EaiItZHW 0CpCiWJoZxaPi+GgRes+HRTe6BtZZ67UbUo10hQIsTvfiDH5h56FnIqB+Vu3g8XqyryIvO 4bgbGY4vwynkQ1KKrgzpJgT6J4kyli28mPi4SmZO2CIHraa4/KfVPb66VIZmbuLb3ZQvq8 dcQuhBt4zpbpJTDZ9l44mEOhOobCIAxGFnnX63tYmkRxjd01eFT7Wqqg92ICZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759594417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+S3D8S9uH/5GciGqLYUZpNqhiIIhyzhToUG11SpEYJs=; b=AbdW/VfPCJY7ngsWq1eykb6YH2VbqOQtzSnEVOcRXy1vI5JX3hV/Vr8i+jSkoII508nVxE A9n83Dl5JqR7sRec47RucySmYqx4c3VEpk2VuzJvhBQDV63NxM3YGUV/Pv6eiZHi2hcYX2 4taEKI9MMkJFoM1KVVmUF3/wp7oggwWQargfc3JpRYdc5GQqSyzWzShPy7QN9bI0gykYa9 vnMJUkWOI8lr04djDKq2N1Eh7g6icNBlUM2S59ZtY0pJXCCm20dZla1frz2XeWit9uaF9b nQSykk8B2+dxyfDj+/Ez4xJ1m441IYhRDhJWI+exMqcgq0OMAMU0YuW2mpJmvg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1759594417; a=rsa-sha256; cv=none; b=XKC8A31q5fBTkTwgHiPO/PqeAlgSXSOwiUVYxECPDHQP+45Jn00TU+j+g3VoemIq2aPeKF I7FMGEkGLYWXv2hNFG54dJ0GuFt/xrYz16oTaevz6C2nWhW+c7SWkXquXeuzkGox6WorJd Yr5KWkTqEgjQF5+DNofWef5vwGoZfeBudv9Xg9UFt/NbfjqX+VMFnRmcmvhvgJzj7vz741 YSdQ/RGZRYifjeaL0Aq5cruLI102Hcv51ejR6TJ1YOpbktSRGzY9787VkIWNedIXy4Z4Tn bZ+7whzMN6WU0L6JgRQ0VB7mxmx/Zh+GxFnKgJKCUK7oRuIfMFT4aB5wSHj8mg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 "E6" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cf9Z84wQBzr7P; Sat, 04 Oct 2025 16:13:36 +0000 (UTC) (envelope-from bz@FreeBSD.org) 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 0B26AA64808; Sat, 04 Oct 2025 16:13:25 +0000 (UTC) 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 D01622D029D8; Sat, 4 Oct 2025 16:13:34 +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 irW94uYWbu8o; Sat, 4 Oct 2025 16:13:33 +0000 (UTC) Received: from nv.t4-02.sbone.de (nv.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:22]) (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 EDB872D029E7; Sat, 4 Oct 2025 16:13:32 +0000 (UTC) Date: Sat, 4 Oct 2025 16:13:32 +0000 (UTC) From: "Bjoern A. Zeeb" To: Zhenlei Huang cc: Mateusz Guzik , Gleb Smirnoff , src-committers@freebsd.org, "" , "dev-commits-src-main@FreeBSD.org" , Kristof Provost Subject: Re: svn commit: r256519 - in head/sys: net netatalk netinet netinet6 netipx In-Reply-To: <13C41285-E7E1-4B49-B9A7-1B157B445CDD@FreeBSD.org> Message-ID: References: <201310151031.r9FAVgRP008282@svn.freebsd.org> <35D99D40-5534-402A-8479-64C71604206B@FreeBSD.org> <13C41285-E7E1-4B49-B9A7-1B157B445CDD@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-511174828-1759594413=:11296" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-511174828-1759594413=:11296 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 30 Sep 2025, Zhenlei Huang wrote: >> On Sep 30, 2025, at 10:59 AM, Mateusz Guzik wrote: >> >> On Tue, Sep 30, 2025 at 4:38 AM Zhenlei Huang > wrote: >>> >>> >>> >>>> On Sep 29, 2025, at 10:29 PM, Mateusz Guzik wrote: >>>> >>>> On Tue, Oct 15, 2013 at 12:31 PM Gleb Smirnoff wrote: >>>>> >>>>> Author: glebius >>>>> Date: Tue Oct 15 10:31:42 2013 >>>>> New Revision: 256519 >>>>> URL: http://svnweb.freebsd.org/changeset/base/256519 >>>>> >>>>> Log: >>>>> Remove ifa_init() and provide ifa_alloc() that will allocate and setup >>>>> struct ifaddr internally. >>>>> >>>>> Sponsored by: Netflix >>>>> Sponsored by: Nginx, Inc. >>>>> >>>>> Modified: >>>>> head/sys/net/if.c >>>>> head/sys/net/if_var.h >>>>> head/sys/netatalk/at_control.c >>>>> head/sys/netinet/in.c >>>>> head/sys/netinet6/in6.c >>>>> head/sys/netipx/ipx.c >>>>> >>>>> Modified: head/sys/net/if.c >>>>> ============================================================================== >>>>> --- head/sys/net/if.c Tue Oct 15 10:19:24 2013 (r256518) >>>>> +++ head/sys/net/if.c Tue Oct 15 10:31:42 2013 (r256519) >>>>> @@ -633,8 +633,7 @@ if_attach_internal(struct ifnet *ifp, in >>>>> socksize = sizeof(*sdl); >>>>> socksize = roundup2(socksize, sizeof(long)); >>>>> ifasize = sizeof(*ifa) + 2 * socksize; >>>>> - ifa = malloc(ifasize, M_IFADDR, M_WAITOK | M_ZERO); >>>>> - ifa_init(ifa); >>>>> + ifa = ifa_alloc(ifasize, M_WAITOK); >>>>> sdl = (struct sockaddr_dl *)(ifa + 1); >>>>> sdl->sdl_len = socksize; >>>>> sdl->sdl_family = AF_LINK; >>>>> @@ -1417,13 +1416,23 @@ if_maddr_runlock(struct ifnet *ifp) >>>>> /* >>>>> * Initialization, destruction and refcounting functions for ifaddrs. >>>>> */ >>>>> -void >>>>> -ifa_init(struct ifaddr *ifa) >>>>> +struct ifaddr * >>>>> +ifa_alloc(size_t size, int flags) >>>>> { >>>>> + struct ifaddr *ifa; >>>>> + >>>>> + KASSERT(size >= sizeof(struct ifaddr), >>>>> + ("%s: invalid size %zu", __func__, size)); >>>>> + >>>> >>>> We have crashes stemming from this: >>>> >>>> panic: ifa_alloc: invalid size 16 >>>> >>>> panic() at panic+0x43/frame 0xfffffe009e777760 >>>> ifa_alloc() at ifa_alloc+0xd6/frame 0xfffffe009e777780 >>>> in6_ifadd() at in6_ifadd+0xd8/frame 0xfffffe009e7778a0 >>>> nd6_ra_input() at nd6_ra_input+0x1023/frame 0xfffffe009e777a80 >>>> icmp6_input() at icmp6_input+0x5b6/frame 0xfffffe009e777c00 >>>> ip6_input() at ip6_input+0xc94/frame 0xfffffe009e777ce0 >>>> sppp_input() at sppp_input+0x502/frame 0xfffffe009e777d70 >>>> pppoe_data_input() at pppoe_data_input+0x1e7/frame 0xfffffe009e777de0 >>>> swi_net() at swi_net+0x19b/frame 0xfffffe009e777e60 >>>> ithread_loop() at ithread_loop+0x266/frame 0xfffffe009e777ef0 >>>> fork_exit() at fork_exit+0x82/frame 0xfffffe009e777f30 >>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe009e777f30 >>>> >>>> in6_ifadd has: >>>> struct in6_addr taddr; >>>> ifa = ifa_alloc(sizeof(taddr), M_WAITOK); >>>> >>>> should the assert be simply removed? >>> >>> Hi Mateusz, >>> >>> I believe you just found a bug. >>> >>> Try the following patch please, >>> >>> --- a/sys/netinet6/nd6_rtr.c >>> +++ b/sys/netinet6/nd6_rtr.c >>> @@ -1243,8 +1243,7 @@ in6_ifadd(struct nd_prefixctl *pr, int mcast) >>> >>> /* No suitable LL address, get the ifid directly */ >>> if (ifid_addr == NULL) { >>> - struct in6_addr taddr; >>> - ifa = ifa_alloc(sizeof(taddr), M_WAITOK); >>> + ifa = ifa_alloc(sizeof(struct in6_ifaddr), M_WAITOK); >>> if (ifa) { >>> ib = (struct in6_ifaddr *)ifa; >>> ifid_addr = &ib->ia_addr.sin6_addr; >>> >> >> Thanks for the patch. I don't have means to readily test it. >> >> This panic was getting in the way of looking at another panic so I did >> not pay much attention. >> >> But now that you point this out, I don't think the patch is sufficient. >> >> in6_get_ifid starts with NET_EPOCH_ASSERT. >> >> At the same time malloc(..., M_WAITOK) is illegal to call from an epoch section. > > So M_NOWAIT should be used, instead of M_WAITOK . > >> >> I don't know if in6_ifadd is called within net epoch, either way the >> above two are clearly contradictory. >> >> Is there are a reason to malloc this in the first place? > > I have not look into the code throughly. That was introduced via commit https://cgit.freebsd.org/src/commit/?id=9e792f7ef7298080c058fbc2d36a4e60e596dae9 . > > See https://reviews.freebsd.org/D51778 for more context. Wait, so first the bug came in on a controversial chnage to which multiple FreeBSD people said they were not sure what it is good for and then we get panic reports from the same source about their own code? I think it is time to backout the original at this point. At least then the commit history can be fixed? /bz -- Bjoern A. Zeeb r15:7 --0-511174828-1759594413=:11296--