Seth Forshee [Fri, 5 Feb 2021 13:32:54 +0000 (07:32 -0600)]
UBUNTU: [Config] Set CONFIG_TMPFS_INODE64=n for s390x
Our testing turned up the following behavior on s390x with 5.9+:
# mount -t tmpfs nodev test
# mount -o remount,rw test
mount: /home/ubuntu/test: mount point not mounted or bad option.
# dmesg | tail -n2
[ 3597.759604] tmpfs: Cannot use inode64 with <64bit inums in kernel
This is because we have CONFIG_TMPFS_INODE64=y, but ino_t is only
32-bit on s390. tmpfs does not handle this situation well. It
sets the inode size to 64-bit on mount without checking the size
of ino_t. It then prints "inode64" in the mount options, so the
remount pases this option. At this point it does do a check of
the ino_t size, and refuses to mount.
Oddly, aside from the remount issue it doesn't appear that this
should cause any big problems. inode numbers might wrap, but
there's already logic in place to do that anyway for the inode32
mount option, and I can't see that the behavior will differ at
all. But upstream needs to handle this better, so let's disable
64-bit inodes in tmpfs for s390x until there's a fix.
Seth Forshee [Fri, 5 Feb 2021 18:10:37 +0000 (12:10 -0600)]
UBUNTU: SAUCE: tmpfs: Don't use 64-bit inodes by defulat with 32-bit ino_t
Currently there seems to be an assumption in tmpfs that 64-bit
architectures also have a 64-bit ino_t. This is not true; s390 at
least has a 32-bit ino_t. With CONFIG_TMPFS_INODE64=y tmpfs
mounts will get 64-bit inode numbers and display "inode64" in the
mount options, but passing the "inode64" mount option will fail.
This leads to the following behavior:
# mkdir mnt
# mount -t tmpfs nodev mnt
# mount -o remount,rw mnt
mount: /home/ubuntu/mnt: mount point not mounted or bad option.
As mount sees "inode64" in the mount options and thus passes it
in the options for the remount.
Ideally CONFIG_TMPFS_INODE64 would depend on sizeof(ino_t) < 8,
but I don't think it's possible to test for this (potentially
CONFIG_ARCH_HAS_64BIT_INO_T or similar could be added, but I'm
not sure whether or not that is wanted). So fix this by simply
refusing to honor the CONFIG_TMPFS_INODE64 setting when
sizeof(ino_t) < 8.
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>
(cherry picked from
https://patchwork.kernel.org/project/linux-input/patch/20210204083315.122952-1-vicamo.yang@canonical.com/) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Kai-Heng Feng [Thu, 4 Feb 2021 13:01:29 +0000 (21:01 +0800)]
r8169: Add support for another RTL8168FP
BugLink: https://bugs.launchpad.net/bugs/1914604
According to the vendor driver, the new chip with XID 0x54b is
essentially the same as the one with XID 0x54a, but it doesn't need the
firmware.
So add support accordingly.
(backported from commit e6d6ca6e12049dfbff6ac8b029678d2d2c55c34f linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andrea Righi [Thu, 14 Jan 2021 11:06:12 +0000 (12:06 +0100)]
UBUNTU: SAUCE: x86/entry: build thunk_$(BITS) only if CONFIG_PREEMPTION=y
With CONFIG_PREEMPTION disabled, arch/x86/entry/thunk_64.o is just an
empty object file.
With the newer binutils (tested with 2.35.90.20210113-1ubuntu1) the GNU
assembler doesn't generate a symbol table for empty object files and
objtool fails with the following error when a valid symbol table cannot
be found:
arch/x86/entry/thunk_64.o: warning: objtool: missing symbol table
To prevent this from happening, build thunk_$(BITS).o only if
CONFIG_PREEMPTION is enabled.
BugLink: https://bugs.launchpad.net/bugs/1911359 Fixes: 320100a5ffe5 ("x86/entry: Remove the TRACE_IRQS cruft") Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Seth Forshee [Fri, 29 Jan 2021 19:13:45 +0000 (13:13 -0600)]
UBUNTU: [Packaging] Don't disable CONFIG_DEBUG_INFO in headers packages
This config is enabled during the kernel build (though modules
are stripped), but we disable it in the config installed by our
headers packages so that dkms modules do not have debug
information. With 5.11 this is causing external modules to fail
to load, and the default behavior of dkms is to strip modules,
so it's unnecessary to disable CONFIG_DEBUG_INFO in the installed
config file. Stop disabling it so that external modules can load.
Chin-Yen Lee [Tue, 26 Jan 2021 07:49:26 +0000 (15:49 +0800)]
rtw88: reduce the log level for failure of tx report
BugLink: https://bugs.launchpad.net/bugs/1913263
Sometimes driver does not get tx report from firmware because wifi
environment is too noisy to get ack from AP about a TX frame,
or firmware is too busy to report driver in a estimated time.
But the condition will not affect wifi function or throughput.
So we reduce the log level to rtw_debug instead of scary backtrace.
Seth Forshee [Thu, 28 Jan 2021 15:30:09 +0000 (09:30 -0600)]
UBUNTU: SAUCE: selftests/seccomp: Accept any valid fd in user_notification_addfd
This test expects fds to have specific values, which works fine
when the test is run standalone. However, the kselftest runner
consumes a couple of extra fds for redirection when running
tests, so the test fails when run via kselftest.
Andy Whitcroft [Thu, 21 Jan 2021 12:07:46 +0000 (12:07 +0000)]
UBUNTU: [Packaging] nvidia -- use dkms-versions to define versions built
Currently each and every Nvidia version added or removed from
dkms-versions requires a pair of corresponding changes to debian/rules
and debian/rules.d/2-binary-arch.mk. Switch to using the listed versions
in debian/dkms-versions to generate the rules we need during build.
BugLink: https://bugs.launchpad.net/bugs/1912803 Acked-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1865402
ODM asks us to use get_display_mode command to confirm the scalar's
behavior, and Windows use this command, too.
To align the behavior with Windows, remove get_scalar_status command and
replace it with get_display_mode.
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Kai-Heng Feng [Thu, 21 Jan 2021 08:49:02 +0000 (16:49 +0800)]
thermal: intel: pch: Fix unexpected shutdown at critical temperature
BugLink: https://bugs.launchpad.net/bugs/1906168
Like previous patch, the intel_pch_thermal device is not in ACPI
ThermalZone namespace, so a critical trip doesn't mean shutdown.
Override the default .critical callback to prevent surprising thermal
shutdoown.
Kai-Heng Feng [Thu, 21 Jan 2021 08:49:01 +0000 (16:49 +0800)]
thermal: int340x: Fix unexpected shutdown at critical temperature
BugLink: https://bugs.launchpad.net/bugs/1906168
We are seeing thermal shutdown on Intel based mobile workstations, the
shutdown happens during the first trip handle in
thermal_zone_device_register():
kernel: thermal thermal_zone15: critical temperature reached (101 C), shutting down
However, we shouldn't do a thermal shutdown here, since
1) We may want to use a dedicated daemon, Intel's thermald in this case,
to handle thermal shutdown.
2) For ACPI based system, _CRT doesn't mean shutdown unless it's inside
ThermalZone namespace. ACPI Spec, 11.4.4 _CRT (Critical Temperature):
"... If this object it present under a device, the device’s driver
evaluates this object to determine the device’s critical cooling
temperature trip point. This value may then be used by the device’s
driver to program an internal device temperature sensor trip point."
So a "critical trip" here merely means we should take a more aggressive
cooling method.
As int340x device isn't present under ACPI ThermalZone, override the
default .critical callback to prevent surprising thermal shutdown.
Daniel Lezcano [Thu, 21 Jan 2021 08:48:58 +0000 (16:48 +0800)]
thermal/drivers/acpi: Use hot and critical ops
BugLink: https://bugs.launchpad.net/bugs/1906168
The acpi driver wants to do a netlink notification in case of a hot or
critical trip point. Implement the corresponding ops to be used for
the thermal zone and use them instead of the notify ops.
BugLink: https://bugs.launchpad.net/bugs/1910965
By default no functions are assigned to LEDs. It's up to user/distribution
to provide udev rules to configure them.
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
(backported from https://github.com/sifive/meta-sifive/blob/2020.11/recipes-kernel/linux/files/freedom-u540/0007-Add-PWM-LEDs-D1-D2-D3-D4.patch) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
Upstream-Status: Not posted for a review
(backported from https://github.com/sifive/meta-sifive/blob/2020.11/recipes-kernel/linux/files/freedom-u540/0004-SiFive-Unleashed-CPUFreq.patch) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
Upstream-Status: Inappropriate [enable feature]
(backported from https://github.com/sifive/meta-sifive/blob/2020.11/recipes-kernel/linux/files/freedom-u540/0002-Microsemi-PCIe-expansion-board-DT-entry.patch) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
PCI: microsemi: Add host driver for Microsemi PCIe controller
BugLink: https://bugs.launchpad.net/bugs/1910965
This patch adds support to the Microsemi/Microchip PolarFire
PCIe controller when configured in host (Root Complex) mode.
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
(backported from https://github.com/sifive/meta-sifive/blob/2020.11/recipes-kernel/linux/files/freedom-u540/0001-PCI-microsemi-Add-host-driver-for-Microsemi-PCIe-con.patch) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606896236-62780-5-git-send-email-yash.shah@sifive.com/) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606896236-62780-4-git-send-email-yash.shah@sifive.com/) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Yash Shah [Wed, 2 Dec 2020 08:03:54 +0000 (13:33 +0530)]
riscv: dts: add initial support for the SiFive FU740-C000 SoC
BugLink: https://bugs.launchpad.net/bugs/1910965
Add initial support for the SiFive FU540-C000 SoC. FU740-C000 is built
around the SiFIve U7 Core Complex and a TileLink interconnect.
This file is expected to grow as more device drivers are added to the
kernel.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606896236-62780-3-git-send-email-yash.shah@sifive.com/ Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Yash Shah [Wed, 2 Dec 2020 08:03:53 +0000 (13:33 +0530)]
dt-bindings: riscv: Update DT binding docs to support SiFive FU740 SoC
BugLink: https://bugs.launchpad.net/bugs/1910965
Add new compatible strings to the DT binding documents to support SiFive
FU740-C000. Also, add new compatible strings in cpus.yaml to support the
E71 and U74 CPU cores ("harts") that are present on FU740-C000 SoC.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606896236-62780-2-git-send-email-yash.shah@sifive.com/) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Yash Shah [Mon, 30 Nov 2020 05:43:04 +0000 (11:13 +0530)]
RISC-V: sifive_l2_cache: Update L2 cache driver to support SiFive FU740
BugLink: https://bugs.launchpad.net/bugs/1910965
SiFive FU740 has 4 ECC interrupt sources as compared to 3 in FU540.
Update the L2 cache controller driver to support this additional
interrupt in case of FU740-C000 chip.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606714984-16593-2-git-send-email-yash.shah@sifive.com) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Yash Shah [Mon, 30 Nov 2020 05:43:03 +0000 (11:13 +0530)]
RISC-V: Update l2 cache DT documentation to add support for SiFive FU740
BugLink: https://bugs.launchpad.net/bugs/1910965
The L2 cache controller in SiFive FU740 has 4 ECC interrupt sources as
compared to 3 in FU540. Update the DT documentation accordingly with
"compatible" and "interrupt" property changes.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606714984-16593-1-git-send-email-yash.shah@sifive.com) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
lib/decompress_unlz4.c: correctly handle zero-padding around initrds.
lz4 compatible decompressor is simple. The format is underspecified and
relies on EOF notification to determine when to stop. Initramfs buffer
format[1] explicitly states that it can have arbitrary number of zero
padding. Thus when operating without a fill function, be extra careful to
ensure that sizes less than 4, or apperantly empty chunksizes are treated
as EOF.
To test this I have created two cpio initrds, first a normal one,
main.cpio. And second one with just a single /test-file with content
"second" second.cpio. Then i compressed both of them with gzip, and with
lz4 -l. Then I created a padding of 4 bytes (dd if=/dev/zero of=pad4 bs=1
count=4). To create four testcase initrds:
The pad4 test-cases replicate the initrd load by grub, as it pads and
aligns every initrd it loads.
All of the above boot, however /test-file was not accessible in the initrd
for the testcase #4, as decoding in lz4 decompressor failed. Also an error
message printed which usually is harmless.
Whith a patched kernel, all of the above testcases now pass, and /test-file
is accessible.
This fixes lz4 initrd decompress warning on every boot with grub. And more
importantly this fixes inability to load multiple lz4 compressed initrds
with grub.
I guess I should convert above decompressor streams with/without padding
into kunit tests, across all decompressor algorithms.
Andrea Righi [Mon, 11 Jan 2021 07:41:29 +0000 (08:41 +0100)]
UBUNTU: [Config] update configs and annotations after rebase to 5.11-rc3
- Introduce CONFIG_NULL_TTY, enabling it as a module everywhere except
on s390x.
- ENABLE_MUST_CHECK has been removed by 196793946264 ("Compiler
Attributes: remove CONFIG_ENABLE_MUST_CHECK"), so let's also remove
it from the annotations file.
- Drop CONFIG_KVM_ARM_PMU from annotations file: 8cbebc4118b5 ("KVM:
arm64: Replace KVM_ARM_PMU with HW_PERF_EVENTS")
- Drop CONFIG_USB_FSL_USB2 from annotations file: a390bef7db1f ("usb:
gadget: fsl_mxc_udc: Remove the driver")
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andy Whitcroft [Fri, 15 May 2020 10:37:30 +0000 (11:37 +0100)]
UBUNTU: [Packaging] file-downloader not handling positive failures correctly
Seems we are not handling positive failures such as 404 correctly. Add
--fail to get server reported errors converted into errors.
BugLink: https://bugs.launchpad.net/bugs/1878897 Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
David Howells [Tue, 27 Feb 2018 10:04:55 +0000 (10:04 +0000)]
UBUNTU: SAUCE: (lockdown) efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode
UEFI machines can be booted in Secure Boot mode. Add an EFI_SECURE_BOOT
flag that can be passed to efi_enabled() to find out whether secure boot is
enabled.
Move the switch-statement in x86's setup_arch() that inteprets the
secure_boot boot parameter to generic code and set the bit there.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org
[Rebased for context; efi_is_table_address was moved to arch/x86] Signed-off-by: Jeremy Cline <jcline@redhat.com>
(cherry picked from commit a080e08b637d48dc9bdf4367447e47948f6d98b8
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Stefan Bader [Thu, 17 Dec 2020 13:57:24 +0000 (14:57 +0100)]
UBUNTU: [dep-8] Allow all hwe kernels
BugLink: https://bugs.launchpad.net/bugs/1908529
The dep-8 tests are limited to kernels which are bootable. But with
moving to versioned hwe kernels this would require constant change.
To avoid that, just allow any kernel source starting with linux-hwe.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1906370
The final shipment of OSN devices was as part of the IBM z13 hardware generation.
The primary exploiter was the IBM Communication Controller,
which was pulled out of marketing in March 2015 and should be out of service now.
Therefore, IBM pulls the support from all Linux distros going forward.
Hence the deactivation of the CONFIG_QETH_OSN kernel config option for hirsute and onwards.
Kamal Mostafa [Wed, 16 Dec 2020 21:40:15 +0000 (13:40 -0800)]
UBUNTU: disable building bpf selftests (no VMLINUX_BTF)
BugLink: https://bugs.launchpad.net/bugs/1908144
Disable selftests/bpf since it cannot be built without having built vmlinux
first, else build fails with either:
Makefile:...: *** Cannot find a vmlinux for VMLINUX_BTF at any of
"{paths}". Stop.
or this more cryptic variant:
Error: failed to load BTF from format: No such file or directory
Reference: "UBUNTU: SAUCE: selftests/bpf: clarify build error if no vmlinux"
Reference: https://lore.kernel.org/bpf/20201210185233.28091-1-broonie@kernel.org/ Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Allows users to implement MAC and Audit Policies using BPF programs.
The LSM won't be added to the list of active LSMs by default (in
CONFIG_LSM or lsm= on the boot parameters) yet, as it adds an indirect
function call overhead by registering an empty callback for all hooks.
The LSM can be made "active" by default when the upstream effort [1] of
getting rid of this overhead is merged in the mainline kernel.
[Regression Potential]
Since the LSM is not active by default, it does not cause any
functional or performance regression.
Signed-off-by: KP Singh <kpsingh@google.com> Acked-by: Andrea Righi <andrea.righi@canonical.com>
[ arighi: updated also the annotations file ] Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
projects / mirror_ubuntu-hirsute-kernel.git / log