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

sunxi-3.0 make ... -C kernel-dir does not work any more #90

Closed
MarcusSt opened this issue Oct 25, 2012 · 4 comments
Closed

sunxi-3.0 make ... -C kernel-dir does not work any more #90

MarcusSt opened this issue Oct 25, 2012 · 4 comments

Comments

@MarcusSt
Copy link

As already in the title, make with -C kernel-dir does not work any more, as the mali driver will look for files in the current working directory rather than the kernel root.

marcus@linux:/mk802/linux-sunxi$ make mrproper
/home/marcus/mk802/linux-sunxi/drivers/gpu/mali/mali/Kbuild:59: "CONFIG_TRACEPOINTS required for USING_PROFILING"
marcus@linux:/mk802/linux-sunxi$ cd ..
marcus@linux:/mk802$ make mrproper -C linux-sunxi/
make: Entering directory /home/marcus/mk802/linux-sunxi' /home/marcus/mk802/linux-sunxi/drivers/gpu/mali/mali/Kbuild:48: "USING_PROFILING not supported, disabling." gcc: error: /home/marcus/mk802/drivers/gpu/mali/mali/arch/config.h: No such file or directory gcc: fatal error: no input files compilation terminated. [...] make: Leaving directory/home/marcus/mk802/linux-sunxi'
marcus@linux:/mk802$
@amery
Copy link
Member

amery commented Oct 26, 2012

can you try on stage/sunxi-3.0? at least when using O= I can't reproduce it. will make a test tree now to test without O=

@amery
Copy link
Member

amery commented Oct 26, 2012

ok, reproducted.

@rzk
Copy link
Member

rzk commented Nov 2, 2012

CONFIG_TRACEPOINTS required for USING_PROFILING
Can be fixed with simple patch I've sent to ML. We dont use profiling anyway.

@amery amery closed this as completed in 777085d Nov 7, 2012
@amery
Copy link
Member

amery commented Nov 7, 2012

both things should be fixed now

amery added a commit that referenced this issue Nov 8, 2012
@amery
gpu: mali: remove $(PWD) usage to fix -C support
9e1f1ed 
closes #90
turl added a commit that referenced this issue Nov 8, 2012
@turl @amery
gpu: mali: remove $(PWD) usage to fix -C support, try #2
4a3eb46 
closes #90 again

Signed-off-by: Emilio López <[email protected]>
turl added a commit that referenced this issue Nov 8, 2012
@turl @amery
gpu: mali: remove $(PWD) usage to fix -C support, try #2
36b9fca 
closes #90 again

Signed-off-by: Emilio López <[email protected]>
amery pushed a commit that referenced this issue Nov 12, 2013
@bp3tk0v
x86/boot: Further compress CPUs bootup message
a17bce4 
Turn it into (for example):

[    0.073380] x86: Booting SMP configuration:
[    0.074005] .... node   #0, CPUs:          #1   #2   #3   #4   #5   #6   #7
[    0.603005] .... node   #1, CPUs:     #8   #9  #10  #11  #12  #13  #14  #15
[    1.200005] .... node   #2, CPUs:    #16  #17  #18  #19  #20  #21  #22  #23
[    1.796005] .... node   #3, CPUs:    #24  #25  #26  #27  #28  #29  #30  #31
[    2.393005] .... node   #4, CPUs:    #32  #33  #34  #35  #36  #37  #38  #39
[    2.996005] .... node   #5, CPUs:    #40  #41  #42  #43  #44  #45  #46  #47
[    3.600005] .... node   #6, CPUs:    #48  #49  #50  #51  #52  #53  #54  #55
[    4.202005] .... node   #7, CPUs:    #56  #57  #58  #59  #60  #61  #62  #63
[    4.811005] .... node   #8, CPUs:    #64  #65  #66  #67  #68  #69  #70  #71
[    5.421006] .... node   #9, CPUs:    #72  #73  #74  #75  #76  #77  #78  #79
[    6.032005] .... node  #10, CPUs:    #80  #81  #82  #83  #84  #85  #86  #87
[    6.648006] .... node  #11, CPUs:    #88  #89  #90  #91  #92  #93  #94  #95
[    7.262005] .... node  #12, CPUs:    #96  #97  #98  #99 #100 #101 #102 #103
[    7.865005] .... node  #13, CPUs:   #104 #105 #106 #107 #108 #109 #110 #111
[    8.466005] .... node  #14, CPUs:   #112 #113 #114 #115 #116 #117 #118 #119
[    9.073006] .... node  #15, CPUs:   #120 #121 #122 #123 #124 #125 #126 #127
[    9.679901] x86: Booted up 16 nodes, 128 CPUs

and drop useless elements.

Change num_digits() to hpa's division-avoiding, cell-phone-typed
version which he went at great lengths and pains to submit on a
Saturday evening.

Signed-off-by: Borislav Petkov <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
wens pushed a commit that referenced this issue Jun 8, 2017
@4ast @davem330
bpf: split bpf core interpreter
f696b8f 
split __bpf_prog_run() interpreter into stack allocation and execution parts.
The code section shrinks which helps interpreter performance in some cases.
   text	   data	    bss	    dec	    hex	filename
  26350	  10328	    624	  37302	   91b6	kernel/bpf/core.o.before
  25777	  10328	    624	  36729	   8f79	kernel/bpf/core.o.after

Very short programs got slower (due to extra function call):
Before:
test_bpf: #89 ALU64_ADD_K: 1 + 2 = 3 jited:0 7 PASS
test_bpf: #90 ALU64_ADD_K: 3 + 0 = 3 jited:0 8 PASS
test_bpf: #91 ALU64_ADD_K: 1 + 2147483646 = 2147483647 jited:0 7 PASS
test_bpf: #92 ALU64_ADD_K: 4294967294 + 2 = 4294967296 jited:0 11 PASS
test_bpf: #93 ALU64_ADD_K: 2147483646 + -2147483647 = -1 jited:0 7 PASS
After:
test_bpf: #89 ALU64_ADD_K: 1 + 2 = 3 jited:0 11 PASS
test_bpf: #90 ALU64_ADD_K: 3 + 0 = 3 jited:0 11 PASS
test_bpf: #91 ALU64_ADD_K: 1 + 2147483646 = 2147483647 jited:0 11 PASS
test_bpf: #92 ALU64_ADD_K: 4294967294 + 2 = 4294967296 jited:0 14 PASS
test_bpf: #93 ALU64_ADD_K: 2147483646 + -2147483647 = -1 jited:0 10 PASS

