Skip to content

correct a wrong word #106

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
Closed
wants to merge 1 commit into from
Closed

correct a wrong word #106

wants to merge 1 commit into from

Conversation

blackmiaool
Copy link

I think the "expression" may be a wrong word.

@ghost
Copy link

ghost commented Jul 22, 2014

No. In C there is something called Expressions with types.

"Like in any other programming language, in C, there are a number of arithmetic relational and logical operators we can use to write expressions that are made up of simpler basic types."

@sigifredo
Copy link

In C language there are no exceptions.

hauke pushed a commit to hauke/linux that referenced this pull request Jul 28, 2014
@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   torvalds#6   torvalds#7
[    0.603005] .... node   #1, CPUs:     torvalds#8   torvalds#9  torvalds#10  torvalds#11  torvalds#12  torvalds#13  torvalds#14  torvalds#15
[    1.200005] .... node   #2, CPUs:    torvalds#16  torvalds#17  torvalds#18  torvalds#19  torvalds#20  torvalds#21  torvalds#22  torvalds#23
[    1.796005] .... node   #3, CPUs:    torvalds#24  torvalds#25  torvalds#26  torvalds#27  torvalds#28  torvalds#29  torvalds#30  torvalds#31
[    2.393005] .... node   #4, CPUs:    torvalds#32  torvalds#33  torvalds#34  torvalds#35  torvalds#36  torvalds#37  torvalds#38  torvalds#39
[    2.996005] .... node   #5, CPUs:    torvalds#40  torvalds#41  torvalds#42  torvalds#43  torvalds#44  torvalds#45  torvalds#46  torvalds#47
[    3.600005] .... node   torvalds#6, CPUs:    torvalds#48  torvalds#49  torvalds#50  torvalds#51  #52  #53  torvalds#54  torvalds#55
[    4.202005] .... node   torvalds#7, CPUs:    torvalds#56  torvalds#57  #58  torvalds#59  torvalds#60  torvalds#61  torvalds#62  torvalds#63
[    4.811005] .... node   torvalds#8, CPUs:    torvalds#64  torvalds#65  torvalds#66  torvalds#67  torvalds#68  torvalds#69  #70  torvalds#71
[    5.421006] .... node   torvalds#9, CPUs:    torvalds#72  torvalds#73  torvalds#74  torvalds#75  torvalds#76  torvalds#77  torvalds#78  torvalds#79
[    6.032005] .... node  torvalds#10, CPUs:    torvalds#80  torvalds#81  torvalds#82  torvalds#83  torvalds#84  torvalds#85  torvalds#86  torvalds#87
[    6.648006] .... node  torvalds#11, CPUs:    torvalds#88  torvalds#89  torvalds#90  torvalds#91  torvalds#92  torvalds#93  torvalds#94  torvalds#95
[    7.262005] .... node  torvalds#12, CPUs:    torvalds#96  torvalds#97  torvalds#98  torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103
[    7.865005] .... node  torvalds#13, CPUs:   torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111
[    8.466005] .... node  torvalds#14, CPUs:   torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119
[    9.073006] .... node  torvalds#15, CPUs:   torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#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 <bp@suse.de>
Cc: huawei.libin@huawei.com
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
hauke pushed a commit to hauke/linux that referenced this pull request Jul 28, 2014
@gregkh
usb: chipidea: udc: Fix spinlock recursion during bus reset
a3aee36 
After configuration, the host also possible sends bus reset
at any time, at such situation, it will trigger below spinlock
recursion dump. This commit unlocks the spinlock before calling
gadget's disconnect.

BUG: spinlock recursion on CPU#0, swapper/0/0
 lock: 0xbf128014, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.0-next-20130910+ torvalds#106
[<80014e20>] (unwind_backtrace+0x0/0xec) from [<80011a6c>] (show_stack+0x10/0x14)
[<80011a6c>] (show_stack+0x10/0x14) from [<805c143c>] (dump_stack+0x94/0xbc)
[<805c143c>] (dump_stack+0x94/0xbc) from [<80282cf8>] (do_raw_spin_lock+0x16c/0x18c)
[<80282cf8>] (do_raw_spin_lock+0x16c/0x18c) from [<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c)
[<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<803cff88>] (ep_disable+0x24/0x110)
[<803cff88>] (ep_disable+0x24/0x110) from [<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial])
[<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial]) from [<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm])
[<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm]) from [<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite])
[<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite]) from [<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite])
[<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite]) from [<803d1024>] (udc_irq+0x770/0xce4)
[<803d1024>] (udc_irq+0x770/0xce4) from [<803cdcc0>] (ci_irq+0x98/0x164)
[<803cdcc0>] (ci_irq+0x98/0x164) from [<8007edfc>] (handle_irq_event_percpu+0x50/0x17c)
[<8007edfc>] (handle_irq_event_percpu+0x50/0x17c) from [<8007ef64>] (handle_irq_event+0x3c/0x5c)
[<8007ef64>] (handle_irq_event+0x3c/0x5c) from [<80081e98>] (handle_fasteoi_irq+0x98/0x168)
[<80081e98>] (handle_fasteoi_irq+0x98/0x168) from [<8007e598>] (generic_handle_irq+0x28/0x3c)
[<8007e598>] (generic_handle_irq+0x28/0x3c) from [<8000edf4>] (handle_IRQ+0x4c/0xb4)
[<8000edf4>] (handle_IRQ+0x4c/0xb4) from [<800085bc>] (gic_handle_irq+0x28/0x5c)
[<800085bc>] (gic_handle_irq+0x28/0x5c) from [<800125c0>] (__irq_svc+0x40/0x54)
Exception stack(0x8083bf68 to 0x8083bfb0)
bf60:                   81533b8 00000000 00096234 8001d760 8088e12c 00000000
bf80: 8083a000 8083a000 8084290c 805cb414 808428ac 8083a000 00000001 8083bfb0
bfa0: 8000f138 8000f13c 60000013 ffffffff
[<800125c0>] (__irq_svc+0x40/0x54) from [<8000f13c>] (arch_cpu_idle+0x30/0x3c)
[<8000f13c>] (arch_cpu_idle+0x30/0x3c) from [<8005eb94>] (cpu_startup_entry+0xf4/0x148)
[<8005eb94>] (cpu_startup_entry+0xf4/0x148) from [<807f1a2c>] (start_kernel+0x2c4/0x318)
BUG: spinlock lockup suspected on CPU#0, swapper/0/0
 lock: 0xbf128014, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.0-next-20130910+ torvalds#106
