From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=185.226.149.38 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793582460; b=Z4fK+vnh5Aa5FKOtUi6Be0jHlh+DV/q+VEPhfoCnH8gCMn8JnYMD7DpcrwwKwtC53YaJ zZ+dyKWYKlU3I1wFWHd8ZSaVR9wbN4PAd3CeX+ZEaiF/qIEBGoVSBEf9EjTyIuzy6FE5v TjO8IRrpxhS8hPqximIPfMQERGPB2EC3oiCmyR9xhXB7PpBgWxDiE0svdfmNtXK1/SxQQ RtSZc79tPELlsP8+IpSyjcvbpoUXySVAyhA08PrONjE1JOlKn2LEofkaZ9WsbXTmD1Zl8 8T1uOi7zLsvdaJ7Dv6NVSmFoZhCTtA3vTBCL55xDeZANgpHCw/lLT248DNd/Y9Iyc9Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793582460; h=DMARC-Filter:Received:DKIM-Signature:Received:Received:Message-ID: Date:MIME-Version:User-Agent:From:Subject:To:Cc:References: Content-Language:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=G90+AFF7kEGEqmo5bVvMlpAQaZeZsFPxsjzSqr1O6BE=; b=bbgEYyYjgh377xGZbH9o4cWE2k40Rsn6juZYudTjzSYbQmNnRjusePZmeN2p0j94bhmo SxzDUwgPOiUUuARtnl98WW3ISoQtXPkfTpsvIttr9vs8txn9hlyOXArf8uySQhRVaBAlR eTj20B3PcCjJOurNXkecJeQuH4A6nMeD5Cbwg397ZMO0vlbf383GMyd8xbowE7hh9IGty 1J4LCjEstDf3nRdkV0rDh0eG9E9fOn2HUJrk2BM1XWgk2ubRRCiJ4apeb8eYXcTzbvLVZ Nx0FbZMJJE7YBYZP7ZdprOn91synphMdI9nWANisBl7trxoS8HLZVr0SKfYPpHjo7dA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=rbox.co; spf=pass smtp.mailfrom=rbox.co; dkim=pass header.d=rbox.co header.i=@rbox.co header.a=rsa-sha256 header.s=selector1 header.b=Y2CS9Qot; arc=none smtp.remote-ip=185.226.149.38 Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [185.226.149.38]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD01A606A329 for ; Mon, 2 Nov 2026 01:20:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org CD01A606A329 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rbox.co Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rbox.co Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=rbox.co header.i=@rbox.co header.a=rsa-sha256 header.s=selector1 header.b=Y2CS9Qot Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1xNgjH-00AGrB-D2; Mon, 02 Nov 2026 02:20:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rbox.co; s=selector1; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Cc:To:Subject:From:MIME-Version:Date:Message-ID; bh=G90+AFF7kEGEqmo5bVvMlpAQaZeZsFPxsjzSqr1O6BE=; b=Y2CS9QotRZ6XM39LE5XVcV5tTd GL/X2Yl2GJPKe0Uw/Ci66wfiyopZWD4QIvEi5IAPjcq7f4WYZHgrgMJ9BnyvCsfJFslnH+XSt0MZP UsHlyKFNPAWbbDwss2RMajcwjr9MpdNbI9fEdMRY0t01T/uLLWt9OaWgZHNk7aWoebFYpzOcyubEo 86wTPCqck8Esd71GkQrQy5BAwElwzCWuvGUZsBtgzrNIXNiza5zb/5o1wHQpHRqDkNe1t9fJ7obYi 8EQ9XP77UojVn0hfZ7NMJSz4+9d6p0eACZuCjrgyQtsEidSB0IbVeOmlCKOUQh1tVHHsMZ8gVcpNg Sfv5bdJg==; Received: from [10.9.9.73] (helo=submission02.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1xNgjH-00067f-3b; Mon, 02 Nov 2026 02:20:55 +0100 Received: by submission02.runbox with esmtpsa [Authenticated ID (604044)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.95) id 1xNgj8-00AE9Q-C3; Mon, 02 Nov 2026 02:20:46 +0100 Message-ID: Date: Mon, 2 Nov 2026 02:20:39 +0100 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Michal Luczaj Subject: Re: [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Shuah Khan , John Fastabend , Lorenz Bauer Cc: bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Sashiko , Jakub Sitnicki References: <20261016-sockmap-update-limit-iter-v1-0-23fa946db59e@rbox.co> <20261016-sockmap-update-limit-iter-v1-2-23fa946db59e@rbox.co> <0bcebb4f-4b36-4f8e-a3cd-1eb0455081a8@rbox.co> Content-Language: pl-PL, en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/1/26 02:28, Alexei Starovoitov wrote: >> Ah, sure. So the same bit for unix_reg_info left for later? > Yes. iter/unix cannot update sockmap after this patch. I've meant setting PTR_TRUSTED on bpf_iter__unix::unix_sk for the sake of unix_sk-consuming functions other than map update. bpf_setsockopt() came to my mind, but now I've realized it doesn't really need that. So this PTR_TRUSTED it's just a preparation for plain-PTR_TO_BTF_ID removal? >> I've noticed commit 7cc639dc45c5 ("bpf: Don't take an extension for an >> iterator program") got merged. Should I post v2 with the env->prog->type >> check dropped or you guys don't want to restrict iters anymore? > > The former. We still want it. > bpf-next doesn't close during merge window. Only people that > can process patches get busier. Ok, I got confused by Documentation/bpf/bpf_devel_QA.rst: "for the time when the merge window is open, bpf-next will not be processed". > Pls send the PTR_TRUSTED part in v2. > > I'd also limit tracing_iter_filter() to iter/tcp and iter/udp. Oh, right. Commit 4ddbcb886268 ("bpf: Add bpf_sock_destroy kfunc") says bpf_sock_destroy() expects a locked sk. So if I get it right, with bpf_iter__sockmap::sk being PTR_TRUSTED, we allow iter/sockmap to invoke bpf_sock_destroy() on an unlocked sk? As for now, v2 posted: https://lore.kernel.org/bpf/20261102-sockmap-update-limit-iter-v2-0-e96a63c43b39@rbox.co/