From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) (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 78FCC22AE65; Fri, 9 Jan 2026 21:56:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767995806; cv=none; b=YHWOp+PV7Tslb2FRUWv5GQojqLd+kX2/8qk22AyPpExAOl0SBnV6yieS3AAwc1RPdEG6QgicSflJlimtisWpzEwGSK9u6ie85zt2U01TIQwo2wWGXGUFF51Af2m28AnBFK6fVzvHU+Q8KBge25Kwbpc07edWjppqMN5dixozVCQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767995806; c=relaxed/simple; bh=6ZnbqF7/kXh5P0Ia9WUeE2BLIbZDXhE7dBGh2KAO1WQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lrWDsLemDM7AEcf3wW58/697j2bea+SnCLsrvOrzRrooR7zVu86h9SdQTlCP61L8+jLveAKzAJUpSlxCouFEgY348u5XnXV1jVaNrSEUByPFieef7sBiIsiYhwvANhkv85e3/NF/o6mfx9q+rGVkrfQHIz2zdJ+PGKWHBXbhFds= 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=BpXSOh+L; arc=none smtp.client-ip=95.215.58.188 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="BpXSOh+L" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1767995802; 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=nHltPQvu0bb8b9qFGSmvXZdn22+rgNKMValwGJobJKw=; b=BpXSOh+LAYUeeksBKEmd/uUTGZ1ZZmWzxY2lIc+BqkFPTMpELsMayzEqBJvKZBIcGGvH8r lJ0jVgMfSQAfUJnjASoBRjGN5Aj8Fwp2Kx+HSKs51Vbm00DBMITy1PRC7JO4HqbK7WSHhr KFh77kVnvy5wkA+22OZH0srsTooBe+c= Date: Fri, 9 Jan 2026 13:56:26 -0800 Precedence: bulk X-Mailing-List: linux-input@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 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 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ihor Solodrai In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 1/9/26 1:49 PM, Alexei Starovoitov wrote: > On Fri, Jan 9, 2026 at 1:39 PM Ihor Solodrai wrote: >> >> On 1/9/26 12:47 PM, Alexei Starovoitov wrote: >>> On Fri, Jan 9, 2026 at 12:02 PM Ihor Solodrai wrote: >>>> >>>> On 1/9/26 11:58 AM, Alexei Starovoitov wrote: >>>>> On Fri, Jan 9, 2026 at 10:50 AM Ihor Solodrai wrote: >>>>>> >>>>>> +__bpf_kfunc int bpf_task_work_schedule_signal(struct task_struct *task, struct bpf_task_work *tw, >>>>>> + void *map__map, bpf_task_work_callback_t callback, >>>>>> + struct bpf_prog_aux *aux) >>>>>> +{ >>>>>> + return bpf_task_work_schedule(task, tw, map__map, callback, aux, TWA_SIGNAL); >>>>>> +} >>>>>> + >>>>>> __bpf_kfunc int bpf_task_work_schedule_signal_impl(struct task_struct *task, >>>>>> struct bpf_task_work *tw, void *map__map, >>>>>> bpf_task_work_callback_t callback, >>>>>> void *aux__prog) >>>>>> { >>>>>> - return bpf_task_work_schedule(task, tw, map__map, callback, aux__prog, TWA_SIGNAL); >>>>>> + return bpf_task_work_schedule_signal(task, tw, map__map, callback, aux__prog); >>>>>> } >>>>> >>>>> I thought we decided that _impl() will not be marked as __bpf_kfunc >>>>> and will not be in BTF_ID(func, _impl). >>>>> We can mark it as __weak noinline and it will be in kallsyms. >>>>> That's all we need for the verifier and resolve_btfid, no? >>>>> >>>>> Sorry, it's been a long time. I must have forgotten something. >>>> >>>> For the *generated* _impl kfuncs there is no decl tags and the ids are >>>> absent from BTF_ID sets, yes. >>>> >>>> However for the "legacy" cases it must be there for backwards >>>> compatibility, as well as relevant verifier checks. >>> >>> I see. >>> 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. > > >> 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/ >> >>