[<80014e20>] (unwind_backtrace+0x0/0xec) from [<80011a6c>] (show_stack+0x10/0x14)
[<80011a6c>] (show_stack+0x10/0x14) from [<805c143c>] (dump_stack+0x94/0xbc)
[<805c143c>] (dump_stack+0x94/0xbc) from [<80282c94>] (do_raw_spin_lock+0x108/0x18c)
[<80282c94>] (do_raw_spin_lock+0x108/0x18c) from [<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c)
[<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<803cff88>] (ep_disable+0x24/0x110)
[<803cff88>] (ep_disable+0x24/0x110) from [<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial])
[<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial]) from [<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm])
[<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm]) from [<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite])
[<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite]) from [<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite])
[<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite]) from [<803d1024>] (udc_irq+0x770/0xce4)
[<803d1024>] (udc_irq+0x770/0xce4) from [<803cdcc0>] (ci_irq+0x98/0x164)
[<803cdcc0>] (ci_irq+0x98/0x164) from [<8007edfc>] (handle_irq_event_percpu+0x50/0x17c)
[<8007edfc>] (handle_irq_event_percpu+0x50/0x17c) from [<8007ef64>] (handle_irq_event+0x3c/0x5c)
[<8007ef64>] (handle_irq_event+0x3c/0x5c) from [<80081e98>] (handle_fasteoi_irq+0x98/0x168)
[<80081e98>] (handle_fasteoi_irq+0x98/0x168) from [<8007e598>] (generic_handle_irq+0x28/0x3c)
[<8007e598>] (generic_handle_irq+0x28/0x3c) from [<8000edf4>] (handle_IRQ+0x4c/0xb4)
[<8000edf4>] (handle_IRQ+0x4c/0xb4) from [<800085bc>] (gic_handle_irq+0x28/0x5c)
[<800085bc>] (gic_handle_irq+0x28/0x5c) from [<800125c0>] (__irq_svc+0x40/0x54)
Exception stack(0x8083bf68 to 0x8083bfb0)
bf60:                   81533b8 00000000 00096234 8001d760 8088e12c 00000000
bf80: 8083a000 8083a000 8084290c 805cb414 808428ac 8083a000 00000001 8083bfb0
bfa0: 8000f138 8000f13c 60000013 ffffffff
[<800125c0>] (__irq_svc+0x40/0x54) from [<8000f13c>] (arch_cpu_idle+0x30/0x3c)
[<8000f13c>] (arch_cpu_idle+0x30/0x3c) from [<8005eb94>] (cpu_startup_entry+0xf4/0x148)
[<8005eb94>] (cpu_startup_entry+0xf4/0x148) from [<807f1a2c>] (start_kernel+0x2c4/0x318)

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
n-aizu pushed a commit to n-aizu/linux that referenced this pull request Sep 10, 2014
@linux4kix
Freescale: usb: chipidea: udc: Fix spinlock recursion during bus reset
0b14fe0 
After configuration, the host also possible sends bus reset
at any time, at such situation, it will trigger below spinlock
recursion dump. This commit unlocks the spinlock before calling
gadget's disconnect.

BUG: spinlock recursion on CPU#0, swapper/0/0
 lock: 0xbf128014, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.0-next-20130910+ torvalds#106
[<80014e20>] (unwind_backtrace+0x0/0xec) from [<80011a6c>] (show_stack+0x10/0x14)
[<80011a6c>] (show_stack+0x10/0x14) from [<805c143c>] (dump_stack+0x94/0xbc)
[<805c143c>] (dump_stack+0x94/0xbc) from [<80282cf8>] (do_raw_spin_lock+0x16c/0x18c)
[<80282cf8>] (do_raw_spin_lock+0x16c/0x18c) from [<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c)
[<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<803cff88>] (ep_disable+0x24/0x110)
[<803cff88>] (ep_disable+0x24/0x110) from [<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial])
[<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial]) from [<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm])
[<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm]) from [<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite])
[<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite]) from [<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite])
[<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite]) from [<803d1024>] (udc_irq+0x770/0xce4)
[<803d1024>] (udc_irq+0x770/0xce4) from [<803cdcc0>] (ci_irq+0x98/0x164)
[<803cdcc0>] (ci_irq+0x98/0x164) from [<8007edfc>] (handle_irq_event_percpu+0x50/0x17c)
[<8007edfc>] (handle_irq_event_percpu+0x50/0x17c) from [<8007ef64>] (handle_irq_event+0x3c/0x5c)
[<8007ef64>] (handle_irq_event+0x3c/0x5c) from [<80081e98>] (handle_fasteoi_irq+0x98/0x168)
[<80081e98>] (handle_fasteoi_irq+0x98/0x168) from [<8007e598>] (generic_handle_irq+0x28/0x3c)
[<8007e598>] (generic_handle_irq+0x28/0x3c) from [<8000edf4>] (handle_IRQ+0x4c/0xb4)
[<8000edf4>] (handle_IRQ+0x4c/0xb4) from [<800085bc>] (gic_handle_irq+0x28/0x5c)
[<800085bc>] (gic_handle_irq+0x28/0x5c) from [<800125c0>] (__irq_svc+0x40/0x54)
Exception stack(0x8083bf68 to 0x8083bfb0)
bf60:                   81533b8 00000000 00096234 8001d760 8088e12c 00000000
bf80: 8083a000 8083a000 8084290c 805cb414 808428ac 8083a000 00000001 8083bfb0
bfa0: 8000f138 8000f13c 60000013 ffffffff
[<800125c0>] (__irq_svc+0x40/0x54) from [<8000f13c>] (arch_cpu_idle+0x30/0x3c)
[<8000f13c>] (arch_cpu_idle+0x30/0x3c) from [<8005eb94>] (cpu_startup_entry+0xf4/0x148)
[<8005eb94>] (cpu_startup_entry+0xf4/0x148) from [<807f1a2c>] (start_kernel+0x2c4/0x318)
BUG: spinlock lockup suspected on CPU#0, swapper/0/0
 lock: 0xbf128014, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.0-next-20130910+ torvalds#106
[<80014e20>] (unwind_backtrace+0x0/0xec) from [<80011a6c>] (show_stack+0x10/0x14)
[<80011a6c>] (show_stack+0x10/0x14) from [<805c143c>] (dump_stack+0x94/0xbc)
[<805c143c>] (dump_stack+0x94/0xbc) from [<80282c94>] (do_raw_spin_lock+0x108/0x18c)
[<80282c94>] (do_raw_spin_lock+0x108/0x18c) from [<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c)
[<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<803cff88>] (ep_disable+0x24/0x110)
[<803cff88>] (ep_disable+0x24/0x110) from [<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial])
[<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial]) from [<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm])
[<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm]) from [<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite])
[<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite]) from [<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite])
[<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite]) from [<803d1024>] (udc_irq+0x770/0xce4)
[<803d1024>] (udc_irq+0x770/0xce4) from [<803cdcc0>] (ci_irq+0x98/0x164)
[<803cdcc0>] (ci_irq+0x98/0x164) from [<8007edfc>] (handle_irq_event_percpu+0x50/0x17c)
[<8007edfc>] (handle_irq_event_percpu+0x50/0x17c) from [<8007ef64>] (handle_irq_event+0x3c/0x5c)
[<8007ef64>] (handle_irq_event+0x3c/0x5c) from [<80081e98>] (handle_fasteoi_irq+0x98/0x168)
[<80081e98>] (handle_fasteoi_irq+0x98/0x168) from [<8007e598>] (generic_handle_irq+0x28/0x3c)
[<8007e598>] (generic_handle_irq+0x28/0x3c) from [<8000edf4>] (handle_IRQ+0x4c/0xb4)
[<8000edf4>] (handle_IRQ+0x4c/0xb4) from [<800085bc>] (gic_handle_irq+0x28/0x5c)
[<800085bc>] (gic_handle_irq+0x28/0x5c) from [<800125c0>] (__irq_svc+0x40/0x54)
Exception stack(0x8083bf68 to 0x8083bfb0)
bf60:                   81533b8 00000000 00096234 8001d760 8088e12c 00000000
bf80: 8083a000 8083a000 8084290c 805cb414 808428ac 8083a000 00000001 8083bfb0
bfa0: 8000f138 8000f13c 60000013 ffffffff
[<800125c0>] (__irq_svc+0x40/0x54) from [<8000f13c>] (arch_cpu_idle+0x30/0x3c)
[<8000f13c>] (arch_cpu_idle+0x30/0x3c) from [<8005eb94>] (cpu_startup_entry+0xf4/0x148)
[<8005eb94>] (cpu_startup_entry+0xf4/0x148) from [<807f1a2c>] (start_kernel+0x2c4/0x318)

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
chrillomat pushed a commit to chrillomat/linux that referenced this pull request Oct 6, 2014
usb: chipidea: udc: Fix spinlock recursion during bus reset
3fe8e80 
After configuration, the host also possible sends bus reset
at any time, at such situation, it will trigger below spinlock
recursion dump. This commit unlocks the spinlock before calling
gadget's disconnect.

