From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 894FC421227 for ; Mon, 17 Aug 2026 15:50:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786981818; cv=none; b=H2+/QYICNtr0QDrc5Ip9veTfLFNSJR5VMO4D/PL7KZNlFDUqX6r/2UhKmcdcJjAwWsv4S+YCFwLgGnutLrmsRx/7zvPiJGmuAjxNF3P4OpJQwaiRXDcQcmCUakHsYwJJzcwWx9qatQDHK25qAOl1rnUwxUKtYD14oYMaZP2WgSg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786981818; c=relaxed/simple; bh=upfOBcx67ccUHVILLZj6LHzNU3JzIn4py8iQVhZWU7I=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=VluUOzJ37l6O68O2opefv/KZvHIGpTdmcIc9YtFaglA1sZXr3TmRdPE9Nv7Z76fWafvSYsT1YZU7U4/fV5fwzifHubc56QRFxllwwt05LuztTJuo4cVf1tiHzUg0qkSYAmFNJaR8W2xdqh0U1rLw072AvcTU+4OM6aX8n9ZIIFs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hlmbvgP3; arc=none smtp.client-ip=209.85.215.179 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) header.d=gmail.com header.i=@gmail.com header.b="hlmbvgP3" Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-cbe6295f05bso11871a12.1 for ; Mon, 17 Aug 2026 08:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786981817; x=1787586617; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=ZqT0TP65I8/htknlz+a1OswTUdfg3AFV14OnEYJmW04=; b=hlmbvgP3nnPeLEfNfXo++sjd7Kd24+tQKpC0DkUL3r1qcfa9vHYRzrOkx8pw+FG9VE 1REURMHWPXrj1sGFEOcqzs46OgPRER6IwlhDCDrxR6WQXNCO3GMvg73qM8zdPEQU7OMZ /4YFmpB2xetxg+NQXrm95/8ZDfToVwDnDHsm7Wwdc6q7A6J+yIwLyQku+9p/dUxAhuNN EbelIv08p04TJEIv3oUPLnxG3JhcdzovscgLpPIgoEz/Yfqo9+u+IKedZtbWuJuH7WV6 eaZNJgfe6v21oL+ew8OAmJSOEvBySQig0q7T7LjJBAqYgnshtTCjTcS/2bIFmv9Ukmn2 k3jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786981817; x=1787586617; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ZqT0TP65I8/htknlz+a1OswTUdfg3AFV14OnEYJmW04=; b=dQiTpnrgK41+eEUbizrME0gv3SCRpvBIsOAkofpKe7fy58Nx3nDrLKluJ4z4bcZcVg ipw46aF7aK1pg3lZ0usTOVjZnxSdh3H/JaoZW/PsIv+tmdWNPFmIXE6fI7+8mMpGMrML CuDZyEjYt7Cr0O+uQWTYOI0ieOx9831GMv9PKoHjDnZsvHemBMuR3gHLyFGzbJfpt/9R /ezzP9SHNvImRa0dxF9Ltu6ZxdILUnyvji9ruEz1Jg9XLft4rx3R8tuJGa6Q0Oyaqdg6 WKSc6tUJmi6cQ+R06g5Uv0R52hTLPUjadR8XroKe0mVvNzvnIq94IFIioytortOQzMg3 r7vA== X-Forwarded-Encrypted: i=1; AHgh+RpadwY6osVia3YRkeWeC+xtRSqR9IV04w+YEOjNuGG9GSQL6c97tJYVIPB43ih3EDjaC3JZJ8YG96G0PNY=@vger.kernel.org X-Gm-Message-State: AOJu0YzBc4WQ9h40hela9wEPtec9E25mzrm+kk9mgaIpjSwQMvS4c0Rd oMpnBIr0PEcZwgnA2+54LbtW1lI1qLB/ak5UKiZBZ9uLiwde1j8ynbT4 X-Gm-Gg: AR+sD11RL2ERRU5Iz4jZD7OkCBICsZUbtC4PVHPYo/33SaheU9rOaBf2jOsTADHIhId P9N5Y2cWAc6FJDrYW/edAcpRPJkPAcPi4rIP/s+aAJuH0zuiLFeY+e/dS4TirYUnAhPgtdZ3p7a Zu0s12Oo6KHUZlBcFY5teE/C2K6fUAPgOW+6SqYVSMuk5Wadz2JlB020HnrhW+lFXjaZBu8eMvm ZhWkNUrRu9fWBSsl1+2g9ebJb4Z+KF4uq+75WMPAoTtf0jdqHIQW5TaNDC4npUZCHTZvTMMA2Cj XTO2edhdaJGcR8SFWUj2gmRqtfbzVKoCLB7h002TLF4NBMw/hgrGAYZecxO0meW60EhXbJrQkN2 NNBC2kvjQdOZ4glj1mCitKMgTUF0XevZWUP/WvglRZmDvrRkx90Bsm/61IchFR2e5bWHZVkZUER XWO74uxZTPl4Tbpb/G9RmvohKd9Wsg9tZw7uatT2CFhUTjQY7vFW8Zlkg= X-Received: by 2002:a17:90b:4d12:b0:387:d5bd:622f with SMTP id 98e67ed59e1d1-3955f25132dmr11450a91.18.1786981816608; Mon, 17 Aug 2026 08:50:16 -0700 (PDT) Received: from omen-arch ([211.58.239.197]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-39339b0d6f4sm4682766a91.0.2026.08.17.08.50.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Aug 2026 08:50:15 -0700 (PDT) From: Junseo Lim To: John Fastabend , Jakub Sitnicki , Jiayuan Chen Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrii Nakryiko , Eduard Zingerman , linux-kernel@vger.kernel.org, bpf@vger.kernel.org, netdev@vger.kernel.org, Sechang Lim , Daniel Borkmann , Emil Tsalapatis Subject: [PATCH bpf v3 0/2] bpf, sockmap: fix forward allocation accounting in strparser self-pass path Date: Tue, 18 Aug 2026 00:50:07 +0900 Message-ID: <20260817155009.232670-1-zirajs7@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The strparser SK_PASS path can queue cloned skbs back to the same socket. When one TCP receive skb is split into many strparser messages, repeated receive-owner assignments for unowned clones can leave sk_forward_alloc in deficit before the next skb_set_owner_r() charge. Teardown can then uncharge more memcg pages than were reserved and trigger a page_counter underflow warning. Fix by avoiding another receive-owner transition for same-socket skbs that are already receive-owned by the socket. For unowned strparser self-pass skbs, settle any existing sk_forward_alloc deficit with sk_rmem_schedule(sk, skb, 0) before skb_set_owner_r(). Patch 1 also fixes psock backlog retries by restoring the original skb redirect metadata after skb_bpf_redirect_clear(). If a deferred strparser self-pass skb needs forward-allocation settlement, that work is done under the socket lock. The selftest adds a sockmap_strp case using a one-byte stream parser and an SK_PASS verdict program. The test checks INET_DIAG_MEMINFO to verify that sk_forward_alloc does not go negative after exercising the self-pass delivery path. Changelog: v2 -> v3: - Do not call skb_set_owner_r() again for already receive-owned same-socket skbs. - Preserve the original _sk_redir value across psock backlog retries. - Add a backlog-specific self-pass path so deferred strparser forward-allocation settlement runs under the socket lock. v1 -> v2: - Keep skb_set_owner_r() and use sk_rmem_schedule(sk, skb, 0) to settle sk_forward_alloc instead of skipping the owner transition. (Emil Tsalapatis) - Apply the same handling to psock backlog retries. - Add a sockmap_strp selftest based on the reproducer. - Add a Reported-by tag. - Change the Fixes tag to point to the commit that introduced the issue. v1: https://lore.kernel.org/bpf/20260723065244.186916-1-zirajs7@gmail.com/T/ v2: https://lore.kernel.org/bpf/20260801102633.1872012-1-zirajs7@gmail.com/T/ Junseo Lim (2): bpf, sockmap: settle sk_forward_alloc for strparser SK_PASS selftests/bpf: Cover strparser self-pass forward allocation net/core/skmsg.c | 125 +++++++++++-- .../selftests/bpf/prog_tests/sockmap_strp.c | 171 ++++++++++++++++++ .../selftests/bpf/progs/test_sockmap_strp.c | 6 + 3 files changed, 282 insertions(+), 20 deletions(-) -- 2.55.0