config v20190319 has a problem #10
Comments
|
It is not clear that do not work. Write detailed steps. |
isjerryxiao
pushed a commit
to isjerryxiao/Amlogic_s905-kernel
that referenced
this issue
Apr 12, 2019
commit fa30dde38aa8628c73a6dded7cb0bba38c27b576 upstream. We see the following NULL pointer dereference while running xfstests generic/475: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 PGD 8000000c84bad067 P4D 8000000c84bad067 PUD c84e62067 PMD 0 Oops: 0000 [150balbes#1] SMP PTI CPU: 7 PID: 9886 Comm: fsstress Kdump: loaded Not tainted 5.0.0-rc8 150balbes#10 RIP: 0010:ext4_do_update_inode+0x4ec/0x760 ... Call Trace: ? jbd2_journal_get_write_access+0x42/0x50 ? __ext4_journal_get_write_access+0x2c/0x70 ? ext4_truncate+0x186/0x3f0 ext4_mark_iloc_dirty+0x61/0x80 ext4_mark_inode_dirty+0x62/0x1b0 ext4_truncate+0x186/0x3f0 ? unmap_mapping_pages+0x56/0x100 ext4_setattr+0x817/0x8b0 notify_change+0x1df/0x430 do_truncate+0x5e/0x90 ? generic_permission+0x12b/0x1a0 This is triggered because the NULL pointer handle->h_transaction was dereferenced in function ext4_update_inode_fsync_trans(). I found that the h_transaction was set to NULL in jbd2__journal_restart but failed to attached to a new transaction while the journal is aborted. Fix this by checking the handle before updating the inode. Fixes: b436b9b ("ext4: Wait for proper transaction commit on fsync") Signed-off-by: Jiufei Xue <jiufei.xue@linux.alibaba.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: stable@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
…_map
[ Upstream commit 39df730b09774bd860e39ea208a48d15078236cb ]
Detected via gcc's ASan:
Direct leak of 2048 byte(s) in 64 object(s) allocated from:
6 #0 0x7f606512e370 in __interceptor_realloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee370)
7 150balbes#1 0x556b0f1d7ddd in thread_map__realloc util/thread_map.c:43
8 150balbes#2 0x556b0f1d84c7 in thread_map__new_by_tid util/thread_map.c:85
9 150balbes#3 0x556b0f0e045e in is_event_supported util/parse-events.c:2250
10 150balbes#4 0x556b0f0e1aa1 in print_hwcache_events util/parse-events.c:2382
11 150balbes#5 0x556b0f0e3231 in print_events util/parse-events.c:2514
12 150balbes#6 0x556b0ee0a66e in cmd_list /home/changbin/work/linux/tools/perf/builtin-list.c:58
13 150balbes#7 0x556b0f01e0ae in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
14 150balbes#8 0x556b0f01e859 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
15 150balbes#9 0x556b0f01edc8 in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
16 150balbes#10 0x556b0f01f71f in main /home/changbin/work/linux/tools/perf/perf.c:520
17 150balbes#11 0x7f6062ccf09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes: 8989605 ("perf tools: Do not put a variable sized type not at the end of a struct")
Link: http://lkml.kernel.org/r/20190316080556.3075-3-changbin.du@gmail.com
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
May 26, 2019
[ Upstream commit 54569ba4b06d5baedae4614bde33a25a191473ba ]
Detected with gcc's ASan:
Direct leak of 66 byte(s) in 5 object(s) allocated from:
#0 0x7ff3b1f32070 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
150balbes#1 0x560c8761034d in collect_config util/config.c:597
150balbes#2 0x560c8760d9cb in get_value util/config.c:169
150balbes#3 0x560c8760dfd7 in perf_parse_file util/config.c:285
150balbes#4 0x560c8760e0d2 in perf_config_from_file util/config.c:476
150balbes#5 0x560c876108fd in perf_config_set__init util/config.c:661
150balbes#6 0x560c87610c72 in perf_config_set__new util/config.c:709
150balbes#7 0x560c87610d2f in perf_config__init util/config.c:718
150balbes#8 0x560c87610e5d in perf_config util/config.c:730
150balbes#9 0x560c875ddea0 in main /home/changbin/work/linux/tools/perf/perf.c:442
150balbes#10 0x7ff3afb8609a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Taeung Song <treeze.taeung@gmail.com>
Fixes: 20105ca ("perf config: Introduce perf_config_set class")
Link: http://lkml.kernel.org/r/20190316080556.3075-6-changbin.du@gmail.com
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
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
May 26, 2019
…_event_on_all_cpus test
[ Upstream commit 93faa52e8371f0291ee1ff4994edae2b336b6233 ]
=================================================================
==7497==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a88f30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
150balbes#1 0x5625e5326213 in cpu_map__trim_new util/cpumap.c:45
150balbes#2 0x5625e5326703 in cpu_map__read util/cpumap.c:103
150balbes#3 0x5625e53267ef in cpu_map__read_all_cpu_map util/cpumap.c:120
150balbes#4 0x5625e5326915 in cpu_map__new util/cpumap.c:135
150balbes#5 0x5625e517b355 in test__openat_syscall_event_on_all_cpus tests/openat-syscall-all-cpus.c:36
150balbes#6 0x5625e51528e6 in run_test tests/builtin-test.c:358
150balbes#7 0x5625e5152baf in test_and_print tests/builtin-test.c:388
150balbes#8 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
150balbes#9 0x5625e515572f in cmd_test tests/builtin-test.c:722
150balbes#10 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
150balbes#11 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
150balbes#12 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
150balbes#13 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
150balbes#14 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes: f30a79b ("perf tools: Add reference counting for cpu_map object")
Link: http://lkml.kernel.org/r/20190316080556.3075-15-changbin.du@gmail.com
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
May 26, 2019
[ Upstream commit f97a8991d3b998e518f56794d879f645964de649 ]
=================================================================
==7506==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 13 byte(s) in 3 object(s) allocated from:
#0 0x7f03339d6070 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
150balbes#1 0x5625e53aaef0 in expr__find_other util/expr.y:221
150balbes#2 0x5625e51bcd3f in test__expr tests/expr.c:52
150balbes#3 0x5625e51528e6 in run_test tests/builtin-test.c:358
150balbes#4 0x5625e5152baf in test_and_print tests/builtin-test.c:388
150balbes#5 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
150balbes#6 0x5625e515572f in cmd_test tests/builtin-test.c:722
150balbes#7 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
150balbes#8 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
150balbes#9 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
150balbes#10 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
150balbes#11 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
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>
Fixes: 0751673 ("perf tools: Add a simple expression parser for JSON")
Link: http://lkml.kernel.org/r/20190316080556.3075-16-changbin.du@gmail.com
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
May 26, 2019
[ Upstream commit d982b33133284fa7efa0e52ae06b88f9be3ea764 ]
=================================================================
==20875==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1160 byte(s) in 1 object(s) allocated from:
#0 0x7f1b6fc84138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
150balbes#1 0x55bd50005599 in zalloc util/util.h:23
150balbes#2 0x55bd500068f5 in perf_evsel__newtp_idx util/evsel.c:327
150balbes#3 0x55bd4ff810fc in perf_evsel__newtp /home/work/linux/tools/perf/util/evsel.h:216
150balbes#4 0x55bd4ff81608 in test__perf_evsel__tp_sched_test tests/evsel-tp-sched.c:69
150balbes#5 0x55bd4ff528e6 in run_test tests/builtin-test.c:358
150balbes#6 0x55bd4ff52baf in test_and_print tests/builtin-test.c:388
150balbes#7 0x55bd4ff543fe in __cmd_test tests/builtin-test.c:583
150balbes#8 0x55bd4ff5572f in cmd_test tests/builtin-test.c:722
150balbes#9 0x55bd4ffc4087 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
150balbes#10 0x55bd4ffc45c6 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
150balbes#11 0x55bd4ffc49ca in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
150balbes#12 0x55bd4ffc5138 in main /home/changbin/work/linux/tools/perf/perf.c:520
150balbes#13 0x7f1b6e34809a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Indirect leak of 19 byte(s) in 1 object(s) allocated from:
#0 0x7f1b6fc83f30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
150balbes#1 0x7f1b6e3ac30f in vasprintf (/lib/x86_64-linux-gnu/libc.so.6+0x8830f)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes: 6a6cd11 ("perf test: Add test for the sched tracepoint format fields")
Link: http://lkml.kernel.org/r/20190316080556.3075-17-changbin.du@gmail.com
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
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
Sep 16, 2019
[ Upstream commit b57a55e2200ede754e4dc9cce4ba9402544b9365 ] There is a KASAN slab-out-of-bounds: BUG: KASAN: slab-out-of-bounds in _copy_from_iter_full+0x783/0xaa0 Read of size 80 at addr ffff88810c35e180 by task mount.cifs/539 CPU: 1 PID: 539 Comm: mount.cifs Not tainted 4.19 150balbes#10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xdd/0x12a print_address_description+0xa7/0x540 kasan_report+0x1ff/0x550 check_memory_region+0x2f1/0x310 memcpy+0x2f/0x80 _copy_from_iter_full+0x783/0xaa0 tcp_sendmsg_locked+0x1840/0x4140 tcp_sendmsg+0x37/0x60 inet_sendmsg+0x18c/0x490 sock_sendmsg+0xae/0x130 smb_send_kvec+0x29c/0x520 __smb_send_rqst+0x3ef/0xc60 smb_send_rqst+0x25a/0x2e0 compound_send_recv+0x9e8/0x2af0 cifs_send_recv+0x24/0x30 SMB2_open+0x35e/0x1620 open_shroot+0x27b/0x490 smb2_open_op_close+0x4e1/0x590 smb2_query_path_info+0x2ac/0x650 cifs_get_inode_info+0x1058/0x28f0 cifs_root_iget+0x3bb/0xf80 cifs_smb3_do_mount+0xe00/0x14c0 cifs_do_mount+0x15/0x20 mount_fs+0x5e/0x290 vfs_kern_mount+0x88/0x460 do_mount+0x398/0x31e0 ksys_mount+0xc6/0x150 __x64_sys_mount+0xea/0x190 do_syscall_64+0x122/0x590 entry_SYSCALL_64_after_hwframe+0x44/0xa9 It can be reproduced by the following step: 1. samba configured with: server max protocol = SMB2_10 2. mount -o vers=default When parse the mount version parameter, the 'ops' and 'vals' was setted to smb30, if negotiate result is smb21, just update the 'ops' to smb21, but the 'vals' is still smb30. When add lease context, the iov_base is allocated with smb21 ops, but the iov_len is initiallited with the smb30. Because the iov_len is longer than iov_base, when send the message, copy array out of bounds. we need to keep the 'ops' and 'vals' consistent. Fixes: 9764c02 ("SMB3: Add support for multidialect negotiate (SMB2.1 and later)") Fixes: d5c7076b772a ("smb3: add smb3.1.1 to default dialect list") Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com> Signed-off-by: Steve French <stfrench@microsoft.com> CC: Stable <stable@vger.kernel.org> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
isjerryxiao
pushed a commit
to isjerryxiao/Amlogic_s905-kernel
that referenced
this issue
Dec 31, 2019
[ Upstream commit 6ee40511cb838f9ced002dff7131bca87e3ccbdd ] Fail to allocate memory for tgid_map, because it requires order-6 page. detail as: c3 sh: page allocation failure: order:6, mode:0x140c0c0(GFP_KERNEL), nodemask=(null) c3 sh cpuset=/ mems_allowed=0 c3 CPU: 3 PID: 5632 Comm: sh Tainted: G W O 4.14.133+ 150balbes#10 c3 Hardware name: Generic DT based system c3 Backtrace: c3 [<c010bdbc>] (dump_backtrace) from [<c010c08c>](show_stack+0x18/0x1c) c3 [<c010c074>] (show_stack) from [<c0993c54>](dump_stack+0x84/0xa4) c3 [<c0993bd0>] (dump_stack) from [<c0229858>](warn_alloc+0xc4/0x19c) c3 [<c0229798>] (warn_alloc) from [<c022a6e4>](__alloc_pages_nodemask+0xd18/0xf28) c3 [<c02299cc>] (__alloc_pages_nodemask) from [<c0248344>](kmalloc_order+0x20/0x38) c3 [<c0248324>] (kmalloc_order) from [<c0248380>](kmalloc_order_trace+0x24/0x108) c3 [<c024835c>] (kmalloc_order_trace) from [<c01e6078>](set_tracer_flag+0xb0/0x158) c3 [<c01e5fc8>] (set_tracer_flag) from [<c01e6404>](trace_options_core_write+0x7c/0xcc) c3 [<c01e6388>] (trace_options_core_write) from [<c0278b1c>](__vfs_write+0x40/0x14c) c3 [<c0278adc>] (__vfs_write) from [<c0278e10>](vfs_write+0xc4/0x198) c3 [<c0278d4c>] (vfs_write) from [<c027906c>](SyS_write+0x6c/0xd0) c3 [<c0279000>] (SyS_write) from [<c01079a0>](ret_fast_syscall+0x0/0x54) Switch to use kvcalloc to avoid unexpected allocation failures. Link: http://lkml.kernel.org/r/1571888070-24425-1-git-send-email-chunyan.zhang@unisoc.com Signed-off-by: Yuming Han <yuming.han@unisoc.com> Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I compile kernel with "config v20190319" , it will report an error:" ‘kernel/config_data.gz’ need a target ‘.config’ ". It can be solved by choose "Kernel .config support".
The text was updated successfully, but these errors were encountered: