History log of /freebsd/lib/libc/gen/sched_setaffinity.c (Results 1 – 9 of 9)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/14.0.0, release/13.2.0
# cbc32e4c 15-Feb-2023 Dmitry Chagin <dchagin@FreeBSD.org>

cpuset: Add compat shim to the sched_affinity functions

To allow to run a newer world on a pre-1400079 kernel a compat shims to
the sched_affinity functions has beed added.

Reported by: antoine
Te

cpuset: Add compat shim to the sched_affinity functions

To allow to run a newer world on a pre-1400079 kernel a compat shims to
the sched_affinity functions has beed added.

Reported by: antoine
Tested by: antoine
Reviewed by: kib
Differential revision: https://reviews.freebsd.org/D38555
MFC after: 3 days

show more ...


# c21b080f 29-Jan-2023 Dmitry Chagin <dchagin@FreeBSD.org>

cpuset: Fix sched_[g|s]etaffinity() for better compatibility with Linux.

Under Linux to sched_[g|s]etaffinity() functions the value returned from a call
to gettid(2) (thread id) can be passed in the

cpuset: Fix sched_[g|s]etaffinity() for better compatibility with Linux.

Under Linux to sched_[g|s]etaffinity() functions the value returned from a call
to gettid(2) (thread id) can be passed in the argument pid. Specifying pid as 0
will set the attribute for the calling thread, and passing the value returned
from a call to getpid(2) (process id) will set the attribute for the main thread
of the thread group.

Native cpuset(2) family of system calls has "which" argument to determine how
the value of id argument is interpreted, i.e., CPU_WHICH_TID is used to pass
a thread id and CPU_WHICH_PID - to pass a process id.

For now native sched_[g|s]etaffinity() implementation is wrong as uses "which"
CPU_WHICH_PID to pass both (process and thread id) to the kernel. To fix this
adding a new "which" CPU_WHICH_TIDPID intended to handle both id's.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D38209
MFC after: 1 week

show more ...


Revision tags: release/12.4.0, release/13.1.0
# f35093f8 11-May-2022 Dmitry Chagin <dchagin@FreeBSD.org>

Use Linux semantics for the thread affinity syscalls.

Linux has more tolerant checks of the user supplied cpuset_t's.

Minimum cpuset_t size that the Linux kernel permits in case of
getaffinity() is

Use Linux semantics for the thread affinity syscalls.

Linux has more tolerant checks of the user supplied cpuset_t's.

Minimum cpuset_t size that the Linux kernel permits in case of
getaffinity() is the maximum CPU id, present in the system / NBBY,
the maximum size is not limited.
For setaffinity(), Linux does not limit the size of the user-provided
cpuset_t, internally using only the meaningful part of the set, where
the upper bound is the maximum CPU id, present in the system, no larger
than the size of the kernel cpuset_t.
Unlike FreeBSD, Linux ignores high bits if set in the setaffinity(),
so clear it in the sched_setaffinity() and Linuxulator itself.

Reviewed by: Pau Amma (man pages)
In collaboration with: jhb
Differential revision: https://reviews.freebsd.org/D34849
MFC after: 2 weeks

show more ...


# 67fc9502 25-Apr-2022 Konstantin Belousov <kib@FreeBSD.org>

sched_getaffinity(3): more compatibility with Linux

Report EINVAL instead of EDEADLK when impossible cpu mask is set.

Noted by: dchagin
Reviewed by: dchagin (previous version), markj
Sponsored by:

sched_getaffinity(3): more compatibility with Linux

Report EINVAL instead of EDEADLK when impossible cpu mask is set.

Noted by: dchagin
Reviewed by: dchagin (previous version), markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D35045

show more ...


# d9cacbf4 02-Jan-2022 Konstantin Belousov <kib@FreeBSD.org>

sched_get/setaffinity(): try to be more compatible with Linux

in handling the cpuset sizes different from sizeof(cpuset_t).

