From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F0803DEFEC for ; Thu, 23 Apr 2026 09:21:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776936080; cv=none; b=nhGknzUI2zTY3zOMWkAa6JDkAj+xzBfQPAqZW3s+MS+lHSlgNG8uqC7iDTti+fI7OWNKVxX2o+UJ4jM9GXxsC0jylihgPdw0qWGl5G/UREr2WvwVQ3+lbvDkd/qRGCsRVm4S2Og81dKWjACDdvjtNlKKNmkkq8hNxHaO/xNnqDA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776936080; c=relaxed/simple; bh=V4Mt7UTBRqduL+DbL4vVk9UpgpA9rLMOPyNCswxxBYE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ww+WyR0DYRDwLDzpKTdlXYJLGFQp089uuQ0OrpT3pX87vcR7GBV93h9v9odLYMcCATvylIaptSGp0iVurw65EcGLo2/A6FwWvJ6oW91AQpKL3PRZ8kd3n0FXrIM+c5wTVe5bhASJAyFxjVICjNndL1bFJ6PjKW/i2800Yhm7viU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=adOhVAXU; arc=none smtp.client-ip=209.85.216.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="adOhVAXU" Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-35d9f68d011so4281424a91.2 for ; Thu, 23 Apr 2026 02:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776936079; x=1777540879; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=SSYCYEdIs9iCX9srVmQAVlFmMGtaVdekW9Bp/Pgyh+U=; b=adOhVAXUiSRZ1Poe1G2VHV+i3nZsKCA+6PdegH4DcOOmL+KOIFfhk9iEU5JxTagFTp aFifmpN+KSFa9sOoAYYvucJ5PSq8HMgpFHFJJMe+ddlR9c1hY6yVAnZ28MY1GBu7eQ4S waDm1vZpNHLoL1pKKUSdMu/T7zuU3uw7FRrTMZLvYITUTR+06f/p/tmk0WRpRT6/jO+P 4LvJQe6cjEQ0tpZYmWf1W+e37C4KLNPl02zbUDov+6sU9bOGz0GQkEmI4Wh9yKv0AI59 5skyY2tFYjl6h6UKt6JYlER40VhCQ875oSGRB8Cmd617Rg0oXKQuxasVaKHX1iekFdFA q24Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776936079; x=1777540879; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SSYCYEdIs9iCX9srVmQAVlFmMGtaVdekW9Bp/Pgyh+U=; b=Hys53zP5Fu/KHbej5O0B4ZlD/7KHwCySkOnrYWckyXOLFb4CdTS09+d9IrXOx1ss7L EhsK4dhyCTB1zL0vGGr2+EKmSYPe0xn+AcLHybH0R5f3xkaSlPFphzRvRiI4m2eWiWWk T3u4+Crm8EbFt2rr7yXzfHgMTt0ZtfipvhLjufY3Gh8wDZ1TFtklvCxaxh2LwNAshGVX MNNT0RFXWElTvOwBt1UTBi80bzmINy1NvY/XMRT1rmLuP5YCYmebGQaPvteehJHmvR7a JRbHkz+iGPkuh6SRCNqkKvnDnzOwtlnVFVSXrtTWNJ3M7VCVm1UiAv5r5rEYOdW1vI6M cOMw== X-Forwarded-Encrypted: i=1; AFNElJ+YZV5FvAXJCShUaJFniYSGYMYnG4zyTq+EfM3mQYBObeK+2UZ2Nh8gMoY/dBRuLtlK/FmahOhOaupo2Ag=@vger.kernel.org X-Gm-Message-State: AOJu0YyEdRG8zu0Rgxg2FPkrcrne38Jnf6W+8HajzPwK3FMjz8mj2ufK AAhlxNqIS4cQyTo78971rFHsF3UylADAyZP2BkSjv/Ykxra6PvJmNetb X-Gm-Gg: AeBDiesZvZ3StKJI8uDlx9+36MNwEy1G59v6BY4LCaDQLzLpV855o3b+ZM6sGN7LdIT E7eOKFvIM1ub6h/bn77EoLHkHvEnXaySNwFBmwxyiJyj7WnCzsOt73sPchA3rGSiYIDFeHhnlxw +9BzBOb3ifJB8mOhHPr+JKn6gokSp8sSKSdVAH8tR7tjdIqPhLYe7iffKGdG61KdK1ZBB2J0B+O PrOBQdUN9/wFW+oetonvlRvQRNsjFaaoZ3FlypP5iIJSEghKfb1EvoqKypnQYmfwTRB9+TdpiWD y6/HWsTu7NTv/LoOixX8pJobFO2j06sAhSkLxcEhu+df8tVL9k4/kwU1UGUGXWm/2UqHYDG0rqF Bdopvl24aCeTNDCdqbcXaxOIw9+xkvEhr6t6QDI7dcWOM06ZPYwMW3V6DOXCCWPE+gG6at5lK+Y DDBVLTgBohRdIr/GM2Aok8r8aRwpZsmJX43SVsvcccbPPnD7x3q3io3Jhko92qGlbT8WFwbtFUP ucUHxw6W/mm2UmF51ga++gKZn0= X-Received: by 2002:a17:90b:3c8d:b0:35a:18b1:c245 with SMTP id 98e67ed59e1d1-361403bd142mr27188937a91.3.1776936078450; Thu, 23 Apr 2026 02:21:18 -0700 (PDT) Received: from cchengyang.duckdns.org (36-225-83-234.dynamic-ip.hinet.net. [36.225.83.234]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-361410a7cb5sm19663803a91.9.2026.04.23.02.21.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 02:21:18 -0700 (PDT) Date: Thu, 23 Apr 2026 17:21:14 +0800 From: Cheng-Yang Chou To: Zhao Mengmeng Cc: Tejun Heo , void@manifault.com, arighi@nvidia.com, changwoo@igalia.com, sched-ext@lists.linux.dev, emil@etsalapatis.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 12/16] sched_ext: Forbid cpu-form kfuncs from cid-form schedulers Message-ID: <20260423171156.G698a@cchengyang.duckdns.org> References: <20260421071945.3110084-1-tj@kernel.org> <20260421071945.3110084-13-tj@kernel.org> <177693500312.275653.17323765149266875001.b4-reply@b4> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <177693500312.275653.17323765149266875001.b4-reply@b4> Hi Zhao, On Thu, Apr 23, 2026 at 05:03:23PM +0800, Zhao Mengmeng wrote: > non_scx_kfunc_deny.bpf.c:17:6: error: conflicting types for 'scx_bpf_kick_cpu' > 17 | void scx_bpf_kick_cpu(s32 cpu, u64 flags) __ksym; > | ^ > /root/work/source-code/linux-next/tools/testing/selftests/sched_ext/build/include/vmlinux.h:136300:13: note: previous declaration is here > 136300 | extern void scx_bpf_kick_cpu(s32 cpu, u64 flags, const struct bpf_prog_aux *aux) __weak __ksym; > | ^ > non_scx_kfunc_deny.bpf.c:26:23: error: too few arguments to function call, expected 3, have 2 > 26 | scx_bpf_kick_cpu(0, 0); > | ~~~~~~~~~~~~~~~~ ^ > /root/work/source-code/linux-next/tools/testing/selftests/sched_ext/build/include/vmlinux.h:136300:13: note: 'scx_bpf_kick_cpu' declared here > 136300 | extern void scx_bpf_kick_cpu(s32 cpu, u64 flags, const struct bpf_prog_aux *aux) __weak __ksym; > > On the one hand, non_scx_kfunc_deny.bpf.c has it own problem, it should > not declare scx_bpf_kick_cpu(), on the other hand, the root cause is after If your point is that a TCP program shouldn't declare scx_bpf_kick_cpu(), you are correct. The main goal of non_scx_kfunc_deny is to ensure that, witch commit 2d2b026c3ea7, no non-SCX programs can use SCX func. > this commit, the signature of scx_bpf_kick_cpu() changes from > > `extern void scx_bpf_kick_cpu(s32 cpu, u64 flags) __weak __ksym;` to > `extern void scx_bpf_kick_cpu(s32 cpu, u64 flags, const struct bpf_prog_aux *aux) __weak __ksym` Regarding the non_scx_kfunc_deny.bpf.c build failure, I'll fix it. If needed, we can test with another SCX function that doesn't require the *aux parameter. Thanks. > > After code analysis and test, I believe scx_bpf_kick_cpu miss the > KF_IMPILCIT_ARGS, just like the defination in scx_kfunc_ids_any. > > So here misses KF_IMPLICIT_ARGS > > +BTF_ID_FLAGS(func, scx_bpf_task_cpu) > Missing KF_RCU. > > +BTF_ID_FLAGS(func, scx_bpf_cpu_rq) > Missing KF_IMPLICIT_ARGS > > +BTF_ID_FLAGS(func, scx_bpf_cpu_curr) > Missing KF_IMPLICIT_ARGS | KF_RET_NULL | KF_RCU_PROTECTED > > +BTF_ID_FLAGS(func, scx_bpf_cpu_node) > > +BTF_ID_FLAGS(func, scx_bpf_cpuperf_cap) > Missing KF_IMPLICIT_ARGS > > +BTF_ID_FLAGS(func, scx_bpf_cpuperf_cur) > Missing KF_IMPLICIT_ARGS > > +BTF_ID_FLAGS(func, scx_bpf_cpuperf_set) > Missing KF_IMPLICIT_ARGS > > +BTF_ID_FLAGS(func, scx_bpf_get_possible_cpumask) > Missing KF_ACQUIRE > > +BTF_ID_FLAGS(func, scx_bpf_get_online_cpumask) > Missing KF_ACQUIRE > > +BTF_ID_FLAGS(func, scx_bpf_put_cpumask) > Missing KF_RELEASE > > +BTF_ID_FLAGS(func, scx_bpf_select_cpu_dfl) > Missing KF_IMPLICIT_ARGS | KF_RCU > > +BTF_ID_FLAGS(func, __scx_bpf_select_cpu_and) > Missing KF_IMPLICIT_ARGS | KF_RCU > > +BTF_ID_FLAGS(func, scx_bpf_select_cpu_and) > Missing KF_RCU > > Please correct me if I miss something. > > +BTF_ID_FLAGS(func, scx_bpf_get_idle_cpumask) > > +BTF_ID_FLAGS(func, scx_bpf_get_idle_cpumask_node) > > +BTF_ID_FLAGS(func, scx_bpf_get_idle_smtmask) > > +BTF_ID_FLAGS(func, scx_bpf_get_idle_smtmask_node) > > +BTF_ID_FLAGS(func, scx_bpf_put_idle_cpumask) > > +BTF_ID_FLAGS(func, scx_bpf_test_and_clear_cpu_idle) > > +BTF_ID_FLAGS(func, scx_bpf_pick_idle_cpu) > > +BTF_ID_FLAGS(func, scx_bpf_pick_idle_cpu_node) > > +BTF_ID_FLAGS(func, scx_bpf_pick_any_cpu) > > +BTF_ID_FLAGS(func, scx_bpf_pick_any_cpu_node) > > +BTF_KFUNCS_END(scx_kfunc_ids_cpu_only) > > + > > /* > > * Per-op kfunc allow flags. Each bit corresponds to a context-sensitive kfunc > > * group; an op may permit zero or more groups, with the union expressed in > > @@ -10031,6 +10067,7 @@ int scx_kfunc_context_filter(const struct bpf_prog *prog, u32 kfunc_id) > > bool in_cpu_release = btf_id_set8_contains(&scx_kfunc_ids_cpu_release, kfunc_id); > > bool in_idle = btf_id_set8_contains(&scx_kfunc_ids_idle, kfunc_id); > > bool in_any = btf_id_set8_contains(&scx_kfunc_ids_any, kfunc_id); > > + bool in_cpu_only = btf_id_set8_contains(&scx_kfunc_ids_cpu_only, kfunc_id); > > u32 moff, flags; > > > > /* Not an SCX kfunc - allow. */ > > @@ -10068,6 +10105,15 @@ int scx_kfunc_context_filter(const struct bpf_prog *prog, u32 kfunc_id) > > prog->aux->st_ops != &bpf_sched_ext_ops_cid) > > return -EACCES; > > > > + /* > > + * cid-form schedulers must use cid/cmask kfuncs. cid and cpu are both > > + * small s32s and trivially confused, so cpu-only kfuncs are rejected at > > + * load time. The reverse (cpu-form calling cid-form kfuncs) is > > + * intentionally permissive to ease gradual cpumask -> cid migration. > > + */ > > + if (prog->aux->st_ops == &bpf_sched_ext_ops_cid && in_cpu_only) > > + return -EACCES; > > + > > /* SCX struct_ops: check the per-op allow list. */ > > if (in_any || in_idle) > > return 0; > > -- > > 2.53.0 > > > > > > > -- Cheers, Cheng-Yang