| Age | Commit message (Collapse) | Author |
|---|
|
in the device tree.
From Paul Fertser.
|
|
AMD 600 Series AHCI set interrupt bits during sd(4) attaching while
using polling mode. Thus, we have to clear them, before enable
interrupt handling. Also the AHCI 1.3.1 saids to do this.
tested by tobhe@
ok tobhe@, jmatthew@
|
|
If ip_deliver() changes the af, e.g. for ip6 over ip4, then it
cannot rely on the caller ip_ours() to enqueue the packet in the
correct queue. ip_deliver() has to do the enqueue depending on the
changed af.
from markus@
|
|
The current behavior of "auto", which implies running at full speed when
on AC power, does not fit all the hardware and use cases. For some people
it results in more power consumption, more heat, more noise, etc.
Extend the semantics of hw.perfpolicy and provide two buttons to
specify the desired behavior:
sysctl hw.perfpolicy=<policy while on ac>[,<policy while on battery>]
Keep the default behavior of "high,auto". People can opt for "auto,auto"
or simply "auto" instead.
No objection from deraadt@, input and ok sobrado@ sthen@
|
|
context (when it calls uvm_pagerealloc_multi()). But the current
implementation of pmap_copy_page() assumes it only runs in process context.
Use splbio() to block the interrupts while we're doing the copy.
Same diff as the one committed to arm64 a bit over a week ago.
ok mpi@, jca@
|
|
The driver for the AMD platform security processor did use a bunch
of EINVAL error codes. It is better to propagate the error up from
the subsystem or use more specific values. Rename the variable
"ret" to "error" to make clear where we deal with an actual errno(2).
Document where and why the error code is ignored.
OK hshoexer@
|
|
OK mpi@
|
|
reported by and fix tested by afresh@
|
|
ifq_deq_set_oactive is a variation on ifq_set_oactive that can be
called inside an if_deq_begin "transaction".
afresh@ found de(4) was calling ifq_set_oactive while holding the
ifq mutex via ifq_deq_begin, which led to a panic because ifq_set_oactive
also tries to take the ifq mutex. ifq_deq_set_oactive assumes the
caller is already holding the mutex.
de(4) is confusing, so it seemed simpler to add a small tweak to
ifqs than try and do major surgery on such a hairy driver.
tested by afresh@
|
|
this replaces a hand rolled list that's been here since 1.1.
ok claudio@ kn@ tb@
|
|
|
|
|
|
unneeded after uvm_vnp_sync() prototype moved to vnode.h in 2014
|
|
With input on prefix handling and ok jsg@
|
|
dlg concurs
|
|
after the last rewrite i was showing bpf ip packets, not the pfsync
payload like the PFSYNC DLT expected.
this also lets bpf see packets being processed by pfsync input
handling, so if you want to see only what's being sent you'll need
to filter by direction.
reported by Marc Boisis
|
|
The return value of atomic_load_int(9) is unsigned so needs a cast,
otherwise securelevel=-1 gets misrepresented.
From Paul Fertser.
|
|
|
|
Also fix some trailing whitespace in comments.
From Christian Schulte, thanks
|
|
From Philip Yang
4c332037fcbb9bb53c46ba4f156951429acc4d97 in linux-6.6.y/6.6.62
68d26c10ef503175df3142db6fcd75dd94860592 in mainline linux
|
|
there's no reason to limit tun/tap to small packets.
ok claudio@
|
|
|
|
ok patrick@
|
|
when bpfsdetach is called by an interface being destroyed, it
iterates over the bpf descriptors using the interface and calls
vdevgone and klist_invalidate against them. however, i'm not sure
the reference the interface holds against the bpf_d is accounted
for properly, so vdevgone might drop it to 0 and free it, which
makes the klist_invalidate a use after free.
avoid this by taking a bpf_d ref before calling vdevgone and
klist_invalidate so the memory can't be freed out from under the
feet of bpfsdetach.
Reported-by: syzbot+b3927f8ad162452a2f39@syzkaller.appspotmail.com
i wasn't able to reproduce whatever syzkaller did. it's possible
this is a double free, but we'll wait and see if it pops up again.
ok mpi@
|
|
userland can request that network packets that are read from or
written to the device special file get prepended with a "tun_hdr"
struct. this struct contains bits which say what offloads are
requested for the packet, including things like ip/tcp/udp/icmp
checksums, tcp segmentation offloads, or ethernet vlan tags.
userland can write a packet with any of these offloads requested
into the kernel at any time, but has to request which ones it's
able to handle coming from the kernel. enabling the tun_hdr struct
and which offloads userland can handle is done with a new TUNSCAP
ioctl.
this is based on the virtio_net_hdr in linux, which jan@ actually
implemented and had working with vmd. however, claudio@ and i
strongly opposed to what feels like a layer violation by pulling
virtio structures into the tun driver, and then trying to emulate
virtio/linux semantics in our network stack, and playing catch up
when the "upstream" projects decide to change the shape or meaning
of these bits. tun_hdr is specific to the openbsd network stack and
it's semantics, which simplifies our kernel implementation. jan has
been pretty gracious about the extra work on the vmd side of things.
tested by and ok jan@
ok claudio@
sthen@ backed this out cos of confusion with the ioctl numbers i
picked to controlling this feature. i've picked new numbers that
don't conflict this time.
|
|
controller. It is used as doorbell for the arm-scmi perf protocol and
a prerequisite for cpu frequency management on X Elite chips.
ok patrick@
|
|
If any other signal is pending the stop signal should be deferred.
Now cursig() uses ffs() to select the signal and so higher numbered
signals like SIGUSR1 would be ignored when going to sleep.
So handle default stop signals specially in the deep case, stash them
and only use them if no other signal is pending.
Fix for signal-stress regress (problem reported by anton@)
With and OK mpi@
|
|
setsigctx() now does this check and clears sig_stop in that case and
instead set sig_ignore. So the check in cursig that is based on sig_stop
can never be true.
OK mpi@
|
|
Prevent a race where anything can happen on `pve' resultint in an incorrect
locking of a given pmap. Found the hardway by sthen@.
ok jsg@, miod@, kettenis@, jca@
|
|
This codes runs under IPL_NET. Interrupt processing would get delayed
until the ioctl handler was done which is probably not what the device
is expecting.
|
|
|
|
|
|
dlg@ advised me that our drivers should always configure the largest
frame size supported by hardware
|
|
|
|
|
|
|
|
From Antonio Quartulli
a613a392417532ca5aaf3deac6e3277aa7aaef2b in linux-6.6.y/6.6.61
a6dd15981c03f2cdc9a351a278f09b5479d53d2e in mainline linux
|
|
From Lijo Lazar
3930715c1aefe8e5cbca94144081aa08b466d571 in linux-6.6.y/6.6.61
3ce3f85787352fa48fc02ef6cbd7a5e5aba93347 in mainline linux
|
|
From Alex Deucher
e2574b57990d482cb4310f8d571e728741c711c8 in linux-6.6.y/6.6.61
b46dadf7e3cfe26d0b109c9c3d81b278d6c75361 in mainline linux
|
|
From Alex Deucher
8906728f2fbd6504cb488f4afdd66af28f330a7a in linux-6.6.y/6.6.61
4d75b9468021c73108b4439794d69e892b1d24e3 in mainline linux
|
|
From Alex Deucher
5a8ae5fa576c3315c0b3ce0b0aec2e5d1aadebc9 in linux-6.6.y/6.6.61
f790a2c494c4ef587eeeb9fca20124de76a1646f in mainline linux
|
|
ok kettenis@
|
|
tb@ agrees
|
|
|
|
|
|
|
|
ok stsp@
|
|
userland can request that network packets that are read from or
written to the device special file get prepended with a "tun_hdr"
struct. this struct contains bits which say what offloads are
requested for the packet, including things like ip/tcp/udp/icmp
checksums, tcp segmentation offloads, or ethernet vlan tags.
userland can write a packet with any of these offloads requested
into the kernel at any time, but has to request which ones it's
able to handle coming from the kernel. enabling the tun_hdr struct
and which offloads userland can handle is done with a new TUNSCAP
ioctl.
this is based on the virtio_net_hdr in linux, which jan@ actually
implemented and had working with vmd. however, claudio@ and i
strongly opposed to what feels like a layer violation by pulling
virtio structures into the tun driver, and then trying to emulate
virtio/linux semantics in our network stack, and playing catch up
when the "upstream" projects decide to change the shape or meaning
of these bits. tun_hdr is specific to the openbsd network stack and
it's semantics, which simplifies our kernel implementation. jan has
been pretty gracious about the extra work on the vmd side of things.
tested by and ok jan@
ok claudio@
|
|
|
|
ok stu deraadt
|
