could you add NFS Kernel module ? #15
Comments
|
Hi |
|
Thank you for your reply. I found the 4.86 have compiled the nfs moudles in kernel. |
isjerryxiao
pushed a commit
to isjerryxiao/Amlogic_s905-kernel
that referenced
this issue
May 26, 2019
commit 8f71370f4b02730e8c27faf460af7a3586e24e1f upstream. If codec registration fails after the ASoC Intel SST driver has been probed, the kernel will Oops and crash at suspend/resume. general protection fault: 0000 [150balbes#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 2811 Comm: cat Tainted: G W 4.19.30 150balbes#15 Hardware name: GOOGLE Clapper, BIOS Google_Clapper.5216.199.7 08/22/2014 RIP: 0010:snd_soc_suspend+0x5a/0xd21 Code: 03 80 3c 10 00 49 89 d7 74 0b 48 89 df e8 71 72 c4 fe 4c 89 fa 48 8b 03 48 89 45 d0 48 8d 98 a0 01 00 00 48 89 d8 48 c1 e8 03 <8a> 04 10 84 c0 0f 85 85 0c 00 00 80 3b 00 0f 84 6b 0c 00 00 48 8b RSP: 0018:ffff888035407750 EFLAGS: 00010202 RAX: 0000000000000034 RBX: 00000000000001a0 RCX: 0000000000000000 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88805c417098 RBP: ffff8880354077b0 R08: dffffc0000000000 R09: ffffed100b975718 R10: 0000000000000001 R11: ffffffff949ea4a3 R12: 1ffff1100b975746 R13: dffffc0000000000 R14: ffff88805cba4588 R15: dffffc0000000000 FS: 0000794a78e91b80(0000) GS:ffff888068d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007bd5283ccf58 CR3: 000000004b7aa000 CR4: 00000000001006e0 Call Trace: ? dpm_complete+0x67b/0x67b ? i915_gem_suspend+0x14d/0x1ad sst_soc_prepare+0x91/0x1dd ? sst_be_hw_params+0x7e/0x7e dpm_prepare+0x39a/0x88b dpm_suspend_start+0x13/0x9d suspend_devices_and_enter+0x18f/0xbd7 ? arch_suspend_enable_irqs+0x11/0x11 ? printk+0xd9/0x12d ? lock_release+0x95f/0x95f ? log_buf_vmcoreinfo_setup+0x131/0x131 ? rcu_read_lock_sched_held+0x140/0x22a ? __bpf_trace_rcu_utilization+0xa/0xa ? __pm_pr_dbg+0x186/0x190 ? pm_notifier_call_chain+0x39/0x39 ? suspend_test+0x9d/0x9d pm_suspend+0x2f4/0x728 ? trace_suspend_resume+0x3da/0x3da ? lock_release+0x95f/0x95f ? kernfs_fop_write+0x19f/0x32d state_store+0xd8/0x147 ? sysfs_kf_read+0x155/0x155 kernfs_fop_write+0x23e/0x32d __vfs_write+0x108/0x608 ? vfs_read+0x2e9/0x2e9 ? rcu_read_lock_sched_held+0x140/0x22a ? __bpf_trace_rcu_utilization+0xa/0xa ? debug_smp_processor_id+0x10/0x10 ? selinux_file_permission+0x1c5/0x3c8 ? rcu_sync_lockdep_assert+0x6a/0xad ? __sb_start_write+0x129/0x2ac vfs_write+0x1aa/0x434 ksys_write+0xfe/0x1be ? __ia32_sys_read+0x82/0x82 do_syscall_64+0xcd/0x120 entry_SYSCALL_64_after_hwframe+0x49/0xbe In the observed situation, the problem is seen because the codec driver failed to probe due to a hardware problem. max98090 i2c-193C9890:00: Failed to read device revision: -1 max98090 i2c-193C9890:00: ASoC: failed to probe component -1 cht-bsw-max98090 cht-bsw-max98090: ASoC: failed to instantiate card -1 cht-bsw-max98090 cht-bsw-max98090: snd_soc_register_card failed -1 cht-bsw-max98090: probe of cht-bsw-max98090 failed with error -1 The problem is similar to the problem solved with commit 2fc995a ("ASoC: intel: Fix crash at suspend/resume without card registration"), but codec registration fails at a later point. At that time, the pointer checked with the above mentioned commit is already set, but it is not cleared if the device is subsequently removed. Adding a remove function to clear the pointer fixes the problem. Cc: stable@vger.kernel.org Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com> Cc: Curtis Malainey <cujomalainey@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
isjerryxiao
pushed a commit
to isjerryxiao/Amlogic_s905-kernel
that referenced
this issue
May 26, 2019
[ Upstream commit 42dfa451d825a2ad15793c476f73e7bbc0f9d312 ]
Using gcc's ASan, Changbin reports:
=================================================================
==7494==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
150balbes#1 0x5625e5330a5e in zalloc util/util.h:23
150balbes#2 0x5625e5330a9b in perf_counts__new util/counts.c:10
150balbes#3 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
150balbes#4 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
150balbes#5 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
150balbes#6 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
150balbes#7 0x5625e51528e6 in run_test tests/builtin-test.c:358
150balbes#8 0x5625e5152baf in test_and_print tests/builtin-test.c:388
150balbes#9 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
150balbes#10 0x5625e515572f in cmd_test tests/builtin-test.c:722
150balbes#11 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
150balbes#12 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
150balbes#13 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
150balbes#14 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
150balbes#15 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Indirect leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
150balbes#1 0x5625e532560d in zalloc util/util.h:23
150balbes#2 0x5625e532566b in xyarray__new util/xyarray.c:10
150balbes#3 0x5625e5330aba in perf_counts__new util/counts.c:15
150balbes#4 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
150balbes#5 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
150balbes#6 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
150balbes#7 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
150balbes#8 0x5625e51528e6 in run_test tests/builtin-test.c:358
150balbes#9 0x5625e5152baf in test_and_print tests/builtin-test.c:388
150balbes#10 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
150balbes#11 0x5625e515572f in cmd_test tests/builtin-test.c:722
150balbes#12 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
150balbes#13 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
150balbes#14 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
150balbes#15 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
150balbes#16 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
His patch took care of evsel->prev_raw_counts, but the above backtraces
are about evsel->counts, so fix that instead.
Reported-by: Changbin Du <changbin.du@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: https://lkml.kernel.org/n/tip-hd1x13g59f0nuhe4anxhsmfp@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
isjerryxiao
pushed a commit
to isjerryxiao/Amlogic_s905-kernel
that referenced
this issue
Jun 3, 2019
[ Upstream commit 36a2ba07757df790b4a874efb1a105b9330a9ae7 ]
In a system where, through IORT firmware mappings, the SMMU device is
mapped to a NUMA node that is not online, the kernel bootstrap results
in the following crash:
Unable to handle kernel paging request at virtual address 0000000000001388
Mem abort info:
ESR = 0x96000004
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
[0000000000001388] user address but active_mm is swapper
Internal error: Oops: 96000004 [150balbes#1] SMP
Modules linked in:
CPU: 5 PID: 1 Comm: swapper/0 Not tainted 5.0.0 150balbes#15
pstate: 80c00009 (Nzcv daif +PAN +UAO)
pc : __alloc_pages_nodemask+0x13c/0x1068
lr : __alloc_pages_nodemask+0xdc/0x1068
...
Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____))
Call trace:
__alloc_pages_nodemask+0x13c/0x1068
new_slab+0xec/0x570
___slab_alloc+0x3e0/0x4f8
__slab_alloc+0x60/0x80
__kmalloc_node_track_caller+0x10c/0x478
devm_kmalloc+0x44/0xb0
pinctrl_bind_pins+0x4c/0x188
really_probe+0x78/0x2b8
driver_probe_device+0x64/0x110
device_driver_attach+0x74/0x98
__driver_attach+0x9c/0xe8
bus_for_each_dev+0x84/0xd8
driver_attach+0x30/0x40
bus_add_driver+0x170/0x218
driver_register+0x64/0x118
__platform_driver_register+0x54/0x60
arm_smmu_driver_init+0x24/0x2c
do_one_initcall+0xbc/0x328
kernel_init_freeable+0x304/0x3ac
kernel_init+0x18/0x110
ret_from_fork+0x10/0x1c
Code: f90013b5 b9410fa1 1a9f0694 b50014c2 (b9400804)
---[ end trace dfeaed4c373a32da ]--
Change the dev_set_proximity() hook prototype so that it returns a
value and make it return failure if the PXM->NUMA-node mapping
corresponds to an offline node, fixing the crash.
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Link: https://lore.kernel.org/linux-arm-kernel/20190315021940.86905-1-wangkefeng.wang@huawei.com/
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
isjerryxiao
pushed a commit
to isjerryxiao/Amlogic_s905-kernel
that referenced
this issue
Aug 17, 2019
commit d0a255e795ab976481565f6ac178314b34fbf891 upstream. A deadlock with this stacktrace was observed. The loop thread does a GFP_KERNEL allocation, it calls into dm-bufio shrinker and the shrinker depends on I/O completion in the dm-bufio subsystem. In order to fix the deadlock (and other similar ones), we set the flag PF_MEMALLOC_NOIO at loop thread entry. PID: 474 TASK: ffff8813e11f4600 CPU: 10 COMMAND: "kswapd0" #0 [ffff8813dedfb938] __schedule at ffffffff8173f405 150balbes#1 [ffff8813dedfb990] schedule at ffffffff8173fa27 150balbes#2 [ffff8813dedfb9b0] schedule_timeout at ffffffff81742fec 150balbes#3 [ffff8813dedfba60] io_schedule_timeout at ffffffff8173f186 150balbes#4 [ffff8813dedfbaa0] bit_wait_io at ffffffff8174034f 150balbes#5 [ffff8813dedfbac0] __wait_on_bit at ffffffff8173fec8 150balbes#6 [ffff8813dedfbb10] out_of_line_wait_on_bit at ffffffff8173ff81 150balbes#7 [ffff8813dedfbb90] __make_buffer_clean at ffffffffa038736f [dm_bufio] 150balbes#8 [ffff8813dedfbbb0] __try_evict_buffer at ffffffffa0387bb8 [dm_bufio] 150balbes#9 [ffff8813dedfbbd0] dm_bufio_shrink_scan at ffffffffa0387cc3 [dm_bufio] 150balbes#10 [ffff8813dedfbc40] shrink_slab at ffffffff811a87ce 150balbes#11 [ffff8813dedfbd30] shrink_zone at ffffffff811ad778 150balbes#12 [ffff8813dedfbdc0] kswapd at ffffffff811ae92f 150balbes#13 [ffff8813dedfbec0] kthread at ffffffff810a8428 150balbes#14 [ffff8813dedfbf50] ret_from_fork at ffffffff81745242 PID: 14127 TASK: ffff881455749c00 CPU: 11 COMMAND: "loop1" #0 [ffff88272f5af228] __schedule at ffffffff8173f405 150balbes#1 [ffff88272f5af280] schedule at ffffffff8173fa27 150balbes#2 [ffff88272f5af2a0] schedule_preempt_disabled at ffffffff8173fd5e 150balbes#3 [ffff88272f5af2b0] __mutex_lock_slowpath at ffffffff81741fb5 150balbes#4 [ffff88272f5af330] mutex_lock at ffffffff81742133 150balbes#5 [ffff88272f5af350] dm_bufio_shrink_count at ffffffffa03865f9 [dm_bufio] 150balbes#6 [ffff88272f5af380] shrink_slab at ffffffff811a86bd 150balbes#7 [ffff88272f5af470] shrink_zone at ffffffff811ad778 150balbes#8 [ffff88272f5af500] do_try_to_free_pages at ffffffff811adb34 150balbes#9 [ffff88272f5af590] try_to_free_pages at ffffffff811adef8 150balbes#10 [ffff88272f5af610] __alloc_pages_nodemask at ffffffff811a09c3 150balbes#11 [ffff88272f5af710] alloc_pages_current at ffffffff811e8b71 150balbes#12 [ffff88272f5af760] new_slab at ffffffff811f4523 150balbes#13 [ffff88272f5af7b0] __slab_alloc at ffffffff8173a1b5 150balbes#14 [ffff88272f5af880] kmem_cache_alloc at ffffffff811f484b 150balbes#15 [ffff88272f5af8d0] do_blockdev_direct_IO at ffffffff812535b3 150balbes#16 [ffff88272f5afb00] __blockdev_direct_IO at ffffffff81255dc3 150balbes#17 [ffff88272f5afb30] xfs_vm_direct_IO at ffffffffa01fe3fc [xfs] 150balbes#18 [ffff88272f5afb90] generic_file_read_iter at ffffffff81198994 150balbes#19 [ffff88272f5afc50] __dta_xfs_file_read_iter_2398 at ffffffffa020c970 [xfs] 150balbes#20 [ffff88272f5afcc0] lo_rw_aio at ffffffffa0377042 [loop] 150balbes#21 [ffff88272f5afd70] loop_queue_work at ffffffffa0377c3b [loop] 150balbes#22 [ffff88272f5afe60] kthread_worker_fn at ffffffff810a8a0c 150balbes#23 [ffff88272f5afec0] kthread at ffffffff810a8428 150balbes#24 [ffff88272f5aff50] ret_from_fork at ffffffff81745242 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
isjerryxiao
pushed a commit
to isjerryxiao/Amlogic_s905-kernel
that referenced
this issue
Oct 1, 2019
commit 5f9242775bb61f390f0885f23fc16397262c7538 upstream. The syzbot fuzzer found a general protection fault in the HID subsystem: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [150balbes#1] SMP KASAN CPU: 0 PID: 3715 Comm: syz-executor.3 Not tainted 5.2.0-rc6+ 150balbes#15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__pm_runtime_resume+0x49/0x180 drivers/base/power/runtime.c:1069 Code: ed 74 d5 fe 45 85 ed 0f 85 9a 00 00 00 e8 6f 73 d5 fe 48 8d bd c1 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 fe 00 00 00 RSP: 0018:ffff8881d99d78e0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000020 RCX: ffffc90003f3f000 RDX: 0000000416d8686d RSI: ffffffff82676841 RDI: 00000020b6c3436a RBP: 00000020b6c340a9 R08: ffff8881c6d64800 R09: fffffbfff0e84c25 R10: ffff8881d99d7940 R11: ffffffff87426127 R12: 0000000000000004 R13: 0000000000000000 R14: ffff8881d9b94000 R15: ffffffff897f9048 FS: 00007f047f542700(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30f21000 CR3: 00000001ca032000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: pm_runtime_get_sync include/linux/pm_runtime.h:226 [inline] usb_autopm_get_interface+0x1b/0x50 drivers/usb/core/driver.c:1707 usbhid_power+0x7c/0xe0 drivers/hid/usbhid/hid-core.c:1234 hid_hw_power include/linux/hid.h:1038 [inline] hidraw_open+0x20d/0x740 drivers/hid/hidraw.c:282 chrdev_open+0x219/0x5c0 fs/char_dev.c:413 do_dentry_open+0x497/0x1040 fs/open.c:778 do_last fs/namei.c:3416 [inline] path_openat+0x1430/0x3ff0 fs/namei.c:3533 do_filp_open+0x1a1/0x280 fs/namei.c:3563 do_sys_open+0x3c0/0x580 fs/open.c:1070 do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe It turns out the fault was caused by a bug in the HID Logitech driver, which violates the requirement that every pathway calling hid_hw_start() must also call hid_hw_stop(). This patch fixes the bug by making sure the requirement is met. Reported-and-tested-by: syzbot+3cbe5cd105d2ad56a1df@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello.
the kernel is very great, but we need the nfs kernel module in phicomm-n1 box, can you complex it within to 5.1 kernel ?
thank you.
The text was updated successfully, but these errors were encountered: