From nobody Tue Sep 30 02:59:20 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 4cbN7w1YsTz69Gnx for ; Tue, 30 Sep 2025 02:59:40 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 4cbN7v6lY5z3fsL for ; Tue, 30 Sep 2025 02:59:39 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-62fbc90e6f6so9487843a12.3 for ; Mon, 29 Sep 2025 19:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759201173; x=1759805973; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=655sC4rpvlUfpg5dFj1G7w0VlmI5ubSOALC0/J9hhN4=; b=H7xtpS9It+/0z9y3XlpOVFn18xqEut7MR7/9BKsoI9RhZudWOet+KMFsUluSzjrZ/2 xuXHGlb8FYFLbyUJRTzU9bmRsQeLI1zc+u1jcxJpGhCIDH+5+k+a3HNMB3S/SvTG3Buz 6KLeCEt4GU705m+vxb105WEEe6QiFVof/69gVJSvS1CBAq5vutrkfM67Y7dDM8vqucnT 7HKwVr0vu3Y8cGWPPLlCiQfmxo3jS6lk+nljKprvF+q99T4oIVmUWVri9UHHld0liBAM QVCepTVaTa4velGGs2qzVGmJ32jfVSNXg89DtrdEkHUTqk93O3w1euXBOG3MofUyszO7 l90g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759201173; x=1759805973; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=655sC4rpvlUfpg5dFj1G7w0VlmI5ubSOALC0/J9hhN4=; b=ifpU1DFLRyiexB2y0ssqGvY3nNqQ40N+wLPSGUXyS/7WnUYr2U7/YDkqo3ubS67n0Q vWUCRb3hJoSFcjuaFsyWbCwYYs8Cp16qrSdbYq/pt+9Bck3SUXfgGqEWeFWGPM+aoxSD 0boTOpFaCfLKz9r0GtL3sRinfIP87ALYKN/Vv/uGmwM5PhUllfiWcXrnmZ/coxfby8UT 4uULvRji+ig8X2hAOjew/LGgxHeKZ1/Wpf9RisxyjmrKBcqc9MPT2m4wxdCbG4pF6btI nAzaFOrBLzH2KNOgJ7d8zdfnvh7k20FICaviXZXPztzFJxI6avYIsJ8UqIkA2SfOmnjI 5OKA== X-Forwarded-Encrypted: i=1; AJvYcCWqsqNalhMo3o0G5HXq1pUCvF1uk0JWfMDWscJ8ErYVR/5k4sFIGbKjoVF2TyZpNVNvlQZlx23ztKJlURfoajOZC8SqjQ==@freebsd.org X-Gm-Message-State: AOJu0YxfJw/Cz3IjqNx9svBiaRDQ9f2T7z30sjg+7kjcOj1WAs7LzbTN ie75dnVIZ5hrNWdVeXQNuOi3X6LoIan8YrfsF8IDg8DjNVNRSCgK6heDo0xUXxejTAxzM7DrRLI X4uyKFxI9PsFGO0GIeuEaOsbEfvLrB9c= X-Gm-Gg: ASbGncuyKedJoHvoSxxFsBsDWVr5kONx/aKTwpwt6mjKYy8SKDcDtNU18iEjYEc4oeN Ic/Ua3ouI+MGFYf9ZcCwRJcl1cpR5zTC5g2+QWZtiV6QMTgmKZl4FQZkKPBzQB7YAuBw+xIpW/N hLggatfrqVcylEksmHAvbcGy5vZyx9o1bUYzf86poSGbgpP3HmxcOIsvxAFVyeSRcEj4l5InzZw ZxR6MEqnOChwNDxUu6c5ZfMZcwC5PoZzR4sRiRy4o8jqlpagjVft2f5CzpQED+AFQ== X-Google-Smtp-Source: AGHT+IEoXD1jViEcnSBhOr6D0pARJe+iefpMfvWYn+udV9ZJFSNTs1uELINpJk6n3x3+Ll/V8EwykeVjheC6jlIfP3I= X-Received: by 2002:a17:907:7246:b0:b45:66f6:6a0a with SMTP id a640c23a62f3a-b4566f67105mr12259666b.44.1759201173362; Mon, 29 Sep 2025 19:59:33 -0700 (PDT) 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 References: <201310151031.r9FAVgRP008282@svn.freebsd.org> <35D99D40-5534-402A-8479-64C71604206B@FreeBSD.org> In-Reply-To: <35D99D40-5534-402A-8479-64C71604206B@FreeBSD.org> From: Mateusz Guzik Date: Tue, 30 Sep 2025 04:59:20 +0200 X-Gm-Features: AS18NWClyPDAvNA4QCXOvMoVq1MdFsLhzIBf-mk842H40MiNGViONK0euTJgvAE Message-ID: Subject: Re: svn commit: r256519 - in head/sys: net netatalk netinet netinet6 netipx To: Zhenlei Huang Cc: Gleb Smirnoff , src-committers@freebsd.org, "" , "dev-commits-src-main@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cbN7v6lY5z3fsL On Tue, Sep 30, 2025 at 4:38=E2=80=AFAM Zhenlei Huang wr= ote: > > > > > On Sep 29, 2025, at 10:29 PM, Mateusz Guzik wrote: > > > > On Tue, Oct 15, 2013 at 12:31=E2=80=AFPM 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 se= tup > >> 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 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > >> --- 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 =3D sizeof(*sdl); > >> socksize =3D roundup2(socksize, sizeof(long)); > >> ifasize =3D sizeof(*ifa) + 2 * socksize; > >> - ifa =3D malloc(ifasize, M_IFADDR, M_WAITOK | M_ZERO); > >> - ifa_init(ifa); > >> + ifa =3D ifa_alloc(ifasize, M_WAITOK); > >> sdl =3D (struct sockaddr_dl *)(ifa + 1); > >> sdl->sdl_len =3D socksize; > >> sdl->sdl_family =3D 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 >=3D 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 =3D 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 =3D=3D NULL) { > - struct in6_addr taddr; > - ifa =3D ifa_alloc(sizeof(taddr), M_WAITOK); > + ifa =3D ifa_alloc(sizeof(struct in6_ifaddr), M_WA= ITOK); > if (ifa) { > ib =3D (struct in6_ifaddr *)ifa; > ifid_addr =3D &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 sec= tion. 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?