Added TTL, HL , IPSET support #14
Open
Conversation
This file contains 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
turex
pushed a commit
to turex/labyrinth_kernel_prague
that referenced
this pull request
Nov 7, 2021
[ 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)
Dil3mm4#1 0x5625e5330a5e in zalloc util/util.h:23
Dil3mm4#2 0x5625e5330a9b in perf_counts__new util/counts.c:10
Dil3mm4#3 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
Dil3mm4#4 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
Dil3mm4#5 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
Dil3mm4#6 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
Dil3mm4#7 0x5625e51528e6 in run_test tests/builtin-test.c:358
Dil3mm4#8 0x5625e5152baf in test_and_print tests/builtin-test.c:388
Dil3mm4#9 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
Dil3mm4#10 0x5625e515572f in cmd_test tests/builtin-test.c:722
Dil3mm4#11 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
Dil3mm4#12 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
Dil3mm4#13 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
Dil3mm4#14 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#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)
Dil3mm4#1 0x5625e532560d in zalloc util/util.h:23
Dil3mm4#2 0x5625e532566b in xyarray__new util/xyarray.c:10
Dil3mm4#3 0x5625e5330aba in perf_counts__new util/counts.c:15
Dil3mm4#4 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
Dil3mm4#5 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
Dil3mm4#6 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
Dil3mm4#7 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
Dil3mm4#8 0x5625e51528e6 in run_test tests/builtin-test.c:358
Dil3mm4#9 0x5625e5152baf in test_and_print tests/builtin-test.c:388
Dil3mm4#10 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
Dil3mm4#11 0x5625e515572f in cmd_test tests/builtin-test.c:722
Dil3mm4#12 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
Dil3mm4#13 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
Dil3mm4#14 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#15 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#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 <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Steven Rostedt (VMware) <[email protected]>
Link: https://lkml.kernel.org/n/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
turex
pushed a commit
to turex/labyrinth_kernel_prague
that referenced
this pull request
Nov 7, 2021
…_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)
Dil3mm4#1 0x5625e5326213 in cpu_map__trim_new util/cpumap.c:45
Dil3mm4#2 0x5625e5326703 in cpu_map__read util/cpumap.c:103
Dil3mm4#3 0x5625e53267ef in cpu_map__read_all_cpu_map util/cpumap.c:120
Dil3mm4#4 0x5625e5326915 in cpu_map__new util/cpumap.c:135
Dil3mm4#5 0x5625e517b355 in test__openat_syscall_event_on_all_cpus tests/openat-syscall-all-cpus.c:36
Dil3mm4#6 0x5625e51528e6 in run_test tests/builtin-test.c:358
Dil3mm4#7 0x5625e5152baf in test_and_print tests/builtin-test.c:388
Dil3mm4#8 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
Dil3mm4#9 0x5625e515572f in cmd_test tests/builtin-test.c:722
Dil3mm4#10 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
Dil3mm4#11 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
Dil3mm4#12 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
Dil3mm4#13 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
Dil3mm4#14 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Signed-off-by: Changbin Du <[email protected]>
Reviewed-by: Jiri Olsa <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Steven Rostedt (VMware) <[email protected]>
Fixes: f30a79b ("perf tools: Add reference counting for cpu_map object")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
turex
pushed a commit
to turex/labyrinth_kernel_prague
that referenced
this pull request
Nov 8, 2021
commit cf3591ef832915892f2499b7e54b51d4c578b28c upstream.
Revert the commit bd293d071ffe65e645b4d8104f9d8fe15ea13862. The proper
fix has been made available with commit d0a255e795ab ("loop: set
PF_MEMALLOC_NOIO for the worker thread").
Note that the fix offered by commit bd293d071ffe doesn't really prevent
the deadlock from occuring - if we look at the stacktrace reported by
Junxiao Bi, we see that it hangs in bit_wait_io and not on the mutex -
i.e. it has already successfully taken the mutex. Changing the mutex
from mutex_lock to mutex_trylock won't help with deadlocks that happen
afterwards.
PID: 474 TASK: ffff8813e11f4600 CPU: 10 COMMAND: "kswapd0"
#0 [ffff8813dedfb938] __schedule at ffffffff8173f405
Dil3mm4#1 [ffff8813dedfb990] schedule at ffffffff8173fa27
Dil3mm4#2 [ffff8813dedfb9b0] schedule_timeout at ffffffff81742fec
Dil3mm4#3 [ffff8813dedfba60] io_schedule_timeout at ffffffff8173f186
Dil3mm4#4 [ffff8813dedfbaa0] bit_wait_io at ffffffff8174034f
Dil3mm4#5 [ffff8813dedfbac0] __wait_on_bit at ffffffff8173fec8
Dil3mm4#6 [ffff8813dedfbb10] out_of_line_wait_on_bit at ffffffff8173ff81
Dil3mm4#7 [ffff8813dedfbb90] __make_buffer_clean at ffffffffa038736f [dm_bufio]
Dil3mm4#8 [ffff8813dedfbbb0] __try_evict_buffer at ffffffffa0387bb8 [dm_bufio]
Dil3mm4#9 [ffff8813dedfbbd0] dm_bufio_shrink_scan at ffffffffa0387cc3 [dm_bufio]
Dil3mm4#10 [ffff8813dedfbc40] shrink_slab at ffffffff811a87ce
Dil3mm4#11 [ffff8813dedfbd30] shrink_zone at ffffffff811ad778
Dil3mm4#12 [ffff8813dedfbdc0] kswapd at ffffffff811ae92f
Dil3mm4#13 [ffff8813dedfbec0] kthread at ffffffff810a8428
Dil3mm4#14 [ffff8813dedfbf50] ret_from_fork at ffffffff81745242
Signed-off-by: Mikulas Patocka <[email protected]>
Cc: [email protected]
Fixes: bd293d071ffe ("dm bufio: fix deadlock with loop device")
Depends-on: d0a255e795ab ("loop: set PF_MEMALLOC_NOIO for the worker thread")
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
turex
pushed a commit
to turex/labyrinth_kernel_prague
that referenced
this pull request
Nov 9, 2021
[ Upstream commit e24c6447ccb7b1a01f9bf0aec94939e6450c0b4d ]
I compiled with AddressSanitizer and I had these memory leaks while I
was using the tep_parse_format function:
Direct leak of 28 byte(s) in 4 object(s) allocated from:
#0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
Dil3mm4#1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985
Dil3mm4#2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140
Dil3mm4#3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206
Dil3mm4#4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291
Dil3mm4#5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299
Dil3mm4#6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849
Dil3mm4#7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161
Dil3mm4#8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207
Dil3mm4#9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786
Dil3mm4#10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285
Dil3mm4#11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369
Dil3mm4#12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335
Dil3mm4#13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389
Dil3mm4#14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431
#15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251
#16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284
#17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593
#18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727
#19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048
#20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127
#21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152
#22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252
#23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347
#24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461
#25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673
#26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
The token variable in the process_dynamic_array_len function is
allocated in the read_expect_type function, but is not freed before
calling the read_token function.
Free the token variable before calling read_token in order to plug the
leak.
Signed-off-by: Philippe Duplessis-Guindon <[email protected]>
Reviewed-by: Steven Rostedt (VMware) <[email protected]>
Link: https://lore.kernel.org/linux-trace-devel/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
turex
pushed a commit
to turex/labyrinth_kernel_prague
that referenced
this pull request
Dec 1, 2021
... before the first use of kaiser_enabled as otherwise funky things happen: about to get started... (XEN) d0v0 Unhandled page fault fault/trap [Dil3mm4#14, ec=0000] (XEN) Pagetable walk from ffff88022a449090: (XEN) L4[0x110] = 0000000229e0e067 0000000000001e0e (XEN) L3[0x008] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S: fault at ffff82d08033fd08 entry.o#create_bounce_frame+0x135/0x14d (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-4.9.1_02-3.21 x86_64 debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e033:[<ffffffff81007460>] (XEN) RFLAGS: 0000000000000286 EM: 1 CONTEXT: pv guest (d0v0) Signed-off-by: Borislav Petkov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
turex
pushed a commit
to turex/labyrinth_kernel_prague
that referenced
this pull request
Dec 2, 2021
[ Upstream commit 2bbea6e117357d17842114c65e9a9cf2d13ae8a3 ] when mounting an ISO filesystem sometimes (very rarely) the system hangs because of a race condition between two tasks. PID: 6766 TASK: ffff88007b2a6dd0 CPU: 0 COMMAND: "mount" #0 [ffff880078447ae0] __schedule at ffffffff8168d605 Dil3mm4#1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49 Dil3mm4#2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995 Dil3mm4#3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef Dil3mm4#4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod] Dil3mm4#5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50 Dil3mm4#6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3 Dil3mm4#7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs] Dil3mm4#8 [ffff880078447da8] mount_bdev at ffffffff81202570 Dil3mm4#9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs] Dil3mm4#10 [ffff880078447e28] mount_fs at ffffffff81202d09 Dil3mm4#11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f Dil3mm4#12 [ffff880078447ea8] do_mount at ffffffff81220fee Dil3mm4#13 [ffff880078447f28] sys_mount at ffffffff812218d6 Dil3mm4#14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49 RIP: 00007fd9ea914e9a RSP: 00007ffd5d9bf648 RFLAGS: 00010246 RAX: 00000000000000a5 RBX: ffffffff81698c49 RCX: 0000000000000010 RDX: 00007fd9ec2bc210 RSI: 00007fd9ec2bc290 RDI: 00007fd9ec2bcf30 RBP: 0000000000000000 R8: 0000000000000000 R9: 0000000000000010 R10: 00000000c0ed0001 R11: 0000000000000206 R12: 00007fd9ec2bc040 R13: 00007fd9eb6b2380 R14: 00007fd9ec2bc210 R15: 00007fd9ec2bcf30 ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002b This task was trying to mount the cdrom. It allocated and configured a super_block struct and owned the write-lock for the super_block->s_umount rwsem. While exclusively owning the s_umount lock, it called sr_block_ioctl and waited to acquire the global sr_mutex lock. PID: 6785 TASK: ffff880078720fb0 CPU: 0 COMMAND: "systemd-udevd" #0 [ffff880078417898] __schedule at ffffffff8168d605 Dil3mm4#1 [ffff880078417900] schedule at ffffffff8168dc59 Dil3mm4#2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605 Dil3mm4#3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838 Dil3mm4#4 [ffff8800784179d0] down_read at ffffffff8168cde0 Dil3mm4#5 [ffff8800784179e8] get_super at ffffffff81201cc7 Dil3mm4#6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de Dil3mm4#7 [ffff880078417a40] flush_disk at ffffffff8123a94b Dil3mm4#8 [ffff880078417a88] check_disk_change at ffffffff8123ab50 Dil3mm4#9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom] Dil3mm4#10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod] Dil3mm4#11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86 Dil3mm4#12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65 Dil3mm4#13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b Dil3mm4#14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7 #15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf #16 [ffff880078417d00] do_last at ffffffff8120d53d #17 [ffff880078417db0] path_openat at ffffffff8120e6b2 #18 [ffff880078417e48] do_filp_open at ffffffff8121082b #19 [ffff880078417f18] do_sys_open at ffffffff811fdd33 #20 [ffff880078417f70] sys_open at ffffffff811fde4e #21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49 RIP: 00007f29438b0c20 RSP: 00007ffc76624b78 RFLAGS: 00010246 RAX: 0000000000000002 RBX: ffffffff81698c49 RCX: 0000000000000000 RDX: 00007f2944a5fa70 RSI: 00000000000a0800 RDI: 00007f2944a5fa70 RBP: 00007f2944a5f540 R8: 0000000000000000 R9: 0000000000000020 R10: 00007f2943614c40 R11: 0000000000000246 R12: ffffffff811fde4e R13: ffff880078417f78 R14: 000000000000000c R15: 00007f2944a4b010 ORIG_RAX: 0000000000000002 CS: 0033 SS: 002b This task tried to open the cdrom device, the sr_block_open function acquired the global sr_mutex lock. The call to check_disk_change() then saw an event flag indicating a possible media change and tried to flush any cached data for the device. As part of the flush, it tried to acquire the super_block->s_umount lock associated with the cdrom device. This was the same super_block as created and locked by the previous task. The first task acquires the s_umount lock and then the sr_mutex_lock; the second task acquires the sr_mutex_lock and then the s_umount lock. This patch fixes the issue by moving check_disk_change() out of cdrom_open() and let the caller take care of it. Signed-off-by: Maurizio Lombardi <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
turex
pushed a commit
to turex/labyrinth_kernel_prague
that referenced
this pull request
Dec 7, 2021
[ Upstream commit ae460c115b7aa50c9a36cf78fced07b27962c9d0 ] On our AT91SAM9260 board we use the same sdio bus for wifi and for the sd card slot. This caused the atmel-mci to give the following splat on the serial console: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 538 at drivers/mmc/host/atmel-mci.c:859 atmci_send_command+0x24/0x44 Modules linked in: CPU: 0 PID: 538 Comm: mmcqd/0 Not tainted 4.14.76 Dil3mm4#14 Hardware name: Atmel AT91SAM9 [<c000fccc>] (unwind_backtrace) from [<c000d3dc>] (show_stack+0x10/0x14) [<c000d3dc>] (show_stack) from [<c0017644>] (__warn+0xd8/0xf4) [<c0017644>] (__warn) from [<c0017704>] (warn_slowpath_null+0x1c/0x24) [<c0017704>] (warn_slowpath_null) from [<c033bb9c>] (atmci_send_command+0x24/0x44) [<c033bb9c>] (atmci_send_command) from [<c033e984>] (atmci_start_request+0x1f4/0x2dc) [<c033e984>] (atmci_start_request) from [<c033f3b4>] (atmci_request+0xf0/0x164) [<c033f3b4>] (atmci_request) from [<c0327108>] (mmc_start_request+0x280/0x2d0) [<c0327108>] (mmc_start_request) from [<c032800c>] (mmc_start_areq+0x230/0x330) [<c032800c>] (mmc_start_areq) from [<c03366f8>] (mmc_blk_issue_rw_rq+0xc4/0x310) [<c03366f8>] (mmc_blk_issue_rw_rq) from [<c03372c4>] (mmc_blk_issue_rq+0x118/0x5ac) [<c03372c4>] (mmc_blk_issue_rq) from [<c033781c>] (mmc_queue_thread+0xc4/0x118) [<c033781c>] (mmc_queue_thread) from [<c002daf8>] (kthread+0x100/0x118) [<c002daf8>] (kthread) from [<c000a580>] (ret_from_fork+0x14/0x34) ---[ end trace 594371ddfa284bd6 ]--- This is: WARN_ON(host->cmd); This was fixed on our board by letting atmci_request_end determine what state we are in. Instead of unconditionally setting it to STATE_IDLE on STATE_END_REQUEST. Signed-off-by: Jonas Danielsson <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
turex
pushed a commit
to turex/labyrinth_kernel_prague
that referenced
this pull request
Dec 9, 2021
[ Upstream commit ae460c115b7aa50c9a36cf78fced07b27962c9d0 ] On our AT91SAM9260 board we use the same sdio bus for wifi and for the sd card slot. This caused the atmel-mci to give the following splat on the serial console: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 538 at drivers/mmc/host/atmel-mci.c:859 atmci_send_command+0x24/0x44 Modules linked in: CPU: 0 PID: 538 Comm: mmcqd/0 Not tainted 4.14.76 Dil3mm4#14 Hardware name: Atmel AT91SAM9 [<c000fccc>] (unwind_backtrace) from [<c000d3dc>] (show_stack+0x10/0x14) [<c000d3dc>] (show_stack) from [<c0017644>] (__warn+0xd8/0xf4) [<c0017644>] (__warn) from [<c0017704>] (warn_slowpath_null+0x1c/0x24) [<c0017704>] (warn_slowpath_null) from [<c033bb9c>] (atmci_send_command+0x24/0x44) [<c033bb9c>] (atmci_send_command) from [<c033e984>] (atmci_start_request+0x1f4/0x2dc) [<c033e984>] (atmci_start_request) from [<c033f3b4>] (atmci_request+0xf0/0x164) [<c033f3b4>] (atmci_request) from [<c0327108>] (mmc_start_request+0x280/0x2d0) [<c0327108>] (mmc_start_request) from [<c032800c>] (mmc_start_areq+0x230/0x330) [<c032800c>] (mmc_start_areq) from [<c03366f8>] (mmc_blk_issue_rw_rq+0xc4/0x310) [<c03366f8>] (mmc_blk_issue_rw_rq) from [<c03372c4>] (mmc_blk_issue_rq+0x118/0x5ac) [<c03372c4>] (mmc_blk_issue_rq) from [<c033781c>] (mmc_queue_thread+0xc4/0x118) [<c033781c>] (mmc_queue_thread) from [<c002daf8>] (kthread+0x100/0x118) [<c002daf8>] (kthread) from [<c000a580>] (ret_from_fork+0x14/0x34) ---[ end trace 594371ddfa284bd6 ]--- This is: WARN_ON(host->cmd); This was fixed on our board by letting atmci_request_end determine what state we are in. Instead of unconditionally setting it to STATE_IDLE on STATE_END_REQUEST. Signed-off-by: Jonas Danielsson <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Added TTL, HL , IPSET support