From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-180.mta1.migadu.com (out-180.mta1.migadu.com [95.215.58.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 52669270EDF for ; Wed, 25 Mar 2026 01:42:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774402973; cv=none; b=Jab1QaDfgQBABcr3QZtsPXyAorQxCNqPp+TyD4p62ycaDFgKgfEIamQ+5CDBVb0ADnVNiK/FSHTG0XTsySHUrMwL4+nC0MY/DlOe1PMSjQ+w2dCo0cCJlITQ3Bq+THRyvMRrn8JFXEiUET8prZ3bgMfyGM3VSJfeksj7jmzqACY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774402973; c=relaxed/simple; bh=poc8RQKZHV6IyOZIlkXBpoaLWdoilvRbScnWqgIzwkg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fPem/+BG6TlJdfyPXAJBdHN/9sYewi3Uoar8UXqWZOT/CE+pmO7V/xymgtNp0JZHyw0l3IqTU8ddboBN6vmduoA6EAbzu3Nly7vbxsaKSIaE04Ph8sVf5NUukf5z0COkVW4XTMJBz4akzFEvvj9MzGzUrFA4JXbe/+6NEsZN/SY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=h4ilSWka; arc=none smtp.client-ip=95.215.58.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="h4ilSWka" Message-ID: <401134e3-2a2f-4c23-8ba0-3a4cc901d6a4@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774402960; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oYZezwn0ZMtB7MrRH2625PaWZJBlv5I3izmJUNinHpU=; b=h4ilSWkafyyuwUX/2VlnmemnQoV//SuMV1p7ZUAymmYa9O79QdPScsrxWS0EsavENGU0Fg GM7UcmvzaWMc/d9DebK2+QIJgUQT8DCm+wwgieK2UEHLzNIqougGu2yvyez4VQcxRzl2aX sojrqgVxAcULluq70GxWejoMEnE6xzE= Date: Wed, 25 Mar 2026 09:42:29 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next 1/3] bpf: Disallow freplace on XDP with mismatched xdp_has_frags values Content-Language: en-US To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , bpf@vger.kernel.org Cc: Alexei Starovoitov , Daniel Borkmann , John Fastabend , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , "David S . Miller" , Jakub Kicinski , Jesper Dangaard Brouer , Lorenzo Bianconi , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, netdev@vger.kernel.org, kernel-patches-bot@fb.com References: <20260324150444.68166-1-leon.hwang@linux.dev> <20260324150444.68166-2-leon.hwang@linux.dev> <87ecl9mc9d.fsf@toke.dk> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Leon Hwang In-Reply-To: <87ecl9mc9d.fsf@toke.dk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 25/3/26 00:18, Toke Høiland-Jørgensen wrote: > Leon Hwang writes: > >> xdp_has_frags was introduced by the commit >> c2f2cdbeffda ("bpf: introduce BPF_F_XDP_HAS_FRAGS flag in prog_flags loading the ebpf program"). >> >> The commit f45d5b6ce2e8 ("bpf: generalise tail call map compatibility check") >> was to ensure backwards compatibility against tail calls. However, it >> missed that XDP progs can be extended by freplace progs, which could break >> the backwards compatibility, e.g. xdp_has_frags=true freplace progs are >> allowed to attach to xdp_has_frags=false XDP progs. >> >> To avoid breaking the backwards compatibility via freplace, disallow >> freplace on XDP programs with different xdp_has_frags values. > > The problem you describe is not actually a problem, though? A > frags-aware program can run on a non-frags interface just fine. > > You're messing with long-standing behaviour (since 5.18!) to solve a > non-existent problem. In a way that completely breaks the frags handling > in libxdp[0]: > > Running tests from ./test-libxdp.sh > [test_link_so] PASS > [test_link_a] PASS > [test_old_dispatcher] PASS > [test_xdp_devbound] PASS > [test_xdp_frags] FAIL > Kernel supports XDP programs with frags > check_load_frags: FAILED > check_load_nofrags_success: PASSED > check_load_nofrags_fail: PASSED > check_load_frags_multi: FAILED > check_load_mix_big: FAILED > check_load_mix_small: FAILED > Test test_xdp_frags exited with return code: 1 > > > Please don't do that. > > -Toke > > [0] Run 'make test' here: https://github.com/xdp-project/xdp-tools > Indeed, it failed to 'make test'. Will drop this patch in v2, as it wasn't an issue. Thanks, Leon