Longer programs got faster:
Before:
test_bpf: #266 BPF_MAXINSNS: Ctx heavy transformations jited:0 20286 20513 PASS
test_bpf: #267 BPF_MAXINSNS: Call heavy transformations jited:0 31853 31768 PASS
test_bpf: #268 BPF_MAXINSNS: Jump heavy test jited:0 9815 PASS
test_bpf: #269 BPF_MAXINSNS: Very long jump backwards jited:0 6 PASS
test_bpf: #270 BPF_MAXINSNS: Edge hopping nuthouse jited:0 13959 PASS
test_bpf: #271 BPF_MAXINSNS: Jump, gap, jump, ... jited:0 210 PASS
test_bpf: #272 BPF_MAXINSNS: ld_abs+get_processor_id jited:0 21724 PASS
test_bpf: #273 BPF_MAXINSNS: ld_abs+vlan_push/pop jited:0 19118 PASS
After:
test_bpf: #266 BPF_MAXINSNS: Ctx heavy transformations jited:0 19008 18827 PASS
test_bpf: #267 BPF_MAXINSNS: Call heavy transformations jited:0 29238 28450 PASS
test_bpf: #268 BPF_MAXINSNS: Jump heavy test jited:0 9485 PASS
test_bpf: #269 BPF_MAXINSNS: Very long jump backwards jited:0 12 PASS
test_bpf: #270 BPF_MAXINSNS: Edge hopping nuthouse jited:0 13257 PASS
test_bpf: #271 BPF_MAXINSNS: Jump, gap, jump, ... jited:0 213 PASS
test_bpf: #272 BPF_MAXINSNS: ld_abs+get_processor_id jited:0 19389 PASS
test_bpf: #273 BPF_MAXINSNS: ld_abs+vlan_push/pop jited:0 19583 PASS

For real world production programs the difference is noise.

This patch is first step towards reducing interpreter stack consumption.

Signed-off-by: Alexei Starovoitov <[email protected]>
Acked-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
amery pushed a commit that referenced this issue Feb 22, 2018
@jgunthorpe
RDMA/uverbs: Sanitize user entered port numbers prior to access it
5d4c05c 
==================================================================
BUG: KASAN: use-after-free in copy_ah_attr_from_uverbs+0x6f2/0x8c0
Read of size 4 at addr ffff88006476a198 by task syzkaller697701/265

CPU: 0 PID: 265 Comm: syzkaller697701 Not tainted 4.15.0+ #90
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Call Trace:
 dump_stack+0xde/0x164
 ? dma_virt_map_sg+0x22c/0x22c
 ? show_regs_print_info+0x17/0x17
 ? lock_contended+0x11a0/0x11a0
 print_address_description+0x83/0x3e0
 kasan_report+0x18c/0x4b0
 ? copy_ah_attr_from_uverbs+0x6f2/0x8c0
 ? copy_ah_attr_from_uverbs+0x6f2/0x8c0
 ? lookup_get_idr_uobject+0x120/0x200
 ? copy_ah_attr_from_uverbs+0x6f2/0x8c0
 copy_ah_attr_from_uverbs+0x6f2/0x8c0
 ? modify_qp+0xd0e/0x1350
 modify_qp+0xd0e/0x1350
 ib_uverbs_modify_qp+0xf9/0x170
 ? ib_uverbs_query_qp+0xa70/0xa70
 ib_uverbs_write+0x7f9/0xef0
 ? attach_entity_load_avg+0x8b0/0x8b0
 ? ib_uverbs_query_qp+0xa70/0xa70
 ? uverbs_devnode+0x110/0x110
 ? cyc2ns_read_end+0x10/0x10
 ? print_irqtrace_events+0x280/0x280
 ? sched_clock_cpu+0x18/0x200
 ? _raw_spin_unlock_irq+0x29/0x40
 ? _raw_spin_unlock_irq+0x29/0x40
 ? _raw_spin_unlock_irq+0x29/0x40
 ? time_hardirqs_on+0x27/0x670
 __vfs_write+0x10d/0x700
 ? uverbs_devnode+0x110/0x110
 ? kernel_read+0x170/0x170
 ? _raw_spin_unlock_irq+0x29/0x40
 ? finish_task_switch+0x1bd/0x7a0
 ? finish_task_switch+0x194/0x7a0
 ? prandom_u32_state+0xe/0x180
 ? rcu_read_unlock+0x80/0x80
 ? security_file_permission+0x93/0x260
 vfs_write+0x1b0/0x550
 SyS_write+0xc7/0x1a0
 ? SyS_read+0x1a0/0x1a0
 ? trace_hardirqs_on_thunk+0x1a/0x1c
 entry_SYSCALL_64_fastpath+0x1e/0x8b
RIP: 0033:0x433c29
RSP: 002b:00007ffcf2be82a8 EFLAGS: 00000217

Allocated by task 62:
 kasan_kmalloc+0xa0/0xd0
 kmem_cache_alloc+0x141/0x480
 dup_fd+0x101/0xcc0
 copy_process.part.62+0x166f/0x4390
 _do_fork+0x1cb/0xe90
 kernel_thread+0x34/0x40
 call_usermodehelper_exec_work+0x112/0x260
 process_one_work+0x929/0x1aa0
 worker_thread+0x5c6/0x12a0
 kthread+0x346/0x510
 ret_from_fork+0x3a/0x50

Freed by task 259:
 kasan_slab_free+0x71/0xc0
 kmem_cache_free+0xf3/0x4c0
 put_files_struct+0x225/0x2c0
 exit_files+0x88/0xc0
 do_exit+0x67c/0x1520
 do_group_exit+0xe8/0x380
 SyS_exit_group+0x1e/0x20
 entry_SYSCALL_64_fastpath+0x1e/0x8b

The buggy address belongs to the object at ffff88006476a000
 which belongs to the cache files_cache of size 832
The buggy address is located 408 bytes inside of
 832-byte region [ffff88006476a000, ffff88006476a340)