For both cases, cpuset size shorter than sizeof(cpuset_t) results
in EINV

sched_get/setaffinity(): try to be more compatible with Linux

in handling the cpuset sizes different from sizeof(cpuset_t).

For both cases, cpuset size shorter than sizeof(cpuset_t) results
in EINVAL on Linux.

For sched_getaffinity(), be more permissive and accept cpuset size
larger than our cpuset_t, by clipping the syscall argument and zeroing
the rest of the output buffer. For sched_setaffinity(), we should allow
shorter cpusets than current ABI size, again zeroing the rest of the bits.

With this change, python os.sched_get/setaffinity functions work.

Reported by: se
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

show more ...


# e2650af1 30-Dec-2021 Stefan Eßer <se@FreeBSD.org>

Make CPU_SET macros compliant with other implementations

The introduction of <sched.h> improved compatibility with some 3rd
party software, but caused the configure scripts of some ports to
assume t

Make CPU_SET macros compliant with other implementations

The introduction of <sched.h> improved compatibility with some 3rd
party software, but caused the configure scripts of some ports to
assume that they were run in a GLIBC compatible environment.

Parts of sched.h were made conditional on -D_WITH_CPU_SET_T being
added to ports, but there still were compatibility issues due to
invalid assumptions made in autoconfigure scripts.

The differences between the FreeBSD version of macros like CPU_AND,
CPU_OR, etc. and the GLIBC versions was in the number of arguments:
FreeBSD used a 2-address scheme (one source argument is also used as
the destination of the operation), while GLIBC uses a 3-adderess
scheme (2 source operands and a separately passed destination).

The GLIBC scheme provides a super-set of the functionality of the
FreeBSD macros, since it does not prevent passing the same variable
as source and destination arguments. In code that wanted to preserve
both source arguments, the FreeBSD macros required a temporary copy of
one of the source arguments.

This patch set allows to unconditionally provide functions and macros
expected by 3rd party software written for GLIBC based systems, but
breaks builds of externally maintained sources that use any of the
following macros: CPU_AND, CPU_ANDNOT, CPU_OR, CPU_XOR.

One contributed driver (contrib/ofed/libmlx5) has been patched to
support both the old and the new CPU_OR signatures. If this commit
is merged to -STABLE, the version test will have to be extended to
cover more ranges.

Ports that have added -D_WITH_CPU_SET_T to build on -CURRENT do
no longer require that option.

The FreeBSD version has been bumped to 1400046 to reflect this
incompatible change.

Reviewed by: kib
MFC after: 2 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D33451

show more ...


# caacda7a 17-Dec-2021 Math Ieu <sigsys@gmail.com>

sched_get/setaffinity(3): pid 0 should designate current process

while FreeBSD' native sched_get/setaffinity use pid -1 for this.

PR: 260487
MFC after: 1 week


Revision tags: release/12.3.0
# 90fa9705 11-Nov-2021 Konstantin Belousov <kib@FreeBSD.org>

sched.h: Hide all Linux compat sched_* functions under _WITH_CPU_SET_T

Instead of only hiding cpu_set_t compat typedef itself.

Too many software packages assume that sched_getaffinity() presence
im

sched.h: Hide all Linux compat sched_* functions under _WITH_CPU_SET_T

Instead of only hiding cpu_set_t compat typedef itself.

Too many software packages assume that sched_getaffinity() presence
implies full source compatibility with glibc. We can (and should)
handle missing CPU_* macros, but then there are incompatible BIT_* uses
which cannot be fixed in src/.

So hide everything under _WITH_CPU_SET_T, in particular, do not expose
sched_getcpu(), sched_get/setaffinity(), as well as CPU_* and BIT_*
macros. Consumers that want sched* functions must opt-in.

Reported by: portmgr (antoine)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

show more ...


# 43736b71 22-Oct-2021 Konstantin Belousov <kib@FreeBSD.org>

Add sched_get/setaffinity(3)

for compatibility with Linux.

Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32901