sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

LinuxKPI: tasklet add (*callback) support

In addition to (*func) tasklet also seems to have a (*callback) with
a different argument. Add support for this and add tasklet_setup()
as well for support

LinuxKPI: tasklet add (*callback) support

In addition to (*func) tasklet also seems to have a (*callback) with
a different argument. Add support for this and add tasklet_setup()
as well for support in more drivers.

The from_tasklet() definition is duplicated in the tree; hide it there
under #ifndef to avoid a re-definition. People should generally add
LinuxKPI bits to linuxkpi rather than private files if they also rely
on other LinuxKPI bits.

X-MFC: DO NOT MFC, space allocated by drivers not us.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D37216

show more ...

Make sure all tasklets are drained before unloading the LinuxKPI.
Else use-after-free may happen.

MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking

linuxkpi: Introduce tasklet_disable_nosync()

This is needed for the drm-kmod 5.5 update.

Reviewed by: hselasky (src)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D30024

MFHead @348740

Sponsored by: The FreeBSD Foundation

LinuxKPI: Fix build on powerpc/sparc.

Use cmpset instead of testandset in tasklet lock code.

Reviewed by: hps
Approved by: imp (mentor), hps
Obtained from: hps
MFC after: 1 week

LinuxKPI: Updates to tasklets for Linux 5.0.

DRM drivers expect tasklets to have a counter for enable/disable calls.
Also, add a few more tasklet locking functions.

This patch is part of D19565

Re

LinuxKPI: Updates to tasklets for Linux 5.0.

DRM drivers expect tasklets to have a counter for enable/disable calls.
Also, add a few more tasklet locking functions.

This patch is part of D19565

Reviewed by: hps
Approved by: imp (mentor), hps
MFC after: 1 week

show more ...

Merge ^/head r343956 through r344177.

Make taskqgroup_attach{,_cpu}(9) work across architectures

So far, intr_{g,s}etaffinity(9) take a single int for identifying
a device interrupt. This approach doesn't work on all architectures
suppo

Make taskqgroup_attach{,_cpu}(9) work across architectures

So far, intr_{g,s}etaffinity(9) take a single int for identifying
a device interrupt. This approach doesn't work on all architectures
supported, as a single int isn't sufficient to globally specify a
device interrupt. In particular, with multiple interrupt controllers
in one system as found on e. g. arm and arm64 machines, an interrupt
number as returned by rman_get_start(9) may be only unique relative
to the bus and, thus, interrupt controller, a certain device hangs
off from.
In turn, this makes taskqgroup_attach{,_cpu}(9) and - internal to
the gtaskqueue implementation - taskqgroup_attach_deferred{,_cpu}()
not work across architectures. Yet in turn, iflib(4) as gtaskqueue
consumer so far doesn't fit architectures where interrupt numbers
aren't globally unique.
However, at least for intr_setaffinity(..., CPU_WHICH_IRQ, ...) as
employed by the gtaskqueue implementation to bind an interrupt to a
particular CPU, using bus_bind_intr(9) instead is equivalent from
a functional point of view, with bus_bind_intr(9) taking the device
and interrupt resource arguments required for uniquely specifying a
device interrupt.
Thus, change the gtaskqueue implementation to employ bus_bind_intr(9)
instead and intr_{g,s}etaffinity(9) to take the device and interrupt
resource arguments required respectively. This change also moves
struct grouptask from <sys/_task.h> to <sys/gtaskqueue.h> and wraps
struct gtask along with the gtask_fn_t typedef into #ifdef _KERNEL
as userland likes to include <sys/_task.h> or indirectly drags it
in - for better or worse also with _KERNEL defined -, which with
device_t and struct resource dependencies otherwise is no longer
as easily possible now.
The userland inclusion problem probably can be improved a bit by
introducing a _WANT_TASK (as well as a _WANT_MOUNT) akin to the
existing _WANT_PRISON etc., which is orthogonal to this change,
though, and likely needs an exp-run.

While at it:
- Change the gt_cpu member in the grouptask structure to be of type
int as used elswhere for specifying CPUs (an int16_t may be too
narrow sooner or later),
- move the gtaskqueue_enqueue_fn typedef from <sys/gtaskqueue.h> to
the gtaskqueue implementation as it's only used and needed there,
- change the GTASK_INIT macro to use "gtask" rather than "task" as
argument given that it actually operates on a struct gtask rather
than a struct task, and
- let subr_gtaskqueue.c consistently use __func__ to print functions
names.

Reported by: mmel
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D19139

show more ...

Create a new macro for static DPCPU data.

On arm64 (and possible other architectures) we are unable to use static
DPCPU data in kernel modules. This is because the compiler will generate
PC-relative

Create a new macro for static DPCPU data.

On arm64 (and possible other architectures) we are unable to use static
DPCPU data in kernel modules. This is because the compiler will generate
PC-relative accesses, however the runtime-linker expects to be able to
relocate these.

In preparation to fix this create two macros depending on if the data is
global or static.

Reviewed by: bz, emaste, markj
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D16140

show more ...

Implement tasklet_enable() and tasklet_disable() in the LinuxKPI.

MFC after: 1 week
Requested by: Johannes Lundberg <johalun0@gmail.com>
Sponsored by: Mellanox Technologies

Merge ^/head r323559 through r325504.

MFhead@r320180

The LinuxKPI atomics do not have acquire nor release semantics unless
specified. Fix code to use READ_ONCE() and WRITE_ONCE() where appropriate.

Suggested by: kib @
MFC after: 1 week
Sponsored by:

The LinuxKPI atomics do not have acquire nor release semantics unless
specified. Fix code to use READ_ONCE() and WRITE_ONCE() where appropriate.

Suggested by: kib @
MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...

Merge ^/head r322398 through r322746.

MFhead@r322675

Move some other SI_SUB_INIT_IF initializations to SI_SUB_TASKQ

Drop the EARLY_AP_STARTUP gtaskqueue code, as gtaskqueues are now
initialized before APs are started.

Reviewed by: hselasky@, jhb@
Spo

Move some other SI_SUB_INIT_IF initializations to SI_SUB_TASKQ

Drop the EARLY_AP_STARTUP gtaskqueue code, as gtaskqueues are now
initialized before APs are started.

Reviewed by: hselasky@, jhb@
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12054

show more ...

Use grouptaskqueue for tasklets in the LinuxKPI.

This avoids creating own per-CPU threads and also ensures the tasklet
execution happens on the same CPU core invoking the tasklet.

MFC after: 1 wee

Use grouptaskqueue for tasklets in the LinuxKPI.

This avoids creating own per-CPU threads and also ensures the tasklet
execution happens on the same CPU core invoking the tasklet.

MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...

Merge ^/head r313896 through r314128.

Add support for LinuxKPI tasklets.

Tasklets are implemented using a taskqueue and a small statemachine on
top. The additional statemachine is required to ensure all LinuxKPI
tasklets get serialized.

Add support for LinuxKPI tasklets.

Tasklets are implemented using a taskqueue and a small statemachine on
top. The additional statemachine is required to ensure all LinuxKPI
tasklets get serialized. FreeBSD taskqueues do not guarantee
serialisation of its tasks, except when there is only one worker
thread configured.

MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...