The buggy address belongs to the page:
page:ffffea000191da80 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0
flags: 0x4000000000008100(slab|head)
raw: 4000000000008100 0000000000000000 0000000000000000 0000000100080008
raw: 0000000000000000 0000000100000001 ffff88006bcf7a80 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88006476a080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88006476a100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88006476a180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                            ^
 ffff88006476a200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88006476a280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Cc: syzkaller <[email protected]>
Cc: <[email protected]> # 4.11
Fixes: 44c5848 ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types")
Reported-by: Noa Osherovich <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
amery pushed a commit that referenced this issue Mar 10, 2018
@dledford
RDMA/mlx5: Fix integer overflow while resizing CQ
28e9091 
The user can provide very large cqe_size which will cause to integer
overflow as it can be seen in the following UBSAN warning:

=======================================================================
UBSAN: Undefined behaviour in drivers/infiniband/hw/mlx5/cq.c:1192:53
signed integer overflow:
64870 * 65536 cannot be represented in type 'int'
CPU: 0 PID: 267 Comm: syzkaller605279 Not tainted 4.15.0+ #90 Hardware
name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Call Trace:
 dump_stack+0xde/0x164
 ? dma_virt_map_sg+0x22c/0x22c
 ubsan_epilogue+0xe/0x81
 handle_overflow+0x1f3/0x251
 ? __ubsan_handle_negate_overflow+0x19b/0x19b
 ? lock_acquire+0x440/0x440
 mlx5_ib_resize_cq+0x17e7/0x1e40
 ? cyc2ns_read_end+0x10/0x10
 ? native_read_msr_safe+0x6c/0x9b
 ? cyc2ns_read_end+0x10/0x10
 ? mlx5_ib_modify_cq+0x220/0x220
 ? sched_clock_cpu+0x18/0x200
 ? lookup_get_idr_uobject+0x200/0x200
 ? rdma_lookup_get_uobject+0x145/0x2f0
 ib_uverbs_resize_cq+0x207/0x3e0
 ? ib_uverbs_ex_create_cq+0x250/0x250
 ib_uverbs_write+0x7f9/0xef0
 ? cyc2ns_read_end+0x10/0x10
 ? print_irqtrace_events+0x280/0x280
 ? ib_uverbs_ex_create_cq+0x250/0x250
 ? uverbs_devnode+0x110/0x110
 ? sched_clock_cpu+0x18/0x200
 ? do_raw_spin_trylock+0x100/0x100
 ? __lru_cache_add+0x16e/0x290
 __vfs_write+0x10d/0x700
 ? uverbs_devnode+0x110/0x110
 ? kernel_read+0x170/0x170
 ? sched_clock_cpu+0x18/0x200
 ? security_file_permission+0x93/0x260
 vfs_write+0x1b0/0x550
 SyS_write+0xc7/0x1a0
 ? SyS_read+0x1a0/0x1a0
 ? trace_hardirqs_on_thunk+0x1a/0x1c
 entry_SYSCALL_64_fastpath+0x1e/0x8b
RIP: 0033:0x433549
RSP: 002b:00007ffe63bd1ea8 EFLAGS: 00000217
=======================================================================

Cc: syzkaller <[email protected]>
Cc: <[email protected]> # 3.13
Fixes: bde5158 ("IB/mlx5: Add support for resize CQ")
Reported-by: Noa Osherovich <[email protected]>
Reviewed-by: Yishai Hadas <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
amery pushed a commit that referenced this issue Jun 3, 2018
@Zashas @davem330
ipv6: sr: fix memory OOB access in seg6_do_srh_encap/inline
bbb40a0 
seg6_do_srh_encap and seg6_do_srh_inline can possibly do an
out-of-bounds access when adding the SRH to the packet. This no longer
happen when expanding the skb not only by the size of the SRH (+
outer IPv6 header), but also by skb->mac_len.

[   53.793056] BUG: KASAN: use-after-free in seg6_do_srh_encap+0x284/0x620
[   53.794564] Write of size 14 at addr ffff88011975ecfa by task ping/674

