Import fixes for standalone build (ElementalX) - #2
Closed
NewEraCracker wants to merge 14 commits into
Closed
Conversation
The arm64 kernel builds fine without the libgcc. Actually it should not be used at all in the kernel. The following are the reasons indicated by Russell King: Although libgcc is part of the compiler, libgcc is built with the expectation that it will be running in userland - it expects to link to a libc. That's why you can't build libgcc without having the glibc headers around. [...] Meanwhile, having the kernel build the compiler support functions that it needs ensures that (a) we know what compiler support functions are being used, (b) we know the implementation of those support functions are sane for use in the kernel, (c) we can build them with appropriate compiler flags for best performance, and (d) we remove an unnecessary dependency on the build toolchain. Signed-off-by: Kevin Hao <haokexin@gmail.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: engstk <eng.stk@sapo.pt>
Signed-off-by: engstk <eng.stk@sapo.pt>
Signed-off-by: NewEraCracker <neweracracker@gmail.com>
virtio wants to read bitwise types from userspace using get_user. At the moment this triggers sparse errors, since the value is passed through an integer. Fix that up using __force. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Will Deacon <will.deacon@arm.com> Bug: 31432001 Change-Id: I1a941e8079cd603456d1ae034a9e708520b26b65 (cherry picked from commit 58fff51) Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: engstk <eng.stk@sapo.pt>
AArch64 toolchains suffer from the following bug: $ cat blah.S 1: .inst 0x01020304 .if ((. - 1b) != 4) .error "blah" .endif $ aarch64-linux-gnu-gcc -c blah.S blah.S: Assembler messages: blah.S:3: Error: non-constant expression in ".if" statement which precludes the use of msr_s and co as part of alternatives. We workaround this issue by not directly testing the labels themselves, but by moving the current output pointer by a value that should always be zero. If this value is not null, then we will trigger a backward move, which is expclicitely forbidden. This triggers the error we're after: AS arch/arm64/kvm/hyp.o arch/arm64/kvm/hyp.S: Assembler messages: arch/arm64/kvm/hyp.S:1377: Error: attempt to move .org backwards scripts/Makefile.build:294: recipe for target 'arch/arm64/kvm/hyp.o' failed make[1]: *** [arch/arm64/kvm/hyp.o] Error 1 Makefile:946: recipe for target 'arch/arm64/kvm' failed Not pretty, but at least works on the current toolchains. Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com> Signed-off-by: engstk <eng.stk@sapo.pt>
Change-Id: I710d6e534ac0a5a94f2a3cf38c987ddf74841446 Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Change-Id: I1df5b2e03ec613fdd97ce52cf87a3d87e600ac04 Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
strncpy_from_user.c only needs EXPORT_SYMBOL, so just include compiler.h and export.h instead of the whole module.h machinery. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: engstk <eng.stk@sapo.pt>
* otherwise there is miscommunication between kernel and our DSP Signed-off-by: Alex Naidis <alex.naidis@linux.com> Signed-off-by: engstk <eng.stk@sapo.pt>
Change-Id: Ie2e60f58fb809c0173adcfab838da19e17775117 Signed-off-by: engstk <eng.stk@sapo.pt>
* extends 9979312490b0b6b3edaf3785543b08be2c7f04dd * found by arter97 Change-Id: I838298628db13417f77a0532150cb4f47a74141d Signed-off-by: Alex Naidis <alex.naidis@linux.com> Signed-off-by: engstk <eng.stk@sapo.pt>
flar2
pushed a commit
that referenced
this pull request
Dec 18, 2016
When peripheral supporting more ssids than apps in a given table entry needs reallocation. No reallocation causes slab-out-of-bounds reads seen as bad access/memory corruption. This patch fixes memory availability limitation. KASAN Report 27.044086:<6> =========================================================== 27.044108:<6> BUG: KASAN: slab-out-of-bounds in diag_cntl_process_read_data+0xeb0/0x10d4 at addr ffffffc033997e6c 27.044112:<6> Read of size 4 by task kworker/u8:9/671 27.044117:<6> =========================================================== 27.044123:<6> BUG kmalloc-128 (Tainted: G B W):kasan: bad access detected 27.044126:<6> ----------------------------------------------------------- 27.044136:<6> INFO: Allocated in d iag_create_msg_mask_table_entry+0x10c/0x148 age=1444 cpu=3 pid=1 27.044147:<6> alloc_debug_processing+0x118/0x170 27.044153:<6> __slab_alloc.isra.20.constprop.22+0x2a4/0x3a0 27.044159:<6> __kmalloc+0xe8/0x27c 27.044165:<6> diag_create_msg_mask_table_entry+0x108/0x148 27.044170:<6> diag_masks_init+0x30c/0xa1c 27.044184:<6> diagchar_init+0x624/0xa4c 27.044190:<6> do_one_initcall+0x250/0x278 27.044198:<6> kernel_init_freeable+0x1c4/0x268 27.044207:<6> kernel_init+0x10/0xd8 27.044212:<6> ret_from_fork+0xc/0x30 27.044219:<6> INFO: Slab 0xffffffba47b79720 objects=16 used=16 fp=0x (null) flags=0x4080 27.044224:<6> INFO: Object 0xffffffc033997e00 @offset=7680 fp=0xffffffc033997c00 27.044232:<6> Bytes b4 ffffffc033997df0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ 27.044238:<6> Object ffffffc033997e00: 1f 00 00 00 1f 00 00 00 1f 00 00 00 1f 00 00 00 ................ 27.044244:<6> Object ffffffc033997e10: 1f 00 00 00 1f 00 00 00 1f 00 00 00 1f 00 00 00 ................ 27.044249:<6> Object ffffffc033997e20: 1f 00 00 00 1f 00 00 00 1f 00 00 00 1f 00 00 00 ................ 27.044255:<6> Object ffffffc033997e30: 1f 00 00 00 1f 00 00 00 1f 00 00 00 1f 00 00 00 ................ 27.044260:<6> Object ffffffc033997e40: 1f 00 00 00 1f 00 00 00 1f 00 00 00 1f 00 00 00 ................ 27.044266:<6> Object ffffffc033997e50: 1f 00 00 00 1f 00 00 00 1f 00 00 00 1f 00 00 00 ................ 27.044271:<6> Object ffffffc033997e60: 1f 00 00 00 1f 00 00 00 1f 00 00 00 00 00 00 00 ................ 27.044277:<6> Object ffffffc033997e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27.044283:<6> Redzone ffffffc033997e80: cc cc cc cc cc cc cc cc ........ 27.044288:<6> Padding ffffffc033997fc0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ 27.044294:<6> Padding ffffffc033997fd0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ 27.044299:<6> Padding ffffffc033997fe0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ 27.044305:<6> Padding ffffffc033997ff0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ 27.044315:<6> CPU: 1 PID: 671 Comm: kworker/u8:9 Tainted: G B W 3.18.20-g2c703ee #2 27.044319:<6> Hardware name: Qualcomm Technologies, Inc. MSM 8996 v3.0 + PMI8994 MTP (DT) 27.044332:<2> Workqueue: DIAG_SOCKMODEM_CNTL socket_read_work_fn 27.044335:<6> Call trace: 27.044343:<2> [<ffffffc00008a168>] dump_backtrace+0x0/0x1c4 27.044350:<2> [<ffffffc00008a33c>] show_stack+0x10/0x1c 27.044359:<2> [<ffffffc00129a850>] dump_stack+0x74/0xc8 27.044366:<2> [<ffffffc000213d8c>] print_trailer+0x19c/0x1b0 27.044372:<2> [<ffffffc000214788>] object_err+0x3c/0x50 27.044378:<2> [<ffffffc000219918>] kasan_report+0x34c/0x504 27.044385:<2> [<ffffffc000218928>] __asan_load4+0x20/0x74 27.044392:<2>[<ffffffc0006f1594>] diag_cntl_process_read_data+0xeac/0x10d4 27.044399:<2> [<ffffffc0006e67f0>] diagfwd_cntl_read_done+0x78/0xf0 27.044407:<2> [<ffffffc0006e7b38>] diagfwd_channel_read_done+0x154/0x184 27.044414:<2> [<ffffffc0006ebdd4>] diag_socket_read+0x480/0x534 27.044420:<2> [<ffffffc0006e85cc>] diagfwd_channel_read+0x348/0x368 27.044427:<2> [<ffffffc0006eabc4>] socket_read_work_fn+0x20/0x30 27.044437:<2> [<ffffffc0000cabf8>] process_one_work+0x394/0x64c 27.044444:<2> [<ffffffc0000cbfb8>] worker_thread+0x3bc/0x550 27.044450:<2> [<ffffffc0000d256c>] kthread+0x180/0x194 27.044753:<6> coresight-tmc 3028000.tmc: TMC aborted 27.044765:<6> Kernel panic - not syncing: kasan: bad access detected CRs-Fixed: 993725 Change-Id: I90a6a560900d6c1c3694cce460ae8f772dc3434e Signed-off-by: Manoj Prabhu B <bmanoj@codeaurora.org>
NewEraCracker
changed the title
Vikram reported that his ARM64 compiler managed to 'optimize' away the preempt_count manipulations in code like: preempt_enable_no_resched(); put_user(); preempt_disable(); Irrespective of that fact that that is horrible code that should be fixed for many reasons, it does highlight a deficiency in the generic preempt_count manipulators. As it is never right to combine/elide preempt_count manipulations like this. Therefore sprinkle some volatile in the two generic accessors to ensure the compiler is aware of the fact that the preempt_count is observed outside of the regular program-order view and thus cannot be optimized away like this. x86; the only arch not using the generic code is not affected as we do all this in asm in order to use the segment base per-cpu stuff. Reported-by: Vikram Mulukutla <markivx@codeaurora.org> Tested-by: Vikram Mulukutla <markivx@codeaurora.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: a787870 ("sched, arch: Create asm/preempt.h") Link: http://lkml.kernel.org/r/20160516131751.GH3205@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar <mingo@kernel.org> Bug: 30147418 (cherry picked from commit 2e636d5e66c35dfcbaf617aa8fa963f6847478fe) Signed-off-by: Patrick Tjin <pattjin@google.com> Change-Id: I88dec230b1fb14e4bf6e1497d088198feae1cf74 Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
apascual89
pushed a commit
to apascual89/android_kernel_oneplus_msm8996-1
that referenced
this pull request
Jan 12, 2017
This patch enhances the xattr consistency of dirs from suddern power-cuts. Possible scenario would be: 1. dir->setxattr used by per-file encryption 2. file->setxattr goes into inline_xattr 3. file->fsync In that case, we should do checkpoint for flar2#1. Otherwise we'd lose dir's key information for the file given flar2#2. Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
flar2
pushed a commit
that referenced
this pull request
May 24, 2017
In the check_only mode, we should not make any dirty node pages. Otherwise, we can get this panic: F2FS-fs (nvme0n1p1): Need to recover fsync data ------------[ cut here ]------------ kernel BUG at fs/f2fs/node.c:2204! CPU: 7 PID: 19923 Comm: mount Tainted: G OE 4.9.8 #2 RIP: 0010:[<ffffffffc0979c0b>] [<ffffffffc0979c0b>] flush_nat_entries+0x43b/0x7d0 [f2fs] Call Trace: [<ffffffffc096ddaa>] ? __f2fs_submit_merged_bio+0x5a/0xd0 [f2fs] [<ffffffffc096ddaa>] ? __f2fs_submit_merged_bio+0x5a/0xd0 [f2fs] [<ffffffffc096dddb>] ? __f2fs_submit_merged_bio+0x8b/0xd0 [f2fs] [<ffffffff860e450f>] ? up_write+0x1f/0x40 [<ffffffffc096dddb>] ? __f2fs_submit_merged_bio+0x8b/0xd0 [f2fs] [<ffffffffc0969f04>] write_checkpoint+0x2f4/0xf20 [f2fs] [<ffffffff860e938d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffffc0960bc9>] ? f2fs_sync_fs+0x79/0x190 [f2fs] [<ffffffffc0960bc9>] ? f2fs_sync_fs+0x79/0x190 [f2fs] [<ffffffffc0960bd5>] f2fs_sync_fs+0x85/0x190 [f2fs] [<ffffffffc097b6de>] f2fs_balance_fs_bg+0x7e/0x1c0 [f2fs] [<ffffffffc0977b64>] f2fs_write_node_pages+0x34/0x350 [f2fs] [<ffffffff860e5f42>] ? __lock_is_held+0x52/0x70 [<ffffffff861d9b31>] do_writepages+0x21/0x30 [<ffffffff86298ce1>] __writeback_single_inode+0x61/0x760 [<ffffffff86909127>] ? _raw_spin_unlock+0x27/0x40 [<ffffffff8629a735>] writeback_single_inode+0xd5/0x190 [<ffffffff8629a889>] write_inode_now+0x99/0xc0 [<ffffffff86283876>] iput+0x1f6/0x2c0 [<ffffffffc0964b52>] f2fs_fill_super+0xc32/0x10c0 [f2fs] [<ffffffff86266462>] mount_bdev+0x182/0x1b0 [<ffffffffc0963f20>] ? f2fs_commit_super+0x100/0x100 [f2fs] [<ffffffffc0960da5>] f2fs_mount+0x15/0x20 [f2fs] [<ffffffff86266e08>] mount_fs+0x38/0x170 [<ffffffff86288bab>] vfs_kern_mount+0x6b/0x160 [<ffffffff8628bcfe>] do_mount+0x1be/0xd60 Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
flar2
pushed a commit
that referenced
this pull request
Sep 13, 2017
(url: https://patchwork.kernel.org/patch/9857935/) When ->freeze_fs is called from lvm for doing snapshot, it needs to make sure there will be no more changes in filesystem's data, however, previously, background threads like GC thread wasn't aware of freezing, so in environment with active background threads, data of snapshot becomes unstable. This patch fixes this issue by adding sb_{start,end}_intwrite in below background threads: - GC thread - flush thread - discard thread Note that, don't use sb_start_intwrite() in gc_thread_func() due to: generic/241 reports below bug: ====================================================== WARNING: possible circular locking dependency detected 4.13.0-rc1+ OnePlusOSS#32 Tainted: G O ------------------------------------------------------ f2fs_gc-250:0/22186 is trying to acquire lock: (&sbi->gc_mutex){+.+...}, at: [<f8fa7f0b>] f2fs_sync_fs+0x7b/0x1b0 [f2fs] but task is already holding lock: (sb_internal#2){++++.-}, at: [<f8fb5609>] gc_thread_func+0x159/0x4a0 [f2fs] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (sb_internal#2){++++.-}: __lock_acquire+0x405/0x7b0 lock_acquire+0xae/0x220 __sb_start_write+0x11d/0x1f0 f2fs_evict_inode+0x2d6/0x4e0 [f2fs] evict+0xa8/0x170 iput+0x1fb/0x2c0 f2fs_sync_inode_meta+0x3f/0xf0 [f2fs] write_checkpoint+0x1b1/0x750 [f2fs] f2fs_sync_fs+0x85/0x1b0 [f2fs] f2fs_do_sync_file.isra.24+0x137/0xa30 [f2fs] f2fs_sync_file+0x34/0x40 [f2fs] vfs_fsync_range+0x4a/0xa0 do_fsync+0x3c/0x60 SyS_fdatasync+0x15/0x20 do_fast_syscall_32+0xa1/0x1b0 entry_SYSENTER_32+0x4c/0x7b -> #1 (&sbi->cp_mutex){+.+...}: __lock_acquire+0x405/0x7b0 lock_acquire+0xae/0x220 __mutex_lock+0x4f/0x830 mutex_lock_nested+0x25/0x30 write_checkpoint+0x2f/0x750 [f2fs] f2fs_sync_fs+0x85/0x1b0 [f2fs] sync_filesystem+0x67/0x80 generic_shutdown_super+0x27/0x100 kill_block_super+0x22/0x50 kill_f2fs_super+0x3a/0x40 [f2fs] deactivate_locked_super+0x3d/0x70 deactivate_super+0x40/0x60 cleanup_mnt+0x39/0x70 __cleanup_mnt+0x10/0x20 task_work_run+0x69/0x80 exit_to_usermode_loop+0x57/0x92 do_fast_syscall_32+0x18c/0x1b0 entry_SYSENTER_32+0x4c/0x7b -> #0 (&sbi->gc_mutex){+.+...}: validate_chain.isra.36+0xc50/0xdb0 __lock_acquire+0x405/0x7b0 lock_acquire+0xae/0x220 __mutex_lock+0x4f/0x830 mutex_lock_nested+0x25/0x30 f2fs_sync_fs+0x7b/0x1b0 [f2fs] f2fs_balance_fs_bg+0xb9/0x200 [f2fs] gc_thread_func+0x302/0x4a0 [f2fs] kthread+0xe9/0x120 ret_from_fork+0x19/0x24 other info that might help us debug this: Chain exists of: &sbi->gc_mutex --> &sbi->cp_mutex --> sb_internal#2 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sb_internal#2); lock(&sbi->cp_mutex); lock(sb_internal#2); lock(&sbi->gc_mutex); *** DEADLOCK *** 1 lock held by f2fs_gc-250:0/22186: #0: (sb_internal#2){++++.-}, at: [<f8fb5609>] gc_thread_func+0x159/0x4a0 [f2fs] stack backtrace: CPU: 2 PID: 22186 Comm: f2fs_gc-250:0 Tainted: G O 4.13.0-rc1+ OnePlusOSS#32 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: dump_stack+0x5f/0x92 print_circular_bug+0x1b3/0x1bd validate_chain.isra.36+0xc50/0xdb0 ? __this_cpu_preempt_check+0xf/0x20 __lock_acquire+0x405/0x7b0 lock_acquire+0xae/0x220 ? f2fs_sync_fs+0x7b/0x1b0 [f2fs] __mutex_lock+0x4f/0x830 ? f2fs_sync_fs+0x7b/0x1b0 [f2fs] mutex_lock_nested+0x25/0x30 ? f2fs_sync_fs+0x7b/0x1b0 [f2fs] f2fs_sync_fs+0x7b/0x1b0 [f2fs] f2fs_balance_fs_bg+0xb9/0x200 [f2fs] gc_thread_func+0x302/0x4a0 [f2fs] ? preempt_schedule_common+0x2f/0x4d ? f2fs_gc+0x540/0x540 [f2fs] kthread+0xe9/0x120 ? f2fs_gc+0x540/0x540 [f2fs] ? kthread_create_on_node+0x30/0x30 ret_from_fork+0x19/0x24 The deadlock occurs in below condition: GC Thread Thread B - sb_start_intwrite - f2fs_sync_file - f2fs_sync_fs - mutex_lock(&sbi->gc_mutex) - write_checkpoint - block_operations - f2fs_sync_inode_meta - iput - sb_start_intwrite - mutex_lock(&sbi->gc_mutex) Fix this by altering sb_start_intwrite to sb_start_write_trylock. Change-Id: Ibea8cff73d684e5aebc950f29ef4d611fc10df76 Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes allow easy building with either "android-ndk-r13b-linux-x86_64.zip" or "gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu.tar.xz" toolchains.
Upstream: OnePlusOSS#14
Thanks!
Regards,
Jorge M. Oliveira