This reverts commit 489a71964f.
Rationale does not apply to Android userspace which does not allow
access to debugfs on user builds.
Bug: 218319878
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Ia36b04b432a3db330e5a12763a3250869b97f0fe
Signed-off-by: Steve Muckle <smuckle@google.com>
blake2s_compress_generic is weakly aliased by blake2s_compress. The
current harness for function selection uses a function pointer, which is
ordinarily inlined and resolved at compile time. But when Clang's CFI is
enabled, CFI still triggers when making an indirect call via a weak
symbol. This seems like a bug in Clang's CFI, as though it's bucketing
weak symbols and strong symbols differently. It also only seems to
trigger when "full LTO" mode is used, rather than "thin LTO".
[ 0.000000][ T0] Kernel panic - not syncing: CFI failure (target: blake2s_compress_generic+0x0/0x1444)
[ 0.000000][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-mainline-06981-g076c855b846e #1
[ 0.000000][ T0] Hardware name: MT6873 (DT)
[ 0.000000][ T0] Call trace:
[ 0.000000][ T0] dump_backtrace+0xfc/0x1dc
[ 0.000000][ T0] dump_stack_lvl+0xa8/0x11c
[ 0.000000][ T0] panic+0x194/0x464
[ 0.000000][ T0] __cfi_check_fail+0x54/0x58
[ 0.000000][ T0] __cfi_slowpath_diag+0x354/0x4b0
[ 0.000000][ T0] blake2s_update+0x14c/0x178
[ 0.000000][ T0] _extract_entropy+0xf4/0x29c
[ 0.000000][ T0] crng_initialize_primary+0x24/0x94
[ 0.000000][ T0] rand_initialize+0x2c/0x6c
[ 0.000000][ T0] start_kernel+0x2f8/0x65c
[ 0.000000][ T0] __primary_switched+0xc4/0x7be4
[ 0.000000][ T0] Rebooting in 5 seconds..
Nonetheless, the function pointer method isn't so terrific anyway, so
this patch replaces it with a simple boolean, which also gets inlined
away. This successfully works around the Clang bug.
In general, I'm not too keen on all of the indirection involved here; it
clearly does more harm than good. Hopefully the whole thing can get
cleaned up down the road when lib/crypto is overhauled more
comprehensively. But for now, we go with a simple bandaid.
Link: https://lore.kernel.org/all/20220124192849.14755-1-Jason@zx2c4.com/
Bug: 218328931
Fixes: 6048fdcc5f ("lib/crypto: blake2s: include as built-in")
Link: https://github.com/ClangBuiltLinux/linux/issues/1567
Reported-by: Miles Chen <miles.chen@mediatek.com>
Tested-by: Miles Chen <miles.chen@mediatek.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
(cherry picked from commit d2a02e3c8b)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: I797c6d79b120041aeb98ae68060d8cc4bd165c1a
This is part of a migration process from build/
to build/kernel.
Test: builds
Bug: 204425264
Change-Id: Id29f8e476fbb3590196789b2b578865798f24cd3
Signed-off-by: Yifan Hong <elsk@google.com>
This is part of the build -> build/kernel transition.
Test: TH
Bug: 204425264
Change-Id: I5bcf6ac00b6388af198e486f191e13f0b60050c9
Signed-off-by: Yifan Hong <elsk@google.com>
Reason for revert: need alternative deployment path for test modules
Change-Id: If2d5ca5a5cd41b2b76114e2db29e6e633f6c7ec2
Bug: 181024194
Signed-off-by: Steve Muckle <smuckle@google.com>
The old and new mount user name spaces need to be populated
before calling vfs_rename().
Bug: 211066171
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: Ieac6975abb4131c8f5bdefe25b5f241c80023e38
Cleanup incremental-fs left overs on umount, otherwise incr-fs will
complain as below:
BUG: Dentry {i=47a,n=.incomplete} still in use [unmount of incremental-fs]
This requires vfs_rmdir() of the special index and incomplete dirs.
Also free options.sysfs_name in incfs_mount_fs() instead of in
incfs_free_mount_info() to make it consistent with incfs_remount_fs().
Since set_anon_super() was used in incfs_mount_fs() the incfs_kill_sb()
should use kill_anon_super() instead of generic_shutdown_super()
otherwise it will leak the pseudo dev_t that set_anon_super() allocates.
Bug: 211066171
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I7ea54db63513fc130e1997cbf79121015ee12405
Steps on the way to 5.17-rc1
Resolves conflicts in:
drivers/scsi/ufs/ufshcd.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I64ad2fb6ed77ba4678f631f4143b64339b1a5ddd
This reverts commit d9a2a3f2c2 which was
not upstream as it is causing merge conflicts with 5.17-rc1.
If this out-of-tree feature is still needed, it must be forward ported
properly again.
Bug: 120440972
Cc: Doug Anderson <dianders@chromium.org>
Cc: Colin Cross <ccross@android.com>
Cc: Amit Pundir <amit.pundir@linaro.org>
Fixes: d9a2a3f2c2 ("ANDROID: of: Support CONFIG_CMDLINE_EXTEND config option")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id34ae0303eb943668418b9aab3f928a7d970ca97
Steps on the way to 5.17-rc1
Resolves conflicts in:
drivers/iommu/dma-iommu.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1f4b257550955dc7a79cb8a6628cd308fe2d8e71
Steps on the way to 5.17-rc1
Resolves conflicts in:
fs/ext4/inode.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7f7d4309bbce5cea381efeee8c27a3505e74f0df
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse") into
android-mainline
Steps on the way to 5.17-rc1
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: Iaa0fdd23d98a0a83e842dca032a14df445f87661
Starting with FUSE 7.36, all the fields for the 32-bit FUSE init flags
have been allocated, so commit 53db28933e ("fuse: extend init flags")
introduces the new 32-bit flags2 field in fuse_init_in and
fuse_init_out. That change also adds the FUSE_INIT_RESERVED flag that
doesn't have any specific purpose yet, is just reserved and should not
be used, and (un)fortunately collides with FUSE_PASSTHROUGH.
This change fixes the conflict by simply setting the FUSE_PASSTHROUGH
value to the next, latest unused fuse2 bit.
Although this is not the best design choice, userspace will know what
FUSE_PASSTHROUGH bit to choose based on the FUSE major and minor version
for FUSE version:
- < 7.36: FUSE_PASSTHROUGH is the 31st bit of flags;
- otherwise: FUSE_PASSTHROUGH is the 31st bit of flags2.
Test: launch_cvd (both android-mainline and android13-5.10) \
`logcat FuseDaemon:V \*:S` shows no FUSE passthrough errors
Bug: 215310351
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: I85d7582008b8c093b3172b3f41c6cdf09863dd45
Add support to install the modules.order file for external modules
during module_install in order to retain the Makefile ordering
of external modules. This helps reduce the extra steps necessary to
properly order loading of external modules when there are multiple
kernel modules compiled within a given KBUILD_EXTMOD directory.
To handle compiling multiple external modules within the same
INSTALL_MOD_DIR, kbuild will append a suffix to the installed
modules.order file defined like so:
echo "${KBUILD_EXTMOD}" | md5sum | cut -d " " -f 1
Example:
KBUILD_EXTMOD=/mnt/a.b/c-d/my_driver results in:
modules.order.7dd3eb90588c21ac15f23a96c2f6d8ec
The installed module.order.$(extmod_suffix) files can then be appended
to the staging modules.order file which defines the order to load all of
the modules during boot.
Example:
cd $(MODLIB)
find extra/. -name modules.order.* -exec cat {} >> modules.order \;
Link: https://lore.kernel.org/all/20220127010009.2617569-1-willmcvicker@google.com/
Bug: 216462633
Bug: 210713925
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: I7baa92163f8e6ea3f47d780b728167d86cc2f6e1
This reverts commit 77cbbcd16f. This patch
hasn't landed upstream yet, but needs a fix. So reverting it first to
help keep the fixes together in case we need to forward port this
feature.
Bug: 216462633
Change-Id: Ia96084bd24d0ee27b7addc2acbd5277e46cb86f1
Signed-off-by: Will McVicker <willmcvicker@google.com>
This reverts commit bf2290a48a (Revert "ANDROID: vendor_hooks: set
debugging data when rt_mutex is working")
The original patch has been reverted to resolve merge issues.
This patch adds again the vendor hooks for the original purpose.
Bug: 216016261
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Change-Id: I00162d88e2a446e9ece4804def098fcdc63fceb9
This reverts commit 31c9ccb138 (Revert "ANDROID: vendor_hooks: add
waiting information for blocked tasks")
And also revert portions of 396a501b17 (Revert "ANDROID: rwsem: Add
vendor hook to the rw-semaphore")
The original patch has been reverted to resolve merge issues.
This patch adds again the vendor hooks for the original purpose.
Bug: 216016261
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Change-Id: I04ed7b055eee40f7975bd5d74fb73dd080cd76bf
It is possible that fget returns NULL. This needs to be handled
correctly in ioctl_permit_fill.
Bug: 212821226
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: Iec8be21982afeab6794b78ab1a542671c52acea2
Correct a path to incremental-fs sysfs entry in incfs.rst
Bug: 211066171
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: Id3a94888edd9022c517939b4667d9792fc04146a
Syzbot recently found a number of issues related to incremental-fs
(see bug numbers below). All have to do with the fact that incr-fs
allows mounts of the same source and target multiple times.
The correct behavior for a file system is to allow only one such
mount, and then every subsequent attempt should fail with a -EBUSY
error code. In case of the issues listed below the common pattern
is that the reproducer calls:
mount("./file0", "./file0", "incremental-fs", 0, NULL)
many times and then invokes a file operation like chmod, setxattr,
or open on the ./file0. This causes a recursive call for all the
mounted instances, which eventually causes a stack overflow and
a kernel crash:
BUG: stack guard page was hit at ffffc90000c0fff8
kernel stack overflow (double-fault): 0000 [#1] PREEMPT SMP KASAN
The reason why many mounts with the same source and target are
possible is because the incfs_mount_fs() as it is allocates a new
super_block for every call, regardless of whether a given mount already
exists or not. This happens every time the sget() function is called
with a test param equal to NULL.
The correct behavior for an FS mount implementation is to call
appropriate mount vfs call for it's type, i.e. mount_bdev() for
a block device backed FS, mount_single() for a pseudo file system,
like sysfs that is mounted in a single, well know location, or
mount_nodev() for other special purpose FS like overlayfs.
In case of incremental-fs the open coded mount logic doesn't check
for abusive mount attempts such as overlays.
To fix this issue the logic needs to be changed to pass a proper
test function to sget() call, which then checks if a super_block
for a mount instance has already been allocated and also allows
the VFS to properly verify invalid mount attempts.
Bug: 211066171
Bug: 213140206
Bug: 213215835
Bug: 211914587
Bug: 211213635
Bug: 213137376
Bug: 211161296
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I66cfc3f1b5aaffb32b0845b2dad3ff26fe952e27
This driver can not build cleanly without warnings just yet, who knows
why it was merged in this way. Until it is fixed up upstream, just
disable it from the builds as no Android systems use it.
Fixes: 12422af819 ("pinctrl: Add Intel Thunder Bay pinctrl driver")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7f13e119e386382ff853e8dd5d42e20484581771
Steps on the way to 5.17-rc1
Resolves merge conflicts in:
fs/iomap/direct-io.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ifa6a219f9c0bee7676881a968a8cced2af88d695
With HW tag-based kasan enable, We will get the warning when we free
object whose address starts with 0xFF.
It is because kmemleak rbtree stores tagged object and this freeing
object's tag does not match with rbtree object.
In the example below, kmemleak rbtree stores the tagged object in the
kmalloc(), and kfree() gets the pointer with 0xFF tag.
Call sequence:
ptr = kmalloc(size, GFP_KERNEL);
page = virt_to_page(ptr);
offset = offset_in_page(ptr);
kfree(page_address(page) + offset);
ptr = kmalloc(size, GFP_KERNEL);
A sequence like that may cause the warning as following:
1) Freeing unknown object:
In kfree(), we will get free unknown object warning in
kmemleak_free(). Because object(0xFx) in kmemleak rbtree and
pointer(0xFF) in kfree() have different tag.
2) Overlap existing:
When we allocate that object with the same hw-tag again, we will
find the overlap in the kmemleak rbtree and kmemleak thread will be
killed.
kmemleak: Freeing unknown object at 0xffff000003f88000
CPU: 5 PID: 177 Comm: cat Not tainted 5.16.0-rc1-dirty #21
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x0/0x1ac
show_stack+0x1c/0x30
dump_stack_lvl+0x68/0x84
dump_stack+0x1c/0x38
kmemleak_free+0x6c/0x70
slab_free_freelist_hook+0x104/0x200
kmem_cache_free+0xa8/0x3d4
test_version_show+0x270/0x3a0
module_attr_show+0x28/0x40
sysfs_kf_seq_show+0xb0/0x130
kernfs_seq_show+0x30/0x40
seq_read_iter+0x1bc/0x4b0
seq_read_iter+0x1bc/0x4b0
kernfs_fop_read_iter+0x144/0x1c0
generic_file_splice_read+0xd0/0x184
do_splice_to+0x90/0xe0
splice_direct_to_actor+0xb8/0x250
do_splice_direct+0x88/0xd4
do_sendfile+0x2b0/0x344
__arm64_sys_sendfile64+0x164/0x16c
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x44/0xec
do_el0_svc+0x74/0x90
el0_svc+0x20/0x80
el0t_64_sync_handler+0x1a8/0x1b0
el0t_64_sync+0x1ac/0x1b0
...
kmemleak: Cannot insert 0xf2ff000003f88000 into the object search tree (overlaps existing)
CPU: 5 PID: 178 Comm: cat Not tainted 5.16.0-rc1-dirty #21
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x0/0x1ac
show_stack+0x1c/0x30
dump_stack_lvl+0x68/0x84
dump_stack+0x1c/0x38
create_object.isra.0+0x2d8/0x2fc
kmemleak_alloc+0x34/0x40
kmem_cache_alloc+0x23c/0x2f0
test_version_show+0x1fc/0x3a0
module_attr_show+0x28/0x40
sysfs_kf_seq_show+0xb0/0x130
kernfs_seq_show+0x30/0x40
seq_read_iter+0x1bc/0x4b0
kernfs_fop_read_iter+0x144/0x1c0
generic_file_splice_read+0xd0/0x184
do_splice_to+0x90/0xe0
splice_direct_to_actor+0xb8/0x250
do_splice_direct+0x88/0xd4
do_sendfile+0x2b0/0x344
__arm64_sys_sendfile64+0x164/0x16c
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x44/0xec
do_el0_svc+0x74/0x90
el0_svc+0x20/0x80
el0t_64_sync_handler+0x1a8/0x1b0
el0t_64_sync+0x1ac/0x1b0
kmemleak: Kernel memory leak detector disabled
kmemleak: Object 0xf2ff000003f88000 (size 128):
kmemleak: comm "cat", pid 177, jiffies 4294921177
kmemleak: min_count = 1
kmemleak: count = 0
kmemleak: flags = 0x1
kmemleak: checksum = 0
kmemleak: backtrace:
kmem_cache_alloc+0x23c/0x2f0
test_version_show+0x1fc/0x3a0
module_attr_show+0x28/0x40
sysfs_kf_seq_show+0xb0/0x130
kernfs_seq_show+0x30/0x40
seq_read_iter+0x1bc/0x4b0
kernfs_fop_read_iter+0x144/0x1c0
generic_file_splice_read+0xd0/0x184
do_splice_to+0x90/0xe0
splice_direct_to_actor+0xb8/0x250
do_splice_direct+0x88/0xd4
do_sendfile+0x2b0/0x344
__arm64_sys_sendfile64+0x164/0x16c
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x44/0xec
do_el0_svc+0x74/0x90
kmemleak: Automatic memory scanning thread ended
[akpm@linux-foundation.org: whitespace tweak]
Link: https://lkml.kernel.org/r/20211118054426.4123-1-Kuan-Ying.Lee@mediatek.com
Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Doug Berger <opendmb@gmail.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Calling kmem_cache_destroy() while the cache still has objects allocated
is a kernel bug, and will usually result in the entire cache being
leaked. While the message in kmem_cache_destroy() resembles a warning,
it is currently not implemented using a real WARN().
This is problematic for infrastructure testing the kernel, all of which
rely on the specific format of WARN()s to pick up on bugs.
Some 13 years ago this used to be a simple WARN_ON() in slub, but commit
d629d81957 ("slub: improve kmem_cache_destroy() error message")
changed it into an open-coded warning to avoid confusion with a bug in
slub itself.
Instead, turn the open-coded warning into a real WARN() with the message
preserved, so that test systems can actually identify these issues, and
we get all the other benefits of using a normal WARN(). The warning
message is extended with "when called from <caller-ip>" to make it even
clearer where the fault lies.
For most configurations this is only a cosmetic change, however, note
that WARN() here will now also respect panic_on_warn.
Link: https://lkml.kernel.org/r/20211102170733.648216-1-elver@google.com
Signed-off-by: Marco Elver <elver@google.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