[   53.796665] CPU: 0 PID: 674 Comm: ping Not tainted 4.17.0-rc3-ARCH+ #90
[   53.796670] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.11.0-20171110_100015-anatol 04/01/2014
[   53.796673] Call Trace:
[   53.796679]  <IRQ>
[   53.796689]  dump_stack+0x71/0xab
[   53.796700]  print_address_description+0x6a/0x270
[   53.796707]  kasan_report+0x258/0x380
[   53.796715]  ? seg6_do_srh_encap+0x284/0x620
[   53.796722]  memmove+0x34/0x50
[   53.796730]  seg6_do_srh_encap+0x284/0x620
[   53.796741]  ? seg6_do_srh+0x29b/0x360
[   53.796747]  seg6_do_srh+0x29b/0x360
[   53.796756]  seg6_input+0x2e/0x2e0
[   53.796765]  lwtunnel_input+0x93/0xd0
[   53.796774]  ipv6_rcv+0x690/0x920
[   53.796783]  ? ip6_input+0x170/0x170
[   53.796791]  ? eth_gro_receive+0x2d0/0x2d0
[   53.796800]  ? ip6_input+0x170/0x170
[   53.796809]  __netif_receive_skb_core+0xcc0/0x13f0
[   53.796820]  ? netdev_info+0x110/0x110
[   53.796827]  ? napi_complete_done+0xb6/0x170
[   53.796834]  ? e1000_clean+0x6da/0xf70
[   53.796845]  ? process_backlog+0x129/0x2a0
[   53.796853]  process_backlog+0x129/0x2a0
[   53.796862]  net_rx_action+0x211/0x5c0
[   53.796870]  ? napi_complete_done+0x170/0x170
[   53.796887]  ? run_rebalance_domains+0x11f/0x150
[   53.796891]  __do_softirq+0x10e/0x39e
[   53.796894]  do_softirq_own_stack+0x2a/0x40
[   53.796895]  </IRQ>
[   53.796898]  do_softirq.part.16+0x54/0x60
[   53.796900]  __local_bh_enable_ip+0x5b/0x60
[   53.796903]  ip6_finish_output2+0x416/0x9f0
[   53.796906]  ? ip6_dst_lookup_flow+0x110/0x110
[   53.796909]  ? ip6_sk_dst_lookup_flow+0x390/0x390
[   53.796911]  ? __rcu_read_unlock+0x66/0x80
[   53.796913]  ? ip6_mtu+0x44/0xf0
[   53.796916]  ? ip6_output+0xfc/0x220
[   53.796918]  ip6_output+0xfc/0x220
[   53.796921]  ? ip6_finish_output+0x2b0/0x2b0
[   53.796923]  ? memcpy+0x34/0x50
[   53.796926]  ip6_send_skb+0x43/0xc0
[   53.796929]  rawv6_sendmsg+0x1216/0x1530
[   53.796932]  ? __orc_find+0x6b/0xc0
[   53.796934]  ? rawv6_rcv_skb+0x160/0x160
[   53.796937]  ? __rcu_read_unlock+0x66/0x80
[   53.796939]  ? __rcu_read_unlock+0x66/0x80
[   53.796942]  ? is_bpf_text_address+0x1e/0x30
[   53.796944]  ? kernel_text_address+0xec/0x100
[   53.796946]  ? __kernel_text_address+0xe/0x30
[   53.796948]  ? unwind_get_return_address+0x2f/0x50
[   53.796950]  ? __save_stack_trace+0x92/0x100
[   53.796954]  ? save_stack+0x89/0xb0
[   53.796956]  ? kasan_kmalloc+0xa0/0xd0
[   53.796958]  ? kmem_cache_alloc+0xd2/0x1f0
[   53.796961]  ? prepare_creds+0x23/0x160
[   53.796963]  ? __x64_sys_capset+0x252/0x3e0
[   53.796966]  ? do_syscall_64+0x69/0x160
[   53.796968]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   53.796971]  ? __alloc_pages_nodemask+0x170/0x380
[   53.796973]  ? __alloc_pages_slowpath+0x12c0/0x12c0
[   53.796977]  ? tty_vhangup+0x20/0x20
[   53.796979]  ? policy_nodemask+0x1a/0x90
[   53.796982]  ? __mod_node_page_state+0x8d/0xa0
[   53.796986]  ? __check_object_size+0xe7/0x240
[   53.796989]  ? __sys_sendto+0x229/0x290
[   53.796991]  ? rawv6_rcv_skb+0x160/0x160
[   53.796993]  __sys_sendto+0x229/0x290
[   53.796996]  ? __ia32_sys_getpeername+0x50/0x50
[   53.796999]  ? commit_creds+0x2de/0x520
[   53.797002]  ? security_capset+0x57/0x70
[   53.797004]  ? __x64_sys_capset+0x29f/0x3e0
[   53.797007]  ? __x64_sys_rt_sigsuspend+0xe0/0xe0
[   53.797011]  ? __do_page_fault+0x664/0x770
[   53.797014]  __x64_sys_sendto+0x74/0x90
[   53.797017]  do_syscall_64+0x69/0x160
[   53.797019]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   53.797022] RIP: 0033:0x7f43b7a6714a
[   53.797023] RSP: 002b:00007ffd891bd368 EFLAGS: 00000246 ORIG_RAX:
000000000000002c
[   53.797026] RAX: ffffffffffffffda RBX: 00000000006129c0 RCX: 00007f43b7a6714a
[   53.797028] RDX: 0000000000000040 RSI: 00000000006129c0 RDI: 0000000000000004
[   53.797029] RBP: 00007ffd891be640 R08: 0000000000610940 R09: 000000000000001c
[   53.797030] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040
[   53.797032] R13: 000000000060e6a0 R14: 0000000000008004 R15: 000000000040b661

[   53.797171] Allocated by task 642:
[   53.797460]  kasan_kmalloc+0xa0/0xd0
[   53.797463]  kmem_cache_alloc+0xd2/0x1f0
[   53.797465]  getname_flags+0x40/0x210
[   53.797467]  user_path_at_empty+0x1d/0x40
[   53.797469]  do_faccessat+0x12a/0x320
[   53.797471]  do_syscall_64+0x69/0x160
[   53.797473]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

[   53.797607] Freed by task 642:
[   53.797869]  __kasan_slab_free+0x130/0x180
[   53.797871]  kmem_cache_free+0xa8/0x230
[   53.797872]  filename_lookup+0x15b/0x230
[   53.797874]  do_faccessat+0x12a/0x320
[   53.797876]  do_syscall_64+0x69/0x160
[   53.797878]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

[   53.798014] The buggy address belongs to the object at ffff88011975e600
                which belongs to the cache names_cache of size 4096
[   53.799043] The buggy address is located 1786 bytes inside of
                4096-byte region [ffff88011975e600, ffff88011975f600)
[   53.800013] The buggy address belongs to the page:
[   53.800414] page:ffffea000465d600 count:1 mapcount:0
mapping:0000000000000000 index:0x0 compound_mapcount: 0
[   53.801259] flags: 0x17fff0000008100(slab|head)
[   53.801640] raw: 017fff0000008100 0000000000000000 0000000000000000
0000000100070007
[   53.803147] raw: dead000000000100 dead000000000200 ffff88011b185a40
0000000000000000
[   53.803787] page dumped because: kasan: bad access detected

[   53.804384] Memory state around the buggy address:
[   53.804788]  ffff88011975eb80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[   53.805384]  ffff88011975ec00: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[   53.805979] >ffff88011975ec80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[   53.806577]                                                                 ^
[   53.807165]  ffff88011975ed00: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[   53.807762]  ffff88011975ed80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[   53.808356] ==================================================================
[   53.808949] Disabling lock debugging due to kernel taint

Fixes: 6c8702c ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
Signed-off-by: David Lebrun <[email protected]>
Signed-off-by: Mathieu Xhonneux <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
repojohnray pushed a commit to repojohnray/linux-sunxi-4.7.y that referenced this issue Jun 13, 2018
@Zashas @gregkh
ipv6: sr: fix memory OOB access in seg6_do_srh_encap/inline
8d80a83 
[ Upstream commit bbb40a0 ]

seg6_do_srh_encap and seg6_do_srh_inline can possibly do an
out-of-bounds access when adding the SRH to the packet. This no longer
happen when expanding the skb not only by the size of the SRH (+
outer IPv6 header), but also by skb->mac_len.

