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

[i2c-aspeed] ERROR: Bad of_node_put() #112

Open
ya-mouse opened this issue Nov 10, 2016 · 0 comments
Open

[i2c-aspeed] ERROR: Bad of_node_put() #112

ya-mouse opened this issue Nov 10, 2016 · 0 comments

Comments

@ya-mouse
Copy link

I still have an ERROR on of_node_put. If I just comment it out, everything seems ok.

Log trace:

[    0.720000] i2c_aspeed 1e78a000.i2c: i2c controller registered, irq 20
[    0.720000] ERROR: Bad of_node_put() on /ahb/apb/i2c@1e78a000/i2c-bus@40
[    0.720000] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.10-8c7da38063c14868eab25e9d3273b6e6c304f4be #1
[    0.720000] Hardware name: ASpeed SoC
[    0.720000] [<c0106cfc>] (unwind_backtrace) from [<c0104f04>] (show_stack+0x10/0x14)
[    0.720000] [<c0104f04>] (show_stack) from [<c02720ac>] (kobject_put+0x178/0x1f4)
[    0.720000] [<c02720ac>] (kobject_put) from [<c02f9d24>] (__of_get_next_child+0x40/0x48)
[    0.720000] [<c02f9d24>] (__of_get_next_child) from [<c02fa314>] (of_get_next_child+0x14/0x1c)
[    0.720000] [<c02fa314>] (of_get_next_child) from [<c02ee1e4>] (ast_i2c_probe+0x160/0x420)
[    0.720000] [<c02ee1e4>] (ast_i2c_probe) from [<c02baecc>] (platform_drv_probe+0x38/0x6c)
[    0.720000] [<c02baecc>] (platform_drv_probe) from [<c02b9ae4>] (driver_probe_device+0x1ac/0x3d8)
[    0.720000] [<c02b9ae4>] (driver_probe_device) from [<c02b9dd8>] (__driver_attach+0xc8/0x108)
[    0.720000] [<c02b9dd8>] (__driver_attach) from [<c02b7f7c>] (bus_for_each_dev+0x78/0xb4)
[    0.720000] [<c02b7f7c>] (bus_for_each_dev) from [<c02b87f0>] (bus_add_driver+0x110/0x230)
[    0.720000] [<c02b87f0>] (bus_add_driver) from [<c02ba4a4>] (driver_register+0x9c/0xe0)
[    0.720000] [<c02ba4a4>] (driver_register) from [<c0500e4c>] (do_one_initcall+0xb8/0x17c)
[    0.720000] [<c0500e4c>] (do_one_initcall) from [<c0501010>] (kernel_init_freeable+0x100/0x1c4)
[    0.720000] [<c0501010>] (kernel_init_freeable) from [<c03f18e8>] (kernel_init+0x8/0x10c)
[    0.720000] [<c03f18e8>] (kernel_init) from [<c0102250>] (ret_from_fork+0x14/0x24)
[    0.920000] ERROR: Bad of_node_put() on /ahb/apb/i2c@1e78a000/i2c-bus@80
...
[    0.920000] ERROR: Bad of_node_put() on /ahb/apb/i2c@1e78a000/i2c-bus@c0
...
[    1.240000] ERROR: Bad of_node_put() on /ahb/apb/i2c@1e78a000/i2c-bus@100
shenki pushed a commit that referenced this issue Jul 30, 2018
@gregkh
net: dccp: avoid crash in ccid3_hc_rx_send_feedback()
2d0624c 
[ Upstream commit 74174fe ]

On fast hosts or malicious bots, we trigger a DCCP_BUG() which
seems excessive.

syzbot reported :

BUG: delta (-6195) <= 0 at net/dccp/ccids/ccid3.c:628/ccid3_hc_rx_send_feedback()
CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.18.0-rc1+ #112
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
 ccid3_hc_rx_send_feedback net/dccp/ccids/ccid3.c:628 [inline]
 ccid3_hc_rx_packet_recv.cold.16+0x38/0x71 net/dccp/ccids/ccid3.c:793
 ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
 dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
 dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
 dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
 sk_backlog_rcv include/net/sock.h:914 [inline]
 __sk_receive_skb+0x3ba/0xd80 net/core/sock.c:517
 dccp_v4_rcv+0x10f9/0x1f58 net/dccp/ipv4.c:875
 ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215
 NF_HOOK include/linux/netfilter.h:287 [inline]
 ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256
 dst_input include/net/dst.h:450 [inline]
 ip_rcv_finish+0x823/0x2220 net/ipv4/ip_input.c:396
 NF_HOOK include/linux/netfilter.h:287 [inline]
 ip_rcv+0xa18/0x1284 net/ipv4/ip_input.c:492
 __netif_receive_skb_core+0x2488/0x3680 net/core/dev.c:4628
 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4693
 process_backlog+0x219/0x760 net/core/dev.c:5373
 napi_poll net/core/dev.c:5771 [inline]
 net_rx_action+0x7da/0x1980 net/core/dev.c:5837
 __do_softirq+0x2e8/0xb17 kernel/softirq.c:284
 run_ksoftirqd+0x86/0x100 kernel/softirq.c:645
 smpboot_thread_fn+0x417/0x870 kernel/smpboot.c:164
 kthread+0x345/0x410 kernel/kthread.c:240
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Cc: dccp@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
shenki pushed a commit that referenced this issue Jul 22, 2020
@prabhakarlad @gregkh
serial: sh-sci: Initialize spinlock for uart console
785dcb1 
commit f38278e upstream.

