From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta1.migadu.com (out-189.mta1.migadu.com [95.215.58.189]) (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 C5CFB157487 for ; Tue, 20 May 2025 19:51:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747770667; cv=none; b=DEgyFwO2N5QvmP7wG02DDX7frtItdoqh/g8mdDdAb26VivAopjSjwF0CoT0eZFFKjkkbRHohOXROO2IJjYZijYnHQORKPuTHNu+IpzxJ43k/0hlmedy9uSaNNb+E2b30aILlsKzdxv0PrJ0H9Y7bLU0SJEGdSFLVj/a2oR32i8A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747770667; c=relaxed/simple; bh=rtMhPgLF66Y12FegexlAHU6LQgkH4cDkYk+lbajOdNk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UuAvssPn5I2zletzGjewc0bOQoxa+6ZxQHaNzCRqWwlYr29PgURtsVngEBbRj7hq837K8diMIrNWYmo7fyEblOrZkS+lnApZWbuNOO1shFk4BSMU8rtslPuIRgrYsrIYkLE0wGnjMlSY/uuFsXjIhpaV51ZR9NDzzTZDF3SRGOc= 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=fpxzjbtR; arc=none smtp.client-ip=95.215.58.189 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="fpxzjbtR" Message-ID: <9a9d68fc-38c4-4c52-b62a-c0c4a522684d@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1747770661; 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=9BzBJv+0GArlNa5r18tN778JHMk1TICmVHHcAfyKBEM=; b=fpxzjbtRfbY0ePa+w8Wh2xXTUsT8uCHELhH2CFoE3jIX+qyfl16SCiopbGcwqJloN3gzS1 DIq2HNIDEcVO9eZE5i14d2DkEP1XgFWEarW2G5uNzD96JRkjHmCLh07bg7HtinETBFF6WU o/Z7zPHjb8bpUMhgANSZI+oobGKKED8= Date: Tue, 20 May 2025 12:50:56 -0700 Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next v3 1/2] bpf: Warn with bpf_unreachable() kfunc maybe due to uninitialized variable Content-Language: en-GB To: Alexei Starovoitov Cc: Kumar Kartikeya Dwivedi , bpf , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Kernel Team , Martin KaFai Lau References: <20250519203339.2060080-1-yonghong.song@linux.dev> <20250519203344.2060544-1-yonghong.song@linux.dev> <85503b11-ccce-412e-b031-cc9654d6291d@linux.dev> <1330496e-5dda-4b42-9524-4bfcfeb50ba7@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yonghong Song In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 5/20/25 2:46 AM, Alexei Starovoitov wrote: > On Tue, May 20, 2025 at 11:39 AM Alexei Starovoitov > wrote: >> So another idea... >> >> maybe we should remove special_kfunc_set instead? >> >> I recall we argued with Kumar years ago about it. >> I don't remember why we kept it >> and what purpose it serves now. >> >> What will break if we do: >> >> - if (meta.btf == btf_vmlinux && >> btf_id_set_contains(&special_kfunc_set, meta.func_id)) { >> + if (meta.btf == btf_vmlinux) { >> if (meta.func_id == >> special_kfunc_list[KF_bpf_obj_new_impl] || >> meta.func_id == >> special_kfunc_list[KF_bpf_percpu_obj_new_impl]) { >> struct btf_struct_meta *struct_meta; >> @@ -13838,10 +13838,6 @@ static int check_kfunc_call(struct >> bpf_verifier_env *env, struct bpf_insn *insn, >> * because packet slices are not refcounted (see >> * dynptr_type_refcounted) >> */ >> - } else { >> - verbose(env, "kernel function %s >> unhandled dynamic return type\n", >> - meta.func_name); >> - return -EFAULT; >> } >> >> ? > Found old Kumar's reply: > https://lore.kernel.org/bpf/20221120204625.ndtr7ygh7zgjxrsz@apollo/ > > and my old reply: > https://lore.kernel.org/bpf/20221120222922.udsuzkr5hcvjzot5@macbook-pro-5.dhcp.thefacebook.com/ > > I think we need to remove special_kfunc_set, > and then special_kfunc_list[] can stay as-is, > and we can keep adding new kfuncs to it like bpf_unreachable in this case. Okay, I will remove special_kfunc_set() then. Thanks!