[   53.793056] BUG: KASAN: use-after-free in seg6_do_srh_encap+0x284/0x620
[   53.794564] Write of size 14 at addr ffff88011975ecfa by task ping/674

[   53.796665] CPU: 0 PID: 674 Comm: ping Not tainted 4.17.0-rc3-ARCH+ linux-sunxi#90
[   53.796670] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.11.0-20171110_100015-anatol 04/01/2014
[   53.796673] Call Trace:
[   53.796679]  <IRQ>
[   53.796689]  dump_stack+0x71/0xab
[   53.796700]  print_address_description+0x6a/0x270
[   53.796707]  kasan_report+0x258/0x380
[   53.796715]  ? seg6_do_srh_encap+0x284/0x620
[   53.796722]  memmove+0x34/0x50
[   53.796730]  seg6_do_srh_encap+0x284/0x620
[   53.796741]  ? seg6_do_srh+0x29b/0x360
[   53.796747]  seg6_do_srh+0x29b/0x360
[   53.796756]  seg6_input+0x2e/0x2e0
[   53.796765]  lwtunnel_input+0x93/0xd0
[   53.796774]  ipv6_rcv+0x690/0x920
[   53.796783]  ? ip6_input+0x170/0x170
[   53.796791]  ? eth_gro_receive+0x2d0/0x2d0
[   53.796800]  ? ip6_input+0x170/0x170
[   53.796809]  __netif_receive_skb_core+0xcc0/0x13f0
[   53.796820]  ? netdev_info+0x110/0x110
[   53.796827]  ? napi_complete_done+0xb6/0x170
[   53.796834]  ? e1000_clean+0x6da/0xf70
[   53.796845]  ? process_backlog+0x129/0x2a0
[   53.796853]  process_backlog+0x129/0x2a0
[   53.796862]  net_rx_action+0x211/0x5c0
[   53.796870]  ? napi_complete_done+0x170/0x170
[   53.796887]  ? run_rebalance_domains+0x11f/0x150
[   53.796891]  __do_softirq+0x10e/0x39e
[   53.796894]  do_softirq_own_stack+0x2a/0x40
[   53.796895]  </IRQ>
[   53.796898]  do_softirq.part.16+0x54/0x60
[   53.796900]  __local_bh_enable_ip+0x5b/0x60
[   53.796903]  ip6_finish_output2+0x416/0x9f0
[   53.796906]  ? ip6_dst_lookup_flow+0x110/0x110
[   53.796909]  ? ip6_sk_dst_lookup_flow+0x390/0x390
[   53.796911]  ? __rcu_read_unlock+0x66/0x80
[   53.796913]  ? ip6_mtu+0x44/0xf0
[   53.796916]  ? ip6_output+0xfc/0x220
[   53.796918]  ip6_output+0xfc/0x220
[   53.796921]  ? ip6_finish_output+0x2b0/0x2b0
[   53.796923]  ? memcpy+0x34/0x50
[   53.796926]  ip6_send_skb+0x43/0xc0
[   53.796929]  rawv6_sendmsg+0x1216/0x1530
[   53.796932]  ? __orc_find+0x6b/0xc0
[   53.796934]  ? rawv6_rcv_skb+0x160/0x160
[   53.796937]  ? __rcu_read_unlock+0x66/0x80
[   53.796939]  ? __rcu_read_unlock+0x66/0x80
[   53.796942]  ? is_bpf_text_address+0x1e/0x30
[   53.796944]  ? kernel_text_address+0xec/0x100
[   53.796946]  ? __kernel_text_address+0xe/0x30
[   53.796948]  ? unwind_get_return_address+0x2f/0x50
[   53.796950]  ? __save_stack_trace+0x92/0x100
[   53.796954]  ? save_stack+0x89/0xb0
[   53.796956]  ? kasan_kmalloc+0xa0/0xd0
[   53.796958]  ? kmem_cache_alloc+0xd2/0x1f0
[   53.796961]  ? prepare_creds+0x23/0x160
[   53.796963]  ? __x64_sys_capset+0x252/0x3e0
[   53.796966]  ? do_syscall_64+0x69/0x160
[   53.796968]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   53.796971]  ? __alloc_pages_nodemask+0x170/0x380
[   53.796973]  ? __alloc_pages_slowpath+0x12c0/0x12c0
[   53.796977]  ? tty_vhangup+0x20/0x20
[   53.796979]  ? policy_nodemask+0x1a/0x90
[   53.796982]  ? __mod_node_page_state+0x8d/0xa0
[   53.796986]  ? __check_object_size+0xe7/0x240
[   53.796989]  ? __sys_sendto+0x229/0x290
[   53.796991]  ? rawv6_rcv_skb+0x160/0x160
[   53.796993]  __sys_sendto+0x229/0x290
[   53.796996]  ? __ia32_sys_getpeername+0x50/0x50
[   53.796999]  ? commit_creds+0x2de/0x520
[   53.797002]  ? security_capset+0x57/0x70
[   53.797004]  ? __x64_sys_capset+0x29f/0x3e0
[   53.797007]  ? __x64_sys_rt_sigsuspend+0xe0/0xe0
[   53.797011]  ? __do_page_fault+0x664/0x770
[   53.797014]  __x64_sys_sendto+0x74/0x90
[   53.797017]  do_syscall_64+0x69/0x160
[   53.797019]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   53.797022] RIP: 0033:0x7f43b7a6714a
[   53.797023] RSP: 002b:00007ffd891bd368 EFLAGS: 00000246 ORIG_RAX:
000000000000002c
[   53.797026] RAX: ffffffffffffffda RBX: 00000000006129c0 RCX: 00007f43b7a6714a
[   53.797028] RDX: 0000000000000040 RSI: 00000000006129c0 RDI: 0000000000000004
[   53.797029] RBP: 00007ffd891be640 R08: 0000000000610940 R09: 000000000000001c
[   53.797030] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040
[   53.797032] R13: 000000000060e6a0 R14: 0000000000008004 R15: 000000000040b661