BUG: spinlock recursion on CPU#0, swapper/0/0
 lock: 0xbf128014, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.0-next-20130910+ torvalds#106
[<80014e20>] (unwind_backtrace+0x0/0xec) from [<80011a6c>] (show_stack+0x10/0x14)
[<80011a6c>] (show_stack+0x10/0x14) from [<805c143c>] (dump_stack+0x94/0xbc)
[<805c143c>] (dump_stack+0x94/0xbc) from [<80282cf8>] (do_raw_spin_lock+0x16c/0x18c)
[<80282cf8>] (do_raw_spin_lock+0x16c/0x18c) from [<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c)
[<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<803cff88>] (ep_disable+0x24/0x110)
[<803cff88>] (ep_disable+0x24/0x110) from [<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial])
[<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial]) from [<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm])
[<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm]) from [<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite])
[<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite]) from [<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite])
[<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite]) from [<803d1024>] (udc_irq+0x770/0xce4)
[<803d1024>] (udc_irq+0x770/0xce4) from [<803cdcc0>] (ci_irq+0x98/0x164)
[<803cdcc0>] (ci_irq+0x98/0x164) from [<8007edfc>] (handle_irq_event_percpu+0x50/0x17c)
[<8007edfc>] (handle_irq_event_percpu+0x50/0x17c) from [<8007ef64>] (handle_irq_event+0x3c/0x5c)
[<8007ef64>] (handle_irq_event+0x3c/0x5c) from [<80081e98>] (handle_fasteoi_irq+0x98/0x168)
[<80081e98>] (handle_fasteoi_irq+0x98/0x168) from [<8007e598>] (generic_handle_irq+0x28/0x3c)
[<8007e598>] (generic_handle_irq+0x28/0x3c) from [<8000edf4>] (handle_IRQ+0x4c/0xb4)
[<8000edf4>] (handle_IRQ+0x4c/0xb4) from [<800085bc>] (gic_handle_irq+0x28/0x5c)
[<800085bc>] (gic_handle_irq+0x28/0x5c) from [<800125c0>] (__irq_svc+0x40/0x54)
Exception stack(0x8083bf68 to 0x8083bfb0)
bf60:                   81533b8 00000000 00096234 8001d760 8088e12c 00000000
bf80: 8083a000 8083a000 8084290c 805cb414 808428ac 8083a000 00000001 8083bfb0
bfa0: 8000f138 8000f13c 60000013 ffffffff
[<800125c0>] (__irq_svc+0x40/0x54) from [<8000f13c>] (arch_cpu_idle+0x30/0x3c)
[<8000f13c>] (arch_cpu_idle+0x30/0x3c) from [<8005eb94>] (cpu_startup_entry+0xf4/0x148)
[<8005eb94>] (cpu_startup_entry+0xf4/0x148) from [<807f1a2c>] (start_kernel+0x2c4/0x318)
BUG: spinlock lockup suspected on CPU#0, swapper/0/0
 lock: 0xbf128014, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.0-next-20130910+ torvalds#106
[<80014e20>] (unwind_backtrace+0x0/0xec) from [<80011a6c>] (show_stack+0x10/0x14)
[<80011a6c>] (show_stack+0x10/0x14) from [<805c143c>] (dump_stack+0x94/0xbc)
[<805c143c>] (dump_stack+0x94/0xbc) from [<80282c94>] (do_raw_spin_lock+0x108/0x18c)
[<80282c94>] (do_raw_spin_lock+0x108/0x18c) from [<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c)
[<805c77e0>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<803cff88>] (ep_disable+0x24/0x110)
[<803cff88>] (ep_disable+0x24/0x110) from [<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial])
[<7f015d50>] (gserial_disconnect+0xa0/0x15c [u_serial]) from [<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm])
[<7f01c06c>] (acm_disable+0xc/0x30 [usb_f_acm]) from [<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite])
[<7f001478>] (reset_config.isra.10+0x34/0x5c [libcomposite]) from [<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite])
[<7f0014d4>] (composite_disconnect+0x34/0x5c [libcomposite]) from [<803d1024>] (udc_irq+0x770/0xce4)
[<803d1024>] (udc_irq+0x770/0xce4) from [<803cdcc0>] (ci_irq+0x98/0x164)
[<803cdcc0>] (ci_irq+0x98/0x164) from [<8007edfc>] (handle_irq_event_percpu+0x50/0x17c)
[<8007edfc>] (handle_irq_event_percpu+0x50/0x17c) from [<8007ef64>] (handle_irq_event+0x3c/0x5c)
[<8007ef64>] (handle_irq_event+0x3c/0x5c) from [<80081e98>] (handle_fasteoi_irq+0x98/0x168)
[<80081e98>] (handle_fasteoi_irq+0x98/0x168) from [<8007e598>] (generic_handle_irq+0x28/0x3c)
[<8007e598>] (generic_handle_irq+0x28/0x3c) from [<8000edf4>] (handle_IRQ+0x4c/0xb4)
[<8000edf4>] (handle_IRQ+0x4c/0xb4) from [<800085bc>] (gic_handle_irq+0x28/0x5c)
[<800085bc>] (gic_handle_irq+0x28/0x5c) from [<800125c0>] (__irq_svc+0x40/0x54)
Exception stack(0x8083bf68 to 0x8083bfb0)
bf60:                   81533b8 00000000 00096234 8001d760 8088e12c 00000000
bf80: 8083a000 8083a000 8084290c 805cb414 808428ac 8083a000 00000001 8083bfb0
bfa0: 8000f138 8000f13c 60000013 ffffffff
[<800125c0>] (__irq_svc+0x40/0x54) from [<8000f13c>] (arch_cpu_idle+0x30/0x3c)
[<8000f13c>] (arch_cpu_idle+0x30/0x3c) from [<8005eb94>] (cpu_startup_entry+0xf4/0x148)
[<8005eb94>] (cpu_startup_entry+0xf4/0x148) from [<807f1a2c>] (start_kernel+0x2c4/0x318)

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dongsupark pushed a commit to dongsupark/linux that referenced this pull request Dec 18, 2014
block: count physical segments through multipage biovecs
ba0742a 
As it's now possible for biovecs to have multiple pages,
__blk_recalc_rq_segments() should also support iterating biovecs
using bio_for_each_page() for each bio. Otherwise kernel could
occasionally crash with the following bug, especially when tested
with virtio-blk.

