lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z6cSFmXvNkmI0qKv@slm.duckdns.org>
Date: Fri, 7 Feb 2025 22:13:10 -1000
From: Tejun Heo <tj@...nel.org>
To: Changwoo Min <changwoo@...lia.com>
Cc: void@...ifault.com, arighi@...dia.com, kernel-dev@...lia.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] sched_ext: Compatible testing of SCX_ENQ_CPU_SELECTED

On Sat, Feb 08, 2025 at 01:43:28PM +0900, Changwoo Min wrote:
> This patchset is for testing `SCX_ENQ_CPU_SELECTED` in a compatible way.
> More specifically, it handles two cases:
>   1. a BPF scheduler is compiled against vmlinux.h where
>   SCX_ENQ_CPU_SELECTED is defined, but it runs on a kernel that does not
>   have SCX_ENQ_CPU_SELECTED.
>   2. a BPF scheduler is compiling against vmlinux.h where
>   SCX_ENQ_CPU_SELECTED is not defined.
> 
> The patch consists of three parts:
>   1. Add enum_defs.autogen.h, which has macros denoting whether SCX
>   enums are defined in the vmlinux.h or not.
>   2. Implement __COMPAT_is_enq_cpu_selected(), which provide the test of
>   SCX_ENQ_CPU_SELECTED in a compatible way.
>   3. Use  __COMPAT_is_enq_cpu_selected() in scx_qmap.
> 
> Also, this patchset is a sync of the relevant PR [1] in the scx repo.
> 
> [1] https://github.com/sched-ext/scx/pull/1314
> 
> Changwoo Min (4):
>   sched_ext: Add enum_defs.autogen.h
>   sched_ext: Include enum_defs.autogen.h from common/common.bpf.h
>   sched_ext: Add __COMPAT_is_enq_cpu_selected() for BPF compatability
>   sched_ext: Use __COMPAT_is_enq_cpu_selected() in scx_qmap

Can you collapse the four patches into a single patch? I don't think this
needs to be split this granularly.

Thanks.

-- 
tejun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