[   53.797171] Allocated by task 642:
[   53.797460]  kasan_kmalloc+0xa0/0xd0
[   53.797463]  kmem_cache_alloc+0xd2/0x1f0
[   53.797465]  getname_flags+0x40/0x210
[   53.797467]  user_path_at_empty+0x1d/0x40
[   53.797469]  do_faccessat+0x12a/0x320
[   53.797471]  do_syscall_64+0x69/0x160
[   53.797473]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

[   53.797607] Freed by task 642:
[   53.797869]  __kasan_slab_free+0x130/0x180
[   53.797871]  kmem_cache_free+0xa8/0x230
[   53.797872]  filename_lookup+0x15b/0x230
[   53.797874]  do_faccessat+0x12a/0x320
[   53.797876]  do_syscall_64+0x69/0x160
[   53.797878]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

[   53.798014] The buggy address belongs to the object at ffff88011975e600
                which belongs to the cache names_cache of size 4096
[   53.799043] The buggy address is located 1786 bytes inside of
                4096-byte region [ffff88011975e600, ffff88011975f600)
[   53.800013] The buggy address belongs to the page:
[   53.800414] page:ffffea000465d600 count:1 mapcount:0
mapping:0000000000000000 index:0x0 compound_mapcount: 0
[   53.801259] flags: 0x17fff0000008100(slab|head)
[   53.801640] raw: 017fff0000008100 0000000000000000 0000000000000000
0000000100070007
[   53.803147] raw: dead000000000100 dead000000000200 ffff88011b185a40
0000000000000000
[   53.803787] page dumped because: kasan: bad access detected

[   53.804384] Memory state around the buggy address:
[   53.804788]  ffff88011975eb80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[   53.805384]  ffff88011975ec00: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[   53.805979] >ffff88011975ec80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[   53.806577]                                                                 ^
[   53.807165]  ffff88011975ed00: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[   53.807762]  ffff88011975ed80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[   53.808356] ==================================================================
[   53.808949] Disabling lock debugging due to kernel taint

Fixes: 6c8702c ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
Signed-off-by: David Lebrun <[email protected]>
Signed-off-by: Mathieu Xhonneux <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
amery pushed a commit that referenced this issue Jun 15, 2018
@borkmann
bpf: implement dummy fops for bpf objects
b165585 
syzkaller was able to trigger the following warning in
do_dentry_open():

  WARNING: CPU: 1 PID: 4508 at fs/open.c:778 do_dentry_open+0x4ad/0xe40 fs/open.c:778
  Kernel panic - not syncing: panic_on_warn set ...

  CPU: 1 PID: 4508 Comm: syz-executor867 Not tainted 4.17.0+ #90
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  Call Trace:
  [...]
   vfs_open+0x139/0x230 fs/open.c:908
   do_last fs/namei.c:3370 [inline]
   path_openat+0x1717/0x4dc0 fs/namei.c:3511
   do_filp_open+0x249/0x350 fs/namei.c:3545
   do_sys_open+0x56f/0x740 fs/open.c:1101
   __do_sys_openat fs/open.c:1128 [inline]
   __se_sys_openat fs/open.c:1122 [inline]
   __x64_sys_openat+0x9d/0x100 fs/open.c:1122
   do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
   entry_SYSCALL_64_after_hwframe+0x49/0xbe

Problem was that prog and map inodes in bpf fs did not
implement a dummy file open operation that would return an
error. The patch in do_dentry_open() checks whether f_ops
are present and if not bails out with an error. While this
may be fine, we really shouldn't be throwing a warning
though. Thus follow the model similar to bad_file_ops and
reject the request unconditionally with -EIO.

Fixes: b219775 ("bpf: add support for persistent maps/progs")
Reported-by: [email protected]
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>
repojohnray pushed a commit to repojohnray/linux-sunxi-4.7.y that referenced this issue Apr 6, 2019
@wens @gregkh
backlight: pwm_bl: Use gpiod_get_value_cansleep() to get initial state
f325ee4 
[ Upstream commit cec2b18 ]

gpiod_get_value() gives out a warning if access to the underlying gpiochip
requires sleeping, which is common for I2C based chips:

    WARNING: CPU: 0 PID: 77 at drivers/gpio/gpiolib.c:2500 gpiod_get_value+0xd0/0x100
    Modules linked in:
    CPU: 0 PID: 77 Comm: kworker/0:2 Not tainted 4.14.0-rc3-00589-gf32897915d48-dirty linux-sunxi#90
    Hardware name: Allwinner sun4i/sun5i Families
    Workqueue: events deferred_probe_work_func
    [<c010ec50>] (unwind_backtrace) from [<c010b784>] (show_stack+0x10/0x14)
    [<c010b784>] (show_stack) from [<c0797224>] (dump_stack+0x88/0x9c)
    [<c0797224>] (dump_stack) from [<c0125b08>] (__warn+0xe8/0x100)
    [<c0125b08>] (__warn) from [<c0125bd0>] (warn_slowpath_null+0x20/0x28)
    [<c0125bd0>] (warn_slowpath_null) from [<c037069c>] (gpiod_get_value+0xd0/0x100)
    [<c037069c>] (gpiod_get_value) from [<c03778d0>] (pwm_backlight_probe+0x238/0x508)
    [<c03778d0>] (pwm_backlight_probe) from [<c0411a2c>] (platform_drv_probe+0x50/0xac)
    [<c0411a2c>] (platform_drv_probe) from [<c0410224>] (driver_probe_device+0x238/0x2e8)
    [<c0410224>] (driver_probe_device) from [<c040e820>] (bus_for_each_drv+0x44/0x94)
    [<c040e820>] (bus_for_each_drv) from [<c040ff0c>] (__device_attach+0xb0/0x114)
    [<c040ff0c>] (__device_attach) from [<c040f4f8>] (bus_probe_device+0x84/0x8c)
    [<c040f4f8>] (bus_probe_device) from [<c040f944>] (deferred_probe_work_func+0x50/0x14c)
    [<c040f944>] (deferred_probe_work_func) from [<c013be84>] (process_one_work+0x1ec/0x414)
    [<c013be84>] (process_one_work) from [<c013ce5c>] (worker_thread+0x2b0/0x5a0)
    [<c013ce5c>] (worker_thread) from [<c0141908>] (kthread+0x14c/0x154)
    [<c0141908>] (kthread) from [<c0107ab0>] (ret_from_fork+0x14/0x24)

