Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

U boot #14

Closed
kelemvor8000 opened this issue May 1, 2019 · 1 comment
Closed

U boot #14

kelemvor8000 opened this issue May 1, 2019 · 1 comment

Comments

@kelemvor8000
Copy link

Can u-boot from one working image be edited so i can boot a odroid c2 image on a s905w tv box
@150balbes
Copy link
Owner

The images for C2 will only work on S905, there are a lot of special patches that won't work on s905w.

isjerryxiao pushed a commit to isjerryxiao/Amlogic_s905-kernel that referenced this issue May 26, 2019
@acmel @isjerryxiao
perf evsel: Free evsel->counts in perf_evsel__exit()
6fba3bd 
[ 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
@changbindu @isjerryxiao
perf tests: Fix a memory leak of cpu_map object in the openat_syscall…
76477e3 
…_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 Jul 15, 2019
@jrfastab @isjerryxiao
bpf: sockmap, fix use after free from sleep in psock backlog workqueue
23a6389 
[ Upstream commit bd95e678e0f6e18351ecdc147ca819145db9ed7b ]

Backlog work for psock (sk_psock_backlog) might sleep while waiting
for memory to free up when sending packets. However, while sleeping
the socket may be closed and removed from the map by the user space
side.

This breaks an assumption in sk_stream_wait_memory, which expects the
wait queue to be still there when it wakes up resulting in a
use-after-free shown below. To fix his mark sendmsg as MSG_DONTWAIT
to avoid the sleep altogether. We already set the flag for the
sendpage case but we missed the case were sendmsg is used.
Sockmap is currently the only user of skb_send_sock_locked() so only
the sockmap paths should be impacted.

==================================================================
BUG: KASAN: use-after-free in remove_wait_queue+0x31/0x70
Write of size 8 at addr ffff888069a0c4e8 by task kworker/0:2/110

CPU: 0 PID: 110 Comm: kworker/0:2 Not tainted 5.0.0-rc2-00335-g28f9d1a3d4fe-dirty 150balbes#14
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
Workqueue: events sk_psock_backlog
Call Trace:
 print_address_description+0x6e/0x2b0
 ? remove_wait_queue+0x31/0x70
 kasan_report+0xfd/0x177
 ? remove_wait_queue+0x31/0x70
 ? remove_wait_queue+0x31/0x70
 remove_wait_queue+0x31/0x70
 sk_stream_wait_memory+0x4dd/0x5f0
 ? sk_stream_wait_close+0x1b0/0x1b0
 ? wait_woken+0xc0/0xc0
 ? tcp_current_mss+0xc5/0x110
 tcp_sendmsg_locked+0x634/0x15d0
 ? tcp_set_state+0x2e0/0x2e0
 ? __kasan_slab_free+0x1d1/0x230
 ? kmem_cache_free+0x70/0x140
 ? sk_psock_backlog+0x40c/0x4b0
 ? process_one_work+0x40b/0x660
 ? worker_thread+0x82/0x680
 ? kthread+0x1b9/0x1e0
 ? ret_from_fork+0x1f/0x30
 ? check_preempt_curr+0xaf/0x130
 ? iov_iter_kvec+0x5f/0x70
 ? kernel_sendmsg_locked+0xa0/0xe0
 skb_send_sock_locked+0x273/0x3c0
 ? skb_splice_bits+0x180/0x180
 ? start_thread+0xe0/0xe0
 ? update_min_vruntime.constprop.27+0x88/0xc0
 sk_psock_backlog+0xb3/0x4b0
 ? strscpy+0xbf/0x1e0
 process_one_work+0x40b/0x660
 worker_thread+0x82/0x680
 ? process_one_work+0x660/0x660
 kthread+0x1b9/0x1e0
 ? __kthread_create_on_node+0x250/0x250
 ret_from_fork+0x1f/0x30

Fixes: 20bf50d ("skbuff: Function to send an skbuf on a socket")
Reported-by: Jakub Sitnicki <jakub@cloudflare.com>
Tested-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
isjerryxiao pushed a commit to isjerryxiao/Amlogic_s905-kernel that referenced this issue Aug 17, 2019
@isjerryxiao
loop: set PF_MEMALLOC_NOIO for the worker thread
d1806e1 
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 Dec 17, 2019
@isjerryxiao
block: fix single range discard merge
52495f5 
commit 2a5cf35 upstream.

There are actually two kinds of discard merge:

- one is the normal discard merge, just like normal read/write request,
and call it single-range discard

- another is the multi-range discard, queue_max_discard_segments(rq->q) > 1

For the former case, queue_max_discard_segments(rq->q) is 1, and we
should handle this kind of discard merge like the normal read/write
request.

This patch fixes the following kernel panic issue[1], which is caused by
not removing the single-range discard request from elevator queue.

Guangwu has one raid discard test case, in which this issue is a bit
easier to trigger, and I verified that this patch can fix the kernel
panic issue in Guangwu's test case.

[1] kernel panic log from Jens's report

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000148
 PGD 0 P4D 0.
 Oops: 0000 [150balbes#1] SMP PTI
 CPU: 37 PID: 763 Comm: kworker/37:1H Not tainted \
4.20.0-rc3-00649-ge64d9a554a91-dirty 150balbes#14  Hardware name: Wiwynn \
Leopard-Orv2/Leopard-DDR BW, BIOS LBM08   03/03/2017       Workqueue: kblockd \
blk_mq_run_work_fn                                            RIP: \
0010:blk_mq_get_driver_tag+0x81/0x120                                       Code: 24 \
10 48 89 7c 24 20 74 21 83 fa ff 0f 95 c0 48 8b 4c 24 28 65 48 33 0c 25 28 00 00 00 \
0f 85 96 00 00 00 48 83 c4 30 5b 5d c3 <48> 8b 87 48 01 00 00 8b 40 04 39 43 20 72 37 \
f6 87 b0 00 00 00 02  RSP: 0018:ffffc90004aabd30 EFLAGS: 00010246                     \
  RAX: 0000000000000003 RBX: ffff888465ea1300 RCX: ffffc90004aabde8
 RDX: 00000000ffffffff RSI: ffffc90004aabde8 RDI: 0000000000000000
 RBP: 0000000000000000 R08: ffff888465ea1348 R09: 0000000000000000
 R10: 0000000000001000 R11: 00000000ffffffff R12: ffff888465ea1300
 R13: 0000000000000000 R14: ffff888465ea1348 R15: ffff888465d10000
 FS:  0000000000000000(0000) GS:ffff88846f9c0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000148 CR3: 000000000220a003 CR4: 00000000003606e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  blk_mq_dispatch_rq_list+0xec/0x480
  ? elv_rb_del+0x11/0x30
  blk_mq_do_dispatch_sched+0x6e/0xf0
  blk_mq_sched_dispatch_requests+0xfa/0x170
  __blk_mq_run_hw_queue+0x5f/0xe0
  process_one_work+0x154/0x350
  worker_thread+0x46/0x3c0
  kthread+0xf5/0x130
  ? process_one_work+0x350/0x350
  ? kthread_destroy_worker+0x50/0x50
  ret_from_fork+0x1f/0x30
 Modules linked in: sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel \
kvm switchtec irqbypass iTCO_wdt iTCO_vendor_support efivars cdc_ether usbnet mii \
cdc_acm i2c_i801 lpc_ich mfd_core ipmi_si ipmi_devintf ipmi_msghandler acpi_cpufreq \
button sch_fq_codel nfsd nfs_acl lockd grace auth_rpcgss oid_registry sunrpc nvme \
nvme_core fuse sg loop efivarfs autofs4  CR2: 0000000000000148                        \

 ---[ end trace 340a1fb996df1b9b ]---
 RIP: 0010:blk_mq_get_driver_tag+0x81/0x120
 Code: 24 10 48 89 7c 24 20 74 21 83 fa ff 0f 95 c0 48 8b 4c 24 28 65 48 33 0c 25 28 \
00 00 00 0f 85 96 00 00 00 48 83 c4 30 5b 5d c3 <48> 8b 87 48 01 00 00 8b 40 04 39 43 \
20 72 37 f6 87 b0 00 00 00 02

Fixes: 445251d ("blk-mq: fix discard merge with scheduler attached")
Reported-by: Jens Axboe <axboe@kernel.dk>
Cc: Guangwu Zhang <guazhang@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jianchao Wang <jianchao.w.wang@oracle.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Cc: Andre Tomt <andre@tomt.net>
Cc: Jack Wang <jack.wang.usish@gmail.com>
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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@150balbes @kelemvor8000