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>
To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware can accept keys
which are wrapped by a per-boot hardware-internal key. This avoids
needing to keep the plaintext keys in kernel memory, without restricting
the number of keys that can be used. Such keys can be initially
generated either by software (in which case they must be imported to
hardware to be wrapped) or directly by the hardware. There is also a
mechanism to derive a "software secret" for cryptographic tasks that
can't be handled by inline encryption.
To support this hardware, allow struct blk_crypto_key to represent a
hardware-wrapped key as an alternative to a standard key, and make
drivers set flags in struct blk_crypto_profile to indicate which types
of keys they support. Also add the derive_sw_secret() low-level
operation, which drivers supporting wrapped keys must implement.
For more information, see the detailed documentation which this patch
adds to Documentation/block/inline-encryption.rst.
This is a reworked version of a patch which was temporily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867367, and
which originated from several ANDROID patches that were consolidated by
https://android-review.googlesource.com/c/kernel/common-patches/+/1350782.
This version of the patch matches the patch in the below "Link:" tag
that was sent upstream as an RFC. However, due to its history as
ANDROID, it remains tagged as ANDROID rather than FROMLIST.
Bug: 160883801
Link: https://lore.kernel.org/r/20211021181608.54127-2-ebiggers@kernel.org
Change-Id: I4d18c261c279d606457b33374234c0a037e1d45a
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add UFSHCD_QUIRK_CUSTOM_CRYPTO_PROFILE which tells ufshcd-core that the
host controller supports inline encryption, but it needs to initialize
the crypto capabilities in a nonstandard way and/or it needs to override
blk_crypto_ll_ops. If enabled, the standard code won't initialize the
blk_crypto_profile; ufs_hba_variant_ops::init() must do it instead.
Note that it is permitted that the blk_crypto_profile has no keyslots.
This is needed for FMP support, as well as for wrapped key support.
This is a reworked version of a patch which was temporarily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867368, and
which originated from several ANDROID patches that were consolidated by
https://android-review.googlesource.com/c/kernel/common-patches/+/1508579.
Bug: 162257402
Bug: 160883801
Change-Id: I556a68cd2d11bd5a7353fefdc31920475a5e7425
Signed-off-by: Eric Biggers <ebiggers@google.com>
TEO governor was implemented in android12-5.10, however CONFIG_CPU_IDLE_GOV_TEO
was not enabled in gki_defconfig and vendor can not select TEO governor.
This commit enable TEO and MENU governors in gki_defconfig, and vendors can
select the governor they wanted, e.g. in rc file:
write /sys/devices/system/cpu/cpuidle/current_governor "teo"
Besides, MENU governor's rating is 20, and higher than TEO governor,
so MENU governor is still the default governor if vendors not select the governor manually.
Bug: 185762657
Change-Id: I87be7c4d119f17901b921f22dd7df8b61ac539af
Signed-off-by: rogercl.yang <rogercl.yang@mediatek.com>
(cherry picked from commit ea527a52d1)
Histogram triggers (already enabled for arm64) will be used
to throttle frequent trace events on Android.
Bug: 146055070
Bug: 145972256
Change-Id: Ia186a79867866e5b4ed37f2cc14be194505f3fba
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
To enable IOMMU driver, we need to enable CONFIG_IOMMU_IO_PGTABLE_ARMV7S
as build-in by default value in gki_defconfig.
Bug: 189076024
Change-Id: Ia9a87682c2c56338f57703a4bc01793fbe1a3496
Signed-off-by: Guangming Cao <Guangming.Cao@mediatek.com>
(cherry picked from commit b6cab5d17d)
Steps on the way to 5.16-rc1
Resolves conflicts with:
kernel/sched/core.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id00b97b9373792e736005a410e35aa6a2828cba1
When KBUILD_MIXED_TREE points to the output folder of another kernel's
build output, Kbuild can compile a complete kernel tree's modules
against that other kernel tree's vmlinux. This is useful when two
kernel trees exist: a "Generic Kernel Image" tree and a "device kernel"
tree. Both trees are complete kernel source trees, and the "Generic
Kernel Image" should provide the kernel Image and device kernel tree
provides device driver modules.
To accomplish this, references to vmlinux in the device kernel
should point to the generic kernel's vmlinux and the device
kernel should skip compilation of built-in files.
Change ee1b16e80d
adds support for KBUILD_MIXED_TREE
in Makefile and Makefile.modpost. This change adds support for
KBUILD_MIXED_TREE in Makefile.modfinal, where vmlinux is referenced.
Bug: 202075496
Change-Id: I9bb3ff34fd6b5f0510b87648b9942af25c903de0
Signed-off-by: Yifan Hong <elsk@google.com>
.... so it can be referenced in mixed builds.
Test: build cuttlefish
Bug: 202075496
Change-Id: I8d79847c54c639fa619edf3280c021f02ba76645
Signed-off-by: Yifan Hong <elsk@google.com>
Signed-off-by: Matthias Maennich <maennich@google.com>
This reverts commit 3ba4b6d6a3.
The futex code is changed in large ways in 5.16-rc1, so the hook here is
no longer relevant and causes merge conflicts. It will have to be
re-added if it is still needed in the future.
Bug: 163431711
Cc: JianMin Liu <jian-min.liu@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I318ed87ac80ef7d4fb55240d55f74efb291b7907
This reverts commit 95d5435480.
It is already included in 5.16-rc1 in a different form, so revert it
here to prevent merge issues from showing up later on, and to make it
obvious that we are taking the upstream version, not the different
version that was in the android-mainline tree.
Bug: 179406580
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I44f1ec90c26f28d8e921749fab2afbfecead6898
Commit 6b19b766e8 ("fs: get rid of the res2 iocb->ki_complete
argument") dropped the res2 argument in ki_complete, which broke the
build in the fuse passthrough code.
Fix this up by dropping the argument here as well.
Bug: 168023149
Cc: Alessio Balsini <balsini@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id4c8d7bd34bda4cdfc6467446cbed9ad267ede03
Steps on the way to 5.16-rc1
Fixes up merge issues with:
drivers/scsi/ufs/ufshcd-crypto.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibb8331eb6115ef0e16f94fc326070b91de6798e4
I had missed a semantic conflict between commit d389a4a811 ("mm: Add
folio flag manipulation functions") from the folio tree, and commit
eac96c3efd ("mm: filemap: check if THP has hwpoisoned subpage for PMD
page fault") that added a new set of page flags.
My build tests had too many options enabled, which hid this issue. But
if you didn't have MEMORY_FAILURE or TRANSPARENT_HUGEPAGE enabled, you'd
end up with build errors like this:
include/linux/page-flags.h:806:29: error: macro "PAGEFLAG_FALSE" requires 2 arguments, but only 1 given
806 | PAGEFLAG_FALSE(HasHWPoisoned)
| ^
due to the missing lowercase name used for folio function naming.
Fixes: 49f8275c7d ("Merge tag 'folio-5.16' of git://git.infradead.org/users/willy/pagecache")
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reported-by: Yang Shi <shy828301@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit e664359367)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iaab7a897e0a62d3ca8a1647a202ac9feb3baa9ce
