profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/emaste/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Ed Maste emaste FreeBSD Committer and Director of Project Development for The FreeBSD Foundation

cosql/lldb 3

Mirror of official lldb git repository located at http://llvm.org/git/lldb. Updated hourly.

emaste/cp210x-cfg 2

CLI utility for programming CP210x USB<->UART bridges

emaste/AbsTK 0

The Abstract Toolkit – a widget toolkit for GUI and text-mode applications.

emaste/age 0

A simple, modern and secure encryption tool with small explicit keys, no config options, and UNIX-style composability.

emaste/atom 0

The hackable text editor :atom:

emaste/bloaty 0

Bloaty McBloatface: a size profiler for binaries

emaste/capnproto 0

Cap'n Proto serialization/RPC system

emaste/capsicum-test 0

Test suite for Capsicum

emaste/capsicumizer 0

Run anything (like full blown GTK apps) under Capsicum

push eventemaste/freebsd

Hans Petter Selasky

commit sha 903873ce15600fc02a0ea42cbf888cff232b411d

Implement and use new mixer(3) library for FreeBSD. Wiki article: https://wiki.freebsd.org/SummerOfCode2021Projects/SoundMixerImprovements This project was part of Google Summer of Code 2021. Submitted by: christos@ Differential Revision: https://reviews.freebsd.org/D31636 Sponsored by: NVIDIA Networking

view details

Hans Petter Selasky

commit sha 0e94a30691385595ef03cc6861f0b67371ff90ef

UPDATING: Add new entry about mixer(8) usage. Differential Revision: https://reviews.freebsd.org/D31636 Sponsored by: NVIDIA Networking

view details

Hans Petter Selasky

commit sha 8fc722a572b8af5afde4a4515a7ff3784360e471

mixer(8): Compile fix for when the "char" type is unsigned. Differential Revision: https://reviews.freebsd.org/D31636 Sponsored by: NVIDIA Networking

view details

Hans Petter Selasky

commit sha db6ba1e0c585d37469c3bc74238b7fc4ea249274

mixer(3) and mixer(8): Update manual pages. - Use correct e-mail address. - Set FreeBSD 14.0 as introduction for the updated mixer(8) utility. Submitted by: christos@ Differential Revision: https://reviews.freebsd.org/D31636 Sponsored by: NVIDIA Networking

view details

Hans Petter Selasky

commit sha 624a34b87b2757cb33b33a5b40821990c8bce673

rc.d/mixer: Use -o flag instead of -s flag to get current mixer state. Submitted by: christos@ Differential Revision: https://reviews.freebsd.org/D31636 Sponsored by: NVIDIA Networking

view details

Konstantin Belousov

commit sha e36d0e86e3282cde5a12b6a623e6deefaabfd0c4

Revert "linux32: add a hack to avoid redefining the type of the savefpu tag" This reverts commit 0f6829488ef32142b9ea1c0806fb5ecfe0872c02. Also it changes the type of md_usr_fpu_save struct mdthread member to void *, which is what uncovered this trouble. Now the save area is untyped, but since it is hidden behind accessors, it is not too significant. Since apparently there are consumers affected outside the tree, this hack is better than one from the reverted revision. PR: 258678 Reported by: cy Reviewed by: cy, kevans, markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D32060

view details

Piotr Pawel Stefaniak

commit sha c866d0c798a20b8f0a92df524f4ddd0d81511c88

sh: improve command completion When there are many matches, find the longest common substring starting from the beginning of each command and use that to replace input. As an example: on my system, llv<tab> will be autocompleted to llvm- and another <tab> will print all matching llvm commands.

view details

Piotr Pawel Stefaniak

commit sha 1f82fb3834105fd8f1186b1c6d719d8a24738180

sh: try to avoid overwriting HISTFILE produced by other shells If an attempt to load history from an existing history file was unsuccessful, do not try to save command history to that file on exit.

view details

Olivier Houchard

commit sha 9bab18b8616bad4fa0adcd0e291903c55263640e

libsysdecode: Decode FreeBSD32 syscalls on arm64. Add aarch64 to the list of architectures that can run 32bits FreeBSD binaries, so that truss works correctly with an arm32 binary. The same should probably be done with mips. MFC After: 1 week

view details

Olivier Houchard

commit sha ebbc3140ca0d7eee154f7a67ccdae7d3d88d13fd

truss: Decode correctly 64bits arguments on 32bits arm. When decoding 32bits arm syscall, make sure we account for the padding when decoding 64bits args. Do it too when using a 64bits truss on a 32bits binary. MFC After: 1 week PR: 256199

view details

Kirk McKusick

commit sha b31c5a25321363ab95c1642dffc6e92319dc42ce

Eliminate an unnecessary rerun request in fsck_ffs. When fsck_ffs is running in preen mode and finds a zero-length directory, it deletes that directory. In doing this operation, it unnecessary set its internal flag saying that fsck_ffs needed to be rerun. This patch deletes the rerun request for this case. Reported by: Mark Johnson PR: 246962 MFC after: 1 week Sponsored by: Netflix

view details

Olivier Houchard

commit sha f4b7018af11a1ab3edfcce8bc0bfa521364cdeb0

truss: Decode correctly 64bits arguments on 32bits arm. Mostly revert ebbc3140ca0d7eee154f7a67ccdae7d3d88d13fd. We don't need to special-case anything for arm64, the check for the pointer size is already done for us, just keep the bits about having arm and arm64 having to add padding for 32bits binaries. MFC after: 1 week

view details

John Baldwin

commit sha b5f90655ea37dc01e48002f83f85c6e3fc7565d8

sysdecode.3: Remove documentation of CloudABI ABIs. Fixes: cf0ee8738e31 Drop cloudabi

view details

Konstantin Belousov

commit sha 3fcbde5e883a253f631082b128dcdf77c840d4c0

tests/sys/fs/fusefs/read.cc: fix build on powerpc64 There sig_atomic_t is shorter than void *. As result, it cannot keep pointer. Assigning to void * is actually safe for us in a signal handler. Reviewed by: asomers Sponsored by: The FreeBSD Foundation MFC after: 1 week Fixes: 4f917847c9037d Differential revision: https://reviews.freebsd.org/D32064

view details

Baptiste Daroussin

commit sha 88741a40c8fb515489b3ef61eba221fd7c8bef1b

check-links.sh: treat PIE executable as elf files

view details

Wojciech Macek

commit sha 319b150003001fa09cb4a97452c57340ce42db35