------------[ cut here ]------------
kernel BUG at drivers/block/virtio_blk.c:172!
CPU: 1 PID: 13523 Comm: mount Not tainted 3.18.0+ torvalds#106
Call Trace:
 [<ffffffff814ddb78>] __blk_mq_run_hw_queue+0x1b8/0x310
 [<ffffffff814de53d>] blk_mq_run_hw_queue+0x6d/0x90
 [<ffffffff814df49d>] blk_mq_insert_requests+0xfd/0x2c0
 [<ffffffff814e03bb>] blk_mq_flush_plug_list+0x12b/0x140
 [<ffffffff814d4aa1>] blk_flush_plug_list+0xb1/0x200
 [<ffffffff814d51a8>] blk_finish_plug+0x18/0x50
 [<ffffffff813845de>] _xfs_buf_ioapply+0x2fe/0x3e0
 [<ffffffff813858a6>] ? xfs_bwrite+0x46/0x80
 [<ffffffff81384de2>] xfs_buf_submit_wait+0xb2/0x6d0
 [<ffffffff813858a6>] xfs_bwrite+0x46/0x80
 [<ffffffff813bba44>] xlog_bwrite+0xc4/0x160
 [<ffffffff813bcb5b>] xlog_write_log_records+0x1ab/0x240
 [<ffffffff813bcd00>] xlog_clear_stale_blocks+0x110/0x1e0
 [<ffffffff813bd10b>] xlog_find_tail+0x33b/0x430
 [<ffffffff813c3a7e>] xlog_recover+0x1e/0xf0
 [<ffffffff813af73c>] xfs_log_mount+0x28c/0x300
 [<ffffffff813a4dc5>] xfs_mountfs+0x4a5/0x9c0
 [<ffffffff813a9672>] xfs_fs_fill_super+0x312/0x390
 [<ffffffff812237a4>] mount_bdev+0x1a4/0x1e0
 [<ffffffff813a9360>] ? xfs_finish_flags+0x170/0x170
 [<ffffffff813a7255>] xfs_fs_mount+0x15/0x20
 [<ffffffff81224129>] mount_fs+0x39/0x1b0
 [<ffffffff811c7495>] ? __alloc_percpu+0x15/0x20
 [<ffffffff8124372b>] vfs_kern_mount+0x6b/0x150
 [<ffffffff81246680>] do_mount+0x210/0xb90
 [<ffffffff811d181f>] ? might_fault+0x5f/0xb0
 [<ffffffff8124733b>] SyS_mount+0x8b/0xe0
 [<ffffffff817e3092>] system_call_fastpath+0x12/0x17
RIP [<ffffffff81620c27>] virtio_queue_rq+0x277/0x280
---[ end trace d56c2abcb8ac6962 ]---

Signed-off-by: Dongsu Park <dongsu.park@profitbricks.com>
dongsupark pushed a commit to dongsupark/linux that referenced this pull request Dec 29, 2014
block: count physical segments through multipage biovecs
14b230b 
As it's now possible for biovecs to have multiple pages,
__blk_recalc_rq_segments() should also support iterating biovecs
using bio_for_each_page() for each bio. Otherwise kernel could
occasionally crash with the following bug, especially when tested
with virtio-blk.

------------[ cut here ]------------
kernel BUG at drivers/block/virtio_blk.c:172!
CPU: 1 PID: 13523 Comm: mount Not tainted 3.18.0+ torvalds#106
Call Trace:
 [<ffffffff814ddb78>] __blk_mq_run_hw_queue+0x1b8/0x310
 [<ffffffff814de53d>] blk_mq_run_hw_queue+0x6d/0x90
 [<ffffffff814df49d>] blk_mq_insert_requests+0xfd/0x2c0
 [<ffffffff814e03bb>] blk_mq_flush_plug_list+0x12b/0x140
 [<ffffffff814d4aa1>] blk_flush_plug_list+0xb1/0x200
 [<ffffffff814d51a8>] blk_finish_plug+0x18/0x50
 [<ffffffff813845de>] _xfs_buf_ioapply+0x2fe/0x3e0
 [<ffffffff813858a6>] ? xfs_bwrite+0x46/0x80
 [<ffffffff81384de2>] xfs_buf_submit_wait+0xb2/0x6d0
 [<ffffffff813858a6>] xfs_bwrite+0x46/0x80
 [<ffffffff813bba44>] xlog_bwrite+0xc4/0x160
 [<ffffffff813bcb5b>] xlog_write_log_records+0x1ab/0x240
 [<ffffffff813bcd00>] xlog_clear_stale_blocks+0x110/0x1e0
 [<ffffffff813bd10b>] xlog_find_tail+0x33b/0x430
 [<ffffffff813c3a7e>] xlog_recover+0x1e/0xf0
 [<ffffffff813af73c>] xfs_log_mount+0x28c/0x300
 [<ffffffff813a4dc5>] xfs_mountfs+0x4a5/0x9c0
 [<ffffffff813a9672>] xfs_fs_fill_super+0x312/0x390
 [<ffffffff812237a4>] mount_bdev+0x1a4/0x1e0
 [<ffffffff813a9360>] ? xfs_finish_flags+0x170/0x170
 [<ffffffff813a7255>] xfs_fs_mount+0x15/0x20
 [<ffffffff81224129>] mount_fs+0x39/0x1b0
 [<ffffffff811c7495>] ? __alloc_percpu+0x15/0x20
 [<ffffffff8124372b>] vfs_kern_mount+0x6b/0x150
 [<ffffffff81246680>] do_mount+0x210/0xb90
 [<ffffffff811d181f>] ? might_fault+0x5f/0xb0
 [<ffffffff8124733b>] SyS_mount+0x8b/0xe0
 [<ffffffff817e3092>] system_call_fastpath+0x12/0x17
RIP [<ffffffff81620c27>] virtio_queue_rq+0x277/0x280
---[ end trace d56c2abcb8ac6962 ]---

Signed-off-by: Dongsu Park <dongsu.park@profitbricks.com>
dongsupark pushed a commit to dongsupark/linux that referenced this pull request Jan 12, 2015
block: count physical segments through multipage biovecs
8decb78 
As it's now possible for biovecs to have multiple pages,
__blk_recalc_rq_segments() should also support iterating biovecs
using bio_for_each_page() for each bio. Otherwise kernel could
occasionally crash with the following bug, especially when tested
with virtio-blk.

------------[ cut here ]------------
kernel BUG at drivers/block/virtio_blk.c:172!
CPU: 1 PID: 13523 Comm: mount Not tainted 3.18.0+ torvalds#106
Call Trace:
 [<ffffffff814ddb78>] __blk_mq_run_hw_queue+0x1b8/0x310
 [<ffffffff814de53d>] blk_mq_run_hw_queue+0x6d/0x90
 [<ffffffff814df49d>] blk_mq_insert_requests+0xfd/0x2c0
 [<ffffffff814e03bb>] blk_mq_flush_plug_list+0x12b/0x140
 [<ffffffff814d4aa1>] blk_flush_plug_list+0xb1/0x200
 [<ffffffff814d51a8>] blk_finish_plug+0x18/0x50
 [<ffffffff813845de>] _xfs_buf_ioapply+0x2fe/0x3e0
 [<ffffffff813858a6>] ? xfs_bwrite+0x46/0x80
 [<ffffffff81384de2>] xfs_buf_submit_wait+0xb2/0x6d0
 [<ffffffff813858a6>] xfs_bwrite+0x46/0x80
 [<ffffffff813bba44>] xlog_bwrite+0xc4/0x160
 [<ffffffff813bcb5b>] xlog_write_log_records+0x1ab/0x240
 [<ffffffff813bcd00>] xlog_clear_stale_blocks+0x110/0x1e0
 [<ffffffff813bd10b>] xlog_find_tail+0x33b/0x430
 [<ffffffff813c3a7e>] xlog_recover+0x1e/0xf0
 [<ffffffff813af73c>] xfs_log_mount+0x28c/0x300
 [<ffffffff813a4dc5>] xfs_mountfs+0x4a5/0x9c0
 [<ffffffff813a9672>] xfs_fs_fill_super+0x312/0x390
 [<ffffffff812237a4>] mount_bdev+0x1a4/0x1e0
 [<ffffffff813a9360>] ? xfs_finish_flags+0x170/0x170
 [<ffffffff813a7255>] xfs_fs_mount+0x15/0x20
 [<ffffffff81224129>] mount_fs+0x39/0x1b0
 [<ffffffff811c7495>] ? __alloc_percpu+0x15/0x20
 [<ffffffff8124372b>] vfs_kern_mount+0x6b/0x150
 [<ffffffff81246680>] do_mount+0x210/0xb90
 [<ffffffff811d181f>] ? might_fault+0x5f/0xb0
 [<ffffffff8124733b>] SyS_mount+0x8b/0xe0
 [<ffffffff817e3092>] system_call_fastpath+0x12/0x17
