From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (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 EE17C100B3 for ; Thu, 17 Aug 2023 22:45:40 +0000 (UTC) Received: from out-61.mta1.migadu.com (out-61.mta1.migadu.com [95.215.58.61]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14D3D35B1 for ; Thu, 17 Aug 2023 15:45:34 -0700 (PDT) Message-ID: <5f061b5f-89a0-fadd-7233-e5bb877e680d@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1692312332; 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=P5cm9AFLUSjvLg/Q5Q1zFGOnGqPEazcej1e5Ponp9Lk=; b=Hvo9WyrqqLdmBrOmgLICRjw0tfxyKAXp19sK4HUy9JuFjgU6UDqZvkuaim2+EfOYZTBP3N FMmjmAuA0584Vu48WojIMChntVTusQl6F2OginhdNT8qfG79Wn9S1paXXbhmfTlp5WL45C EjHhXLdhOQJckjf91YfcKNStXRU/tXg= Date: Thu, 17 Aug 2023 15:45:26 -0700 Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [RFC bpf-next v3 4/5] bpf: Add a new dynptr type for CGRUP_SOCKOPT. Content-Language: en-US To: Alexei Starovoitov Cc: bpf , Alexei Starovoitov , Song Liu , Kernel Team , Andrii Nakryiko , Stanislav Fomichev , Yonghong Song , Kui-Feng Lee , Kui-Feng Lee , Kui-Feng Lee References: <20230815174712.660956-1-thinker.li@gmail.com> <20230815174712.660956-5-thinker.li@gmail.com> <20230817012518.erfkm4tgdm3isnks@MacBook-Pro-8.local> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Martin KaFai Lau In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On 8/17/23 2:46 PM, Alexei Starovoitov wrote: >> To avoid other potential optname cases that may run into similar situation and >> requires the bpf prog work around it again like the above, it needs a way to >> track whether a bpf prog has changed the optval in runtime. If it is not >> changed, use the result from the kernel set/getsockopt. If reading/writing to >> optval is done through a kfunc, this can be tracked. The kfunc can also directly >> read/write the user memory in optval, avoid the pre-alloc kernel memory and the >> PAGE_SIZE limit but this is a minor point. > so I'm still not following what sleepable progs that can access everything > would help the existing situation. > I agree that sleepable bpf sockopt should be free from old mistakes, > but people might still write old-style non-sleeptable bpf sockopt and > might repeat the same mistakes. > I'm missing the value of the new interface. It's better, sure, but why? > Do we expect to rewrite existing sockopt progs in sleepable way? > It might not be easy due to sleepable limitations like maps and whatever else. so far our sockopt progs only uses sk local storage that can support sleepable and we can all move to the sleepable way to avoid any future quirk. Agree that others may have sockopt prog that has hard dependency on non-sleepable. If the existing non-sleepable and sleepable inter-leaved together, it would end up hitting similar issue. Lets drop the idea of this set.