From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.217.48 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792537980; b=KPxX8SLCBVTNkD8V0GEIm4yp+7bvJtB+V4gy/DSiYcFcrUs6XfTC3BT2RkxgWKzuGeTP 868H53TnSDU318pdIn9vI64ery6B/54a4g6lqrRMpENQvijiZpanJ3151/9KPF48IzvJb S0c9ZIkFcr9ArAjhWlfhV2diZOnXBPpHuoa6cIeBuMGCvH/1U5QvMFONy/Uq1OW4661ov HduZQhACTtuz7S9YtZWdmHvgKRvaUlMwCuAknL6hKB00T17qMKmbs8HgpQZ8/ltbI3Fbk 1At7PmYb6L23PWWnuHJTAlRupCG6750WQ/9oLYZ4A5WUm5gJF7l02EpKXpdTus80gdg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792537980; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=V4dEpVJ6+z1cOz8lzxIgY22zi/dH+CU6Y8aHuWhhhWA=; b=b8smObxsc/T4LXm8fTUf3QPj/oXVxnZBoGBGrJoV+thrgsArgoa81SH4xZN0wbtoGMN4 irMfhuXzejOusf9DbnfksVHYV6kzf+godIBRRfgONmAQv6OX93N8pwqr5UoCtJmLtIlCK pRKEZiAb4GZE+NmFcfy0dHqSSPadXizzmibXvvKxw0LeYVFCNy76Dz7I2h6vmT0B6QRIL ApZvB8YhVDvMEGQLjjMgsu6z18iEfEO5zNegSeh3SSyGZn0rrfvx7ZiQTEM10wRg7MtUB +adljrD0QC2HIMgJoh0cZuxjQuKMkrSJF+cJYkPHopgBxUY4ENdF4knTdCE+H+Tj13w== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b="Bff/zOrQ"; arc=none smtp.remote-ip=209.85.217.48 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 578AA606A31B for ; Tue, 20 Oct 2026 23:12:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 578AA606A31B Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=Bff/zOrQ Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-745497ac8fcso131848137.0 for ; Tue, 20 Oct 2026 16:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1792537979; x=1793142779; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=V4dEpVJ6+z1cOz8lzxIgY22zi/dH+CU6Y8aHuWhhhWA=; b=Bff/zOrQS58D8lWXqbV5dgpvEkhMpH+A+e56BI4NZxfEzq1YHbf1gpbKVbSvCRUk2u PZ93UxEymZJRDkSwSxJH8vl4sCT44pwR5XyFRCpa6iUm4G60dyJi2m6wJvoutjeYgApC 1hMF5ffNK2zBSavYm0J8dFI+9wDpqFWfMhBZLkBePQuHeRC4DlrbNCDvSJnmHSEzV1yz F0hDmgJ7I/Fus9OhFHtI9ItSQueyGrEwc9fydxPQKw3A3z5UzFEEKoFo/h2Z0Yf6ISc+ wOCGVPS7mpH3kXX7QGtqwe8IL+5DyZcEXP1DokQPO5Dzty/rqLxL6HwMtbEFm3mxSpav Miww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792537979; x=1793142779; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=V4dEpVJ6+z1cOz8lzxIgY22zi/dH+CU6Y8aHuWhhhWA=; b=d8SYWgMwlMhpNCchgZ0Rue+FR8DPYWi0tst1uDgSSqraApaOFR/Dvh5MMDB37Nw0EN p5IOaJ6tHu/iisnieguHSxxxdLo2CujVhemcfsbvMnps3yrASfNuv8VreKIWUAcnSV4Z sXjDf0d4R/qV5Mnlm1pXE7bA7ZNO02Nj1hK+FnVwSkkMy5wphcyUE8R5k9WIdastOhcW yQoKa50uOPp0E0YRg2Aysrx1V4ZlGlWHwtD9sn+ZvjVs8dqwg4bODOj87RvCJdvjBjvd zEQFMTlk0veKOyNYNMCz67fz32t971RLWNA+XuCbaelVdcX32i2xf88bo0Zd9H7DJVnJ 7dXg== X-Forwarded-Encrypted: i=1; AKwUvByRtNiK6nSVbamkg4UKiEYAtva0KENZBDVjuRf+AdM4WZcNGEK7rt+uzQMPoKeg9p4CQEUhvIycbZg=@vger.kernel.org X-Gm-Message-State: AFq9FYLe5canedZQBC2Khus7VXicWqpp2wNcgAOxH7zxGsfFZW08YEfY 7HkyLV0yl3jlP+2pF2oZ0dmT5HrM6FPm/pePTTKoZ/kULPUKhkWTaf9c X-Gm-Gg: AYBFou1s33B0Ch5umwmsifcaW1dctJTEkW+Of5vARvTvnic//dCAz8Q6JAwsVD6IU0N v/kU866ncPvGSKg1c0UoQboC1R6UROsUPM5J8QYXini8OUaxWZJueESWcozftOV+l5Al1zgcEQX zgCJXyZgW8JCfP99F/Bk5OUxtl/rbGThrllWk3jvs1sLQ77x0msJNfI+uDqWMNbMjcI+FGm5+GU pOekCLMXQXz+rAVGLB8QQbRxRFsAdcaBxcvjsqpmMs82A7uDrTZ3Dpkisn2htTW/oaWemdzJBVy oYg+omz4s2U2FD+JKmHfs/HS/Kf5frrCwC+adUN5x0sc2RvCbZ0IHZoE6Wqv7w1D8VsUTErE6a8 5kB5fmkXiqwrJ5AXFuQBGCAi6PMsjWfa1CIrsOV9tamBZsapD0PzK7fpzaTE8SaTS7KQ6HCxr1B YEC05fZl+ub2V3gzaVZ8BzvXR/KSIXnVMo/A4ybLMXgC0R5POvCVY2gizulJGjhn2kddo9TRxMD 8Xsq9Kn1Uhs20FlLIE85prIILnM+pVLYqD2eFlX3npeZCKFOH/zF/j/HCCLrLwM1/MeASe0nDOU Iz8M5YsRGvqZ4EzYR6Tve0Mr8ax3ueMPkIn+Pg== X-Received: by 2002:a05:6102:a145:b0:7cc:95ed:3147 with SMTP id ada2fe7eead31-7cc95edaf07mr37812137.34.1792537978890; Tue, 20 Oct 2026 16:12:58 -0700 (PDT) Received: from gmail.com (111.46.245.35.bc.googleusercontent.com. [35.245.46.111]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-990d108ff73sm1235667241.7.2026.10.20.16.12.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2026 16:12:58 -0700 (PDT) Date: Tue, 20 Oct 2026 19:12:57 -0400 From: Willem de Bruijn To: "Michael S. Tsirkin" , Willem de Bruijn Cc: linux-kernel@vger.kernel.org, Chris Arges , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Phil Sutter , Jason Wang , =?UTF-8?B?RXVnZW5pbyBQw6lyZXo=?= , Xuan Zhuo , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, virtualization@lists.linux.dev, Max Krasnyansky , Rusty Russell , Jonathan Corbet , Shuah Khan , Randy Dunlap , Simon Horman , linux-doc@vger.kernel.org Message-ID: In-Reply-To: <20261020162048-mutt-send-email-mst@kernel.org> References: <6f23c55c6eba3e3ec6b2c7e3a80728a326ed58af.1792411304.git.mst@redhat.com> <20261020155917-mutt-send-email-mst@kernel.org> <20261020162048-mutt-send-email-mst@kernel.org> Subject: Re: [PATCH net v3 6/8] net: add a sysctl to opt out of virtio net hdr checksum validation X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Michael S. Tsirkin wrote: > On Tue, Oct 20, 2026 at 04:19:41PM -0400, Willem de Bruijn wrote: > > Michael S. Tsirkin wrote: > > > On Tue, Oct 20, 2026 at 03:54:23PM -0400, Willem de Bruijn wrote: > > > > Michael S. Tsirkin wrote: > > > > > The ingress validation as implemented by the previous > > > > > patch is stricter than what it replaced: GSO > > > > > packets whose checksum metadata matches no transport header are > > > > > dropped, and non-GSO ones get their checksum completed in place. > > > > > Such packets used to pass with the metadata unvalidated, > > > > > and with no overhead. > > > > > > > > > > I judge that this should not affect any deployments, but there is still > > > > > some risk that it does. In case a deployment depends on them anyway, > > > > > provide a per-netns switch to get the old behavior back: > > > > > > > > > > echo 0 > /proc/sys/net/core/virtio_net_hdr_csum_check > > > > > > > > > > The default is validating. > > > > > > > > > > Assisted-by: LLM > > > > > Signed-off-by: Michael S. Tsirkin > > > > > --- > > > > > Documentation/admin-guide/sysctl/net.rst | 19 ++++++++ > > > > > include/linux/virtio_net.h | 23 +++++++++ > > > > > include/net/netns/core.h | 1 + > > > > > net/core/dev.c | 6 +++ > > > > > net/core/net_namespace.c | 1 + > > > > > net/core/sysctl_net_core.c | 60 ++++++++++++++++++++++++ > > > > > 6 files changed, 110 insertions(+) > > > > > > > > > > diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst > > > > > index e586e17fc7a5..b1a1c4714b22 100644 > > > > > --- a/Documentation/admin-guide/sysctl/net.rst > > > > > +++ b/Documentation/admin-guide/sysctl/net.rst > > > > > @@ -246,6 +246,25 @@ processes are dropped unless socket option SOF_TIMESTAMPING_OPT_TSONLY is set. > > > > > Default: 1 (on) > > > > > > > > > > > > > > > +virtio_net_hdr_csum_check > > > > > +------------------------- > > > > > > > > virtio_net_hdr_validate? In case we do have to add more validation > > > > later. > > > > > > If you insist. My worry would be what if that validation is again > > > user-visible somehow and we need to distinguish users who want > > > to disable that future thing and users who want to disable > > > just this current thing. > > > > > > Hard to predict the future. But I will go with your intuition. > > > > Thanks, but definitely feel free to ignore my suggestions. > > > > My intuition would be to define as > > > > 0: off > > 1: everything one > > 2+: sadly needed fudge values because we keep having to tighten, > > but some crazy workloads need to opt-out to avoid breakage. > > yes you said i just do not get how it will work for userspace, > maybe u can explain? > > and what specifically is needed right now, while we > just have 1. Right now the sysctl is boolean. If we define it as a narrow, very precisely defined sysctl, then its exact behavior is set in stone. If we then add additional validation later, that can similarly have unintended breakage of weird users, we need to add another sysctl. And if that validation is not entirely independent, i.e., builds on this, you get a weird set of interdependent sysctls. While in general systems will run with all validation enabled, unless they do something weird that gets hit by validation. A single broadly defined sysctl ("validate input at the source") can be refined over time, including to expand to validation of other virtio_net_hdr fields or protocol combinations. Even if defining it more broadly we can still leave it a boolean: all validation on or off. Or, optionally, we can also define additional validation levels, e.g, 0:off, 1:everything-on, 2:validate-csum-only.