RIP [<ffffffff81620c27>] virtio_queue_rq+0x277/0x280
---[ end trace d56c2abcb8ac6962 ]---

Signed-off-by: Dongsu Park <dongsu.park@profitbricks.com>
apxii pushed a commit to apxii/linux that referenced this pull request May 27, 2015
@tobetter
Merge pull request torvalds#106 from tobetter/odroidxu3-3.10.y
a8c8483 
ODROIDXU3 : AX88179 Driver update(V1.13.0, 2014/12/25)
ddstreet pushed a commit to ddstreet/linux that referenced this pull request Jun 12, 2015
@davem330
enic: unlock napi busy poll before unmasking intr
6286e82 
There is a small window between vnic_intr_unmask() and enic_poll_unlock_napi().
In this window if an irq occurs and napi is scheduled on different cpu, it tries
to acquire enic_poll_lock_napi() and hits the following WARN_ON message.

Fix is to unlock napi_poll before unmasking the interrupt.

[  781.121746] ------------[ cut here ]------------
[  781.121789] WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/cisco/enic/vnic_rq.h:228 enic_poll_msix_rq+0x36a/0x3c0 [enic]()
[  781.121834] Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver coretemp intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel mgag200 ttm drm_kms_helper joydev aes_x86_64 lrw drm gf128mul mousedev glue_helper sb_edac ablk_helper iTCO_wdt iTCO_vendor_support evdev ipmi_si syscopyarea sysfillrect sysimgblt i2c_algo_bit i2c_core edac_core lpc_ich mac_hid cryptd pcspkr ipmi_msghandler shpchp tpm_tis acpi_power_meter tpm wmi processor hwmon button ac sch_fq_codel nfs lockd grace sunrpc fscache hid_generic usbhid hid ehci_pci ehci_hcd sd_mod megaraid_sas usbcore scsi_mod usb_common enic crc32c_generic crc32c_intel btrfs xor raid6_pq ext4 crc16 mbcache jbd2
[  781.122176] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc6-ARCH-00040-gc46a024-dirty torvalds#106
[  781.122210] Hardware name: Cisco Systems Inc UCSB-B200-M4/UCSB-B200-M4, BIOS B200M4.2.2.2.23.061220140128 06/12/2014
[  781.122252]  0000000000000000 bddbbc9d655ec96e ffff880277e43da8 ffffffff81583fe8
[  781.122286]  0000000000000000 0000000000000000 ffff880277e43de8 ffffffff8107acfa
[  781.122319]  ffff880272c01000 ffff880273f18000 ffff880273f1a100 0000000000000000
[  781.122352] Call Trace:
[  781.122364]  <IRQ>  [<ffffffff81583fe8>] dump_stack+0x4f/0x7b
[  781.122399]  [<ffffffff8107acfa>] warn_slowpath_common+0x8a/0xc0
[  781.122425]  [<ffffffff8107ae2a>] warn_slowpath_null+0x1a/0x20
[  781.122455]  [<ffffffffa01fa9ca>] enic_poll_msix_rq+0x36a/0x3c0 [enic]
[  781.122487]  [<ffffffff8148525a>] net_rx_action+0x22a/0x370
[  781.122512]  [<ffffffff8107ed3d>] __do_softirq+0xed/0x2d0
[  781.122537]  [<ffffffff8107f06e>] irq_exit+0x7e/0xa0
[  781.122560]  [<ffffffff8158c424>] do_IRQ+0x64/0x100
[  781.122582]  [<ffffffff8158a42e>] common_interrupt+0x6e/0x6e
[  781.122605]  <EOI>  [<ffffffff810bd331>] ? cpu_startup_entry+0x121/0x480
[  781.122638]  [<ffffffff810bd2fc>] ? cpu_startup_entry+0xec/0x480
[  781.122667]  [<ffffffff810f2ed3>] ? clockevents_register_device+0x113/0x1f0
[  781.122698]  [<ffffffff81050ab6>] start_secondary+0x196/0x1e0
[  781.122723] ---[ end trace cec2e9dd3af7b9db ]---

Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
harisokanovic pushed a commit to harisokanovic/linux that referenced this pull request Dec 5, 2016
@umgwanakikbuti
connector/cn_proc: Protect send_msg() with a local lock on RT
b8b8f1b 
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
|Preemption disabled at:[<ffffffff8148019b>] proc_exit_connector+0xbb/0x140
|
|CPU: 4 PID: 31807 Comm: sleep Tainted: G        W   E   4.8.0-rt11-rt torvalds#106
|Call Trace:
| [<ffffffff813436cd>] dump_stack+0x65/0x88
| [<ffffffff8109c425>] ___might_sleep+0xf5/0x180
| [<ffffffff816406b0>] __rt_spin_lock+0x20/0x50
| [<ffffffff81640978>] rt_read_lock+0x28/0x30
| [<ffffffff8156e209>] netlink_broadcast_filtered+0x49/0x3f0
| [<ffffffff81522621>] ? __kmalloc_reserve.isra.33+0x31/0x90
| [<ffffffff8156e5cd>] netlink_broadcast+0x1d/0x20
| [<ffffffff8147f57a>] cn_netlink_send_mult+0x19a/0x1f0
| [<ffffffff8147f5eb>] cn_netlink_send+0x1b/0x20
| [<ffffffff814801d8>] proc_exit_connector+0xf8/0x140
| [<ffffffff81077f71>] do_exit+0x5d1/0xba0
| [<ffffffff810785cc>] do_group_exit+0x4c/0xc0
| [<ffffffff81078654>] SyS_exit_group+0x14/0x20
| [<ffffffff81640a72>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Since ab8ed95 ("connector: fix out-of-order cn_proc netlink message
delivery") which is v4.7-rc6.

Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
kernelOfTruth pushed a commit to kernelOfTruth/linux that referenced this pull request Dec 28, 2016
@umgwanakikbuti
connector/cn_proc: Protect send_msg() with a local lock on RT
714e224 
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
|Preemption disabled at:[<ffffffff8148019b>] proc_exit_connector+0xbb/0x140
|
|CPU: 4 PID: 31807 Comm: sleep Tainted: G        W   E   4.8.0-rt11-rt torvalds#106
|Call Trace:
| [<ffffffff813436cd>] dump_stack+0x65/0x88
| [<ffffffff8109c425>] ___might_sleep+0xf5/0x180
| [<ffffffff816406b0>] __rt_spin_lock+0x20/0x50
| [<ffffffff81640978>] rt_read_lock+0x28/0x30
| [<ffffffff8156e209>] netlink_broadcast_filtered+0x49/0x3f0
| [<ffffffff81522621>] ? __kmalloc_reserve.isra.33+0x31/0x90
| [<ffffffff8156e5cd>] netlink_broadcast+0x1d/0x20
| [<ffffffff8147f57a>] cn_netlink_send_mult+0x19a/0x1f0
| [<ffffffff8147f5eb>] cn_netlink_send+0x1b/0x20
| [<ffffffff814801d8>] proc_exit_connector+0xf8/0x140
| [<ffffffff81077f71>] do_exit+0x5d1/0xba0
| [<ffffffff810785cc>] do_group_exit+0x4c/0xc0
| [<ffffffff81078654>] SyS_exit_group+0x14/0x20
| [<ffffffff81640a72>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Since ab8ed95 ("connector: fix out-of-order cn_proc netlink message
delivery") which is v4.7-rc6.

Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
harisokanovic pushed a commit to harisokanovic/linux that referenced this pull request Feb 3, 2017
@umgwanakikbuti
connector/cn_proc: Protect send_msg() with a local lock on RT
54bee3a 
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
|Preemption disabled at:[<ffffffff8148019b>] proc_exit_connector+0xbb/0x140
|
|CPU: 4 PID: 31807 Comm: sleep Tainted: G        W   E   4.8.0-rt11-rt torvalds#106
|Call Trace:
| [<ffffffff813436cd>] dump_stack+0x65/0x88
| [<ffffffff8109c425>] ___might_sleep+0xf5/0x180
| [<ffffffff816406b0>] __rt_spin_lock+0x20/0x50
| [<ffffffff81640978>] rt_read_lock+0x28/0x30
| [<ffffffff8156e209>] netlink_broadcast_filtered+0x49/0x3f0
| [<ffffffff81522621>] ? __kmalloc_reserve.isra.33+0x31/0x90
| [<ffffffff8156e5cd>] netlink_broadcast+0x1d/0x20
| [<ffffffff8147f57a>] cn_netlink_send_mult+0x19a/0x1f0
| [<ffffffff8147f5eb>] cn_netlink_send+0x1b/0x20
| [<ffffffff814801d8>] proc_exit_connector+0xf8/0x140
| [<ffffffff81077f71>] do_exit+0x5d1/0xba0
| [<ffffffff810785cc>] do_group_exit+0x4c/0xc0
| [<ffffffff81078654>] SyS_exit_group+0x14/0x20
| [<ffffffff81640a72>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Since ab8ed95 ("connector: fix out-of-order cn_proc netlink message
delivery") which is v4.7-rc6.

Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
kernelOfTruth pushed a commit to kernelOfTruth/linux that referenced this pull request Feb 19, 2017
@umgwanakikbuti
connector/cn_proc: Protect send_msg() with a local lock on RT
ccc392a 
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
|Preemption disabled at:[<ffffffff8148019b>] proc_exit_connector+0xbb/0x140
|
|CPU: 4 PID: 31807 Comm: sleep Tainted: G        W   E   4.8.0-rt11-rt torvalds#106
|Call Trace:
| [<ffffffff813436cd>] dump_stack+0x65/0x88
| [<ffffffff8109c425>] ___might_sleep+0xf5/0x180
| [<ffffffff816406b0>] __rt_spin_lock+0x20/0x50
| [<ffffffff81640978>] rt_read_lock+0x28/0x30
| [<ffffffff8156e209>] netlink_broadcast_filtered+0x49/0x3f0
| [<ffffffff81522621>] ? __kmalloc_reserve.isra.33+0x31/0x90
| [<ffffffff8156e5cd>] netlink_broadcast+0x1d/0x20
| [<ffffffff8147f57a>] cn_netlink_send_mult+0x19a/0x1f0
| [<ffffffff8147f5eb>] cn_netlink_send+0x1b/0x20
| [<ffffffff814801d8>] proc_exit_connector+0xf8/0x140
| [<ffffffff81077f71>] do_exit+0x5d1/0xba0
| [<ffffffff810785cc>] do_group_exit+0x4c/0xc0
| [<ffffffff81078654>] SyS_exit_group+0x14/0x20
| [<ffffffff81640a72>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Since ab8ed95 ("connector: fix out-of-order cn_proc netlink message
delivery") which is v4.7-rc6.

Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
kernelOfTruth pushed a commit to kernelOfTruth/linux that referenced this pull request May 10, 2017
@umgwanakikbuti
connector/cn_proc: Protect send_msg() with a local lock on RT
03d0476 
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
|Preemption disabled at:[<ffffffff8148019b>] proc_exit_connector+0xbb/0x140
|
|CPU: 4 PID: 31807 Comm: sleep Tainted: G        W   E   4.8.0-rt11-rt torvalds#106
|Call Trace:
| [<ffffffff813436cd>] dump_stack+0x65/0x88
| [<ffffffff8109c425>] ___might_sleep+0xf5/0x180
| [<ffffffff816406b0>] __rt_spin_lock+0x20/0x50
| [<ffffffff81640978>] rt_read_lock+0x28/0x30
| [<ffffffff8156e209>] netlink_broadcast_filtered+0x49/0x3f0
| [<ffffffff81522621>] ? __kmalloc_reserve.isra.33+0x31/0x90
| [<ffffffff8156e5cd>] netlink_broadcast+0x1d/0x20
| [<ffffffff8147f57a>] cn_netlink_send_mult+0x19a/0x1f0
| [<ffffffff8147f5eb>] cn_netlink_send+0x1b/0x20
| [<ffffffff814801d8>] proc_exit_connector+0xf8/0x140
| [<ffffffff81077f71>] do_exit+0x5d1/0xba0
| [<ffffffff810785cc>] do_group_exit+0x4c/0xc0
| [<ffffffff81078654>] SyS_exit_group+0x14/0x20
| [<ffffffff81640a72>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Since ab8ed95 ("connector: fix out-of-order cn_proc netlink message
delivery") which is v4.7-rc6.

Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
kernelOfTruth pushed a commit to kernelOfTruth/linux that referenced this pull request May 10, 2017
@umgwanakikbuti
connector/cn_proc: Protect send_msg() with a local lock on RT
7af01f5 
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
|Preemption disabled at:[<ffffffff8148019b>] proc_exit_connector+0xbb/0x140
|
|CPU: 4 PID: 31807 Comm: sleep Tainted: G        W   E   4.8.0-rt11-rt torvalds#106
|Call Trace:
| [<ffffffff813436cd>] dump_stack+0x65/0x88
| [<ffffffff8109c425>] ___might_sleep+0xf5/0x180
| [<ffffffff816406b0>] __rt_spin_lock+0x20/0x50
| [<ffffffff81640978>] rt_read_lock+0x28/0x30
| [<ffffffff8156e209>] netlink_broadcast_filtered+0x49/0x3f0
| [<ffffffff81522621>] ? __kmalloc_reserve.isra.33+0x31/0x90
| [<ffffffff8156e5cd>] netlink_broadcast+0x1d/0x20
| [<ffffffff8147f57a>] cn_netlink_send_mult+0x19a/0x1f0
| [<ffffffff8147f5eb>] cn_netlink_send+0x1b/0x20
| [<ffffffff814801d8>] proc_exit_connector+0xf8/0x140
| [<ffffffff81077f71>] do_exit+0x5d1/0xba0
| [<ffffffff810785cc>] do_group_exit+0x4c/0xc0
| [<ffffffff81078654>] SyS_exit_group+0x14/0x20
| [<ffffffff81640a72>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Since ab8ed95 ("connector: fix out-of-order cn_proc netlink message
delivery") which is v4.7-rc6.

Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
kernelOfTruth pushed a commit to kernelOfTruth/linux that referenced this pull request May 10, 2017
@umgwanakikbuti
connector/cn_proc: Protect send_msg() with a local lock on RT
8b6fb71 
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
|Preemption disabled at:[<ffffffff8148019b>] proc_exit_connector+0xbb/0x140
|
|CPU: 4 PID: 31807 Comm: sleep Tainted: G        W   E   4.8.0-rt11-rt torvalds#106
|Call Trace:
| [<ffffffff813436cd>] dump_stack+0x65/0x88
| [<ffffffff8109c425>] ___might_sleep+0xf5/0x180
| [<ffffffff816406b0>] __rt_spin_lock+0x20/0x50
| [<ffffffff81640978>] rt_read_lock+0x28/0x30
| [<ffffffff8156e209>] netlink_broadcast_filtered+0x49/0x3f0
| [<ffffffff81522621>] ? __kmalloc_reserve.isra.33+0x31/0x90
| [<ffffffff8156e5cd>] netlink_broadcast+0x1d/0x20
| [<ffffffff8147f57a>] cn_netlink_send_mult+0x19a/0x1f0
| [<ffffffff8147f5eb>] cn_netlink_send+0x1b/0x20
| [<ffffffff814801d8>] proc_exit_connector+0xf8/0x140
| [<ffffffff81077f71>] do_exit+0x5d1/0xba0
| [<ffffffff810785cc>] do_group_exit+0x4c/0xc0
| [<ffffffff81078654>] SyS_exit_group+0x14/0x20
| [<ffffffff81640a72>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Since ab8ed95 ("connector: fix out-of-order cn_proc netlink message
delivery") which is v4.7-rc6.

Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
heftig referenced this pull request in zen-kernel/zen-kernel May 20, 2017
@djbw @gregkh
libnvdimm: fix nvdimm_bus_lock() vs device_lock() ordering
a3ff3eb 
commit 452bae0 upstream.

A debug patch to turn the standard device_lock() into something that
lockdep can analyze yielded the following:

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 4.11.0-rc4+ #106 Tainted: G           O
 -------------------------------------------------------
 lt-libndctl/1898 is trying to acquire lock:
  (&dev->nvdimm_mutex/3){+.+.+.}, at: [<ffffffffc023c948>] nd_attach_ndns+0x178/0x1b0 [libnvdimm]

 but task is already holding lock:
  (&nvdimm_bus->reconfig_mutex){+.+.+.}, at: [<ffffffffc022e0b1>] nvdimm_bus_lock+0x21/0x30 [libnvdimm]

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 (&nvdimm_bus->reconfig_mutex){+.+.+.}:
        lock_acquire+0xf6/0x1f0
        __mutex_lock+0x88/0x980
        mutex_lock_nested+0x1b/0x20
        nvdimm_bus_lock+0x21/0x30 [libnvdimm]
        nvdimm_namespace_capacity+0x1b/0x40 [libnvdimm]
        nvdimm_namespace_common_probe+0x230/0x510 [libnvdimm]
        nd_pmem_probe+0x14/0x180 [nd_pmem]
        nvdimm_bus_probe+0xa9/0x260 [libnvdimm]

 -> #0 (&dev->nvdimm_mutex/3){+.+.+.}:
        __lock_acquire+0x1107/0x1280
        lock_acquire+0xf6/0x1f0
        __mutex_lock+0x88/0x980
        mutex_lock_nested+0x1b/0x20
        nd_attach_ndns+0x178/0x1b0 [libnvdimm]
        nd_namespace_store+0x308/0x3c0 [libnvdimm]
        namespace_store+0x87/0x220 [libnvdimm]

In this case '&dev->nvdimm_mutex/3' mirrors '&dev->mutex'.

Fix this by replacing the use of device_lock() with nvdimm_bus_lock() to protect
nd_{attach,detach}_ndns() operations.

Fixes: 8c2f7e8 ("libnvdimm: infrastructure for btt devices")
Reported-by: Yi Zhang <yizhan@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
koenkooi pushed a commit to koenkooi/linux that referenced this pull request May 21, 2017
@djbw @gregkh
libnvdimm: fix nvdimm_bus_lock() vs device_lock() ordering
116ada1 
commit 452bae0 upstream.

A debug patch to turn the standard device_lock() into something that
lockdep can analyze yielded the following:

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 4.11.0-rc4+ torvalds#106 Tainted: G           O
 -------------------------------------------------------
 lt-libndctl/1898 is trying to acquire lock:
  (&dev->nvdimm_mutex/3){+.+.+.}, at: [<ffffffffc023c948>] nd_attach_ndns+0x178/0x1b0 [libnvdimm]

 but task is already holding lock:
  (&nvdimm_bus->reconfig_mutex){+.+.+.}, at: [<ffffffffc022e0b1>] nvdimm_bus_lock+0x21/0x30 [libnvdimm]

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 (&nvdimm_bus->reconfig_mutex){+.+.+.}:
        lock_acquire+0xf6/0x1f0
        __mutex_lock+0x88/0x980
        mutex_lock_nested+0x1b/0x20
        nvdimm_bus_lock+0x21/0x30 [libnvdimm]
        nvdimm_namespace_capacity+0x1b/0x40 [libnvdimm]
        nvdimm_namespace_common_probe+0x230/0x510 [libnvdimm]
        nd_pmem_probe+0x14/0x180 [nd_pmem]
        nvdimm_bus_probe+0xa9/0x260 [libnvdimm]

 -> #0 (&dev->nvdimm_mutex/3){+.+.+.}:
        __lock_acquire+0x1107/0x1280
        lock_acquire+0xf6/0x1f0
        __mutex_lock+0x88/0x980
        mutex_lock_nested+0x1b/0x20
        nd_attach_ndns+0x178/0x1b0 [libnvdimm]
        nd_namespace_store+0x308/0x3c0 [libnvdimm]
        namespace_store+0x87/0x220 [libnvdimm]

In this case '&dev->nvdimm_mutex/3' mirrors '&dev->mutex'.

Fix this by replacing the use of device_lock() with nvdimm_bus_lock() to protect
nd_{attach,detach}_ndns() operations.

Fixes: 8c2f7e8 ("libnvdimm: infrastructure for btt devices")
Reported-by: Yi Zhang <yizhan@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
chyyuu pushed a commit to chyyuu/linux that referenced this pull request May 30, 2017
@umgwanakikbuti @chyyuu-tsinghua-cs
connector/cn_proc: Protect send_msg() with a local lock on RT
bed0536 
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
|Preemption disabled at:[<ffffffff8148019b>] proc_exit_connector+0xbb/0x140
|
|CPU: 4 PID: 31807 Comm: sleep Tainted: G        W   E   4.8.0-rt11-rt torvalds#106
|Call Trace:
| [<ffffffff813436cd>] dump_stack+0x65/0x88
| [<ffffffff8109c425>] ___might_sleep+0xf5/0x180
| [<ffffffff816406b0>] __rt_spin_lock+0x20/0x50
| [<ffffffff81640978>] rt_read_lock+0x28/0x30
| [<ffffffff8156e209>] netlink_broadcast_filtered+0x49/0x3f0
| [<ffffffff81522621>] ? __kmalloc_reserve.isra.33+0x31/0x90
| [<ffffffff8156e5cd>] netlink_broadcast+0x1d/0x20
| [<ffffffff8147f57a>] cn_netlink_send_mult+0x19a/0x1f0
| [<ffffffff8147f5eb>] cn_netlink_send+0x1b/0x20
| [<ffffffff814801d8>] proc_exit_connector+0xf8/0x140
| [<ffffffff81077f71>] do_exit+0x5d1/0xba0
| [<ffffffff810785cc>] do_group_exit+0x4c/0xc0
| [<ffffffff81078654>] SyS_exit_group+0x14/0x20
| [<ffffffff81640a72>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Since ab8ed95 ("connector: fix out-of-order cn_proc netlink message
delivery") which is v4.7-rc6.

Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
chyyuu pushed a commit to chyyuu/linux that referenced this pull request Jun 5, 2017
@umgwanakikbuti @chyyuu-tsinghua-cs
connector/cn_proc: Protect send_msg() with a local lock on RT
5655d16 
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
|Preemption disabled at:[<ffffffff8148019b>] proc_exit_connector+0xbb/0x140
|
|CPU: 4 PID: 31807 Comm: sleep Tainted: G        W   E   4.8.0-rt11-rt torvalds#106
|Call Trace:
| [<ffffffff813436cd>] dump_stack+0x65/0x88
| [<ffffffff8109c425>] ___might_sleep+0xf5/0x180
| [<ffffffff816406b0>] __rt_spin_lock+0x20/0x50
| [<ffffffff81640978>] rt_read_lock+0x28/0x30
| [<ffffffff8156e209>] netlink_broadcast_filtered+0x49/0x3f0
| [<ffffffff81522621>] ? __kmalloc_reserve.isra.33+0x31/0x90
| [<ffffffff8156e5cd>] netlink_broadcast+0x1d/0x20
| [<ffffffff8147f57a>] cn_netlink_send_mult+0x19a/0x1f0
| [<ffffffff8147f5eb>] cn_netlink_send+0x1b/0x20
| [<ffffffff814801d8>] proc_exit_connector+0xf8/0x140
| [<ffffffff81077f71>] do_exit+0x5d1/0xba0
| [<ffffffff810785cc>] do_group_exit+0x4c/0xc0
| [<ffffffff81078654>] SyS_exit_group+0x14/0x20
| [<ffffffff81640a72>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Since ab8ed95 ("connector: fix out-of-order cn_proc netlink message
delivery") which is v4.7-rc6.

Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Jul 18, 2017
@umgwanakikbuti
connector/cn_proc: Protect send_msg() with a local lock on RT
b874fe4 
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
|in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
|Preemption disabled at:[<ffffffff8148019b>] proc_exit_connector+0xbb/0x140
|
|CPU: 4 PID: 31807 Comm: sleep Tainted: G        W   E   4.8.0-rt11-rt torvalds#106
|Call Trace:
| [<ffffffff813436cd>] dump_stack+0x65/0x88
| [<ffffffff8109c425>] ___might_sleep+0xf5/0x180
| [<ffffffff816406b0>] __rt_spin_lock+0x20/0x50
| [<ffffffff81640978>] rt_read_lock+0x28/0x30
| [<ffffffff8156e209>] netlink_broadcast_filtered+0x49/0x3f0
| [<ffffffff81522621>] ? __kmalloc_reserve.isra.33+0x31/0x90
| [<ffffffff8156e5cd>] netlink_broadcast+0x1d/0x20
| [<ffffffff8147f57a>] cn_netlink_send_mult+0x19a/0x1f0
| [<ffffffff8147f5eb>] cn_netlink_send+0x1b/0x20
| [<ffffffff814801d8>] proc_exit_connector+0xf8/0x140
| [<ffffffff81077f71>] do_exit+0x5d1/0xba0
| [<ffffffff810785cc>] do_group_exit+0x4c/0xc0
| [<ffffffff81078654>] SyS_exit_group+0x14/0x20
| [<ffffffff81640a72>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Since ab8ed95 ("connector: fix out-of-order cn_proc netlink message
delivery") which is v4.7-rc6.

Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
jhovold added a commit to jhovold/linux that referenced this pull request Jun 16, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
90b2776 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Jun 21, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
5174705 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jun 23, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
1f64e23 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jun 23, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
b0811b4 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Jun 30, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
74b7231 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jun 30, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
4d360dc 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jun 30, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
86f0046 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jul 7, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
0c042b5 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jul 7, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
d785c26 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Jul 10, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
b872129 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jul 14, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
18e182c 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jul 14, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
57bc570 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
vamanea pushed a commit to vamanea/linux-magicbook that referenced this pull request Jul 14, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
9835d68 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Jul 15, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
a925ab2 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Jul 16, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
2c97d92 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jul 21, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
775a013 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jul 21, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
433ca75 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Jul 26, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
a8d244b 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Sombre-Osmoze pushed a commit to Sombre-Osmoze/linux that referenced this pull request Jul 26, 2025
@jhovold @tobhe
hack: media: qcom: camss: fix sensor pad null-deref at boot
94e7048 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Jul 26, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
c685eeb 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jul 28, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
9ace80b 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
jhovold added a commit to jhovold/linux that referenced this pull request Jul 28, 2025
@jhovold
hack: media: qcom: camss: fix sensor pad null-deref at boot
07eb520 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
krzk pushed a commit to krzk/linux that referenced this pull request Jul 31, 2025
@jhovold @abelvesa
hack: media: qcom: camss: fix sensor pad null-deref at boot
484b15f 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Aug 1, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
0daf70d 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Aug 16, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
0055f91 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Aug 16, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
5c23191 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Aug 19, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
0bea930 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
steev pushed a commit to steev/linux that referenced this pull request Aug 23, 2025
@jhovold @0x011011110
hack: media: qcom: camss: fix sensor pad null-deref at boot
78ab07e 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
vamanea pushed a commit to vamanea/linux-magicbook that referenced this pull request Aug 25, 2025
@jhovold @abelvesa
hack: media: qcom: camss: fix sensor pad null-deref at boot
3c7d240 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
krzk pushed a commit to krzk/linux that referenced this pull request Aug 30, 2025
@jhovold @abelvesa
hack: media: qcom: camss: fix sensor pad null-deref at boot
879c631 
Due to an unresolved bug in camss (or v4l2), user space can access the
camera device before things have been fully set up.

This specifically results in a NULL pointer dereference in
camss_find_sensor_pad() when udev tries to identify the v4l2 device
during boot (and this in turn prevents the display from being probed).

    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

    CPU: 3 UID: 0 PID: 442 Comm: v4l_id Not tainted 6.15.0-rc1 torvalds#106 PREEMPT

    Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

    Call trace:
     camss_find_sensor_pad+0x20/0x74 [qcom_camss] (P)
     camss_get_pixel_clock+0x18/0x64 [qcom_camss]
     vfe_get+0xb8/0x504 [qcom_camss]
     vfe_set_power+0x30/0x58 [qcom_camss]
     pipeline_pm_power_one+0x13c/0x150 [videodev]
     pipeline_pm_power.part.0+0x58/0xf4 [videodev]
     v4l2_pipeline_pm_use+0x58/0x94 [videodev]
     v4l2_pipeline_pm_get+0x14/0x20 [videodev]
     video_open+0x78/0xf4 [qcom_camss]
     v4l2_open+0x80/0x120 [videodev]

Work around the bug by bailing out if camss_find_sensor_pad() is called
for an uninitialised media entity to allow machines like the Lenovo
ThinkPad X13s to boot.

Link: https://lore.kernel.org/lkml/Z_PXzvL5Zt9QkivE@hovoldconsulting.com/
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@blackmiaool @sigifredo