pmc: intr pmc.soft(3) update Obtained from: Semihalf Sponsored by: Stormshield Reviewed by: mhorne Differential revision: https://reviews.freebsd.org/D32055

view details

Wojciech Macek

commit sha 7bc13692a2d6b33b4e80bb9ad70d5eede6b148af

hwpmc: fix performance issues Differential revision: https://reviews.freebsd.org/D32025 Avoid using atomics as it_wait is guarded by td_lock. Report threshold calculation is done only if at least one PMC hook is installed Fixes: * avoid unnecessary branching (if frame != null ...) by having PMC_HOOK_INSTALLED_ANY condition on the top of them, which should hint the core not to execute speculatively anything which us underneath; * access intr_hwpmc_waiting_report_threshold cacheline only if at least one hook is loaded;

view details

Kyle Evans

commit sha 6895cade9421238abf541f24fb9327ebd19e94ff

kern: random: drop read_rate and associated functionality Refer to discussion in PR 230808 for a less incomplete discussion, but the gist of this change is that we currently collect orders of magnitude more entropy than we need. The excess comes from bytes being read out of /dev/*random. The default rate at which we collect entropy without the read_rate increase is already more than we need to recover from a compromise of an internal state. Reviewed by: #csprng (cem, delphij, markm) Differential Revision: https://reviews.freebsd.org/D32021

view details

Kyle Evans

commit sha 5e79bba562bc303eed669dbd0d391b6c6a9c289b

kern: random: collect ~16x less from fast-entropy sources Previously, we were collecting at a base rate of: 64 bits x 32 pools x 10 Hz = 2.5 kB/s This change drops it to closer to 64-ish bits per pool per second, to work a little better with entropy providers in virtualized environments without compromising the security goals of Fortuna. Reviewed by: #csprng (cem, delphij, markm) Differential Revision: https://reviews.freebsd.org/D32021

view details

Hans Petter Selasky

commit sha 90f6610b197550d841bcc13b7c2a90be627443b5

UPDATING: Fix spelling. Submitted by: gljennjohn@gmail.com Differential Revision: https://reviews.freebsd.org/D31636 Sponsored by: NVIDIA Networking

view details

push time in 2 hours

create barnchemaste/freebsd

branch : D32059

created branch time in 20 hours

issue commentrust-lang/rust

Drop support for FreeBSD 10 from std

There's a related discussion happening for Go now, although Go's avoidance of libc makes it interesting: https://github.com/golang/go/issues/48164

I agree with dropping FreeBSD 10 support immediately and also agree with moving to 12.x the minimum supported version. However, the official EOL is hust over a week from the time I'm writing this comment and I would suggest waiting a short time after that, to allow time for a heads-up on FreeBSD mailing lists or elsewhere.

There are a number of companies and others building products and projects on top of FreeBSD who for better or worse continue to use older, unsupported versions. While it is not reasonable (or possible) to accommodate this case long-term, I'd generally like to avoid forcing them into an urgent and unplanned need to upgrade.

asomers

comment created time in a day

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work and msdosfs_rename reports

+== Improved amd64 UEFI boot++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader+handoff to the operating system kernel, there are still some memory+regions that are reserved by BIOS for different reasons.  Examples+are runtime services code and data.++On the other hand, legacy/CSM BIOS boot works with memory completely+differently, there are known memory regions that hold BIOS data and+must be avoided.  Otherwise, the memory is considered free for loader+and OS to use. (Of course it is not that straightforward, the+definition of known regions is up to the vendor and there are a lot of+workarounds there.)++BIOS boot puts the kernel and preloaded data (like modules, memory+disk, CPU microcode update etc) at the contigous physical memory block+starting at 2M.  This algorithm goes back to how i386 kernel boots.++Also, when preparing to pass control to the kernel, the loader+creates quite special temporal mappings, where low 1G of physical

"very" seems slightly more typical to me, although for quarterly report entries I think it isn't critical

kostikbel

comment created time in a day

PullRequestReviewEvent

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work and msdosfs_rename reports

+== Improved amd64 UEFI boot++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader

yeah, I think "the BIOS" here sounds better

kostikbel

comment created time in a day

PullRequestReviewEvent

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work and msdosfs_rename reports

+== Improved amd64 UEFI boot++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment

streamlined would have to change too then, "a much richer and more streamlined ..."

kostikbel

comment created time in a day

PullRequestReviewEvent

fork emaste/cloudlibc

CloudABI's standard C library

fork in 2 days

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging ++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One of+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader+handoff to the operating system kernel, there are still some memory+regions that are reserved by BIOS for different reasons, most knows+are runtime services code and data.++On the other hand, legacy/CSM BIOS boot works with memory completely+differently, there are known memory regions that hold BIOS data and+must be avoided.  Otherwise, the memory is considered free for loader+and OS to use. [Of course it is not that straightforward, the+definition of known regions is up to the vendor and there are a lot of+workarounds there]++BIOS boot puts the kernel and preloaded data (like modules, memory+disk, CPU microcode update etc) at the contigous physical memory block+starting at 2M.  This algorithm goes back to how i386 kernel boots.++Also, when preparing to handle the control of to the kernel, loader+creates quite special temporal mappings, where low 1G of physical+address space is mapped 1:1 into virtual address space, and then+repeated for each 1G until the virtual memory end.  Kernel knows about+its physical location and the temporal mapping, and constructs kernel+page tables assuming that the physical address of the text is at 2M.++This mechanism of loader to kernel handoff was left unchanged when+loader got support for UEFI environment.  Loader prepares kernel and+auxillary preload data in so called staging area while UEFI boot+services are active, and after EFI_BOOT_SERVICES.ExitBootServices(),+the temporal mapping is activated and staging area is copied at 2M.++An advantage at that time was that no changes to the kernel were+needed.  But there are issues, the biggest is that memory at 2M might+be not free for reuse.  For instance, BIOS runtime code or data might+be located there.  Or there might be no memory at 2M at all.  Or+trampoling page table or code, or even some parts of the staging area+overlapped with the 2M region where staging area is copied.  The+outcome was a weird and hard to diagnose boot time failures, typically+machine hangs hard when loader started kernel.++Another limitation is the 1G transient mapping, which due to copying+means that total size of preloaded data cannot exceed around 400M for+everything, including kernel, memory disks, and anything else.  Also+the code to grow staging area on demand was quite unflexible, only+able to grow the staging area in place.++Described work allows UEFI loader on amd64 to start kernel from the+staging area without copying.  Kernel assumptions about the hand-off+were explicitly identified and documented.  Kernel only requires that+the staging area was located below 4G together with the trampoline+page table (this is a consequence of CPU architecture requiring 32bit+protected mode to enter long mode), be 2M aligned and whole low 4G+mapped 1:1 at hand-off.  Kernel deduces its physical address and+builds kernel page tables accordingly.++Making booting with staging area in-place work required identifying+all places where amd64 kernel grown a dependency on its physical+location.  Most complicated part was application processors startup,+which required rewriting initialization code, which we were able to+streamline as result.  In particular, when AP enters paging mode, it+does so right into correct kernel page table, without loading+intermediate trampoline page table.++Updated loader automatically detects if the loaded kernel can handle+in-place staging are ('non-copying mode').  If needed, this can be

staging //area// I presume?

kostikbel

comment created time in 2 days

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging ++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One of+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader+handoff to the operating system kernel, there are still some memory+regions that are reserved by BIOS for different reasons, most knows+are runtime services code and data.++On the other hand, legacy/CSM BIOS boot works with memory completely+differently, there are known memory regions that hold BIOS data and+must be avoided.  Otherwise, the memory is considered free for loader+and OS to use. [Of course it is not that straightforward, the+definition of known regions is up to the vendor and there are a lot of+workarounds there]++BIOS boot puts the kernel and preloaded data (like modules, memory+disk, CPU microcode update etc) at the contigous physical memory block+starting at 2M.  This algorithm goes back to how i386 kernel boots.++Also, when preparing to handle the control of to the kernel, loader+creates quite special temporal mappings, where low 1G of physical+address space is mapped 1:1 into virtual address space, and then+repeated for each 1G until the virtual memory end.  Kernel knows about+its physical location and the temporal mapping, and constructs kernel+page tables assuming that the physical address of the text is at 2M.++This mechanism of loader to kernel handoff was left unchanged when+loader got support for UEFI environment.  Loader prepares kernel and+auxillary preload data in so called staging area while UEFI boot+services are active, and after EFI_BOOT_SERVICES.ExitBootServices(),+the temporal mapping is activated and staging area is copied at 2M.++An advantage at that time was that no changes to the kernel were+needed.  But there are issues, the biggest is that memory at 2M might+be not free for reuse.  For instance, BIOS runtime code or data might+be located there.  Or there might be no memory at 2M at all.  Or+trampoling page table or code, or even some parts of the staging area+overlapped with the 2M region where staging area is copied.  The+outcome was a weird and hard to diagnose boot time failures, typically+machine hangs hard when loader started kernel.++Another limitation is the 1G transient mapping, which due to copying+means that total size of preloaded data cannot exceed around 400M for+everything, including kernel, memory disks, and anything else.  Also+the code to grow staging area on demand was quite unflexible, only+able to grow the staging area in place.++Described work allows UEFI loader on amd64 to start kernel from the+staging area without copying.  Kernel assumptions about the hand-off+were explicitly identified and documented.  Kernel only requires that+the staging area was located below 4G together with the trampoline+page table (this is a consequence of CPU architecture requiring 32bit+protected mode to enter long mode), be 2M aligned and whole low 4G+mapped 1:1 at hand-off.  Kernel deduces its physical address and+builds kernel page tables accordingly.++Making booting with staging area in-place work required identifying+all places where amd64 kernel grown a dependency on its physical

grew a dependency or perhaps had a dependency

kostikbel

comment created time in 2 days

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging ++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One of+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader+handoff to the operating system kernel, there are still some memory+regions that are reserved by BIOS for different reasons, most knows+are runtime services code and data.++On the other hand, legacy/CSM BIOS boot works with memory completely+differently, there are known memory regions that hold BIOS data and+must be avoided.  Otherwise, the memory is considered free for loader+and OS to use. [Of course it is not that straightforward, the+definition of known regions is up to the vendor and there are a lot of+workarounds there]++BIOS boot puts the kernel and preloaded data (like modules, memory+disk, CPU microcode update etc) at the contigous physical memory block+starting at 2M.  This algorithm goes back to how i386 kernel boots.++Also, when preparing to handle the control of to the kernel, loader+creates quite special temporal mappings, where low 1G of physical+address space is mapped 1:1 into virtual address space, and then+repeated for each 1G until the virtual memory end.  Kernel knows about+its physical location and the temporal mapping, and constructs kernel+page tables assuming that the physical address of the text is at 2M.++This mechanism of loader to kernel handoff was left unchanged when+loader got support for UEFI environment.  Loader prepares kernel and+auxillary preload data in so called staging area while UEFI boot+services are active, and after EFI_BOOT_SERVICES.ExitBootServices(),+the temporal mapping is activated and staging area is copied at 2M.++An advantage at that time was that no changes to the kernel were+needed.  But there are issues, the biggest is that memory at 2M might+be not free for reuse.  For instance, BIOS runtime code or data might+be located there.  Or there might be no memory at 2M at all.  Or+trampoling page table or code, or even some parts of the staging area+overlapped with the 2M region where staging area is copied.  The+outcome was a weird and hard to diagnose boot time failures, typically+machine hangs hard when loader started kernel.++Another limitation is the 1G transient mapping, which due to copying+means that total size of preloaded data cannot exceed around 400M for+everything, including kernel, memory disks, and anything else.  Also+the code to grow staging area on demand was quite unflexible, only+able to grow the staging area in place.++Described work allows UEFI loader on amd64 to start kernel from the

The work described in this report allows or just This project allows

kostikbel

comment created time in 2 days

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging ++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One of+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader+handoff to the operating system kernel, there are still some memory+regions that are reserved by BIOS for different reasons, most knows+are runtime services code and data.++On the other hand, legacy/CSM BIOS boot works with memory completely+differently, there are known memory regions that hold BIOS data and+must be avoided.  Otherwise, the memory is considered free for loader+and OS to use. [Of course it is not that straightforward, the+definition of known regions is up to the vendor and there are a lot of+workarounds there]++BIOS boot puts the kernel and preloaded data (like modules, memory+disk, CPU microcode update etc) at the contigous physical memory block+starting at 2M.  This algorithm goes back to how i386 kernel boots.++Also, when preparing to handle the control of to the kernel, loader+creates quite special temporal mappings, where low 1G of physical+address space is mapped 1:1 into virtual address space, and then+repeated for each 1G until the virtual memory end.  Kernel knows about+its physical location and the temporal mapping, and constructs kernel+page tables assuming that the physical address of the text is at 2M.++This mechanism of loader to kernel handoff was left unchanged when+loader got support for UEFI environment.  Loader prepares kernel and+auxillary preload data in so called staging area while UEFI boot+services are active, and after EFI_BOOT_SERVICES.ExitBootServices(),+the temporal mapping is activated and staging area is copied at 2M.++An advantage at that time was that no changes to the kernel were+needed.  But there are issues, the biggest is that memory at 2M might+be not free for reuse.  For instance, BIOS runtime code or data might+be located there.  Or there might be no memory at 2M at all.  Or+trampoling page table or code, or even some parts of the staging area+overlapped with the 2M region where staging area is copied.  The+outcome was a weird and hard to diagnose boot time failures, typically

"a" doesn't match "failures" maybe "hard to diagnose boot time failure, typically a hard hang when the loader started the kernel."

kostikbel

comment created time in 2 days

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging ++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One of+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader+handoff to the operating system kernel, there are still some memory+regions that are reserved by BIOS for different reasons, most knows+are runtime services code and data.++On the other hand, legacy/CSM BIOS boot works with memory completely+differently, there are known memory regions that hold BIOS data and+must be avoided.  Otherwise, the memory is considered free for loader+and OS to use. [Of course it is not that straightforward, the+definition of known regions is up to the vendor and there are a lot of+workarounds there]++BIOS boot puts the kernel and preloaded data (like modules, memory+disk, CPU microcode update etc) at the contigous physical memory block+starting at 2M.  This algorithm goes back to how i386 kernel boots.++Also, when preparing to handle the control of to the kernel, loader+creates quite special temporal mappings, where low 1G of physical+address space is mapped 1:1 into virtual address space, and then+repeated for each 1G until the virtual memory end.  Kernel knows about+its physical location and the temporal mapping, and constructs kernel+page tables assuming that the physical address of the text is at 2M.++This mechanism of loader to kernel handoff was left unchanged when+loader got support for UEFI environment.  Loader prepares kernel and+auxillary preload data in so called staging area while UEFI boot+services are active, and after EFI_BOOT_SERVICES.ExitBootServices(),+the temporal mapping is activated and staging area is copied at 2M.++An advantage at that time was that no changes to the kernel were+needed.  But there are issues, the biggest is that memory at 2M might+be not free for reuse.  For instance, BIOS runtime code or data might+be located there.  Or there might be no memory at 2M at all.  Or+trampoling page table or code, or even some parts of the staging area+overlapped with the 2M region where staging area is copied.  The+outcome was a weird and hard to diagnose boot time failures, typically+machine hangs hard when loader started kernel.++Another limitation is the 1G transient mapping, which due to copying+means that total size of preloaded data cannot exceed around 400M for+everything, including kernel, memory disks, and anything else.  Also+the code to grow staging area on demand was quite unflexible, only+able to grow the staging area in place.++Described work allows UEFI loader on amd64 to start kernel from the+staging area without copying.  Kernel assumptions about the hand-off+were explicitly identified and documented.  Kernel only requires that+the staging area was located below 4G together with the trampoline+page table (this is a consequence of CPU architecture requiring 32bit+protected mode to enter long mode), be 2M aligned and whole low 4G+mapped 1:1 at hand-off.  Kernel deduces its physical address and+builds kernel page tables accordingly.++Making booting with staging area in-place work required identifying+all places where amd64 kernel grown a dependency on its physical+location.  Most complicated part was application processors startup,+which required rewriting initialization code, which we were able to+streamline as result.  In particular, when AP enters paging mode, it+does so right into correct kernel page table, without loading+intermediate trampoline page table.++Updated loader automatically detects if the loaded kernel can handle+in-place staging are ('non-copying mode').  If needed, this can be+controlled by loader copy_staging command.  Also, the code to grow

maybe "overridden with the ... command". Perhaps include an inline example if it doesn't make this too awkward.

kostikbel

comment created time in 2 days

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging ++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One of+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader+handoff to the operating system kernel, there are still some memory+regions that are reserved by BIOS for different reasons, most knows+are runtime services code and data.++On the other hand, legacy/CSM BIOS boot works with memory completely+differently, there are known memory regions that hold BIOS data and+must be avoided.  Otherwise, the memory is considered free for loader+and OS to use. [Of course it is not that straightforward, the+definition of known regions is up to the vendor and there are a lot of+workarounds there]++BIOS boot puts the kernel and preloaded data (like modules, memory+disk, CPU microcode update etc) at the contigous physical memory block+starting at 2M.  This algorithm goes back to how i386 kernel boots.++Also, when preparing to handle the control of to the kernel, loader+creates quite special temporal mappings, where low 1G of physical+address space is mapped 1:1 into virtual address space, and then+repeated for each 1G until the virtual memory end.  Kernel knows about+its physical location and the temporal mapping, and constructs kernel+page tables assuming that the physical address of the text is at 2M.++This mechanism of loader to kernel handoff was left unchanged when+loader got support for UEFI environment.  Loader prepares kernel and+auxillary preload data in so called staging area while UEFI boot

in //a// so called staging

kostikbel

comment created time in 2 days

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging ++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One of+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader+handoff to the operating system kernel, there are still some memory+regions that are reserved by BIOS for different reasons, most knows+are runtime services code and data.++On the other hand, legacy/CSM BIOS boot works with memory completely+differently, there are known memory regions that hold BIOS data and+must be avoided.  Otherwise, the memory is considered free for loader+and OS to use. [Of course it is not that straightforward, the+definition of known regions is up to the vendor and there are a lot of+workarounds there]++BIOS boot puts the kernel and preloaded data (like modules, memory+disk, CPU microcode update etc) at the contigous physical memory block+starting at 2M.  This algorithm goes back to how i386 kernel boots.++Also, when preparing to handle the control of to the kernel, loader+creates quite special temporal mappings, where low 1G of physical+address space is mapped 1:1 into virtual address space, and then+repeated for each 1G until the virtual memory end.  Kernel knows about+its physical location and the temporal mapping, and constructs kernel+page tables assuming that the physical address of the text is at 2M.++This mechanism of loader to kernel handoff was left unchanged when+loader got support for UEFI environment.  Loader prepares kernel and

maybe "loader gained support for the UEFI environment"

kostikbel

comment created time in 2 days

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging ++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One of+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader+handoff to the operating system kernel, there are still some memory+regions that are reserved by BIOS for different reasons, most knows

... different reasons. Examples are runtime...

kostikbel

comment created time in 2 days

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging ++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One of+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader+handoff to the operating system kernel, there are still some memory+regions that are reserved by BIOS for different reasons, most knows+are runtime services code and data.++On the other hand, legacy/CSM BIOS boot works with memory completely+differently, there are known memory regions that hold BIOS data and+must be avoided.  Otherwise, the memory is considered free for loader+and OS to use. [Of course it is not that straightforward, the

() are typical, (Of course ... workarounds there.)

kostikbel

comment created time in 2 days

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging 

I would drop "staging" here, it refers to an aspect of the boot but reads as if this is part of an "amd64 staging" branch.

How about simply "Improved amd64 UEFI boot"?

kostikbel

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging ++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One of+such requirement is that loader must coordinate its memory use with

One such requirement (no "of")

kostikbel

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentfreebsd/freebsd-quarterly

amd64 UEFI loader copy_staging work

+== Changes to UEFI boot on amd64 staging ++Contact: Konstantin Belousov <kib@FreeBSD.org>  ++UEFI BIOS on PC provides much more rich and streamlined environment+for pre-OS programs, but also it imposes some requirements on the+programs that are executed there, OS loaders in particular.  One of+such requirement is that loader must coordinate its memory use with+BIOS, only using memory that was allocated for it.  Even after loader+handoff to the operating system kernel, there are still some memory+regions that are reserved by BIOS for different reasons, most knows+are runtime services code and data.++On the other hand, legacy/CSM BIOS boot works with memory completely+differently, there are known memory regions that hold BIOS data and+must be avoided.  Otherwise, the memory is considered free for loader+and OS to use. [Of course it is not that straightforward, the+definition of known regions is up to the vendor and there are a lot of+workarounds there]++BIOS boot puts the kernel and preloaded data (like modules, memory+disk, CPU microcode update etc) at the contigous physical memory block+starting at 2M.  This algorithm goes back to how i386 kernel boots.++Also, when preparing to handle the control of to the kernel, loader

Maybe

... preparing to pass control to the kernel, the loader creates...

kostikbel

comment created time in 2 days

push eventemaste/freebsd

Marko Zec

commit sha 2ac039f7be620f692a3a086f35a51f1a0b6b03d2

[fib_algo][dxr] Merge adjacent empty range table chunks. MFC after: 3 days

view details

Xin LI

commit sha 6f62e3a719bdaba2a1ccdafe4e3a810217aea817

The linux rc.d script mounts several filesystems related to Linux ABI compatibility layer. When /compat is located on a ZFS other than /, mount would fail because they were not mounted. Solve this by moving `linux` to depend on `zfs` which mounts all ZFS filesystems. Differential Revision: https://reviews.freebsd.org/D31848 MFC after: 2 weeks

view details

Xin LI

commit sha 7ba7bf48d5bd6ca89f4e81579456b74ee7aa9e4f

Update leap-seconds to leap-seconds.3676924800. Obtained from: ftp://ftp.nist.gov/pub/time/leap-seconds.3676924800. MFC after: 3 days

view details

Peter Holm

commit sha 9ac518adf03e371aa3e8499f84d995663bd4e0c1

stress2: Update test to ensure propper cleanup of fifo files

view details

Hubert Mazur

commit sha b831f9ce7079b040b5f319b9c0f60daba4c6151a

if_mvneta: Build the driver as a kernel module Fix device detach and attach routine. Add required Makefile to build as a module. Remove entry from GENERIC, since now it can be loaded automatically. Tested on EspressoBin. Obtained from: Semihalf Reviewed by: manu Differential revision: https://reviews.freebsd.org/D31581

view details

Andrew Turner

commit sha b94d360e4aa66d626ad5a0acde683ae9a9c71729

Add ELF macros found in the aaelf64 spec The arm64 aaelf64 spec [0] has DT_AARCH64_ that could be used with dynamic linking. It also adds GNU_PROPERTY_AARCH64_FEATURE_1_AND used to tell the kernel which CPU features the binary is compatible with, but does not require to execute correctly. Add these values so the kernel and elf tools can make use of them. [0] https://github.com/ARM-software/abi-aa/blob/2021Q1/aaelf64/aaelf64.rst Sponsored by: The FreeBSD Foundation

view details

Michael Tuexen

commit sha 34b1efcea19dd4324eecd19d2de313d039fd9656

sctp: use a valid outstream when adding it to the scheduler Without holding the stcb send lock, the outstreams might get reallocated if the number of streams are increased. Reported by: syzbot+4a5431d7caa666f2c19c@syzkaller.appspotmail.com Reported by: syzbot+aa2e3b013a48870e193d@syzkaller.appspotmail.com Reported by: syzbot+e4368c3bde07cd2fb29f@syzkaller.appspotmail.com Reported by: syzbot+fe2f110e34811ea91690@syzkaller.appspotmail.com Reported by: syzbot+ed6e8de942351d0309f4@syzkaller.appspotmail.com MFC after: 1 week

view details

Bartlomiej Grzesik

commit sha b91fc6c43a81d3b760fb570c8439a922e536d7e6

acpica: add ACPI_GET_PROPERTY to access Device Specific Data (DSD) Add lazy acquiring of DSD package, which allows accessing Device Specific Data. Reviewed by: manu, mw Sponsored by: Semihalf Differential revision: https://reviews.freebsd.org/D31596

view details

Bartlomiej Grzesik

commit sha 3f9a00e3b577dcca57e331842e0baf2dbdf9325f

device: add device_get_property and device_has_property Generialize bus specific property accessors. Those functions allow driver code to access device specific information. Currently there is only support for FDT and ACPI buses. Reviewed by: manu, mw Sponsored by: Semihalf Differential revision: https://reviews.freebsd.org/D31597

view details

Bartlomiej Grzesik

commit sha 8a8166e5bcfb50e2b7280581b600d098fa6c9fc7

mmc: switch mmc_helper to device_ api Add generic mmc_helper which uses newly introduced device_*_property api. Thanks to this change the sd/mmc drivers will be capable of parsing both DT and ACPI description. Ensure backward compatibility for all mmc_fdt_helper users. Reviewed by: manu, mw Sponsored by: Semihalf Differential revision: https://reviews.freebsd.org/D31598

view details

Mark Johnston

commit sha 9e0c051249e3832e0f6a0067058ff9735677f3d5

opencrypto: Allow kern.crypto.allow_soft to be specified as a tunable MFC after: 1 week Sponsored by: The FreeBSD Foundation

view details

push time in 3 days

push eventemaste/freebsd

Marko Zec

commit sha eb3148cc4d256c20b5c7c9052539139b6f57f58b

[fib algo][dxr] Fix division by zero. A division by zero would occur if DXR would be activated on a vnet with no IP addresses configured on any interfaces. PR: 257965 MFC after: 3 days Reported by: Raul Munoz

view details

Artur Rojek

commit sha a3f0d18237bdcf272461d3b4b682de384c572144

ena: fix building in-kernel driver When building ENA as compiled into the kernel, the driver would fail to build. Resolve the problem by introducing the following changes: 1. Add missing `ena_rss.c` entry in `sys/conf/files`. 2. Prevent SYSCTL_ADD_INT from throwing an assert due to an extra CTLTYPE_INT flag. Fixes: 986e7b92276 ("ena: Move RSS logic into its own source files") Fixes: 6d1ef2abd33 ("ena: Implement full RSS reconfiguration") Obtained from: Semihalf Sponsored by: Amazon, Inc. MFC after: 1 week

view details

Marcin Wojtas

commit sha e8a872536042970b4dbf14dc75755a352fb14488

pci_host_generic: update Synopsys device description for ACPI The recent addition of Synopsys ECAM quirk set the device description only for the DT variant. Do the same in ACPI case. Reported by: jrtc27

view details

Konstantin Belousov

commit sha 181bfb42fd01bfa9f4636e803ccb3eeed8ac8ba4

vm_phys: do not ignore phys_avail[] segments that do not fit completely into vm_phys segments If phys_avail[] segment only intersect with some vm_phys segment, add pages from it to the free list that belong to the given vm_phys_seg, instead of dropping them. The vm_phys segments are generally result of subdivision of phys_avail segments, for instance DMA32 or LOWMEM boundaries split them. On amd64, after UEFI in-place kernel activation (copy_staging disable) was enabled, we typically have a large phys_avail[] segment below 4G which crosses LOWMEM (1M) boundary. With the current way of requiring phys_avail[] fully fit into vm_phys_seg, this memory was ignored. Reported by: madpilot Reviewed by: markj Discussed with: alc Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D31958

view details

Konstantin Belousov

commit sha f575573ca57716395ad88b962388a55d755cf6a7

Remove PT_GET_SC_ARGS_ALL Reimplement bdf0f24bb16d556a5b by checking for the caller' ABI in the implementation of PT_GET_SC_ARGS, and copying out everything if it is Linuxolator. Also fix a minor information leak: if PT_GET_SC_ARGS_ALL is done on the thread reused after other process, it allows to read some number of that thread last syscall arguments. Clear td_sa.args in thread_alloc(). Reviewed by: jhb Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D31968

view details

Konstantin Belousov

commit sha 9a8eb5db55964c2fc7aca0db5939d8300badc9ab

test/ptrace/scescx.c: fix printing of braces for syscalls without args Also do not print stray closing brace for error condition. Sponsored by: The FreeBSD Foundation MFC after: 3 days

view details

Warner Losh

commit sha 7cf62c68c0f48c44e3fcb098d0406f417c1f488b

nanobsd: Provide empty routines for new embedded scheme calculate_partitioning and create_code_slice are now required in nanobsd.sh. While things work with the ones provided by legacy.sh, it's fighting embedded/common's other actions. Instead, replace them with stubs. Sponsored by: Netflix

view details

Ed Maste

commit sha adb56e58e8db84d8087ebe3d3e7def0074cb5a90

openssh: use global state for blacklist in grace_alarm_handler Obtained from: security/openssh-portable Fixes: 19261079b743 ("openssh: update to OpenSSH v8.7p1") Sponsored by: The FreeBSD Foundation

view details

Colin Percival

commit sha 0aa2a94ea6359fb2587af81841fbf8eb30ab36b0

EC2: Allow AMI boot mode to be specified The default boot method for amd64 AMIs is BIOS, but at AMI creation time a flag can be set to specify that UEFI should be used instead. This commit adds a variable AMIBOOTMETHOD which, if set to "UEFI", causes the appropriate flag to be set during AMI creation. The only boot method supported by EC2 for arm64 is UEFI. The names of AMIs are also amended to include the boot method; they now look like "FreeBSD 14.0-CURRENT-amd64-20210915 UEFI". MFC after: 1 week Sponsored by: https://www.patreon.com/cperciva

view details

Colin Percival

commit sha b43d7aa09b3c91fb6b652306db2ac13e1459c497

EC2: Default to UEFI booting This reduces the FreeBSD boot time by approximately 5 seconds, roughly equally divided betwenn two factors: * Disk I/O is faster in the EFI loader since it can perform larger I/Os. (The BIOS loader is limited due to the use of bounce buffers in sub-1M memory.) * The EFI console is much faster than the VGA console. Note however that not all EC2 instance types support UEFI; as a general rule the newer instances (based on Amazon's "Nitro" platform) support UEFI but the older instances (based on Xen) do not. X-MFC: TBD based on tradeoff between performance and compatibility Relnotes: yes Sponsored by: https://www.patreon.com/cperciva

view details

Mike Karels

commit sha fd0765933c3ccb059ad7456e657b2e8ed22f58b0

Change lowest address on subnet (host 0) not to broadcast by default. The address with a host part of all zeros was used as a broadcast long ago, but the default has been all ones since 4.3BSD and RFC1122. Until now, we would broadcast the host zero address as well as the configured address. Change to not broadcasting that address by default, but add a sysctl (net.inet.ip.broadcast_lowest) to re-enable it. Note that the correct way to use the zero address for broadcast would be to configure it as the broadcast address for the network. See https:/datatracker.ietf.org/doc/draft-schoen-intarea-lowest-address/ and the discussion in https://reviews.freebsd.org/D19316. Note, Linux now implements this. Reviewed by: rgrimes, tuexen; melifaro (previous version) MFC after: 1 month Relnotes: yes Differential Revision: https://reviews.freebsd.org/D31861

view details

Konstantin Belousov

commit sha 1349891a0eed79625faafa5ad354d65ff9ea6012

Style Reviewed by: brooks, emaste, markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D31779

view details

Konstantin Belousov

commit sha 796a8e1ad1ae3f7b8e4c9f97bebbef5d7d5a2c16

procctl(2): Add PROC_WXMAP_CTL/STATUS It allows to override kern.elf{32,64}.allow_wx on per-process basis. In particular, it makes it possible to run binaries without PT_GNU_STACK and without elfctl note while allow_wx = 0. Reviewed by: brooks, emaste, markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D31779

view details

Konstantin Belousov

commit sha ac8af1938085dae0df32db3229c9d5cb659b90a4

proccontrol(1): Add wxmap control Reviewed by: brooks, emaste, markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D31779

view details

Ed Maste

commit sha f161abf9f2cd7fdd28543f9774de82c89675477c

readelf: include notes (-n) and unwind (-u) in --all/-a This matches the GNU and LLVM versions of readelf. As markj noted in the review -u is not actually implemented yet and has no effect. The option is accepted and just ignored. Reported by: andrew Reviewed by: andrew, markj MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32003

view details

Ed Maste

commit sha deef4b8ce8ba7292fe5088bf9f6d4e2e35662fe8

readelf: document that -u / --unwind is not yet implemented ELF tool chain readelf accepts -u / --unwind but just ignores the option. This was previously undocumented, which could be confusing for someone encountering `readelf -u` (in a script or GNU readelf example). Reported by: markj (in D32003) MFC after: 1 week Sponsored by: The FreeBSD Foundation

view details

Mark Johnston

commit sha 7eb138a9e53636366e615bdf04062fedc044bcea

libc/locale: Fix races between localeconv(3) and setlocale(3) Each locale embeds a lazily initialized lconv which is populated by localeconv(3) and localeconv_l(3). When setlocale(3) updates the global locale, the lconv needs to be (lazily) reinitialized. To signal this, we set flag variables in the locale structure. There are two problems: - The flags are set before the locale is fully updated, so a concurrent localeconv() call can observe partially initialized locale data. - No barriers ensure that localeconv() observes a fully initialized locale if a flag is set. So, move the flag update appropriately, and use acq/rel barriers to provide some synchronization. Note that this is inadequate in the face of multiple concurrent calls to setlocale(3), but this is not expected to work regardless. Thanks to Henry Hu <henry.hu.sh@gmail.com> for providing a test case demonstrating the race. PR: 258360 MFC after: 3 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D31899

view details

John Baldwin

commit sha c6efcb1281f3518a92fdc579d2c3c3c74eb6070c

bhyve: Support setting the disk serial number for VirtIO block devices. Reviewed by: allanjude Obtained from: illumos Differential Revision: https://reviews.freebsd.org/D31983

view details

Konstantin Belousov

commit sha 197a4f29f39e6ae6215a6dbd28ef449d305e6d49

buffer pager: allow get_blksize method to return error Reported and reviewed by: asomers Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D31998

view details

Mark Johnston

commit sha 40fcdb9366d51400259020accaac9df212bd9508

kcov: Disable address and memory sanitizers in get_kinfo() get_kinfo() is only called from the coverage sanitizer callbacks, which are similarly uninstrumented. Sponsored by: The FreeBSD Foundation

view details

push time in 4 days

push eventemaste/freebsd

Jorgen Lundman

commit sha 3e8d5e4ff3a67fd3eb4d5d8af9370a5133e7dc4e

Add zpool_disable_datasets_os() / zfs_unmount_os() zpool_disable_datasets_os(): macOS needs to do a bunch of work to kick everything off zvols. zfs_unmount_os(): This allows us to unmount any zvols that may be mounted. Like with zfs destroy foo/vol Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: John Kennedy <john.kennedy@delphix.com> Signed-off-by: Jorgen Lundman <lundman@lundman.net> Closes #12436

view details

Ryan Moeller

commit sha c27c124a88b2a42e0d7b3bedd12197608122702b

ZTS: Remove exceptions for flaky zhack on FreeBSD Issue #11854 has been resolved, so we can remove the exceptions for it. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: John Kennedy <john.kennedy@delphix.com> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Ryan Moeller <ryan@iXsystems.com> Closes #12527

view details

Jorgen Lundman

commit sha 157a4d05bd732bdeb6f23158331dd683d89305cb

autoconf: allow Release to contain hyphen To avoid clashing with tags and releases, we'll use "zfs-macOS". Meta: 1 Name: zfs-macOS Reviewed-by: John Kennedy <john.kennedy@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Jorgen Lundman <lundman@lundman.net> Closes #12437

view details

George Melikov

commit sha a9655fc2bd1f83f1b305ff7ed16f698b87834e73

Check for libabigail version We need to use 1.8.0+ version, older versions may segfault and give inconsistent results. Reviewed-by: John Kennedy <john.kennedy@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: George Melikov <mail@gmelikov.ru> Closes #12529

view details

George Melikov

commit sha d510924520dd23d43511e2594183d59e20fffc2b

CI: use fresh libabigail via docker image Reviewed-by: John Kennedy <john.kennedy@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: George Melikov <mail@gmelikov.ru> Closes #12529

view details

George Melikov

commit sha 1aaebea2f58743b8d4b1bd7ec4b3b41d52cec30b

Libabigail: make .abi files more consistent Reviewed-by: John Kennedy <john.kennedy@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: George Melikov <mail@gmelikov.ru> Closes #12529

view details

George Melikov

commit sha 6ea058da16cc1ddaea44d8d74afa8a8966677662

Update ABI files via new libabigail version Reviewed-by: John Kennedy <john.kennedy@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: George Melikov <mail@gmelikov.ru> Closes #12529

view details

George Melikov

commit sha 3eb3e4d14cf008045b79afbbe9d24812d56917be

CI: don't install abigail-tools We use docker image instead. Reviewed-by: John Kennedy <john.kennedy@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: George Melikov <mail@gmelikov.ru> Closes #12529

view details

Don Brady

commit sha ab15b1fc0e713e3fe91cc5e1eaf414b377b8108e

Detect iSCSI in the zpool cmd vdev media script Reviewed-by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Tony Nguyen <tony.nguyen@delphix.com> Signed-off-by: Don Brady <don.brady@delphix.com> Closes #12206

view details

Brian Behlendorf

commit sha f6166058219707ca379064a4529ae4ce87e4e64f

Linux 5.15 compat: block device readahead The 5.15 kernel moved the backing_dev_info structure out of the request queue structure which causes a build failure. Rather than look in the new location for the BDI we instead detect this upstream refactoring by the existance of either the blk_queue_update_readahead() or disk_update_readahead() functions. In either case, there's no longer any reason to manually set the ra_pages value since it will be overridden with a reasonable default (2x the block size) when blk_queue_io_opt() is called. Therefore, we update the compatibility wrapper to do nothing for 5.9 and newer kernels. While it's tempting to do the same for older kernels we want to keep the compatibility code to preserve the existing behavior. Removing it would effectively increase the default readahead to 128k. Reviewed-by: Tony Nguyen <tony.nguyen@delphix.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #12532

view details

Alexander

commit sha a3588c68f7026c49291a7ec92a78c69b22e15df1

Linux 5.15 compat: standalone <linux/stdarg.h> Kernel commits 39f75da7bcc8 ("isystem: trim/fixup stdarg.h and other headers") c0891ac15f04 ("isystem: ship and use stdarg.h") 564f963eabd1 ("isystem: delete global -isystem compile option") (for now can be found in linux-next.git tree, will land into the Linus' tree during the ongoing 5.15 cycle with one of akpm merges) removed the -isystem flag and disallowed the inclusion of any compiler header files. They also introduced a minimal <linux/stdarg.h> as a replacement for <stdarg.h>. include/os/linux/spl/sys/cmn_err.h in the ZFS source tree includes <stdarg.h> unconditionally. Introduce a test for <linux/stdarg.h> and include it instead of the compiler's one to prevent module build breakage. Reviewed-by: Tony Nguyen <tony.nguyen@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Alexander Lobakin <alobakin@pm.me> Closes #12531

view details

Paul Dagnelie

commit sha c634320e51df32095bb0ed7b2a74089e24a850c7

Compressed receive with different ashift can result in incorrect PSIZE on disk We round up the psize to the nearest multiple of the asize or to the lsize, whichever is smaller. Once that's done, we allocate a new buffer of the appropriate size, zero the tail, and copy the data into it. This adds a small performance cost to these kinds of writes, but fixes the bookkeeping problems. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Matthew Ahrens <mahrens@delphix.com> Co-authored-by: Matthew Ahrens <matthew.ahrens@delphix.com> Signed-off-by: Paul Dagnelie <pcd@delphix.com> Closes #12522 Closes #8462

view details

Jorgen Lundman

commit sha 49d8a99a4d6579a61b04c4b05f732fab26b09d30

Upstream: zdb inode mapping Unfortunately macOS reserves inode ID numbers 0-15, and we can not used them. In macOS port we simply map them really high IDs. Normally this is hidden inside the _os implementation, but this is the one place in the common source files. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Jorgen Lundman <lundman@lundman.net> Closes #12530

view details

Rich Ercolani

commit sha 7676ffc51f5e4963c7e7f9971561f483dcd65976

arc: Drop an incorrect assert Unfortunately, there was an overzealous assertion that was (in pretty specific circumstances) false, causing failure. This assertion was added in error, so we're removing it. Reviewed-by: Matthew Ahrens <mahrens@delphix.com> Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rich Ercolani <rincebrain@gmail.com> Closes #9897 Closes #12020 Closes #12246

view details

Allan Jude

commit sha a68e4b5919dc5e7f53762d37adcc711174e1e936

Allow sending corrupt snapshots even if metadata is corrupted When zfs_send_corrupt_data is set, use the TRAVERSE_HARD flag, so traverse_visitbp() will not fail with ECKSUM if a blockpointer cannot be read, but rather will continue and send the objects it can. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: John Kennedy <john.kennedy@delphix.com> Signed-off-by: Allan Jude <allan@klarasystems.com> Sponsored-By: Klara Inc. Sponsored-By: WHC Online Solutions Inc. Closes #12541

view details

Brian Behlendorf

commit sha 2079111f42a90b123f484337b43a549b7c5e50ba

Linux 5.15 compat: get_acl() Kernel commits 332f606b32b6 ovl: enable RCU'd ->get_acl() 0cad6246621b vfs: add rcu argument to ->get_acl() callback Added compatibility code to detect the new ->get_acl() interface and correctly handle the case where the new rcu argument is set. Reviewed-by: Coleman Kane <ckane@colemankane.org> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #12548

view details

Jorgen Lundman

commit sha 5a54a4e0517959dd917c0f78d692f7364e597a68

Upstream: Add snapshot and zvol events For kernel to send snapshot mount/unmount events to zed. For kernel to send symlink creates/removes on zvol plumbing. (/dev/run/dsk/zvol/$pool/$zvol -> /dev/diskX) If zed misses the ENODEV, all errors after are EINVAL. Treat any error as kernel module failure. Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Jorgen Lundman <lundman@lundman.net> Closes #12416

view details

Brian Behlendorf

commit sha b9ec4a15e5ab40e6c32dd445ecebcd3a3fed1ef9

Verify embedded blkptr's in arc_read() The block pointer verification check in arc_read() should also cover embedded block pointers. While highly unlikely, accessing a damaged block pointer can result in panic. To further harden the code extend the existing check to include embedded block pointers and add a comment explaining the rational for this sanity check. Lastly, correct a flaw in zfs_blkptr_verify() so the error count is checked even when checking a untrusted config to verify the non-pool-specific portions of a block pointer. Reviewed-by: Matthew Ahrens <mahrens@delphix.com> Reviewed-by: Tony Nguyen <tony.nguyen@delphix.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #12535

view details

Brian Behlendorf

commit sha 695d4ae81551ef4122c47fce8bb58d1721c0abdd

ZTS: Waiting for zvols to be available This is a follow up patch for PR #12515 which addresses some additional ZTS tests which are unreliable are should explicitly wait for the required zvols to be available. Reviewed-by: John Kennedy <john.kennedy@delphix.com> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Reviewed-by: @Theo13111 Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #12553

view details

Arun KV

commit sha f82f0279ed588505c16a9026786ba966dbc5f0ee

Fixed data integrity issue when underlying disk returns error Errors in zil_lwb_write_done() are not propagated to zil_lwb_flush_vdevs_done() which can result in zil_commit_impl() not returning an error to applications even when zfs was not able to write data to the disk. Remove the ZIO_FLAG_DONT_PROPAGATE flag from zio_rewrite() to allow errors to propagate and consolidate the error handling for flush and write errors to a single location (rather than having error handling split between the "write done" and "flush done" handlers). Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Prakash Surya <prakash.surya@delphix.com> Signed-off-by: Arun KV <arun.kv@datacore.com> Closes #12391 Closes #12443

view details

push time in 4 days

push eventemaste/libcbor

Ed Maste

commit sha b48eac0950df6232b0b38141ef13a8736925e767

run tests in build dir

view details

push time in 6 days

fork emaste/tinycbor

Concise Binary Object Representation (CBOR) Library

fork in 6 days

push eventemaste/libcbor

Ed Maste

commit sha 7d8cbeccb7312f26d936c2ad0e3a002c166051e7

add missing space

view details

push time in 6 days