From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (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 7EFB738737D for ; Mon, 12 Jan 2026 18:54:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768244053; cv=none; b=pxqth8bL5xDboHeDOdznGzLlIlkoCBe4DMkqDTeBGs8iLvkoS3tjVdvVx1ywsw6+Sygq1o5CdEEY8j9lAbp3F+1wI11DjZFamUUI85gPnwxbR5ar+Xcj48bd70Y6ZzJoiK6odeYKKoeWxgidut35mpZQsC/f9kHC1U70zCSycBA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768244053; c=relaxed/simple; bh=QqykXITTByyTT+FGlcEOND0SlMloNxcQl9qxBKW1MJ0=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=KfSvt+VyryUCNwwtJkaxTGj93soTk6uIWdjBrOcodlAX/6/hdEGteo9UOVjTgc6pR6q/WHoG5THOcnOApiRFINmTVtDvvCBIKKj1zgkq4uwkZampccFzkrfUYWVvakRR5n2OhJC5SeiNHn7Sl66ja0n7P5VjqevNlTJzG4gQ8Ws= 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=Bw3Ys4yY; arc=none smtp.client-ip=91.218.175.172 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="Bw3Ys4yY" Message-ID: <3a697699-ffcb-4e2f-a7a4-9e3f571aa402@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1768244039; 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=/9vtTJ8E+WsBFblmJc5UE1EN6AZB8Sa5imYu+eocYP4=; b=Bw3Ys4yYFJsGcrFo94H7o4SnkRA4tr8AFowTqSo0kSbLHRH2fm7D/evq7AdA/S2U9Y/TG4 T62PnUk+mExAbwv2FPR7pjVaQJCHzjjl8B+lHaA2tGuvkeRlpe6l9qLum4aAB576+c6rnd mWcYkqF0IzDnkAW7JNrPExrWO7RglpU= Date: Mon, 12 Jan 2026 10:53:53 -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 08/10] bpf: Add bpf_task_work_schedule_* kfuncs with KF_IMPLICIT_ARGS X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ihor Solodrai To: Alexei Starovoitov Cc: Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Eduard Zingerman , Mykyta Yatsenko , Tejun Heo , Alan Maguire , Benjamin Tissoires , Jiri Kosina , bpf , LKML , "open list:HID CORE LAYER" , sched-ext@lists.linux.dev References: <20260109184852.1089786-1-ihor.solodrai@linux.dev> <20260109184852.1089786-9-ihor.solodrai@linux.dev> <0c4d84ab-1725-45bc-9c1c-8bdc1f5fc032@linux.dev> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 1/9/26 1:56 PM, Ihor Solodrai wrote: > On 1/9/26 1:49 PM, Alexei Starovoitov wrote: >> On Fri, Jan 9, 2026 at 1:39 PM Ihor Solodrai wrote: >>> >>> [...] >>> >>>> I feel bpf_task_work_schedule_resume() is ok to break, since it's so new. >>>> We can remove bpf_task_work_schedule_[resume|singal]_impl() >>>> to avoid carrying forward forever. >>>> >>>> bpf_stream_vprintk_impl() is not that clear. I would remove it too. >>> >>> That leaves only bpf_wq_set_callback_impl(). Can we break that too? >> >> Sounds like Benjamin is ok removing it. >> So I think we can indeed remove them all. >> >>> Then there won't be legacy cases at all. It was introduced in v6.16 >>> along the with __prog suffix [1][2]. >>> >>> If we go this route, we could clean up __prog support/docs too. >>> >>> I think it's worth it to make an "all or nothing" decision here: >>> either break all 4 existing kfuncs, or backwards-support all of them. >> >> I don't see why "all or nothing" is a good thing. >> It won't be "all" anyway. >> We have bpf_rbtree_add_impl(), bpf_list_push_front_impl(), etc. >> And those we cannot remove. sched-ext is using them. >> Another few categories are bpf_obj_new_impl(), bpf_obj_drop_impl(). >> There are not __prog type, but conceptually the same thing and >> KF_IMPLICIT_ARGS should support them too eventually. > > I was thinking we could remove/simplify code relevant to backwards > compat of existing _impl kfuncs. But you're right, if we start using > implicit args for other types/kfuncs, the "legacy" case still has to > work. > > Ok, in the next revision I'll remove all the __prog users, but leave > the "legacy" case support in place for future use. I just had an off-list chat with Andrii, and we agreed that leaving the existing _impl kfuncs supported may be a good idea. It doesn't cost us much: we keep the mechanism for legacy functions anyways, so supporting bpf_wq_set_callback_impl() and co only requires keeping definitions in the kernel. The only benefit of *removing* these _impl functions is that we could clean up __prog support. But having backwards compat seems like a better deal. What do you think? > >> >> >>> git tag --contains bc049387b41f | grep -v rc >>> v6.16 >>> v6.17 >>> v6.18 >>> >>> [1] https://lore.kernel.org/all/20250513142812.1021591-1-memxor@gmail.com/ >>> [2] https://lore.kernel.org/all/20240420-bpf_wq-v2-13-6c986a5a741f@kernel.org/ >>> >>> >