Enable a few config options that help performance with
5.16-rc kernels.
Bug: 146449535
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: I1b83a8f69ab7f9760cd3fcd162be2e6b18f0db78
Steps on the way to 5.16-rc1
Resolves conflicts in:
drivers/gpu/drm/i915/gem/i915_gem_context.c
drivers/gpu/drm/i915/gt/intel_rps.c
drivers/gpu/drm/i915/i915_trace.h
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id4d5f1398e96f280d3455cc2e2af61786959bde5
Steps on the way to 5.16-rc1
Resolves conflicts in:
drivers/gpu/drm/drm_panel_orientation_quirks.c
drivers/gpu/drm/msm/msm_gem_submit.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9c61ce473ae764ab79c2dd5923aab8886fbbcc0a
Steps on the way to 5.16-rc1
Resolves conflicts in:
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
drivers/gpu/drm/drm_panel_orientation_quirks.c
drivers/gpu/drm/i915/gem/i915_gem_ttm.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iaae62240e81569925b6bb6c11f08c07abd2ecd52
Steps on the way to 5.16-rc1.
Resolves merge conflicts in:
kernel/power/suspend.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie7497d13d654d3a430082291090b626b1bc638c2
The 5.16-rc1 kernel has changed the default to disable eBPF unprivileged
programs to run because of Intel's broken hardware which allows for
speculation leaks to happen very easily on those platforms. This is not
an issue on the majority of Android systems, and the Android networking
functionality relies on this feature, so specifically disable the
configuration option so that things continue to work properly.
Disabling a disable configuration option, ugh...
Fixes: 8a03e56b25 ("bpf: Disallow unprivileged bpf by default")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ifd055add42ec1e8360c3d7823ae12567513dba19
While overriding sugov behavior, it is also necessary to know the
runqueue on which the task is going to be enqueued.
Bug: 171598214
Change-Id: I1491a2be34a6e615c5d4bc68e095647744870233
Signed-off-by: Shaleen Agrawal <shalagra@codeaurora.org>
Steps on the way to 5.16-rc1
Resolves merge conflicts in:
drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6f34ccdd38594c59146fd6b7cd25904ab83bb063
br_switchdev_mdb_notify() is conditionally compiled only when
CONFIG_NET_SWITCHDEV=y and CONFIG_BRIDGE_IGMP_SNOOPING=y. It is called
from br_mdb.c, which is conditionally compiled only when
CONFIG_BRIDGE_IGMP_SNOOPING=y.
The shim definition of br_switchdev_mdb_notify() is therefore needed for
the case where CONFIG_NET_SWITCHDEV=n, however we mistakenly put it
there for the case where CONFIG_BRIDGE_IGMP_SNOOPING=n. This results in
build failures when CONFIG_BRIDGE_IGMP_SNOOPING=y and
CONFIG_NET_SWITCHDEV=n.
To fix this, put the shim definition right next to
br_switchdev_fdb_notify(), which is properly guarded by NET_SWITCHDEV=n.
Since this is called only from br_mdb.c, we need not take any extra
safety precautions, when NET_SWITCHDEV=n and BRIDGE_IGMP_SNOOPING=n,
this shim definition will be absent but nobody will be needing it.
Fixes: 9776457c78 ("net: bridge: mdb: move all switchdev logic to br_switchdev.c")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20211029223606.3450523-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit ae0393500e)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic0e3c6290af073ed8b500611fe6ae3e6b5e2cce6
Steps on the way to 5.16-rc1
Resolves conflicts in:
include/net/sock.h
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I65e908f7cb0a0588b4eb37afb0ce221981d0aab5
Steps on the way to 5.16-rc1
Resolves merge conflicts with:
tools/testing/selftests/net/ioam6.sh
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I2c7f5ee7cb7c5df2b757d7284e23eb5bd9851851
Building an allmodconfig kernel arm64 kernel, the following build error
shows up:
In file included from drivers/crypto/marvell/octeontx2/cn10k_cpt.c:4:
include/linux/soc/marvell/octeontx2/asm.h:38:15: error: unknown type name 'u64'
38 | static inline u64 otx2_atomic64_fetch_add(u64 incr, u64 *ptr)
| ^~~
Include linux/types.h in asm.h so the compiler knows what the type
'u64' are.
Fixes: af3826db74 ("octeontx2-pf: Use hardware register for CQE count")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Link: https://lore.kernel.org/r/20211013135743.3826594-1-anders.roxell@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 6312d52838)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I94a5f0cd94166d3b2d111aea52a7114b06500086
Steps on the way to 5.16-rc1.
Resolves merge conflicts in:
drivers/net/ethernet/intel/ice/ice_devlink.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I188502a1e6b84b61582bf3f5539785f8f2e7864f
This reverts commit 6b7933539f.
It causes lots of merge conflicts with upstream changes that come into
the tree in 5.16-rc1, so revert it for now. If this is really still
needed, it can come back later, ideally it should go upstream first.
Bug: 202075496
Cc: Yifan Hong <elsk@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I994ce12885e06bb984c1b8cbe3d9c5663f77bb51
Commit a52f8a59ae ("fortify: Explicitly disable Clang support")
dropped fortify support for clang compilers until the compiler is fixed
up. This requires us to also drop it from the gki configurations as it
is not able to be selected anymore.
Fixes: a52f8a59ae ("fortify: Explicitly disable Clang support")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iad106506847e3f88c1129e8c61f58f68412f7cae
Commit c597bfddc9 ("sched: Provide Kconfig support for default dynamic
preempt mode") changed the dependancies for CONFIG_PREEMPT, now
CONFIG_PREEMPT_BEHAVIOR needs to be set, so fix up the GKI config files
to properly do this.
Fixes: c597bfddc9 ("sched: Provide Kconfig support for default dynamic preempt mode")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9b2e80b93985159a1925af3af8c221b556577f3d
Steps on the way to 5.16-rc1.
Resolves merge conflicts in:
kernel/irq_work.c
kernel/sched/core.c
kernel/sched/fair.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I4b144ffba858a38a417e9d71d76c23d015b7aa9b
clang is throwing up when it hits the BUILD_BUG_ON() macro at the
moment, so remove it from arch_time.h for arm64 to fix the build at this
point in time.
Fixes: a1cb80290f ("Merge 57a315cd71 ("Merge tag 'timers-core-2021-10-31' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip") into android-mainline")
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Marc Zyngier <mzyngier@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0ccd2fa80b3f9fea92464ba40cd3ca6ad013a5d1
`__compiletime_assert` declares a fake `extern` function
which appears (to the compiler) to be called when the test fails.
Therefore, compilers may emit possibly-uninitialized warnings
in some cases, even if it will be an error anyway (for compilers
supporting the `error` attribute, e.g. GCC and Clang >= 14)
or a link failure (for those that do not, e.g. Clang < 14).
Annotating the fake function as `__noreturn` gives them
the information they need to avoid the warning,
e.g. see https://godbolt.org/z/x1v69jjYY.
Link: https://lore.kernel.org/llvm/202110100514.3h9CI4s0-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Change-Id: I6aaf5325bc7821cafda8fea501e8e304750ad84a
Fixes: a1cb80290f ("Merge 57a315cd71 ("Merge tag 'timers-core-2021-10-31' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip") into android-mainline")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add support for hardware-wrapped keys to fscrypt. Hardware-wrapped keys
are inline encryption keys which are only present in kernel memory in
ephemerally-wrapped form, and which can only be unwrapped by dedicated
hardware. Such keys are protected from certain attacks, such as cold
boot attacks. For more information, see the "Hardware-wrapped keys"
section of Documentation/block/inline-encryption.rst.
To support hardware-wrapped keys in fscrypt, we allow the fscrypt master
keys to be hardware-wrapped, and we allow encryption policies to be
flagged as needing a hardware-wrapped key. File contents encryption is
done by passing the wrapped key to the inline encryption hardware via
blk-crypto. Other fscrypt operations such as filenames encryption
continue to be done by the kernel, using the "software secret" which the
hardware derives.
Note that this feature doesn't require any filesystem-specific changes.
However it does depend on inline encryption support, and thus currently
it is only applicable to ext4 and f2fs, not to ubifs or CephFS.
This is a reworked version of a patch which was temporily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867364, and
which originated from
https://android-review.googlesource.com/c/kernel/common/+/1200864.
This is based on a version of this patch that I've proposed upstream
(https://lore.kernel.org/r/20211021181608.54127-4-ebiggers@kernel.org),
but by necessity it preserves the existing UAPI and on-disk format which
Android expects. I also dropped the changes to the documentation file.
Bug: 160883801
Change-Id: If4bb83f1188a5863184717c04cb8a064dc4ea168
Signed-off-by: Eric Biggers <ebiggers@google.com>
Update the device-mapper core to support exposing the inline crypto
support of wrapped keys through the device-mapper device.
derive_sw_secret in keyslot manager is used to derive the software
secret from the given wrapped keyblob using the underlying blk device.
Given that the sw_secret is the same for a given wrapped keyblob the
call exits when the first underlying blk-device suceeds.
This is a reworked version of a patch which was temporily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867366, and
which originated from
https://android-review.googlesource.com/c/kernel/common/+/1229460.
Bug: 147209885
Bug: 160883266
Bug: 160883801
Test: Validated FBE with wrappedkey_v0 when /data is mounted on a
dm device.
Change-Id: Id30d00afdbd3114e089887db1493ffd41e833e21
Signed-off-by: Barani Muthukumaran <bmuthuku@codeaurora.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware supports
protecting the keys in hardware without software having access to or the
ability to set the plaintext keys. Instead, software only sees "wrapped
keys", which may differ on every boot. The keys can be initially
generated either by software (in which case they need to be imported to
hardware to be wrapped), or directly by the hardware.
Add support for this type of hardware by allowing keys to be flagged as
hardware-wrapped. When used, dm-default-key will pass the wrapped key
to the inline encryption hardware to encryption metadata. The hardware
will internally unwrap the key and derive the metadata encryption key.
This is a reworked version of a patch which was temporily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867365, and
which originated from
https://android-review.googlesource.com/c/kernel/common/+/1224286.
Bug: 147209885
Bug: 160883801
Bug: 160883266
Bug: 160885805
Test: Validate metadata encryption & FBE with wrapped keys.
Change-Id: I38393727bf71e5d20b3c3ac9d2af62a1864a0a82
Signed-off-by: Barani Muthukumaran <bmuthuku@codeaurora.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