This was missed in commit 0c9501f ("backlight: pwm_bl: Handle gpio
that can sleep"). The code was then moved to a separate function in
commit 7613c92 ("backlight: pwm_bl: Move the checks for initial power
state to a separate function").

The only usage of gpiod_get_value() is during the probe stage, which is
safe to sleep in. Switch to gpiod_get_value_cansleep().

Fixes: 0c9501f ("backlight: pwm_bl: Handle gpio that can sleep")
Signed-off-by: Chen-Yu Tsai <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Acked-by: Daniel Thompson <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
repojohnray pushed a commit to repojohnray/linux-sunxi-4.7.y that referenced this issue Apr 6, 2019
@wens @gregkh
backlight: pwm_bl: Use gpiod_get_value_cansleep() to get initial state
d9c6147 
[ Upstream commit cec2b18 ]

gpiod_get_value() gives out a warning if access to the underlying gpiochip
requires sleeping, which is common for I2C based chips:

    WARNING: CPU: 0 PID: 77 at drivers/gpio/gpiolib.c:2500 gpiod_get_value+0xd0/0x100
    Modules linked in:
    CPU: 0 PID: 77 Comm: kworker/0:2 Not tainted 4.14.0-rc3-00589-gf32897915d48-dirty linux-sunxi#90
    Hardware name: Allwinner sun4i/sun5i Families
    Workqueue: events deferred_probe_work_func
    [<c010ec50>] (unwind_backtrace) from [<c010b784>] (show_stack+0x10/0x14)
    [<c010b784>] (show_stack) from [<c0797224>] (dump_stack+0x88/0x9c)
    [<c0797224>] (dump_stack) from [<c0125b08>] (__warn+0xe8/0x100)
    [<c0125b08>] (__warn) from [<c0125bd0>] (warn_slowpath_null+0x20/0x28)
    [<c0125bd0>] (warn_slowpath_null) from [<c037069c>] (gpiod_get_value+0xd0/0x100)
    [<c037069c>] (gpiod_get_value) from [<c03778d0>] (pwm_backlight_probe+0x238/0x508)
    [<c03778d0>] (pwm_backlight_probe) from [<c0411a2c>] (platform_drv_probe+0x50/0xac)
    [<c0411a2c>] (platform_drv_probe) from [<c0410224>] (driver_probe_device+0x238/0x2e8)
    [<c0410224>] (driver_probe_device) from [<c040e820>] (bus_for_each_drv+0x44/0x94)
    [<c040e820>] (bus_for_each_drv) from [<c040ff0c>] (__device_attach+0xb0/0x114)
    [<c040ff0c>] (__device_attach) from [<c040f4f8>] (bus_probe_device+0x84/0x8c)
    [<c040f4f8>] (bus_probe_device) from [<c040f944>] (deferred_probe_work_func+0x50/0x14c)
    [<c040f944>] (deferred_probe_work_func) from [<c013be84>] (process_one_work+0x1ec/0x414)
    [<c013be84>] (process_one_work) from [<c013ce5c>] (worker_thread+0x2b0/0x5a0)
    [<c013ce5c>] (worker_thread) from [<c0141908>] (kthread+0x14c/0x154)
    [<c0141908>] (kthread) from [<c0107ab0>] (ret_from_fork+0x14/0x24)

This was missed in commit 0c9501f ("backlight: pwm_bl: Handle gpio
that can sleep"). The code was then moved to a separate function in
commit 7613c92 ("backlight: pwm_bl: Move the checks for initial power
state to a separate function").

The only usage of gpiod_get_value() is during the probe stage, which is
safe to sleep in. Switch to gpiod_get_value_cansleep().

Fixes: 0c9501f ("backlight: pwm_bl: Handle gpio that can sleep")
Signed-off-by: Chen-Yu Tsai <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Acked-by: Daniel Thompson <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
repojohnray pushed a commit to repojohnray/linux-sunxi-4.7.y that referenced this issue Oct 26, 2022
@gregkh
md: Replace snprintf with scnprintf
f95825c 
[ Upstream commit 1727fd5 ]

Current code produces a warning as shown below when total characters
in the constituent block device names plus the slashes exceeds 200.
snprintf() returns the number of characters generated from the given
input, which could cause the expression “200 – len” to wrap around
to a large positive number. Fix this by using scnprintf() instead,
which returns the actual number of characters written into the buffer.

[ 1513.267938] ------------[ cut here ]------------
[ 1513.267943] WARNING: CPU: 15 PID: 37247 at <snip>/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510
[ 1513.267944] Modules linked in:  <snip>
[ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure linux-sunxi#90~18.04.1-Ubuntu
[ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510
<-snip->
[ 1513.267982] Call Trace:
[ 1513.267986]  snprintf+0x45/0x70
[ 1513.267990]  ? disk_name+0x71/0xa0
[ 1513.267993]  dump_zones+0x114/0x240 [raid0]
[ 1513.267996]  ? _cond_resched+0x19/0x40
[ 1513.267998]  raid0_run+0x19e/0x270 [raid0]
[ 1513.268000]  md_run+0x5e0/0xc50
[ 1513.268003]  ? security_capable+0x3f/0x60
[ 1513.268005]  do_md_run+0x19/0x110
[ 1513.268006]  md_ioctl+0x195e/0x1f90
[ 1513.268007]  blkdev_ioctl+0x91f/0x9f0
[ 1513.268010]  block_ioctl+0x3d/0x50
[ 1513.268012]  do_vfs_ioctl+0xa9/0x640
[ 1513.268014]  ? __fput+0x162/0x260
[ 1513.268016]  ksys_ioctl+0x75/0x80
[ 1513.268017]  __x64_sys_ioctl+0x1a/0x20
[ 1513.268019]  do_syscall_64+0x5e/0x200
[ 1513.268021]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: 7660388 ("md/raid0: replace printk() with pr_*()")
Reviewed-by: Michael Kelley <[email protected]>
Acked-by: Guoqing Jiang <[email protected]>
Signed-off-by: Saurabh Sengar <[email protected]>
Signed-off-by: Song Liu <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
jwrdegoede pushed a commit to jwrdegoede/linux-sunxi that referenced this issue May 14, 2024
@claudiubeznea @geertu
pinctrl: renesas: rzg2l: Execute atomically the interrupt configuration
aa43c15 
Lockdep detects a possible deadlock as listed below. This is because it
detects the IA55 interrupt controller .irq_eoi() API is called from
interrupt context while configuration-specific API (e.g., .irq_enable())
could be called from process context on resume path (by calling
rzg2l_gpio_irq_restore()). To avoid this, protect the call of
rzg2l_gpio_irq_enable() with spin_lock_irqsave()/spin_unlock_irqrestore().
With this the same approach that is available in __setup_irq() is mimicked
to pinctrl IRQ resume function.

Below is the lockdep report:

    WARNING: inconsistent lock state
    6.8.0-rc5-next-20240219-arm64-renesas-00030-gb17a289abf1f linux-sunxi#90 Not tainted
    --------------------------------
    inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
    str_rwdt_t_001./159 [HC0[0]:SC0[0]:HE1:SE1] takes:
    ffff00000b001d70 (&rzg2l_irqc_data->lock){?...}-{2:2}, at: rzg2l_irqc_irq_enable+0x60/0xa4
    {IN-HARDIRQ-W} state was registered at:
    lock_acquire+0x1e0/0x310
    _raw_spin_lock+0x44/0x58
    rzg2l_irqc_eoi+0x2c/0x130
    irq_chip_eoi_parent+0x18/0x20
    rzg2l_gpio_irqc_eoi+0xc/0x14
    handle_fasteoi_irq+0x134/0x230
    generic_handle_domain_irq+0x28/0x3c
    gic_handle_irq+0x4c/0xbc
    call_on_irq_stack+0x24/0x34
    do_interrupt_handler+0x78/0x7c
    el1_interrupt+0x30/0x5c
    el1h_64_irq_handler+0x14/0x1c
    el1h_64_irq+0x64/0x68
    _raw_spin_unlock_irqrestore+0x34/0x70
    __setup_irq+0x4d4/0x6b8
    request_threaded_irq+0xe8/0x1a0
    request_any_context_irq+0x60/0xb8
    devm_request_any_context_irq+0x74/0x104
    gpio_keys_probe+0x374/0xb08
    platform_probe+0x64/0xcc
    really_probe+0x140/0x2ac
    __driver_probe_device+0x74/0x124
    driver_probe_device+0x3c/0x15c
    __driver_attach+0xec/0x1c4
    bus_for_each_dev+0x70/0xcc
    driver_attach+0x20/0x28
    bus_add_driver+0xdc/0x1d0
    driver_register+0x5c/0x118
    __platform_driver_register+0x24/0x2c
    gpio_keys_init+0x18/0x20
    do_one_initcall+0x70/0x290
    kernel_init_freeable+0x294/0x504
    kernel_init+0x20/0x1cc
    ret_from_fork+0x10/0x20
    irq event stamp: 69071
    hardirqs last enabled at (69071): [<ffff800080e0dafc>] _raw_spin_unlock_irqrestore+0x6c/0x70
    hardirqs last disabled at (69070): [<ffff800080e0cfec>] _raw_spin_lock_irqsave+0x7c/0x80
    softirqs last enabled at (67654): [<ffff800080010614>] __do_softirq+0x494/0x4dc
    softirqs last disabled at (67645): [<ffff800080015238>] ____do_softirq+0xc/0x14

    other info that might help us debug this:
    Possible unsafe locking scenario:

    CPU0
    ----
    lock(&rzg2l_irqc_data->lock);
    <Interrupt>
    lock(&rzg2l_irqc_data->lock);

    *** DEADLOCK ***

    4 locks held by str_rwdt_t_001./159:
    #0: ffff00000b10f3f0 (sb_writers#4){.+.+}-{0:0}, at: vfs_write+0x1a4/0x35c
    #1: ffff00000e43ba88 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xe8/0x1a8
    #2: ffff00000aa21dc8 (kn->active#40){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xf0/0x1a8
    #3: ffff80008179d970 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9c/0x278

    stack backtrace:
    CPU: 0 PID: 159 Comm: str_rwdt_t_001. Not tainted 6.8.0-rc5-next-20240219-arm64-renesas-00030-gb17a289abf1f linux-sunxi#90
    Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT)
    Call trace:
    dump_backtrace+0x94/0xe8
    show_stack+0x14/0x1c
    dump_stack_lvl+0x88/0xc4
    dump_stack+0x14/0x1c
    print_usage_bug.part.0+0x294/0x348
    mark_lock+0x6b0/0x948
    __lock_acquire+0x750/0x20b0
    lock_acquire+0x1e0/0x310
    _raw_spin_lock+0x44/0x58
    rzg2l_irqc_irq_enable+0x60/0xa4
    irq_chip_enable_parent+0x1c/0x34
    rzg2l_gpio_irq_enable+0xc4/0xd8
    rzg2l_pinctrl_resume_noirq+0x4cc/0x520
    pm_generic_resume_noirq+0x28/0x3c
    genpd_finish_resume+0xc0/0xdc
    genpd_resume_noirq+0x14/0x1c
    dpm_run_callback+0x34/0x90
    device_resume_noirq+0xa8/0x268
    dpm_noirq_resume_devices+0x13c/0x160
    dpm_resume_noirq+0xc/0x1c
    suspend_devices_and_enter+0x2c8/0x570
    pm_suspend+0x1ac/0x278
    state_store+0x88/0x124
    kobj_attr_store+0x14/0x24
    sysfs_kf_write+0x48/0x6c
    kernfs_fop_write_iter+0x118/0x1a8
    vfs_write+0x270/0x35c
    ksys_write+0x64/0xec
    __arm64_sys_write+0x18/0x20
    invoke_syscall+0x44/0x108
    el0_svc_common.constprop.0+0xb4/0xd4
    do_el0_svc+0x18/0x20
    el0_svc+0x3c/0xb8
    el0t_64_sync_handler+0xb8/0xbc
    el0t_64_sync+0x14c/0x150

Fixes: 254203f ("pinctrl: renesas: rzg2l: Add suspend/resume support")
Signed-off-by: Claudiu Beznea <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Geert Uytterhoeven <[email protected]>
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
3 participants
@amery @rzk @MarcusSt