From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) (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 6159B24BBE4 for ; Wed, 14 Jan 2026 04:08:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768363691; cv=none; b=Cs4hbaWsOsf4Uu9xKvwKcMHxoXzGxw9QnLdbh04fa5yd51xYPY/qVbu2/IeZJpdAd4F9IzEt/8EHlNVEELQxqcGZ8YPkulKA0zm3Y/r4IAlzs8Q0lhqPLv7yIGrgVQTN5cmX8Tmh/3gzKAp+D33aai9dHAZVwZgzTRnR9HvR4sw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768363691; c=relaxed/simple; bh=Aum4e75q/c3WD6beapNhk9vDmdL2F+An3dcb9kVyPNw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mroMx0q8qPMu5O4NB/R8UYeuC4MTK5NCMCLOuiPp5EfxJBpBVVUnS88MuI3U+jQM7Xhm//XUTKvpPeueHtArMy1+q0KQXpf3Hv0n2sXRMlCldQalHfGy7hi6V9IW82dSsYIvXAcHq7YYkf6bHO/mYzcJNmp9DoJVtMaHsc3une8= 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=r8aqhHFK; arc=none smtp.client-ip=91.218.175.179 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="r8aqhHFK" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1768363688; 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=vjgazky+ZRtvPL75QtxyxWAG7S1HJNuCDfOmdekMQb4=; b=r8aqhHFKIgqYlt4KzfjTy42NxtLo8k/QdluHHs/RtNdt/NIJ1m9DeINM0hCi/p8oIJ7EQ9 SS0iMcFC04uEk91NrPICu2cgPtTp8mP56PXd7dV2je5gGjl2PHH5HLi7S/F47J/hzEe27k XkePeuCi6/ZCGEOsZUZyw0DIIH+fU0U= Date: Tue, 13 Jan 2026 20:08:02 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next v1 03/10] bpf: Verifier support for KF_IMPLICIT_ARGS To: Eduard Zingerman , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau Cc: Mykyta Yatsenko , Tejun Heo , Alan Maguire , Benjamin Tissoires , Jiri Kosina , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, sched-ext@lists.linux.dev References: <20260109184852.1089786-1-ihor.solodrai@linux.dev> <20260109184852.1089786-4-ihor.solodrai@linux.dev> <18d9b15319bf8d71a3cd5b08239529505714dc96.camel@gmail.com> <5027595d4eff50d423af8ebc5fecd6a0f7229d60.camel@gmail.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ihor Solodrai In-Reply-To: <5027595d4eff50d423af8ebc5fecd6a0f7229d60.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 1/13/26 5:06 PM, Eduard Zingerman wrote: > On Tue, 2026-01-13 at 16:03 -0800, Ihor Solodrai wrote: >> On 1/13/26 1:59 PM, Eduard Zingerman wrote: >>> On Fri, 2026-01-09 at 10:48 -0800, Ihor Solodrai wrote: >>> >>> [...] >>> >>>> --- a/kernel/bpf/verifier.c >>>> +++ b/kernel/bpf/verifier.c >>>> @@ -3271,6 +3271,38 @@ static struct btf *find_kfunc_desc_btf(struct bpf_verifier_env *env, s16 offset) >>>> return btf_vmlinux ?: ERR_PTR(-ENOENT); >>>> } >>>> >>>> +#define KF_IMPL_SUFFIX "_impl" >>>> + >>>> +static const struct btf_type *find_kfunc_impl_proto(struct bpf_verifier_env *env, >>>> + struct btf *btf, >>>> + const char *func_name) >>>> +{ >>>> + char impl_name[KSYM_SYMBOL_LEN]; >>> >>> Oh, as we discussed already, this should use env->tmp_str_buf. >> >> The env->tmp_str_buf size is smaller: >> >> #define TMP_STR_BUF_LEN 320 >> >> *And* there is already a local char buffer of size KSYM_SYMBOL_LEN >> already in use in verifier.c: >> >> int bpf_check_attach_target(...) { >> bool prog_extension = prog->type == BPF_PROG_TYPE_EXT; >> bool prog_tracing = prog->type == BPF_PROG_TYPE_TRACING; >> char trace_symbol[KSYM_SYMBOL_LEN]; >> [...] >> >> Since these are function names, the real limit is KSYM_SYMBOL_LEN, >> right? >> >> Sure >320 chars long kfunc name is unlikely, but technically possible. > > 320 is good enough, you'll be able to cover this: > > kfunc_trace_long_descriptive_kernel_symbol_for_tracing_scheduler_memory_io_and_interrupt_paths_during_runtime_analysis_of_latency_throughput_and_resource_contention_on_large_scale_multiprocessor_linux_systems_using_bpf_and_kprobes_without_requiring_kernel_recompilation_or_system_restart_for_production_use_cases_v2x > > But not this: > > kfunc_trace_kernel_scheduler_and_memory_management_path_for_observing_task_lifecycle_events_context_switches_page_fault_handling_and_io_wait_states_while_debugging_performance_regressions_on_large_multiprocessor_systems_running_preemptible_linux_kernels_with_bpf_tracing_and_dynamic_instrumentation_enabled_for_deep_visibility_into_runtime_behavior_and_latency_sensitive_code_paths_without_recompilation. > > Should suffice, I think. I will laugh for at least 321 seconds when the size of this buffer will have to be increased, and will make sure you hear it :) They thought 640K of memory is enough, you know.