Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not all architectures did what the installer does with empty disks.
|
|
(such as the one on the x13s) allocate memory with the EfiBootSevicesData
type in a semi-random fashion. Ignoring small regions with that type
results in different memory maps between boots of the same kernel.
This causes problems with upcoming hibernate support.
The decision to ignore small regions was made because we do this on
amd64 to work arounmd broken BIOS implementations and because of fears
that we would run out of physical memory segments in UVM. We have some
reasons to believe that we can trust the EFI memory map on arm64 and the
risk of running out of physical memory segments is mitigated by the fact
that we try to merge memory regions before loading them into UVM. If
for some reason we see a significant drop in physical memory on certain
machines, we should probably increase the number of items in the array
we use to store memory regions and/or increase the number of physical
memory segments in UVM.
ok mlarkin@
|
|
If a providerAS sets an afiLimit, subsequent providerAS that don't set it
would erroneously inherit that limit. Zero out the provider at the top of
the loop to avoid this problem.
ok job
|
|
counter parts. Input deraadt.
ok bluhm
|
|
MP safe. Due to the KAME scope address hack, the link-local all
nodes and all routers IPv6 addresses cannot be const.
OK benno@
|
|
provide locking of the PCB. If that is possible, use shared instead
of exclusive netlock in soreceive(). The PCB mutex provides a per
socket lock against multiple soreceive() running in parallel.
Release and regrab both locks in sosleep_nsec().
OK mvs@
|
|
From Charlene Liu
85dd24ff77c15f5fc0e16bc3f288f5d1ac93e02b in linux 5.15.y/5.15.65
5544a7b5a07480192eb5fd3536462faed2c21528 in mainline linux
|
|
From Dusica Milinkovic
898467ac9bcb56090f0b651088a36331ff779e4c in linux 5.15.y/5.15.65
373008bfc9cdb0f050258947fa5a095f0657e1bc in mainline linux
|
|
From Ilya Bakoulin
4df54c493e76f3cfa0bc8c54c5c43faa3b6e78d4 in linux 5.15.y/5.15.65
04fb918bf421b299feaee1006e82921d7d381f18 in mainline linux
|
|
From Evan Quan
a89e753d5a9f3b321f4a3098e2755c5aabcff0af in linux 5.15.y/5.15.65
0a2d922a5618377cdf8fa476351362733ef55342 in mainline linux
|
|
From Fudong Wang
5ee30bcfdb32526233d2572f3d9ec371928679f1 in linux 5.15.y/5.15.65
b2a93490201300a749ad261b5c5d05cb50179c44 in mainline linux
|
|
From Alvin Lee
e407e04a93d7b1209669220fab5eb69ab7b09baf in linux 5.15.y/5.15.65
84ef99c728079dfd21d6bc70b4c3e4af20602b3c in mainline linux
|
|
From Leo Ma
2cddd3d0b049a5e0666f93ea8c0d6ba6cc4bbec4 in linux 5.15.y/5.15.65
0591183699fceeafb4c4141072d47775de83ecfb in mainline linux
|
|
From Josip Pavic
0c8abeceee0f58ad3fdc66e1de0c0e02b962653b in linux 5.15.y/5.15.65
8de297dc046c180651c0500f8611663ae1c3828a in mainline linux
|
|
From Chris Wilson
4676773ea117624ced48fdf9806d5e0dc051bd7f in linux 5.15.y/5.15.65
e5a95c83ed1492c0f442b448b20c90c8faaf702b in mainline linux
|
|
From Maxime Ripard
f8b07c05b69969c41efafda7022d6cb184d61bf9 in linux 5.15.y/5.15.65
59050d783848d9b62e9d8fb6ce0cd00771c2bf87 in mainline linux
|
|
ok job
|
|
|
|
Running installboot(8) on softraid(4) volumes means installing stages on
every softraid chunk.
The overall idea is the same, but MD implementations differ.
sparc64_softraid.c's sr_install_bootblk() reuses sparc64_installboot.c's
md_installboot() for this.
For sparc64, md_installboot() does the copy of stage 2, usually
/usr/mdec/ofwboot to /ofwboot, so when `-r root' is passed, it prefixes the
file path with "root".
For single-disk installations (plain-disk and single-chunk softraid) this is
fine, but as soon as multiple chunks are used, md_installboot() currently
prefixes the path each time, obviously resulting in invalid paths starting
with the second run.
Other architectures do reuse md_installboot() as well but either don't do
such a copy or implement the prefixing differently -- plus they must support
softraid in the firt place to be able to hit this type of bug.
With this fixed, regress/usr.sbin/installboot finally passes on sparc64 and
installboot no longer fails at the end of a fresh installation onto softraid
with multiple chunks.
"looks correct" miod
|
|
|
|
On sparc64, installboot(8) does not deal with any file system; its -p is a
NOOP and according to CVS history the old sys/arch/sparc64/installboot/
never prepared a file system, either.
Remove this single misleading mention alltogether and rely on the now
consistently cross-linked MI installboot(8) for details, if any.
This syncs the list of currently existing MD boot_*(8/*) pages with the list
of usr.sbin/installboot/*_installboot.c files.
boot_alpha(8/alpha) already references installboot(8) but still uses
sys/arch/alpha/stand/installboot/ instead of usr.sbin/installboot/.
boot_luna88k(8/luna88k) exists but luna88k does not use installboot at all.
installboot(8) has additional support for efi (armv7, arm64, riscv64),
landisk, loongson, octeon and powerpc64 but those architectures currently
lack their own MD boot_*(8/*) manual.
OK miod
|
|
In boot_macppc(8), the current format a) claims to support specific disk/MBR
partitions which ofwboot clearly does not parse as such and b) lacks markup
to make clear which optional parts can (not) be omitted in what way.
Fixing both turns
promdev:partition/filename options
into
[[promdev:]filename] [-acds]
Same goes for boot(8/macppc), which has been apparently has been copied
from boot(8/amd64) without accounting for all platform specific details.
On amd64, biosboot(8) sees disks as 'sd' which (accidentially?) matches the
kernel driver's sd(4) name; it also supports specific disklabel(5) slices,
so amd64 can do 'sd0a:/bsd'.
On macppc, disks show up as 'ide', 'cd' or 'hd' which stems from
OpenFirmware alone, not matching the wd(4) driver's name. Also, ofwboot
always boots off the 'a' label, so macppc can only do 'hd:/bsd'.
Found while installing OpenBSD/macppc from CD inside QEMU but failing to
boot from disk inside QEMU and consulting our manual pages for help wrt.
specifying a boot device. Turns out QEMU's OpenBIOS simply cannot boot from
MSDOS filesystems (thanks gkoehler), so it wouldn't work no matter what
boot file specification I'd use.
tests/agreement gkoehler
Feedback OK miod
OK tobhe
OK jmc on a previous boot_macppc.8 diff
|
|
like xhci(4) and ehci(4).
ok mpi@
|
|
Used to flag the newly added test_bind_unix_socket() as expected to
fail.
|
|
No change in generated assembly.
|
|
No change in generated assembly.
|
|
The EVP cipher API uses size_t, however a number of the underlying
implementations use long in their API. This means that an input with
size > LONG_MAX will go negative.
Found by Coverity, hiding under a large pile of macros.
ok tb@
|
|
Only change to generated assembly is due to line numbers.
|
|
Only change in generated assembly is due to line numbers.
|
|
Pull the init_key and ctrl (if present) functions up to the top. This
improves readability and allows for the removal of function prototypes.
No functional change.
|
|
|
|
|
|
|
|
No change in generated assembly.
|
|
checking socket type is not sufficient as it could splice together
unix and inet sockets resulting in crashes. As splicing is about
sending, the same send function looks like a good criteria.
Reported-by: syzbot+fc6901d63d858d5dd00a@syzkaller.appspotmail.com
Reported-by: syzbot+0e026f1bf8b259c6395e@syzkaller.appspotmail.com
OK gnezdo@
|
|
No change in generated assembly.
|
|
No change in generated assembly.
|
|
devices, audio, and video. It's still not perfect, and will need
further improvements.
High level, the diff contains following changes:
* Sync up with the Linux code base, which did re-work the periodic
scheduling code path.
* Run the driver in IPL_VM instead of IPL_USB to prioritize us before
lower/equal interrupts (same what NetBSD does).
* Add two new flags to our USB stack required by the updated driver
code:
- 'multi' flag in the usbd_hub structure to keep track whether
a hub has one Transaction Translator for all ports (single TT)
or one Transaction Translator per port (multi TT).
- 'hcpriv' pointer in the usbd_tt structure for the HC driver to
allocate memory for the scheduling depending on single or multi TT.
"go for it" kettenis@
|
|
|
|
This includes the wonderful BLOCK_CIPHER_ecb_loop - a for loop in a macro.
No change in generated assembly.
|
|
OK jmc
|
|
|
|
This simplifies memory management and makes it easier to see the leak
that were introduced in the previous commit. Sprinkle a few malloc
errors for consistency.
CID 278396
with/ok jsing
|