serial core expects the spinlock to be initialized by the controller
driver for serial console, this patch makes sure the spinlock is
initialized, fixing the below issue:

[    0.865928] BUG: spinlock bad magic on CPU#0, swapper/0/1
[    0.865945]  lock: sci_ports+0x0/0x4c80, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[    0.865955] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc1+ #112
[    0.865961] Hardware name: HopeRun HiHope RZ/G2H with sub board (DT)
[    0.865968] Call trace:
[    0.865979]  dump_backtrace+0x0/0x1d8
[    0.865985]  show_stack+0x14/0x20
[    0.865996]  dump_stack+0xe8/0x130
[    0.866006]  spin_dump+0x6c/0x88
[    0.866012]  do_raw_spin_lock+0xb0/0xf8
[    0.866023]  _raw_spin_lock_irqsave+0x80/0xa0
[    0.866032]  uart_add_one_port+0x3a4/0x4e0
[    0.866039]  sci_probe+0x504/0x7c8
[    0.866048]  platform_drv_probe+0x50/0xa0
[    0.866059]  really_probe+0xdc/0x330
[    0.866066]  driver_probe_device+0x58/0xb8
[    0.866072]  device_driver_attach+0x6c/0x90
[    0.866078]  __driver_attach+0x88/0xd0
[    0.866085]  bus_for_each_dev+0x74/0xc8
[    0.866091]  driver_attach+0x20/0x28
[    0.866098]  bus_add_driver+0x14c/0x1f8
[    0.866104]  driver_register+0x60/0x110
[    0.866109]  __platform_driver_register+0x40/0x48
[    0.866119]  sci_init+0x2c/0x34
[    0.866127]  do_one_initcall+0x88/0x428
[    0.866137]  kernel_init_freeable+0x2c0/0x328
[    0.866143]  kernel_init+0x10/0x108
[    0.866150]  ret_from_fork+0x10/0x18

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Fixes: a3cb39d ("serial: core: Allow detach and attach serial device for console")
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1593618100-2151-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
amboar pushed a commit that referenced this issue Feb 11, 2024
@gregkh
bpf: Fix a few selftest failures due to llvm18 change
e02851a 
[ Upstream commit b16904f ]

With latest upstream llvm18, the following test cases failed:

  $ ./test_progs -j
  #13/2    bpf_cookie/multi_kprobe_link_api:FAIL
  #13/3    bpf_cookie/multi_kprobe_attach_api:FAIL
  #13      bpf_cookie:FAIL
  #77      fentry_fexit:FAIL
  #78/1    fentry_test/fentry:FAIL
  #78      fentry_test:FAIL
  #82/1    fexit_test/fexit:FAIL
  #82      fexit_test:FAIL
  #112/1   kprobe_multi_test/skel_api:FAIL
  #112/2   kprobe_multi_test/link_api_addrs:FAIL
  [...]
  #112     kprobe_multi_test:FAIL
  torvalds#356/17  test_global_funcs/global_func17:FAIL
  torvalds#356     test_global_funcs:FAIL

Further analysis shows llvm upstream patch [1] is responsible for the above
failures. For example, for function bpf_fentry_test7() in net/bpf/test_run.c,
without [1], the asm code is:

  0000000000000400 <bpf_fentry_test7>:
     400: f3 0f 1e fa                   endbr64
     404: e8 00 00 00 00                callq   0x409 <bpf_fentry_test7+0x9>
     409: 48 89 f8                      movq    %rdi, %rax
     40c: c3                            retq
     40d: 0f 1f 00                      nopl    (%rax)

... and with [1], the asm code is:

  0000000000005d20 <bpf_fentry_test7.specialized.1>:
    5d20: e8 00 00 00 00                callq   0x5d25 <bpf_fentry_test7.specialized.1+0x5>
    5d25: c3                            retq

... and <bpf_fentry_test7.specialized.1> is called instead of <bpf_fentry_test7>
and this caused test failures for #13/#77 etc. except torvalds#356.

For test case torvalds#356/17, with [1] (progs/test_global_func17.c)), the main prog
looks like:

  0000000000000000 <global_func17>:
       0:       b4 00 00 00 2a 00 00 00 w0 = 0x2a
       1:       95 00 00 00 00 00 00 00 exit

... which passed verification while the test itself expects a verification
failure.

Let us add 'barrier_var' style asm code in both places to prevent function
specialization which caused selftests failure.

  [1] llvm/llvm-project#72903

Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20231127050342.1945270-1-yonghong.song@linux.dev
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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ya-mouse