Age | Commit message (Collapse) | Author |
|
Note that ip_ours() runs with shared netlock, while ip_local() has
exclusive netlock after queuing. Move existing the code into
function ip_fragcheck() and call it from ip_ours().
OK mvs@
|
|
is reflected in more recent device trees. Adjust the driver accordingly.
ok patrick@
|
|
A single "out of order" line is too generic.
OK kettenis
|
|
netlock anymore.
ok bluhm@ yasuoka@
|
|
We don't use "static" keyword for functions declaration to allow ddb(4)
debug. Also, many "Static" functions are called by pppx(4) layer outside
pipex(4) layer.
This is the mostly mechanic diff, except the `pipex_pppoe_padding' which
should be "static const".
ok bluhm@ yasuoka@
|
|
smr_tqh_last is not intended for lockless use with SMR_PTR_GET().
|
|
Let's try this again now that the kernel locking issue in nfsrv_rcv()
has been fixed.
The previous attempt of the conversion triggered hangs on NFS servers.
This was probably caused by the removal of the kernel-locked section
just prior to the socket upcall. The section had masked a locking error
in NFS code.
|
|
shared net lock. ip_deliver() needs exclusive net lock. Instead
of calling ip_deliver() directly, use ip6_ours() to queue the packet.
Move the write lock assertion into ip_deliver() to catch such bugs
earlier.
The assertion was only triggered with IPv6 multicast forwarding or
router alert hop by hop option. Found by regress test.
OK kn@ mvs@
|
|
|
|
The AR9280 half Mini Card (HB92) supports 5GHz as confirmed by athn(4)'s
"The AR9220, AR9223 and AR9280 (codenamed Merlin) ..." paragraph.
pcidevs however wrongly identifies this device as
athn0 at pci2 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 17
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:30:37:de
athn(4) says AR9281 is 2GHz only, so the first line (pcidevs string) does
not match the real information on the second line (from real hardware).
Looking around, the PCI Vendor ID: 168c, Product ID: 002a are described as
* https://pcilookup.com/?ven=168c&dev=002a&action=submit
"AR928X Wireless Network Adapter (PCI-Express)"
* https://pci-ids.ucw.cz/read/PC/168c/002a calls this
"AR928X Wireless Network Adapter (PCI-Express)"
* https://github.com/torvalds/linux/blob/fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4/Documentation/devicetree/bindings/net/wireless/qca%2Cath9k.yaml#L27
says
- pci168c,002a # AR9280 and AR9283
* https://pcisig.com/membership/member-companies?combine=168c
(empty, no result)
* NetBSD pcidevs is like ours
product ATHEROS AR9281 0x002a AR9281
Im summary, "AR928X" seems more appropiate and matches both AR9280 and
AR9281 chipsets, so use that to avoid contradicting dmesg lines:
athn0 at pci2 dev 0 function 0 "Atheros AR928X" rev 0x01: apic 2 int 17
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:30:37:de
stsp confirms how "Atheros naming is very convoluted."
Feedback sthen
OK stsp
|
|
Found the hard way by mlarkin@ and deraadt@.
|
|
On PowerPC, by design, you cannot mask decrementer (DEC) interrupts
without also masking other interrupts that we want to leave unmasked
at or above IPL_CLOCK. So, currently, the DEC is left unmasked, even
when we're working at IPL_CLOCK or IPL_HIGH. If a DEC interrupt
arrives while we're at those priority levels, the current solution is
to postpone any clock interrupt work until the next hardclock(9) or
statclock tick.
This is a problem for a machine-independent clock interrupt subsystem
because the MD code, e.g. decr_intr(), ideally shouldn't need to know
anything about when the next event is scheduled to occur.
The most obvious solution to this problem that I can think of is to
instead postpone clock interrupt work until the next time our priority
level drops below IPL_CLOCK. This is something we can do from the MD
code without any knowledge of when the next clock interrupt event is
scheduled to occur.
So:
- Add a new boolean, ci_dec_deferred, to the PowerPC cpu_info struct.
- If we reach decr_intr() when the CPU's priority level is too high,
set ci_dec_deferred, clear the DEC exception, and return.
- If we reach decr_intr() and the CPU's priority level is low enough,
clear ci_dec_deferred and do any needed clock interrupt work.
- In splx(9) (there are three different versions we need to update),
check ci_dec_deferred. If it's set and our priority level is
dropping below IPL_CLOCK, raise a DEC exception.
Tested by me on PowerMac7,3 (openpic). Tested by miod@ on PowerMac1,1
(macintr) (`make build` completes). Tested by gkoehler@ on an unknown
PowerMac (probably openpic).
With lots of help from kettenis@.
ok gkoehler@ miod@
|
|
The timecounting subsystem computes elapsed time by scaling (64 bits)
the difference between two counter values (32 bits at most) up into a
struct bintime (128 bits).
Under normal circumstances it is sufficient to do this with 64-bit
multiplication, like this:
struct bintime bt;
bt.sec = 0;
bt.frac = th->tc_scale * tc_delta(th);
However, if tc_delta() exceeds 1 second's worth of counter ticks, that
multiplication overflows. The result is that the monotonic clock appears
to jump backwards.
When can this happen? In practice, I have seen it when trying to
compile LLVM on an EdgeRouter Lite when using an SD card as the
backing disk. The box gets stuck in swap, the hardclock(9) is
delayed, and we appear to "lose time".
To avoid this overflow we need to compute the full 96-bit product of
the delta and the scale.
This commit adds TIMECOUNT_TO_BINTIME(), a function for computing that
full product, to sys/time.h. The patch puts the new function to use
in lib/libc/sys/microtime.c and sys/kern/kern_tc.c.
(The commit also reorganizes some of our high resolution bintime code
so that we always read the timecounter first.)
Doing the full 96-bit multiplication is between 0% and 15% slower than
doing the cheaper 64-bit multiplication on amd64. Measuring a precise
difference is extremely difficult because the computation is already
quite fast.
I would guess that the cost is slightly higher than that on 32-bit
platforms. Nobody ever volunteered to test, so this remains a guess.
Thread: https://marc.info/?l=openbsd-tech&m=163424607918042&w=2
6 month bump: https://marc.info/?l=openbsd-tech&m=165124251401342&w=2
Committed after 9 months without review.
|
|
Apparently, we used to created several kthreads before the kernel
random number generator was up and running. A toggle, "randompid",
was needed to tell allocpid() whether it made sense to attempt to
allocate random PIDs.
However, these days we get e.g. arc4random(9) into a working state
before any kthreads are spawned, so the toggle is no longer needed.
Thread: https://marc.info/?l=openbsd-tech&m=165541052614453&w=2
Very nice historical context provided by miod@.
probably ok miod@ deraadt@
|
|
prevent cursor jumps when using the trackpoint on some lenovo laptops.
Known affected models:
- Lenovo Thinkpad X13 Gen1
- Lenovo Thinkpad T14(s)
- Lenovo Thinkpad E15 Gen3
- Lenovo A475
With help from stsp@
OK stsp@ miod@ deraadt@ bru@
|
|
Only used once, so use the macro directly like ND6_SLOWTIMER_INTERVAL
is used in many places.
OK florian
|
|
OK bluhm
|
|
There since KAME IPv6 import in 1999.
OK "Pool statistics has this info already." bluhm
|
|
nd6_timer_to is a global struct and nd6_timer() accesses it as such,
thereby ignoring its function argument.
Make that clear when setting the timeout, which now goes like the other
two timeouts.
OK bluhem
|
|
From Thomas Zimmermann
31f351eb534e889d11cd149de547d99eb5a15c64 in linux 5.15.y/5.15.56
bf43e4521ff3223a613f3a496991a22a4d78e04b in mainline linux
|
|
From Yefim Barashkin
8c37e7a2000d795aaad7256950f43c25f2aac67f in linux 5.15.y/5.15.56
0638c98c17aa12fe914459c82cd178247e21fb2b in mainline linux
|
|
From Mario Kleiner
cded1186f7e930045fb4ee17dbfa6bae41f3882c in linux 5.15.y/5.15.56
add61d3c31de6a4b5e11a2ab96aaf4c873481568 in mainline linux
|
|
From Thomas Hellstrom
a6cecaf058c48c6def2548473d814a2d54cb3667 in linux 5.15.y/5.15.56
c2ea703dcafccf18d7d77d8b68fb08c2d9842b7a in mainline linux
|
|
From Daniele Ceraolo Spurio
60d1bb301ea5a4be3e1071d3d0c179140b270ef8 in linux 5.15.y/5.15.56
35d4efec103e1afde968cfc9305f00f9aceb19cc in mainline linux
|
|
From Chris Wilson
86062ca5edf1c2acc4de26452a34ba001e9b6a68 in linux 5.15.y/5.15.56
a1c5a7bf79c1faa5633b918b5c0666545e84c4d1 in mainline linux
|
|
From Chris Wilson
0ee5874dad61d2b154a9e3db196fc33e8208ce1b in linux 5.15.y/5.15.56
b24dcf1dc507f69ed3b5c66c2b6a0209ae80d4d4 in mainline linux
|
|
From Bruce Chang
f8ba02531476196f44a486df178b4f1fec178234 in linux 5.15.y/5.15.56
154cfae6158141b18d65abb0db679bb51a8294e7 in mainline linux
|
|
From Dan Carpenter
40c12fc520234b0145bb776f38642507180dfad8 in linux 5.15.y/5.15.56
896dcabd1f8f613c533d948df17408c41f8929f5 in mainline linux
|
|
From Dan Carpenter
f6e3ced9c60f3cab517cfb748572c26576573715 in linux 5.15.y/5.15.56
e87197fbd137c888fd6c871c72fe7e89445dd015 in mainline linux
|
|
From Hangyu Hua
505114dda5bbfd07f4ce9a2df5b7d8ef5f2a1218 in linux 5.15.y/5.15.56
85144df9ff4652816448369de76897c57cbb1b93 in mainline linux
|
|
but hopefully this will encourage someone with the hardware to test a snap.
ok jsg@
|
|
There since import.
OK sthen
|
|
Without any later realloactions, size is taken from vnet_dring_alloc().
OK kettenis
|
|
version number issues close to release
|
|
It was possible to exhaust kernel memory by repeatedly calling
pfioctl DIOCXBEGIN with different anchor names.
OK bluhm@
Reported-by: syzbot+9dd98cbce69e26f0fc11@syzkaller.appspotmail.com
|
|
ok guenther
|
|
|
|
ok guenther
|
|
the last slot of the packet rather than the first slot of the next.
ok dlg@
|
|
Those are the read-only operations allowed for non-root users:
SWAP_NSWAP and SWAP_STATS. Users of pledge("vminfo") in base which also
call swapctl(2) with said commands: top(1) and pstat(8).
No regression spotted with top(1) and pstat(8) -s/-T.
ok deraadt@
|
|
/var/run/ypbind.lock. "getpw" is now only allows ypconnect(2) and the minimum
unveil bypasses.
Still allow open/acesss to file for a little while, because getpwent/getgrent/etc
were opening it unconditionally to hint for YPACTIVE.
That code should be deleted before 7.2
|
|
Even though -march=octeon seems to work, avoid it for now. It is
not entirely certain that the compiler will not use cnMIPS special
registers accidentally in normal kernel code.
Discussed with and OK miod@
|
|
|
|
inside ypconnect(), it is best if we prevent "../" problems. so reject
domainnames containing '/.
discussed with jca
|
|
if chrooted
issue pointed out by semarie
|
|
and pmap_remove(9) here since we're dealing with managed pages here. Found
out the hard way by deraadt@ on landisk where we're running into issues
with virtual cache aliases because multiple mappings exist for the
pages we're dealing with here. The pmap_enter(9) and pmap_remove(9)
functions handle conflicting cache aliases, whereas pmap_map_direct(9) and
pmap_kenter_pa(9) assume that the pages is exclusively mapped in the kernel
pmap.
ok deraadt@
|
|
new libc..
|
|
no longer does accesses /var/run/ypbind.lock to trigger extra permissions
for userland-opening of files & sockets to engage with ypserver for YP/LDAP
lookups. libc now uses the super secret special ypconnect() system call
to perform socket-setup.
Delete some other things which are no longer reached via libc/rpc
ok jmatthew, miod
|
|
field of the route with a mutex. Keep rt_llinfo not NULL consistent
with RTF_LLINFO flag is set. Also do not put the mutex in the fast
path.
OK mpi@
|
|
numbers don't necessarily match the CPU numbers used by our kernel.
Seen on an Amlogic S922X SoC where cluster 0 consists of two Cortex-A53
cores and cluster 1 consists of four Cortes-A73 cores.
ok anton@
|