Juerg Haefliger [Mon, 1 Nov 2021 09:16:14 +0000 (10:16 +0100)]
UBUNTU: [Packaging] Replace Perl oneliner with Bash statements
Replace the only Perl oneliner in the Ubuntu Makefiles with Bash
statements. This brings us one step closer to dropping Perl as a build
dependency for the Ubuntu kernel.
Signed-off-by: Juerg Haefliger <juergh@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andrea Righi [Wed, 27 Oct 2021 06:07:39 +0000 (08:07 +0200)]
Revert "UBUNTU: SAUCE: cachefiles: Page leaking in cachefiles_read_backing_file while vmscan is active"
BugLink: https://bugs.launchpad.net/bugs/1947709
This SAUCE patch has been applied to fix a page leaking issue. However a
slightly different fix has been applied upstream:
9a24ce5b66f9 ("cachefiles: Fix page leak in cachefiles_read_backing_file while vmscan is active")
In practice we are fixing the same issue in two different ways at the
same time, but, even worse, our patch introduces a potential NULL
pointer dereference: we do a put_page(newpage) and set newpage = NULL in
the main for() loop and then we may do additional put_page(newpage)
after the main for loop if ret == -EEXIST, that would trigger the NULL
pointer dereference.
Revert the SAUCE patch and rely on the upstream fix.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
With commit 27d53323664c54 "l2tp: remove skb_dst_set() from
l2tp_xmit_skb()" landed in our kernel and l2tp.sh test re-enabled in
our test suite [1], we can now revert this SAUCE patch to get l2tp.sh
tested.
UBUNTU: [Packaging] Add fips-checks as part of finalchecks
BugLink: https://bugs.launchpad.net/bugs/1945989
Call fips-checks as part of the debian target "finalchecks". That will
ensure the checks are executed during build and during cranky close.
Kernels need to enable this check via do_fips_checks.
Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
UBUNTU: [Packaging] Add system trusted and revocation keys final check
BugLink: https://bugs.launchpad.net/bugs/1947174
If certificates are packaged, the config keys to use them must be
enabled otherwise boot testing will fail. This check ensures early
detection of incorrect configuration when rebasing derivative kernels.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Juerg Haefliger [Wed, 20 Oct 2021 13:05:03 +0000 (15:05 +0200)]
UBUNTU: [Debian] Remove old and unused firmware helper scripts
There are scripts in the kernel tree that supposedly help with managing
firmware files/blobs but they haven't been used nor needed in ages so get
rid of them.
Signed-off-by: Juerg Haefliger <juergh@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Kai-Heng Feng [Mon, 11 Oct 2021 04:16:26 +0000 (12:16 +0800)]
r8169: Implement dynamic ASPM mechanism
BugLink: https://bugs.launchpad.net/bugs/1946433
r8169 NICs on some platforms have abysmal speed when ASPM is enabled.
Same issue can be observed with older vendor drivers.
The issue is however solved by the latest vendor driver. There's a new
mechanism, which disables r8169's internal ASPM when the NIC traffic has
more than 10 packets per second, and vice versa. The possible reason for
this is likely because the buffer on the chip is too small for its ASPM
exit latency.
Realtek confirmed that all their PCIe LAN NICs, r8106, r8168 and r8125
use dynamic ASPM under Windows. So implement the same mechanism here to
resolve the issue.
Also introduce a lock to prevent race on accessing config registers.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=214307 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
(cherry picked from
https://patchwork.ozlabs.org/project/linux-pci/patch/20211007161552.272771-4-kai.heng.feng@canonical.com/) Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Kai-Heng Feng [Mon, 11 Oct 2021 04:16:25 +0000 (12:16 +0800)]
r8169: Enable chip-specific ASPM regardless of PCIe ASPM status
BugLink: https://bugs.launchpad.net/bugs/1946433
To really enable ASPM on r8169 NICs, both standard PCIe ASPM and
chip-specific ASPM have to be enabled at the same time.
Since PCIe ASPM can be enabled or disabled vis sysfs and there's no
mechanism to notify driver about ASPM change, unconditionally enable
chip-specific ASPM to make ASPM really take into effect.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
(cherry picked from
https://patchwork.ozlabs.org/project/linux-pci/patch/20211007161552.272771-3-kai.heng.feng@canonical.com/) Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Yang Li [Mon, 25 Oct 2021 11:44:12 +0000 (19:44 +0800)]
rtw89: remove unneeded semicolon
BugLink: https://bugs.launchpad.net/bugs/1945967
Eliminate the following coccicheck warning:
./drivers/net/wireless/realtek/rtw89/pci.c:1348:2-3: Unneeded semicolon
Reported-by: Abaci Robot <abaci@linux.alibaba.com> Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634630094-1156-1-git-send-email-yang.lee@linux.alibaba.com
(cherry picked from commit e0e037b9fe5fbd19b21c0e542e44dd65f1b8cf58 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Colin Ian King [Mon, 25 Oct 2021 11:44:10 +0000 (19:44 +0800)]
rtw89: Remove redundant check of ret after call to rtw89_mac_enable_bb_rf
BugLink: https://bugs.launchpad.net/bugs/1945967
The function rtw89_mac_enable_bb_rf is a void return type, so there is
no return error code to ret, so the following check for an error in ret
is redundant dead code and can be removed.
Addresses-Coverity: ("Logically dead code") Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211015152113.33179-1-colin.king@canonical.com
(cherry picked from commit f7e7e440550b0b176df3d2ea3e76106bc89915d9 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Ping-Ke Shih [Mon, 25 Oct 2021 11:44:09 +0000 (19:44 +0800)]
rtw89: add Realtek 802.11ax driver
BugLink: https://bugs.launchpad.net/bugs/1945967
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
(cherry picked from commit e3ec7017f6a20d12ddd9fe23d345ebb7b8c104dd linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Ville Syrjälä [Tue, 28 Sep 2021 18:51:05 +0000 (21:51 +0300)]
drm/i915: Stop force enabling pipe bottom color gammma/csc
BugLink: https://bugs.launchpad.net/bugs/1945932
While sanitizing the hardware state we're currently forcing
the pipe bottom color legacy csc/gamma bits on. That is not a
good idea as BIOSen are likely to leave gabage in the LUTs and
so doing this causes ugly visual glitches if and when the
planes covering the background get disabled. This was exactly
the case on this Dell Precision 5560 tgl laptop.
On icl+ we don't normally even use these legacy bits
anymore and instead use their GAMMA_MODE counterparts.
On earlier platforms the bits are used, but we still
shouldn't force them on without knowing what's in the LUT.
So two options, get rid of the whole thing, or do what
intel_color_commit() does to make sure the bottom color state
matches whatever out hardware readout produced. I chose the
latter since it'll match what happens on older platforms when
the primary plane gets turned off. In fact let's just call
intel_color_commit(). It'll also do some CSC programming but
since we don't have readout for that it'll actually just set
to all zeros. So in the unlikely case of CSC actually being
enabld by the BIOS we'll end up with all black until the first
atomic commit happens.
Still not totally sure what we should do about color management
features here in general. Probably the safest thing would be to
force everything off exactly at the same time when we disable
the primary plane as there is no guarantees that whatever the
LUTs/CSCs contain make any sense whatsoever without the
specific pixel data in the BIOS fb. And if we preserve the
primary plane then we should disable the color management
features exactly when the primary plane fb contents first
changes since the new content assumes more or less no
transformations. But of course synchronizing front buffer
rendering with anything else is a bit hard...
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3534 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210928185105.3030-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
(cherry picked from commit f22f4e5be89c4296d76eaa9ba83dda46bdf11134 linux-next) Signed-off-by: Koba Ko <koba.ko@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1948038
KFENCE devs are changing CONFIG_KFENCE_STATIC_KEYS to be disabled by
default, because it's introducing more problems than benefits:
This also seems to trigger QEMU bugs during the systemd autopkgtest, like:
https://bugs.launchpad.net/qemu/+bug/1920934
Even if this may introduce a small overhead in terms of performance it
seems safer to keep KFENCE_STATIC_KEYS disabled for now, and it is still
a better solution than disabling KFENCE completely.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Seth Forshee [Wed, 19 May 2021 15:21:20 +0000 (10:21 -0500)]
UBUNTU: [Config] Temporarily disable signing for ppc64el and s390x
We're awaiting testing of lockdown under secureboot on these
architectures. Disable signing in the meantime to allow putting
linux-unstable into -proposed.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Shrirang Bagul [Mon, 4 Oct 2021 05:57:51 +0000 (13:57 +0800)]
UBUNTU: [Config] update modules list
BugLink: https://bugs.launchpad.net/bugs/1945938 Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Shrirang Bagul [Mon, 4 Oct 2021 05:57:50 +0000 (13:57 +0800)]
UBUNTU: SAUCE: xr-usb-serial: remove driver
BugLink: https://bugs.launchpad.net/bugs/1945938
This custom driver was added in Xenial LTS kernel to add support for USB
UART chips:
Product Family: USB UART
Part Numbers:
XR21V1410, XR21V1412, XR21V1414,
XR21B1411, XR21B1420, XR21B1422,
XR21B1424, XR22801, XR22802,
XR22804
Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
This is used to re-enable ASPM on RTL8106e, if it is possible.
Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Andy Whitcroft [Wed, 1 Sep 2021 10:59:12 +0000 (11:59 +0100)]
UBUNTU: [Packaging] switch to kernel-versions
Switch to obtaining the DKMS package versions from the kernel-versions
dataset rather than from the archive. This allows it to be more
resilient against parallel update of those versions in the archive.
Replace the existing `update-versions-dkms` script with
`update-dkms-versions`. This change in name is deliberate as the new
script must be called at a different stage of the crank process, it must
follow the `cranky link-tb` stage to obtain the correct versions. See
the crank documentation for details.
BugLink: https://bugs.launchpad.net/bugs/1928921
Properties: no-test-build Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
UBUNTU: [Config] mark CONFIG_BPF_UNPRIV_DEFAULT_OFF enforced
Setting unprivileged_bpf_disabled to 2 by default will prevent attacks
using BPF by unprivileged users by default. If necessary, the sysadmin will
be able to turn this on again by setting unprivileged_bpf_disabled to 0. On
the other hand, the sysadmin can disable unprivileged BPF without allowing
it to be reenabled by setting unprivileged_bpf_disabled to 1.
Additionaly, there is a CAP_BPF that allows processes to use BPF without
having the complete capability set or CAP_SYS_ADMIN.
Mark the option as enforced so derivative kernels will pick it up.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Drop unused and unmaintained x32 architecture configs.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Juerg Haefliger <juergh@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
UBUNTU: [Packaging] remove remaining references to ports
Remove remaining few, unused, references to family=ports builds. Also
remove the maintainer targets to operate on ports.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Juerg Haefliger <juergh@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
UBUNTU: [Config] Enforce SYSTEM_TRUSTED_KEYS and SYSTEM_REVOCATION_KEYS
BugLink: https://bugs.launchpad.net/bugs/1932029
Enforce SYSTEM_TRUSTED_KEYS and SYSTEM_REVOCATION_KEYS on all
architectures, including riscv64. Note that TRUSTED and REVOCATION
keys files are dynamically generated and individual kernels may
add/revoke certificates specific to them, as needed. But all kernels
must trust & revoke a base set of certificates.
Note some kernel flavours don't enherit, or don't enforce all
annotation keys by default, hence enforcement of these options is
required.
Fixes: 503c7ca37e ("UBUNTU: [Config] Configure CONFIG_SYSTEM_REVOCATION_KEYS with revoked keys") Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Kunyang_Fan [Tue, 24 Aug 2021 07:26:59 +0000 (15:26 +0800)]
UBUNTU: ODM: mfd: Check AAEON BFPI version before adding device
BugLink: https://bugs.launchpad.net/bugs/1937897
For the below: error log occurring in some devices:
gpio gpiochip0: (gpio_aaeon): tried to insert a GPIO chip with zero lines
gpiochip_add_data_with_key: GPIOs 0..-1 (gpio_aaeon) failed to register
Add the BFPI version checking mechanism to prevent error log bumping.
Fixes: 424945128781 ("UBUNTU: ODM: mfd: Add support for IO functions of AAEON devices") Signed-off-by: Kunyang_Fan <kunyang_fan@asus.com> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1931725
Previously v5.13+ based kernels enabled ZSTD kernel image compression
on amd64 & s390x. Due to significant bootspeed impact this change
should be enforced for all derivatives as well. Not all derivatives
currently inherit and enforce all annotations from parent config.
Fixes: f88bdfaeaf ("UBUNTU: [Packaging] use ZSTD to compress s390 kernels") Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Kees Cook [Fri, 20 Aug 2021 07:10:02 +0000 (00:10 -0700)]
UBUNTU: [Config] Enable CONFIG_UBSAN_BOUNDS
This enables run-time array index bounds checking for arrays with
compile-time known sizes. This catches some potentially serious issues
at run-time with nearly zero performance impact. Syzkaller is still
catching bugs with this. (See "array-index-out-of-bounds" reports at
https://syzkaller.appspot.com/upstream)
Using UBSAN_TRAP=y has nearly no impact on image size, though it makes
caught conditions much less verbose.
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1914685 Signed-off-by: Kees Cook <kees@ubuntu.com>
[ disable CONFIG_UBSAN_SANITIZE_ALL on armhf - no arch support ] Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
CONFIG_HARDENED_USERCOPY_FALLBACK was designed to catch old out of tree
drivers doing bad things with CONFIG_HARDENED_USERCOPY, and weakens the
protection. It's been several years now; it's time to turn this off.
Kernel stack offset randomization is a useful security feature
that should be enabled. Benchmarking showed that the impact is
within the noise of various microbenchmarks so I believe this
has some added benefit with minimal performance impact. The
security folk believe this is worth enabling, so lets switch
it on.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
(cherry picked from commit 2ea2b647bcdd1baa0b2489e8420875121a39af39) Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Because the Realtek WiFi (PCI 06:00.0) is in the same IOMMU group as AMD
graphics (PCI 01:00.0),
[ 1.326166] pci 0000:01:00.0: Adding to iommu group 0
...
[ 1.326268] pci 0000:06:00.0: Adding to iommu group 0
And the AMD graphics supports iommu_v2, so the group uses intentity
mapping based on the query from amd_iommu_def_domain_type().
However, the Realtek WiFi only supports 32bit DMA, so we need to
make sure swiotlb is enabled.
The swiotlb is enabled by pci_swiotlb_detect_4gb() to support legacy
devices on highmen DMA, but it gets disabled later by
amd_iommu_init_dma_ops(). Keep swiotlb enabled to resolve the issue.
I am working on a more dynamic fix for upstream inclusion, but right now
lets keep swiotlb enabled like what Intel and ARM64 do.
You-Sheng Yang [Thu, 19 Aug 2021 06:14:26 +0000 (14:14 +0800)]
UBUNTU: [Config] Enable Cirrus Logic HDA bridge support
BugLink: https://bugs.launchpad.net/bugs/1939541 Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
projects / mirror_ubuntu-jammy-kernel.git / log