Configure Mend for GitHub.com #58
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![mend-for-github-com[bot]](https://avatars.githubusercontent.com/in/30796?s=60&v=4){kind=small}
BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Philip Cox <[email protected]>
Ignore: yes Signed-off-by: Philip Cox <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2059637 Properties: no-test-build Signed-off-by: Philip Cox <[email protected]>
Signed-off-by: Philip Cox <[email protected]>
Ignore: yes Signed-off-by: Roxana Nicolescu <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2061451 Properties: no-test-build Signed-off-by: Roxana Nicolescu <[email protected]>
Signed-off-by: Roxana Nicolescu <[email protected]>
Ignore: yes Signed-off-by: Stefan Bader <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2061762 Properties: no-test-build Signed-off-by: Stefan Bader <[email protected]>
Signed-off-by: Stefan Bader <[email protected]>
Ignore: yes Signed-off-by: Philip Cox <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2063584 Properties: no-test-build Signed-off-by: Philip Cox <[email protected]>
Signed-off-by: Philip Cox <[email protected]>
…oured BugLink: https://bugs.launchpad.net/bugs/2060992 Theoretically, when the hardware signature in FACS changes, the OS is supposed to gracefully decline to attempt to resume from S4: "If the signature has changed, OSPM will not restore the system context and can boot from scratch" In practice, Windows doesn't do this and many laptop vendors do allow the signature to change especially when docking/undocking, so it would be a bad idea to simply comply with the specification by default in the general case. However, there are use cases where we do want the compliant behaviour and we know it's safe. Specifically, when resuming virtual machines where we know the hypervisor has changed sufficiently that resume will fail. We really want to be able to *tell* the guest kernel not to try, so it boots cleanly and doesn't just crash. This patch provides a way to opt in to the spec-compliant behaviour on the command line. A follow-up patch may do this automatically for certain "known good" machines based on a DMI match, or perhaps just for all hypervisor guests since there's no good reason a hypervisor would change the hardware_signature that it exposes to guests *unless* it wants them to obey the ACPI specification. Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> (cherry picked from commit 74d9555) (backported from commit 9bb5343dc480ac00683d8d8e982cbef124ec32a3 from git.infradead.org/users/dwmw2/linux.git/psci-hibernate-5.15 [calling conventions in acpi_sleep_setup adjusted]) Signed-off-by: Philip Cox <[email protected]> Acked-by: John Cabaj <[email protected]> Acked-by: Tim Gardner <[email protected]>
…lt for virtual guests BugLink: https://bugs.launchpad.net/bugs/2060992 The ACPI specification says that OSPM should refuse to restore from hibernate if the hardware signature changes, and should boot from scratch. However, real BIOSes often vary the hardware signature in cases where we *do* want to resume from hibernate, so Linux doesn't follow the spec by default. However, in a virtual environment there's no reason for the VMM to vary the hardware signature *unless* it wants to trigger a clean reboot as defined by the ACPI spec. So enable the check by default if a hypervisor is detected. Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> (cherry picked from commit f6c46b1) (cherry picked from commit 2df47eeda338958ae18cfdd798d6b5ad5b8df316 from git.infradead.org/users/dwmw2/linux.git/psci-hibernate-5.15) Signed-off-by: Philip Cox <[email protected]> Acked-by: John Cabaj <[email protected]> Acked-by: Tim Gardner <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2060992 ACPICA commit 44fc328a1a14b097d92b8be83989e4bf69b6e6cb The FACS is optional even on hardware reduced platforms, and may exist for the purpose of communicating the hardware_signature field to provoke a clean reboot instead of a resume from hibernation. Signed-off-by: David Woodhouse <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit c943f8287704322340e1df02005bb79164416cdd from git.infradead.org/users/dwmw2/linux.git/psci-hibernate-5.15) Signed-off-by: Philip Cox <[email protected]> Acked-by: John Cabaj <[email protected]> Acked-by: Tim Gardner <[email protected]>
…if it exists BugLink: https://bugs.launchpad.net/bugs/2060992 If the firmware_signature changes then OSPM should not attempt to resume from hibernate, but should instead perform a clean reboot. Set the global swsusp_hardware_signature to allow the generic code to include the value in the swsusp header on disk, and perform the appropriate check on resume. Signed-off-by: David Woodhouse <[email protected]> Acked-by: Sudeep Holla <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit 1524bcae1ef7e3889214ebfb56dbae389fb20eb9 from git.infradead.org/users/dwmw2/linux.git/psci-hibernate-5.15) Signed-off-by: Philip Cox <[email protected]> Acked-by: John Cabaj <[email protected]> Acked-by: Tim Gardner <[email protected]>
…tion (ALPHA) BugLink: https://bugs.launchpad.net/bugs/2060992 The v1.3 PSCI spec (https://developer.arm.com/documentation/den0022) adds SYSTEM_OFF2, CLEAN_INV_MEMREGION and CLEAN_INV_MEMREGION_ATTRIBUTES functions. Add definitions for them and their parameters, along with the new TIMEOUT, RATE_LIMITED and BUSY error values. [5.15 backport: Include interim updates] Signed-off-by: David Woodhouse <[email protected]> (cherry picked from commit 02b78cb50e9727e601cfd941e0ce6a6d651466f8 from git.infradead.org/users/dwmw2/linux.git/psci-hibernate-5.15) Signed-off-by: Philip Cox <[email protected]> Acked-by: John Cabaj <[email protected]> Acked-by: Tim Gardner <[email protected]>
…rnate BugLink: https://bugs.launchpad.net/bugs/2060992 The PSCI v1.3 specification (alpha) adds support for a SYSTEM_OFF2 function which is analogous to ACPI S4 state. This will allow hosting environments to determine that a guest is hibernated rather than just powered off, and handle that state appropriately on subsequent launches. Since commit 60c0d45 ("efi/arm64: use UEFI for system reset and poweroff") the EFI shutdown method is deliberately preferred over PSCI or other methods. So register a SYS_OFF_MODE_POWER_OFF handler which *only* handles the hibernation, leaving the original PSCI SYSTEM_OFF as a last resort via the legacy pm_power_off function pointer. The hibernation code already exports a system_entering_hibernation() function which is be used by the higher-priority handler to check for hibernation. That existing function just returns the value of a static boolean variable from hibernate.c, which was previously only set in the hibernation_platform_enter() code path. Set the same flag in the simpler code path around the call to kernel_power_off() too. An alternative way to hook SYSTEM_OFF2 into the hibernation code would be to register a platform_hibernation_ops structure with an ->enter() method which makes the new SYSTEM_OFF2 call. But that would have the unwanted side-effect of making hibernation take a completely different code path in hibernation_platform_enter(), invoking a lot of special dpm callbacks. Another option might be to add a new SYS_OFF_MODE_HIBERNATE mode, with fallback to SYS_OFF_MODE_POWER_OFF. Or to use the sys_off_data to indicate whether the power off is for hibernation. But this version works and is relatively simple. [5.15: Override pm_power_off() like EFI does (and *after* EFI does).] Signed-off-by: David Woodhouse <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> (cherry picked from commit 8f8110f55c1aaab1685525c314c260fe755dfa47 from git.infradead.org/users/dwmw2/linux.git/psci-hibernate-5.15) Signed-off-by: Philip Cox <[email protected]> Acked-by: John Cabaj <[email protected]> Acked-by: Tim Gardner <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2060992 Signed-off-by: Philip Cox <[email protected]> Acked-by: John Cabaj <[email protected]> Acked-by: Tim Gardner <[email protected]>
Ignore: yes Signed-off-by: Philip Cox <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2063712 Properties: no-test-build Signed-off-by: Philip Cox <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2060992 Signed-off-by: Philip Cox <[email protected]>
Signed-off-by: Philip Cox <[email protected]>
Ignore: yes Signed-off-by: Philip Cox <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2068191 Properties: no-test-build Signed-off-by: Philip Cox <[email protected]>
Signed-off-by: Philip Cox <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2069352 A large part of the kernel boot time is creating the kernel linear map page tables. When rodata=full, all memory is mapped by pte. And when there is lots of physical ram, there are lots of pte tables to populate. The primary cost associated with this is mapping and unmapping the pte table memory in the fixmap; at unmap time, the TLB entry must be invalidated and this is expensive. Previously, each pmd and pte table was fixmapped/fixunmapped for each cont(pte|pmd) block of mappings (16 entries with 4K granule). This means we ended up issuing 32 TLBIs per (pmd|pte) table during the population phase. Let's fix that, and fixmap/fixunmap each page once per population, for a saving of 31 TLBIs per (pmd|pte) table. This gives a significant boot speedup. Execution time of map_mem(), which creates the kernel linear map page tables, was measured on different machines with different RAM configs: | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra | VM, 16G | VM, 64G | VM, 256G | Metal, 512G ---------------|-------------|-------------|-------------|------------- | ms (%) | ms (%) | ms (%) | ms (%) ---------------|-------------|-------------|-------------|------------- before | 168 (0%) | 2198 (0%) | 8644 (0%) | 17447 (0%) after | 78 (-53%) | 435 (-80%) | 1723 (-80%) | 3779 (-78%) Signed-off-by: Ryan Roberts <[email protected]> Tested-by: Itaru Kitayama <[email protected]> Tested-by: Eric Chanudet <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit 5c63db59c5f89925add57642be4f789d0d671ccd) Signed-off-by: Philip Cox <[email protected]> Acked-by: Manuel Diewald <manuel.diewald at canonical.com> Acked-by: Thibault Ferrante <thibault.ferrante at canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2069352 After removing uneccessary TLBIs, the next bottleneck when creating the page tables for the linear map is DSB and ISB, which were previously issued per-pte in __set_pte(). Since we are writing multiple ptes in a given pte table, we can elide these barriers and insert them once we have finished writing to the table. Execution time of map_mem(), which creates the kernel linear map page tables, was measured on different machines with different RAM configs: | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra | VM, 16G | VM, 64G | VM, 256G | Metal, 512G ---------------|-------------|-------------|-------------|------------- | ms (%) | ms (%) | ms (%) | ms (%) ---------------|-------------|-------------|-------------|------------- before | 78 (0%) | 435 (0%) | 1723 (0%) | 3779 (0%) after | 11 (-86%) | 161 (-63%) | 656 (-62%) | 1654 (-56%) Signed-off-by: Ryan Roberts <[email protected]> Tested-by: Itaru Kitayama <[email protected]> Tested-by: Eric Chanudet <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> (backported from commit 1fcb7cea8a5f7747e02230f816c2c80b060d9517 [context changes in init_pte(), replaced __set_pte() with set_pte()]) Signed-off-by: Philip Cox <[email protected]> Acked-by: Manuel Diewald <manuel.diewald at canonical.com> Acked-by: Thibault Ferrante <thibault.ferrante at canonical.com>
Ignore: yes Signed-off-by: Philip Cox <[email protected]>
Ignore: yes Signed-off-by: Roxana Nicolescu <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2078103 Properties: no-test-build Signed-off-by: Roxana Nicolescu <[email protected]>
Signed-off-by: Roxana Nicolescu <[email protected]>
Ignore: yes Signed-off-by: Philip Cox <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082123 Properties: no-test-build Signed-off-by: Philip Cox <[email protected]>
Signed-off-by: Philip Cox <[email protected]>
Ignore: yes Signed-off-by: Philip Cox <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082951 Properties: no-test-build Signed-off-by: Philip Cox <[email protected]>
Signed-off-by: Philip Cox <[email protected]>
This is a placeholder commit to separate the Ubuntu kernel source and our patches. Used by kernel_merge_with_upstream() in the linux-pkg repo.
…rs absent in kernel (#37) PR URL: https://www.github.com/delphix/linux-kernel-aws/pull/37
) Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Bogdanov <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Co-authored-by: Dmitry Bogdanov <[email protected]>
delphix-devops-bot
force-pushed
the
develop
branch
from
c48e503 to
80644de
Compare
|
Hi @sebroy , |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Welcome to Mend for GitHub.com (formerly WhiteSource). This is an onboarding PR to help you understand and configure settings before Mend starts scanning your repository for security vulnerabilities.
🚦 Mend for GitHub.com will start scanning your repository only once you merge this Pull Request. To disable Mend for GitHub.com, simply close this Pull Request.
What to Expect
This PR contains a '.whitesource' configuration file which can be customized to your needs. If no changes were applied to this file, Mend for GitHub.com will use the default configuration.
Before merging this PR, Make sure the Issues tab is enabled. Once you merge this PR, Mend for GitHub.com will scan your repository and create a GitHub Issue for every vulnerability detected in your repository.
If you do not want a GitHub Issue to be created for each detected vulnerability, you can edit the '.whitesource' file and set the 'minSeverityLevel' parameter to 'NONE'.
If Mend Remediate Workflow Rules are set on your repository (from the Mend 'Integrate' tab), Mend will also generate a fix Pull Request for relevant vulnerabilities.
❓ Got questions? Check out Mend for GitHub.com docs.
If you need any further assistance then you can also request help here.