Skip to content
New issue

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

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

Update nv50.c #43

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update nv50.c #43

wants to merge 1 commit into from

Conversation

nmtigor
Copy link

@nmtigor nmtigor commented Aug 10, 2013

"limit" is "length-1", otherwise line 143 should be corrected.

techn pushed a commit to techn/linux-allwinner that referenced this pull request Aug 12, 2013
heftig referenced this pull request in zen-kernel/zen-kernel Sep 3, 2013
Set acpi_skip_timer_override to force ignoring BIOS
IRQ0 pin2 override. This fixes resume from suspend on
AMD based ThinkPad Edge 11,13,14 and 15.

Please note that with this patch applied, you will see
a warning message from the kernel, this is printed in acpi/boot.c
before it sets acpi_skip_timer_override=1;

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at /home/manjo/ubuntu-maverick-674710/arch/x86/kernel/acpi/boot.c:1345 dmi_ignore_irq0_timer_override+0x2e/0x52()
[    0.000000] Hardware name: 254523U
[    0.000000] ati_ixp4x0 quirk not complete.
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.35-25-generic #43
[    0.000000] Call Trace:
[    0.000000]  [<c014ad42>] warn_slowpath_common+0x72/0xa0
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c014ae13>] warn_slowpath_fmt+0x33/0x40
[    0.000000]  [<c0826724>] dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c04dd7d0>] dmi_check_system+0x30/0x50
[    0.000000]  [<c0826df4>] acpi_boot_table_init+0x10/0x7d
[    0.000000]  [<c0821ea7>] ? io_delay_init+0x16/0x18
[    0.000000]  [<c081f556>] setup_arch+0x562/0x645
[    0.000000]  [<c012cf19>] ? default_spin_lock_flags+0x9/0x10
[    0.000000]  [<c081b57b>] start_kernel+0xcf/0x374
[    0.000000]  [<c081b0d7>] i386_start_kernel+0xd7/0xdf
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] ThinkPad Edge detected: Ignoring BIOS IRQ0 pin2 override

Signed-off-by: Manoj Iyer <[email protected]>

BugLink: http://launchpad.net/bugs/702434
Acked-by: Stefan Bader <[email protected]>
Signed-off-by: Andy Whitcroft <[email protected]>
swarren pushed a commit to swarren/linux-tegra that referenced this pull request Oct 14, 2013
As the new x86 CPU bootup printout format code maintainer, I am
taking immediate action to improve and clean (and thus indulge
my OCD) the reporting of the cores when coming up online.

Fix padding to a right-hand alignment, cleanup code and bind
reporting width to the max number of supported CPUs on the
system, like this:

 [    0.074509] smpboot: Booting Node   0, Processors:      #1  #2  #3  #4  #5  torvalds#6  torvalds#7 OK
 [    0.644008] smpboot: Booting Node   1, Processors:  torvalds#8  torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 OK
 [    1.245006] smpboot: Booting Node   2, Processors: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 OK
 [    1.864005] smpboot: Booting Node   3, Processors: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 OK
 [    2.489005] smpboot: Booting Node   4, Processors: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 OK
 [    3.093005] smpboot: Booting Node   5, Processors: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 OK
 [    3.698005] smpboot: Booting Node   6, Processors: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 OK
 [    4.304005] smpboot: Booting Node   7, Processors: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 OK
 [    4.961413] Brought up 64 CPUs

and this:

 [    0.072367] smpboot: Booting Node   0, Processors:    #1 #2 #3 #4 #5 torvalds#6 torvalds#7 OK
 [    0.686329] Brought up 8 CPUs

Signed-off-by: Borislav Petkov <[email protected]>
Cc: Libin <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
swarren pushed a commit to swarren/linux-tegra that referenced this pull request Oct 14, 2013
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 <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
heftig referenced this pull request in zen-kernel/zen-kernel Nov 4, 2013
Set acpi_skip_timer_override to force ignoring BIOS
IRQ0 pin2 override. This fixes resume from suspend on
AMD based ThinkPad Edge 11,13,14 and 15.

Please note that with this patch applied, you will see
a warning message from the kernel, this is printed in acpi/boot.c
before it sets acpi_skip_timer_override=1;

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at /home/manjo/ubuntu-maverick-674710/arch/x86/kernel/acpi/boot.c:1345 dmi_ignore_irq0_timer_override+0x2e/0x52()
[    0.000000] Hardware name: 254523U
[    0.000000] ati_ixp4x0 quirk not complete.
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.35-25-generic #43
[    0.000000] Call Trace:
[    0.000000]  [<c014ad42>] warn_slowpath_common+0x72/0xa0
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c014ae13>] warn_slowpath_fmt+0x33/0x40
[    0.000000]  [<c0826724>] dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c04dd7d0>] dmi_check_system+0x30/0x50
[    0.000000]  [<c0826df4>] acpi_boot_table_init+0x10/0x7d
[    0.000000]  [<c0821ea7>] ? io_delay_init+0x16/0x18
[    0.000000]  [<c081f556>] setup_arch+0x562/0x645
[    0.000000]  [<c012cf19>] ? default_spin_lock_flags+0x9/0x10
[    0.000000]  [<c081b57b>] start_kernel+0xcf/0x374
[    0.000000]  [<c081b0d7>] i386_start_kernel+0xd7/0xdf
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] ThinkPad Edge detected: Ignoring BIOS IRQ0 pin2 override

Signed-off-by: Manoj Iyer <[email protected]>

BugLink: http://launchpad.net/bugs/702434
Acked-by: Stefan Bader <[email protected]>
Signed-off-by: Andy Whitcroft <[email protected]>
heftig referenced this pull request in zen-kernel/zen-kernel Jan 20, 2014
Set acpi_skip_timer_override to force ignoring BIOS
IRQ0 pin2 override. This fixes resume from suspend on
AMD based ThinkPad Edge 11,13,14 and 15.

Please note that with this patch applied, you will see
a warning message from the kernel, this is printed in acpi/boot.c
before it sets acpi_skip_timer_override=1;

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at /home/manjo/ubuntu-maverick-674710/arch/x86/kernel/acpi/boot.c:1345 dmi_ignore_irq0_timer_override+0x2e/0x52()
[    0.000000] Hardware name: 254523U
[    0.000000] ati_ixp4x0 quirk not complete.
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.35-25-generic #43
[    0.000000] Call Trace:
[    0.000000]  [<c014ad42>] warn_slowpath_common+0x72/0xa0
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c014ae13>] warn_slowpath_fmt+0x33/0x40
[    0.000000]  [<c0826724>] dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c04dd7d0>] dmi_check_system+0x30/0x50
[    0.000000]  [<c0826df4>] acpi_boot_table_init+0x10/0x7d
[    0.000000]  [<c0821ea7>] ? io_delay_init+0x16/0x18
[    0.000000]  [<c081f556>] setup_arch+0x562/0x645
[    0.000000]  [<c012cf19>] ? default_spin_lock_flags+0x9/0x10
[    0.000000]  [<c081b57b>] start_kernel+0xcf/0x374
[    0.000000]  [<c081b0d7>] i386_start_kernel+0xd7/0xdf
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] ThinkPad Edge detected: Ignoring BIOS IRQ0 pin2 override

Signed-off-by: Manoj Iyer <[email protected]>

BugLink: http://launchpad.net/bugs/702434
Acked-by: Stefan Bader <[email protected]>
Signed-off-by: Andy Whitcroft <[email protected]>
heftig referenced this pull request in zen-kernel/zen-kernel Mar 31, 2014
Set acpi_skip_timer_override to force ignoring BIOS
IRQ0 pin2 override. This fixes resume from suspend on
AMD based ThinkPad Edge 11,13,14 and 15.

Please note that with this patch applied, you will see
a warning message from the kernel, this is printed in acpi/boot.c
before it sets acpi_skip_timer_override=1;

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at /home/manjo/ubuntu-maverick-674710/arch/x86/kernel/acpi/boot.c:1345 dmi_ignore_irq0_timer_override+0x2e/0x52()
[    0.000000] Hardware name: 254523U
[    0.000000] ati_ixp4x0 quirk not complete.
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.35-25-generic #43
[    0.000000] Call Trace:
[    0.000000]  [<c014ad42>] warn_slowpath_common+0x72/0xa0
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c014ae13>] warn_slowpath_fmt+0x33/0x40
[    0.000000]  [<c0826724>] dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c04dd7d0>] dmi_check_system+0x30/0x50
[    0.000000]  [<c0826df4>] acpi_boot_table_init+0x10/0x7d
[    0.000000]  [<c0821ea7>] ? io_delay_init+0x16/0x18
[    0.000000]  [<c081f556>] setup_arch+0x562/0x645
[    0.000000]  [<c012cf19>] ? default_spin_lock_flags+0x9/0x10
[    0.000000]  [<c081b57b>] start_kernel+0xcf/0x374
[    0.000000]  [<c081b0d7>] i386_start_kernel+0xd7/0xdf
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] ThinkPad Edge detected: Ignoring BIOS IRQ0 pin2 override

Signed-off-by: Manoj Iyer <[email protected]>

BugLink: http://launchpad.net/bugs/702434
Acked-by: Stefan Bader <[email protected]>
Signed-off-by: Andy Whitcroft <[email protected]>
heftig referenced this pull request in zen-kernel/zen-kernel Jun 9, 2014
Set acpi_skip_timer_override to force ignoring BIOS
IRQ0 pin2 override. This fixes resume from suspend on
AMD based ThinkPad Edge 11,13,14 and 15.

Please note that with this patch applied, you will see
a warning message from the kernel, this is printed in acpi/boot.c
before it sets acpi_skip_timer_override=1;

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at /home/manjo/ubuntu-maverick-674710/arch/x86/kernel/acpi/boot.c:1345 dmi_ignore_irq0_timer_override+0x2e/0x52()
[    0.000000] Hardware name: 254523U
[    0.000000] ati_ixp4x0 quirk not complete.
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.35-25-generic #43
[    0.000000] Call Trace:
[    0.000000]  [<c014ad42>] warn_slowpath_common+0x72/0xa0
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c014ae13>] warn_slowpath_fmt+0x33/0x40
[    0.000000]  [<c0826724>] dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c04dd7d0>] dmi_check_system+0x30/0x50
[    0.000000]  [<c0826df4>] acpi_boot_table_init+0x10/0x7d
[    0.000000]  [<c0821ea7>] ? io_delay_init+0x16/0x18
[    0.000000]  [<c081f556>] setup_arch+0x562/0x645
[    0.000000]  [<c012cf19>] ? default_spin_lock_flags+0x9/0x10
[    0.000000]  [<c081b57b>] start_kernel+0xcf/0x374
[    0.000000]  [<c081b0d7>] i386_start_kernel+0xd7/0xdf
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] ThinkPad Edge detected: Ignoring BIOS IRQ0 pin2 override

Signed-off-by: Manoj Iyer <[email protected]>

BugLink: http://launchpad.net/bugs/702434
Acked-by: Stefan Bader <[email protected]>
Signed-off-by: Andy Whitcroft <[email protected]>
jonsmirl pushed a commit to jonsmirl/lpc31xx that referenced this pull request Jun 20, 2014
heftig referenced this pull request in zen-kernel/zen-kernel Aug 4, 2014
Set acpi_skip_timer_override to force ignoring BIOS
IRQ0 pin2 override. This fixes resume from suspend on
AMD based ThinkPad Edge 11,13,14 and 15.

Please note that with this patch applied, you will see
a warning message from the kernel, this is printed in acpi/boot.c
before it sets acpi_skip_timer_override=1;

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at /home/manjo/ubuntu-maverick-674710/arch/x86/kernel/acpi/boot.c:1345 dmi_ignore_irq0_timer_override+0x2e/0x52()
[    0.000000] Hardware name: 254523U
[    0.000000] ati_ixp4x0 quirk not complete.
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.35-25-generic #43
[    0.000000] Call Trace:
[    0.000000]  [<c014ad42>] warn_slowpath_common+0x72/0xa0
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c014ae13>] warn_slowpath_fmt+0x33/0x40
[    0.000000]  [<c0826724>] dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c04dd7d0>] dmi_check_system+0x30/0x50
[    0.000000]  [<c0826df4>] acpi_boot_table_init+0x10/0x7d
[    0.000000]  [<c0821ea7>] ? io_delay_init+0x16/0x18
[    0.000000]  [<c081f556>] setup_arch+0x562/0x645
[    0.000000]  [<c012cf19>] ? default_spin_lock_flags+0x9/0x10
[    0.000000]  [<c081b57b>] start_kernel+0xcf/0x374
[    0.000000]  [<c081b0d7>] i386_start_kernel+0xd7/0xdf
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] ThinkPad Edge detected: Ignoring BIOS IRQ0 pin2 override

Signed-off-by: Manoj Iyer <[email protected]>

BugLink: http://launchpad.net/bugs/702434
Acked-by: Stefan Bader <[email protected]>
Signed-off-by: Andy Whitcroft <[email protected]>
intelfx pushed a commit to intelfx/linux that referenced this pull request Sep 27, 2014
Problem:
parse_cut() calculates cut mode incorrectly when the range contains
objects with non-unique keys, e.g. directory items.

Scenario of corruption.
A node contains only one cde-item with 44 (#0-torvalds#43) units, and the units
torvalds#42,torvalds#43 have identical keys (because of hash collision). We shift units
#0-torvalds#42 to left. In this case parse_cut() jumps to the branch "removed
completely". As the result the whole item is removed, while only units
#0-torvalds#42 are copied to the left neighbor. unlink() can not find directory
entry which corresponds to unexpectedly killed unit torvalds#43. rmdir() doesn't
decrement size of the directory in the error path. As the result, the
directory becomes non-deletable.

Fixup:
For ranges with non-unique keys use a special version of parse_cut(),
which doesn't calculate cut mode by keys.

Signed-off-by: Edward Shishkin <[email protected]>
torvalds pushed a commit that referenced this pull request Oct 29, 2014
This patch wires up the new syscall sys_bpf() on powerpc.

Passes the tests in samples/bpf:

    #0 add+sub+mul OK
    #1 unreachable OK
    #2 unreachable2 OK
    #3 out of range jump OK
    #4 out of range jump2 OK
    #5 test1 ld_imm64 OK
    #6 test2 ld_imm64 OK
    #7 test3 ld_imm64 OK
    #8 test4 ld_imm64 OK
    #9 test5 ld_imm64 OK
    #10 no bpf_exit OK
    #11 loop (back-edge) OK
    #12 loop2 (back-edge) OK
    #13 conditional loop OK
    #14 read uninitialized register OK
    #15 read invalid register OK
    #16 program doesn't init R0 before exit OK
    #17 stack out of bounds OK
    #18 invalid call insn1 OK
    #19 invalid call insn2 OK
    #20 invalid function call OK
    #21 uninitialized stack1 OK
    #22 uninitialized stack2 OK
    #23 check valid spill/fill OK
    #24 check corrupted spill/fill OK
    #25 invalid src register in STX OK
    #26 invalid dst register in STX OK
    #27 invalid dst register in ST OK
    #28 invalid src register in LDX OK
    #29 invalid dst register in LDX OK
    #30 junk insn OK
    #31 junk insn2 OK
    #32 junk insn3 OK
    #33 junk insn4 OK
    #34 junk insn5 OK
    #35 misaligned read from stack OK
    #36 invalid map_fd for function call OK
    #37 don't check return value before access OK
    #38 access memory with incorrect alignment OK
    #39 sometimes access memory with incorrect alignment OK
    #40 jump test 1 OK
    #41 jump test 2 OK
    #42 jump test 3 OK
    #43 jump test 4 OK

Signed-off-by: Pranith Kumar <[email protected]>
[mpe: test using samples/bpf]
Signed-off-by: Michael Ellerman <[email protected]>
dabrace referenced this pull request in dabrace/linux Nov 10, 2014
This patch wires up the new syscall sys_bpf() on powerpc.

Passes the tests in samples/bpf:

    #0 add+sub+mul OK
    #1 unreachable OK
    #2 unreachable2 OK
    #3 out of range jump OK
    #4 out of range jump2 OK
    #5 test1 ld_imm64 OK
    #6 test2 ld_imm64 OK
    #7 test3 ld_imm64 OK
    #8 test4 ld_imm64 OK
    #9 test5 ld_imm64 OK
    #10 no bpf_exit OK
    #11 loop (back-edge) OK
    #12 loop2 (back-edge) OK
    #13 conditional loop OK
    #14 read uninitialized register OK
    #15 read invalid register OK
    #16 program doesn't init R0 before exit OK
    #17 stack out of bounds OK
    #18 invalid call insn1 OK
    #19 invalid call insn2 OK
    #20 invalid function call OK
    #21 uninitialized stack1 OK
    #22 uninitialized stack2 OK
    #23 check valid spill/fill OK
    #24 check corrupted spill/fill OK
    #25 invalid src register in STX OK
    #26 invalid dst register in STX OK
    #27 invalid dst register in ST OK
    #28 invalid src register in LDX OK
    #29 invalid dst register in LDX OK
    #30 junk insn OK
    #31 junk insn2 OK
    #32 junk insn3 OK
    #33 junk insn4 OK
    #34 junk insn5 OK
    #35 misaligned read from stack OK
    #36 invalid map_fd for function call OK
    #37 don't check return value before access OK
    #38 access memory with incorrect alignment OK
    #39 sometimes access memory with incorrect alignment OK
    #40 jump test 1 OK
    #41 jump test 2 OK
    #42 jump test 3 OK
    #43 jump test 4 OK

Signed-off-by: Pranith Kumar <[email protected]>
[mpe: test using samples/bpf]
Signed-off-by: Michael Ellerman <[email protected]>
heftig referenced this pull request in zen-kernel/zen-kernel Dec 11, 2014
Set acpi_skip_timer_override to force ignoring BIOS
IRQ0 pin2 override. This fixes resume from suspend on
AMD based ThinkPad Edge 11,13,14 and 15.

Please note that with this patch applied, you will see
a warning message from the kernel, this is printed in acpi/boot.c
before it sets acpi_skip_timer_override=1;

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at /home/manjo/ubuntu-maverick-674710/arch/x86/kernel/acpi/boot.c:1345 dmi_ignore_irq0_timer_override+0x2e/0x52()
[    0.000000] Hardware name: 254523U
[    0.000000] ati_ixp4x0 quirk not complete.
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.35-25-generic #43
[    0.000000] Call Trace:
[    0.000000]  [<c014ad42>] warn_slowpath_common+0x72/0xa0
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c014ae13>] warn_slowpath_fmt+0x33/0x40
[    0.000000]  [<c0826724>] dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c04dd7d0>] dmi_check_system+0x30/0x50
[    0.000000]  [<c0826df4>] acpi_boot_table_init+0x10/0x7d
[    0.000000]  [<c0821ea7>] ? io_delay_init+0x16/0x18
[    0.000000]  [<c081f556>] setup_arch+0x562/0x645
[    0.000000]  [<c012cf19>] ? default_spin_lock_flags+0x9/0x10
[    0.000000]  [<c081b57b>] start_kernel+0xcf/0x374
[    0.000000]  [<c081b0d7>] i386_start_kernel+0xd7/0xdf
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] ThinkPad Edge detected: Ignoring BIOS IRQ0 pin2 override

Signed-off-by: Manoj Iyer <[email protected]>

BugLink: http://launchpad.net/bugs/702434
Acked-by: Stefan Bader <[email protected]>
Signed-off-by: Andy Whitcroft <[email protected]>
heftig referenced this pull request in zen-kernel/zen-kernel Feb 9, 2015
Set acpi_skip_timer_override to force ignoring BIOS
IRQ0 pin2 override. This fixes resume from suspend on
AMD based ThinkPad Edge 11,13,14 and 15.

Please note that with this patch applied, you will see
a warning message from the kernel, this is printed in acpi/boot.c
before it sets acpi_skip_timer_override=1;

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at /home/manjo/ubuntu-maverick-674710/arch/x86/kernel/acpi/boot.c:1345 dmi_ignore_irq0_timer_override+0x2e/0x52()
[    0.000000] Hardware name: 254523U
[    0.000000] ati_ixp4x0 quirk not complete.
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.35-25-generic #43
[    0.000000] Call Trace:
[    0.000000]  [<c014ad42>] warn_slowpath_common+0x72/0xa0
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c014ae13>] warn_slowpath_fmt+0x33/0x40
[    0.000000]  [<c0826724>] dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c04dd7d0>] dmi_check_system+0x30/0x50
[    0.000000]  [<c0826df4>] acpi_boot_table_init+0x10/0x7d
[    0.000000]  [<c0821ea7>] ? io_delay_init+0x16/0x18
[    0.000000]  [<c081f556>] setup_arch+0x562/0x645
[    0.000000]  [<c012cf19>] ? default_spin_lock_flags+0x9/0x10
[    0.000000]  [<c081b57b>] start_kernel+0xcf/0x374
[    0.000000]  [<c081b0d7>] i386_start_kernel+0xd7/0xdf
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] ThinkPad Edge detected: Ignoring BIOS IRQ0 pin2 override

Signed-off-by: Manoj Iyer <[email protected]>

BugLink: http://launchpad.net/bugs/702434
Acked-by: Stefan Bader <[email protected]>
Signed-off-by: Andy Whitcroft <[email protected]>
torvalds pushed a commit that referenced this pull request Mar 3, 2015
Feb 12 18:20:42 nfdev kernel: ------------[ cut here ]------------
Feb 12 18:20:42 nfdev kernel: WARNING: CPU: 4 PID: 4359 at kernel/module.c:963 module_put+0x9b/0xba()
Feb 12 18:20:42 nfdev kernel: CPU: 4 PID: 4359 Comm: ebtables-compat Tainted: G        W      3.19.0-rc6+ #43
[...]
Feb 12 18:20:42 nfdev kernel: Call Trace:
Feb 12 18:20:42 nfdev kernel: [<ffffffff815fd911>] dump_stack+0x4c/0x65
Feb 12 18:20:42 nfdev kernel: [<ffffffff8103e6f7>] warn_slowpath_common+0x9c/0xb6
Feb 12 18:20:42 nfdev kernel: [<ffffffff8109919f>] ? module_put+0x9b/0xba
Feb 12 18:20:42 nfdev kernel: [<ffffffff8103e726>] warn_slowpath_null+0x15/0x17
Feb 12 18:20:42 nfdev kernel: [<ffffffff8109919f>] module_put+0x9b/0xba
Feb 12 18:20:42 nfdev kernel: [<ffffffff813ecf7c>] nft_match_destroy+0x45/0x4c
Feb 12 18:20:42 nfdev kernel: [<ffffffff813e683f>] nf_tables_rule_destroy+0x28/0x70

Reported-by: Arturo Borrero Gonzalez <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Tested-by: Arturo Borrero Gonzalez <[email protected]>
heftig referenced this pull request in zen-kernel/zen-kernel Mar 26, 2015
commit 520aa74 upstream.

Feb 12 18:20:42 nfdev kernel: ------------[ cut here ]------------
Feb 12 18:20:42 nfdev kernel: WARNING: CPU: 4 PID: 4359 at kernel/module.c:963 module_put+0x9b/0xba()
Feb 12 18:20:42 nfdev kernel: CPU: 4 PID: 4359 Comm: ebtables-compat Tainted: G        W      3.19.0-rc6+ #43
[...]
Feb 12 18:20:42 nfdev kernel: Call Trace:
Feb 12 18:20:42 nfdev kernel: [<ffffffff815fd911>] dump_stack+0x4c/0x65
Feb 12 18:20:42 nfdev kernel: [<ffffffff8103e6f7>] warn_slowpath_common+0x9c/0xb6
Feb 12 18:20:42 nfdev kernel: [<ffffffff8109919f>] ? module_put+0x9b/0xba
Feb 12 18:20:42 nfdev kernel: [<ffffffff8103e726>] warn_slowpath_null+0x15/0x17
Feb 12 18:20:42 nfdev kernel: [<ffffffff8109919f>] module_put+0x9b/0xba
Feb 12 18:20:42 nfdev kernel: [<ffffffff813ecf7c>] nft_match_destroy+0x45/0x4c
Feb 12 18:20:42 nfdev kernel: [<ffffffff813e683f>] nf_tables_rule_destroy+0x28/0x70

Reported-by: Arturo Borrero Gonzalez <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Tested-by: Arturo Borrero Gonzalez <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
gthelen pushed a commit to gthelen/linux that referenced this pull request Apr 1, 2015
Sumeone needs to buy a tab key.

WARNING: please, no spaces at the start of a line
torvalds#29: FILE: security/tomoyo/util.c:951:
+       struct file *exe_file;$

WARNING: please, no spaces at the start of a line
torvalds#30: FILE: security/tomoyo/util.c:952:
+       const char *cp;$

WARNING: please, no spaces at the start of a line
torvalds#31: FILE: security/tomoyo/util.c:953:
+       struct mm_struct *mm = current->mm;$

WARNING: please, no spaces at the start of a line
torvalds#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)$

WARNING: suspect code indent for conditional statements (7, 15)
torvalds#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)
+	       return NULL;

WARNING: please, no spaces at the start of a line
torvalds#42: FILE: security/tomoyo/util.c:957:
+       exe_file = get_mm_exe_file(mm);$

WARNING: please, no spaces at the start of a line
torvalds#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)$

WARNING: suspect code indent for conditional statements (7, 15)
torvalds#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)
+	       return NULL;

WARNING: please, no spaces at the start of a line
torvalds#46: FILE: security/tomoyo/util.c:961:
+       cp = tomoyo_realpath_from_path(&exe_file->f_path);$

WARNING: please, no spaces at the start of a line
torvalds#47: FILE: security/tomoyo/util.c:962:
+       fput(exe_file);$

WARNING: please, no spaces at the start of a line
torvalds#48: FILE: security/tomoyo/util.c:963:
+       return cp;$

total: 0 errors, 11 warnings, 28 lines checked

./patches/tomoyo-reduce-mmap_sem-hold-for-mm-exe_file.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Davidlohr Bueso <[email protected]>
Cc: James Morris <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
heftig referenced this pull request in zen-kernel/zen-kernel Apr 13, 2015
Set acpi_skip_timer_override to force ignoring BIOS
IRQ0 pin2 override. This fixes resume from suspend on
AMD based ThinkPad Edge 11,13,14 and 15.

Please note that with this patch applied, you will see
a warning message from the kernel, this is printed in acpi/boot.c
before it sets acpi_skip_timer_override=1;

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at /home/manjo/ubuntu-maverick-674710/arch/x86/kernel/acpi/boot.c:1345 dmi_ignore_irq0_timer_override+0x2e/0x52()
[    0.000000] Hardware name: 254523U
[    0.000000] ati_ixp4x0 quirk not complete.
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.35-25-generic #43
[    0.000000] Call Trace:
[    0.000000]  [<c014ad42>] warn_slowpath_common+0x72/0xa0
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c0826724>] ? dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c014ae13>] warn_slowpath_fmt+0x33/0x40
[    0.000000]  [<c0826724>] dmi_ignore_irq0_timer_override+0x2e/0x52
[    0.000000]  [<c04dd7d0>] dmi_check_system+0x30/0x50
[    0.000000]  [<c0826df4>] acpi_boot_table_init+0x10/0x7d
[    0.000000]  [<c0821ea7>] ? io_delay_init+0x16/0x18
[    0.000000]  [<c081f556>] setup_arch+0x562/0x645
[    0.000000]  [<c012cf19>] ? default_spin_lock_flags+0x9/0x10
[    0.000000]  [<c081b57b>] start_kernel+0xcf/0x374
[    0.000000]  [<c081b0d7>] i386_start_kernel+0xd7/0xdf
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] ThinkPad Edge detected: Ignoring BIOS IRQ0 pin2 override

Signed-off-by: Manoj Iyer <[email protected]>

BugLink: http://launchpad.net/bugs/702434
Acked-by: Stefan Bader <[email protected]>
Signed-off-by: Andy Whitcroft <[email protected]>
jk-ozlabs pushed a commit to open-power/linux that referenced this pull request May 22, 2015
BugLink: http://bugs.launchpad.net/bugs/1441317

commit 520aa74 upstream.

Feb 12 18:20:42 nfdev kernel: ------------[ cut here ]------------
Feb 12 18:20:42 nfdev kernel: WARNING: CPU: 4 PID: 4359 at kernel/module.c:963 module_put+0x9b/0xba()
Feb 12 18:20:42 nfdev kernel: CPU: 4 PID: 4359 Comm: ebtables-compat Tainted: G        W      3.19.0-rc6+ torvalds#43
[...]
Feb 12 18:20:42 nfdev kernel: Call Trace:
Feb 12 18:20:42 nfdev kernel: [<ffffffff815fd911>] dump_stack+0x4c/0x65
Feb 12 18:20:42 nfdev kernel: [<ffffffff8103e6f7>] warn_slowpath_common+0x9c/0xb6
Feb 12 18:20:42 nfdev kernel: [<ffffffff8109919f>] ? module_put+0x9b/0xba
Feb 12 18:20:42 nfdev kernel: [<ffffffff8103e726>] warn_slowpath_null+0x15/0x17
Feb 12 18:20:42 nfdev kernel: [<ffffffff8109919f>] module_put+0x9b/0xba
Feb 12 18:20:42 nfdev kernel: [<ffffffff813ecf7c>] nft_match_destroy+0x45/0x4c
Feb 12 18:20:42 nfdev kernel: [<ffffffff813e683f>] nf_tables_rule_destroy+0x28/0x70

Reported-by: Arturo Borrero Gonzalez <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Tested-by: Arturo Borrero Gonzalez <[email protected]>
Signed-off-by: Luis Henriques <[email protected]>
Signed-off-by: Brad Figg <[email protected]>
ddstreet referenced this pull request in ddstreet/linux Jul 31, 2015
GIT 78add8a6901c143cfb091fae54e793af8a48ee41

commit e323d56eb06b266b77c2b430cb5f1977ba549e03
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Jun 12 10:53:25 2015 +0900

    clk: exynos4: Fix wrong clock for Exynos4x12 ADC
    
    The TSADC gate clock was used in Exynos4x12 DTSI for exynos-adc driver.
    However TSADC is present only on Exynos4210 so on Trats2 board (with
    Exynos4412 SoC) the exynos-adc driver could not be probed:
       ERROR: could not get clock /adc@126C0000:adc(0)
       exynos-adc 126c0000.adc: failed getting clock, err = -2
       exynos-adc: probe of 126c0000.adc failed with error -2
    
    Instead on Exynos4x12 SoCs the main clock used by Analog to Digital
    Converter is located in different register and it is named in datasheet
    as PCLK_ADC. Regardless of the name the purpose of this PCLK_ADC clock
    is the same as purpose of TSADC from Exynos4210.
    
    The patch adds gate clock for Exynos4x12 using the proper register so
    backward compatibility is preserved. This fixes the probe of exynos-adc
    driver on Exynos4x12 boards and allows accessing sensors connected to it
    on Trats2 board (ntc,ncp15wb473 AP and battery thermistors).
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Cc: <[email protected]>
    Fixes: c63c57433003 ("ARM: dts: Add ADC's dt data to read raw data for exynos4x12")
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Acked-by: Tomasz Figa <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit fe0d34d242fa1e0dec059e774d146a705420bc9a
Author: Rusty Russell <[email protected]>
Date:   Wed Jul 29 05:52:14 2015 +0930

    module: weaken locking assertion for oops path.
    
    We don't actually hold the module_mutex when calling find_module_all
    from module_kallsyms_lookup_name: that's because it's used by the oops
    code and we don't want to deadlock.
    
    However, access to the list read-only is safe if preempt is disabled,
    so we can weaken the assertion.  Keep a strong version for external
    callers though.
    
    Fixes: 0be964be0d45 ("module: Sanitize RCU usage and locking")
    Reported-by: He Kuang <[email protected]>
    Cc: [email protected]
    Acked-by: Peter Zijlstra (Intel) <[email protected]>
    Signed-off-by: Rusty Russell <[email protected]>

commit ca0169cfa2b37814a4da760e7097467042d2464d
Author: Hai Li <[email protected]>
Date:   Mon Jul 27 13:49:45 2015 -0400

    drm/msm: Enable clocks during enable/disable_vblank() callbacks
    
    AHB clock should be enabled before accessing registers during
    enable/disable_vblank(). Since these 2 callbacks are called in
    atomic context while clk_prepare may cause thread sleep, a work
    is scheduled to control vblanks.
    
    v2: fixup spinlock initialization
    
    Signed-off-by: Hai Li <[email protected]>
    [add comment about cancel_work_sync() before drm_irq_uninstall()]
    Signed-off-by: Rob Clark <[email protected]>

commit 55ceb5071d7a629ec290938c0a234467f57801f4
Author: jilai wang <[email protected]>
Date:   Wed Jul 8 18:25:40 2015 -0400

    drm/msm/mdp5: Add support for msm8x74v1
    
    msm8x74v1 has different MDP5 version (v1.0) from msm8x74v2 (v1.2).
    Add a separate config data to support msm8x74v1.
    
    Signed-off-by: Jilai Wang <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 4aeea572a7154c82abee18375db6dfc8379324ee
Author: jilai wang <[email protected]>
Date:   Tue Jul 7 17:17:28 2015 -0400

    drm/msm/mdp5: Add DMA pipe planes for MDP5
    
    This change is to add planes which use DMA pipes for MDP5.
    
    Signed-off-by: Jilai Wang <[email protected]>
    [slight comment adjust to s/Construct public planes/Construct video
    planes/ since DMA planes are public planes too, they just can't scale
    or CSC]
    Signed-off-by: Rob Clark <[email protected]>

commit 8e6170d1f73dd49a8b98d8b29d1d6e59ff819706
Author: Kyle Huey <[email protected]>
Date:   Mon Jul 13 10:35:45 2015 -0700

    ARM: tegra: Add Tegra124 PMU support
    
    This patch modifies the device tree for Tegra124 based devices to enable
    the Cortex A15 PMU. The interrupt numbers are taken from NVIDIA Tegra K1
    TRM (DP-06905-001_v03p). This patch was tested on a Jetson TK1.
    
    Signed-off-by: Kyle Huey <[email protected]>
    Acked-by: Mark Rutland <[email protected]>
    Acked-by: Jon Hunter <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>

commit b2df19e35e023e922ab7b6cc1cd9efd751e5d062
Author: jilai wang <[email protected]>
Date:   Wed Jul 8 18:12:40 2015 -0400

    drm/msm/mdp: Add capabilities to MDP planes (v2)
    
    MDP planes can be implemented using different type of HW pipes,
    RGB/VIG/DMA pipes for MDP5 and RGB/VG/DMA pipes for MDP4. Each type
    of pipe has different HW capabilities such as scaling, color space
    conversion, decimation... Add a variable in plane data structure
    to specify the difference of each plane which comes from mdp5_cfg data
    and use it to differenciate the plane operation.
    V1: Initial change
    V2: Fix a typo in mdp4_kms.h
    
    Signed-off-by: Jilai Wang <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit c09adc18aa2916c76322861e8a2120ff2a3452e0
Author: Stephane Viau <[email protected]>
Date:   Mon Jul 6 16:35:31 2015 -0400

    drm/msm/mdp5: add more YUV formats for MDP5
    
    Add packed YUV422 and planar YUV420 formats to MDP supported
    formats.
    
    Signed-off-by: Stephane Viau <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 6fd8b7e8b3aec6be833115c6f0e56fb888ec2c15
Author: Rob Clark <[email protected]>
Date:   Tue Jul 28 15:09:00 2015 -0400

    fixup! drm/msm/mdp5: use 2 memory clients for YUV formats on newer mdp5

commit 589e72d416fa4cea501d77d01e1b377d03779327
Author: Wentao Xu <[email protected]>
Date:   Mon Jul 6 16:35:30 2015 -0400

    drm/msm/mdp5: use 2 memory clients for YUV formats on newer mdp5
    
    Newer MDP5 uses 2 shared memory pool clients for certain YUV formats.
    For example, if VIG0 is used to fetch data in YUYV format, it will use
    VIG0_Y for Y component, and VIG0_Cr for UV packed.
    
    Signed-off-by: Wentao Xu <[email protected]>
    [rebase]
    Signed-off-by: Stephane Viau <[email protected]>

commit fe9e51fabcd9c32939e5e59ba695f0bfca97290b
Author: Wentao Xu <[email protected]>
Date:   Mon Jul 6 16:35:29 2015 -0400

    drm/msm/mdp: mark if a MDP format is YUV at definition
    
    This makes it easy to determine if a format is YUV. The old
    method of using chroma sample type incorrectly marks YUV444 as
    RGB format.
    
    Signed-off-by: Wentao Xu <[email protected]>
    [rebase]
    Signed-off-by: Stephane Viau <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 4e59a31078dc77ac07897c6f4dcb20c98e2b1611
Author: Uwe Kleine-König <[email protected]>
Date:   Mon Jul 6 11:09:41 2015 +0200

    drm/msm/dp: use flags argument of devm_gpiod_get to set direction
    
    Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
    which appeared in v3.17-rc1, the gpiod_get* functions take an additional
    parameter that allows to specify direction and initial value for output.
    
    Use this to simplify the driver. Furthermore this is one caller less
    that stops us making the flags argument to gpiod_get*() mandatory.
    
    Acked-by: Alexandre Courbot <[email protected]>
    Acked-by: Linus Walleij <[email protected]>
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 8ef625a74f6d1c9fa8d940b8c88757a859bb34f9
Author: Hai Li <[email protected]>
Date:   Fri Jul 3 10:09:46 2015 -0400

    drm/msm/dsi: Save/Restore PLL status across PHY reset
    
    Reset DSI PHY silently changes its PLL registers to reset status,
    which will make cached status in clock driver invalid and result
    in wrong output rate of link clocks. The current restore mechanism
    in DSI PLL does not cover all the cases. This change is to recover
    PLL status after PHY reset to match HW status with cached status
    in clock driver.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit de03fbbbfbd04a82ddb3fe3abf096d717ed97f57
Author: Markus Elfring <[email protected]>
Date:   Sat Jun 27 22:23:28 2015 +0200

    drm/msm/dsi: One function call less in dsi_init() after error detection
    
    The dsi_destroy() function was called in two cases by the dsi_init() function
    during error handling even if the passed variable contained a null pointer.
    
    * This implementation detail could be improved by adjustments for jump
      targets according to the Linux coding style convention.
    
    * Drop an unnecessary initialisation for the variable "msm_dsi" then.
    
    Signed-off-by: Markus Elfring <[email protected]>
    [add couple missing ERR_PTR()'s]
    Signed-off-by: Rob Clark <[email protected]>

commit 4d5fa81f42043e6a5bb9ce856b9f804cf21d202b
Author: Markus Elfring <[email protected]>
Date:   Sat Jun 27 22:05:31 2015 +0200

    drm/msm/dsi: Delete an unnecessary check before the function call "dsi_destroy"
    
    The dsi_destroy() function tests whether its argument is NULL and then
    returns immediately. Thus the test around the call is not needed.
    
    This issue was detected by using the Coccinelle software.
    
    Signed-off-by: Markus Elfring <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 37c5a9eea828c5b094ebfe3bba5b28712fbf3f30
Author: Hai Li <[email protected]>
Date:   Fri Jun 26 16:03:26 2015 -0400

    drm/msm/mdp5: Allocate CTL0/1 for dual DSI single FLUSH
    
    This change takes advantage of a HW feature that synchronize
    flush operation on CTL1 to CTL0, to keep dual DSI pipes in
    sync.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 2d9aa78a562c8b5e59eb7aab1c63b44ca3601ed6
Author: Hai Li <[email protected]>
Date:   Fri Jun 26 16:03:25 2015 -0400

    drm/msm/mdp5: Allocate CTL for each display interface
    
    In MDP5, CTL contains information of the whole pipeline whose
    output goes down to a display interface. In various cases, one
    interface may require 2 CRTCs, but only one CTL. Some interfaces
    also require to use certain CTLs.
    
    Instead of allocating CTL for each active CRTC, this change is to
    associate a CTL with each interface.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 00f3ec37d29efed8983a2add67b692ca509ec99b
Author: Rob Herring <[email protected]>
Date:   Mon Jul 27 15:55:14 2015 -0500

    clk: kill off set_irq_flags usage
    
    set_irq_flags is ARM specific with custom flags which have genirq
    equivalents. Convert drivers to use the genirq interfaces directly, so we
    can kill off set_irq_flags. The translation of flags is as follows:
    
    IRQF_VALID -> !IRQ_NOREQUEST
    IRQF_PROBE -> !IRQ_NOPROBE
    IRQF_NOAUTOEN -> IRQ_NOAUTOEN
    
    For IRQs managed by an irqdomain, the irqdomain core code handles clearing
    and setting IRQ_NOREQUEST already, so there is no need to do this in
    .map() functions and we can simply remove the set_irq_flags calls. Some
    users also modify IRQ_NOPROBE and this has been maintained although it
    is not clear that is really needed. There appears to be a great deal of
    blind copy and paste of this code.
    
    Signed-off-by: Rob Herring <[email protected]>
    Acked-by: Boris Brezillon <[email protected]>
    Cc: Mike Turquette <[email protected]>
    Acked-by: Stephen Boyd <[email protected]>
    Cc: [email protected]
    Signed-off-by: Stephen Boyd <[email protected]>

commit d99215ae06be51558b723a3648515e672898ca4b
Author: Jun Nie <[email protected]>
Date:   Thu Jul 23 15:02:53 2015 +0800

    clk: zx: Constify parent names in clock init data
    
    The array of parent names can be made as array of const pointers to
    const strings.
    
    Signed-off-by: Jun Nie <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 105644e59a2b1c43fe2eeba6595d142c390552c2
Author: Jun Nie <[email protected]>
Date:   Thu Jul 23 15:02:52 2015 +0800

    clk: zx: Add audio and GPIO clock for zx296702
    
    Add SPDIF/I2S and GPIO clock for zx296702
    
    Signed-off-by: Jun Nie <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 4599dd2c926915b5e8c27e0ca21a6172f9d6881c
Author: Jun Nie <[email protected]>
Date:   Thu Jul 23 15:02:51 2015 +0800

    clk: zx: Add audio div clock method for zx296702
    
    Add SPDIF/I2S divider clock method for zx296702
    
    Signed-off-by: Jun Nie <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 7764d0cdc3dbf15010f66e0e2e5786f0f03d402a
Author: Vaibhav Hiremath <[email protected]>
Date:   Wed Jul 22 15:04:53 2015 +0530

    clk: s2mps11: Use kcalloc instead of kzalloc for array allocation
    
    This patch cleans up the driver for,
    
      - Use devm_kcalloc() variant instead of devm_kzalloc() for array
        allocation.
      - clk_prepare()/unprepare(), remove "ret" variable as it is not required
      - use __exit for cleanup function
    
    As I am referring this driver as a reference for my 88pm800 clk driver,
    applying same changes here as well.
    
    Signed-off-by: Vaibhav Hiremath <[email protected]>
    Tested-by: Anand Moon <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit a57aa18539f8b232065f574f438edb646c6b9d9b
Author: Stephen Boyd <[email protected]>
Date:   Fri Jul 24 12:24:48 2015 -0700

    clk: Silence warnings about lock imbalances
    
    The recursive spinlock implementation trips up sparse and it
    complains that these functions have lock imbalances. That isn't
    really true though, so add some __acquires() and __releases()
    information so that sparse is quiet.
    
    drivers/clk/clk.c:116:22: warning: context imbalance in 'clk_enable_lock' - wrong count at exit
    drivers/clk/clk.c:141:9: warning: context imbalance in 'clk_enable_unlock' - unexpected unlock
    
    Signed-off-by: Stephen Boyd <[email protected]>

commit 661e2180cf050a2f859d466f30d74e990b9345be
Author: Stephen Boyd <[email protected]>
Date:   Fri Jul 24 12:21:12 2015 -0700

    clk: basic-type: Silence warnings about lock imbalances
    
    The basic clock types use conditional locking for the register
    accessor spinlocks. Add __acquire() and __release() markings in
    the right locations so that sparse isn't tripped up on the
    conditional locking.
    
    drivers/clk/clk-mux.c:68:12: warning: context imbalance in 'clk_mux_set_parent' - different lock contexts for basic block
    drivers/clk/clk-divider.c:379:12: warning: context imbalance in 'clk_divider_set_rate' - different lock contexts for basic block
    drivers/clk/clk-gate.c:71:9: warning: context imbalance in 'clk_gate_endisable' - different lock contexts for basic block
    drivers/clk/clk-fractional-divider.c:36:9: warning: context imbalance in 'clk_fd_recalc_rate' - different lock contexts for basic block
    drivers/clk/clk-fractional-divider.c:68:12: warning: context imbalance in 'clk_fd_set_rate' - different lock contexts for basic block
    
    Cc: Andy Shevchenko <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 169f05e80522e2848c9089a17976ebf31e735d5c
Author: Stephen Boyd <[email protected]>
Date:   Fri Jul 24 11:55:42 2015 -0700

    clk: qcom: Give clk-qcom.ko module a GPLv2 license
    
    The missing license causes the clk-qcom.ko module to taint the
    kernel. Add the appropriate license to avoid taint.
    
    Signed-off-by: Stephen Boyd <[email protected]>

commit 37bff2c159a3629b592e54162239cb8c337c965d
Author: Stephen Boyd <[email protected]>
Date:   Fri Jul 24 09:31:29 2015 -0700

    clk: gpio: Mark parent_names array const
    
    Let's encourage const arrays of parent names like other basic
    clock types.
    
    Cc: Sergej Sawazki <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit afe76c8fd030dd6b75fa69f7af7b7eb1e212f248
Author: Jim Quinlan <[email protected]>
Date:   Fri May 15 15:45:47 2015 -0400

    clk: allow a clk divider with max divisor when zero
    
    This commit allows certain Broadcom STB clock dividers to be used with
    clk-divider.c.  It allows for a clock whose field value is the equal
    to the divisor, execpt when the field value is zero, in which case the
    divisor is 2^width.  For example, consider a divisor clock with a two
    bit field:
    
    value		divisor
    0		4
    1		1
    2		2
    3		3
    
    Signed-off-by: Jim Quinlan <[email protected]>
    Signed-off-by: Michael Turquette <[email protected]>

commit 25d4d341d31b349836e1b12d10be34b9b575c12b
Author: Andy Shevchenko <[email protected]>
Date:   Mon Jul 13 17:07:43 2015 +0300

    clk: socfpga: switch to GENMASK()
    
    Convert the code to use GENMASK() helper instead of div_mask() macro.
    
    Signed-off-by: Andy Shevchenko <[email protected]>
    Acked-by: Dinh Nguyen <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 4b5fb7dc9096d949a22651370bb6bf11f21edb30
Author: Robert Jarzmik <[email protected]>
Date:   Sun Jul 12 22:49:53 2015 +0200

    clk: pxa: fix core frequency reporting unit
    
    Legacy drivers which are not yet ported, such as cpufreq-pxa[23]xx, rely
    on pxaXXx_get_clk_frequency_khz() to find the CPU core frequency.
    
    This reporting was broken because the expected unit is kHz and not
    Hz. Fix the reporting for pxa25x, pxa27x and pxa3xx.
    
    Fixes: fe7710fae477 ("clk: add pxa25x clock drivers")
    Fixes: d40670dc6169 ("clk: add pxa27x clock drivers")
    Fixes: 9bbb8a338fb2 ("clk: pxa: add pxa3xx clock driver")
    Signed-off-by: Robert Jarzmik <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 2bbfe00147a7c075f5c43e657ec218afea662819
Author: Douglas Anderson <[email protected]>
Date:   Tue Jul 21 13:41:23 2015 -0700

    clk: rockchip: Fix PLL bandwidth
    
    In the TRM we see that BWADJ is "a 12-bit bus that selects the values
    1-4096 for the bandwidth divider (NB)":
     NB = BWADJ[11:0] + 1
    The recommended setting of NB: NB = NF / 2.
    
    So:
      NB = NF / 2
      BWADJ[11:0] + 1 = NF / 2
      BWADJ[11:0] = NF / 2 - 1
    
    Right now, we have:
    
    {                                               \
            .rate   = _rate##U,                     \
            .nr = _nr,                              \
            .nf = _nf,                              \
            .no = _no,                              \
            .bwadj = (_nf >> 1),                    \
    }
    
    That means we set bwadj to NF / 2, not NF / 2 - 1
    
    All of this is a bit confusing because we specify "NR" (the 1-based
    value), "NF" (the 1-based value), "NO" (the 1-based value), but
    "BWADJ" (the 0-based value) instead of "NB" (the 1-based value).
    
    Let's change to working with "NB" and fix the off by one error.  This
    may affect PLL jitter in a small way (hopefully for the better).
    
    Signed-off-by: Douglas Anderson <[email protected]>
    Reviewed-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 9da9e761273702b3afd6e3538c23ece95693e586
Author: Dinh Nguyen <[email protected]>
Date:   Mon Jul 6 22:59:06 2015 -0500

    clk: ti: make use of of_clk_parent_fill helper function
    
    Use of_clk_parent_fill to fill in the parent clock names' array.
    
    Signed-off-by: Dinh Nguyen <[email protected]>
    Cc: Tero Kristo <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 8a53fb2bceea00081c4a6af7b477bea8ec00b74b
Author: Dinh Nguyen <[email protected]>
Date:   Mon Jul 6 22:59:05 2015 -0500

    clk: sunxi: make use of of_clk_parent_fill helper function
    
    Use of_clk_parent_fill to fill in the parent clock names' array.
    
    Signed-off-by: Dinh Nguyen <[email protected]>
    Acked-by: Maxime Ripard <[email protected]>
    Cc: "Emilio López" <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 0b4e7f0842fe5c8bd19654999f6c41c4119e7c90
Author: Dinh Nguyen <[email protected]>
Date:   Mon Jul 6 22:59:04 2015 -0500

    clk: st: make use of of_clk_parent_fill helper function
    
    Use of_clk_parent_fill to fill in the parent clock names' array.
    
    Signed-off-by: Dinh Nguyen <[email protected]>
    Tested-by Gabriel Fernandez <[email protected]>
    Cc: Peter Griffin <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 5f23eff7af6bc1d8cc8e17fc12e8d989042236ed
Author: Dinh Nguyen <[email protected]>
Date:   Mon Jul 6 22:59:03 2015 -0500

    clk: keystone: make use of of_clk_parent_fill helper function
    
    Use of_clk_parent_fill to fill in the parent clock names' array.
    
    Signed-off-by: Dinh Nguyen <[email protected]>
    Acked-by: Santosh Shilimkar <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit f0557fbe1303aade362bd578753a1c898a80851c
Author: Dinh Nguyen <[email protected]>
Date:   Mon Jul 6 22:59:01 2015 -0500

    clk: at91: make use of of_clk_parent_fill helper function
    
    Use of_clk_parent_fill to fill in the parent clock names' array.
    
    Signed-off-by: Dinh Nguyen <[email protected]>
    Cc: Boris Brezillon <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 75ce0cdb6243d42daca6130e5feb71f536bb136e
Author: James Liao <[email protected]>
Date:   Fri Jul 10 16:39:34 2015 +0800

    clk: mediatek: Add MT8173 MMPLL change rate support
    
    MT8173 MMPLL frequency settings are different from common PLLs.
    It needs different post divider settings for some ranges of frequency.
    This patch add support for MT8173 MMPLL frequency setting by adding
    div-rate table to lookup suitable post divider setting under a
    specified frequency.
    
    Signed-off-by: James Liao <[email protected]>
    Acked-by: Sascha Hauer <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 196de71a9d9e9090406a87362d22b67ae633fa7a
Author: James Liao <[email protected]>
Date:   Fri Jul 10 16:39:33 2015 +0800

    clk: mediatek: Fix calculation of PLL rate settings
    
    Avoid u32 overflow when calculate post divider setting, and
    increase the max post divider setting from 3 (/8) to 4 (/16).
    
    Signed-off-by: James Liao <[email protected]>
    Acked-by: Sascha Hauer <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit b3be457e5854e3095cd0be850058c765aaf467ab
Author: James Liao <[email protected]>
Date:   Fri Jul 10 16:39:32 2015 +0800

    clk: mediatek: Fix PLL registers setting flow
    
    Write postdiv and pcw settings at the same time for PLLs if postdiv
    and pcw settings are on the same register.
    
    This is need by PLLs such as MT8173 MMPLL and ARM*PLL.
    
    Signed-off-by: James Liao <[email protected]>
    Acked-by: Sascha Hauer <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 9783c0d98501aa146ff467916ab4b8830a655d7c
Author: Stephen Boyd <[email protected]>
Date:   Thu Jul 16 12:50:27 2015 -0700

    clk: Allow providers to configure min/max rates
    
    clk providers are using the consumer APIs to set min/max rates on
    the clock they're providing. To encourage clk providers to move
    away from the consumer APIs, add a provider API to set the
    min/max rate of a clock. The assumption is that this is done
    before the clock can be requested via clk_get() and that the
    clock rate is already within the boundaries of the min/max that's
    configured.
    
    Tested-by: Sudeep Holla <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 5c757456c16ce056a40a120e63235bc00c94ee7f
Author: Axel Lin <[email protected]>
Date:   Thu Jul 16 22:15:53 2015 +0800

    clk: twl6040: Convert to use devm_clk_register
    
    Use devm_clk_register() to simplify the code by removing
    twl6040_clk_remove().
    
    Signed-off-by: Axel Lin <[email protected]>
    Acked-by: Peter Ujfalusi <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 264e3b75de4eee6e4ee4616bf2b2a3d522cad72a
Author: Axel Lin <[email protected]>
Date:   Thu Jul 16 21:59:43 2015 +0800

    clk: s2mps11: Simplify s2mps11_clk_probe unwind paths
    
    The devm_clk_unregister() in .probe error case is not necessary as it will
    be automatically called when probe fails.
    
    Signed-off-by: Axel Lin <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 5a1cfafaeab5237523d43cd033e1fb42bf5c1933
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Jun 23 15:09:27 2015 +0200

    clk: shmobile: Remove unneeded #include <linux/clkdev.h>
    
    The CCF implementations for the various shmobile SoCs don't use clkdev
    functionality, hence drop the inclusion of <linux/clkdev.h>.
    
    Add the missing #include <linux/slab.h>, which was included implicitly
    through <asm/clkdev.h> before.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 14cc4e9578841a4c0025ce064133b2da53c9d1c9
Author: Stephen Boyd <[email protected]>
Date:   Wed Jul 15 12:58:22 2015 -0700

    clk: ti: Force pointer to be __iomem
    
    Add __force here so that sparse doesn't complain about us playing
    tricks with __iomem.
    
    Acked-by: Tero Kristo <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 76642eb4cb040b436319e5aa747a5ef026207eef
Author: Stephen Boyd <[email protected]>
Date:   Wed Jul 15 12:04:53 2015 -0700

    clk: ti: clk-3xxx: Remove unused structures
    
    Sparse complains about these structures missing static, but they
    also don't look to be used. Remove them.
    
    drivers/clk/ti/clk-3xxx.c:74:30: warning: symbol 'clkhwops_omap3430es2_ssi_wait' was not declared. Should it be static?
    drivers/clk/ti/clk-3xxx.c:157:30: warning: symbol 'clkhwops_omap3430es2_hsotgusb_wait' was not declared. Should it be static?
    
    Acked-by: Tero Kristo <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 3fe6d697420c706b640730dbbae17f48b3aad506
Author: Stephen Boyd <[email protected]>
Date:   Wed Jul 15 12:03:52 2015 -0700

    clk: ti: Mark ti_clk_features static
    
    This variable isn't exported outside of this file so mark it
    static. Silences the following sparse warning:
    
    drivers/clk/ti/clk.c:36:24: warning: symbol 'ti_clk_features' was not declared. Should it be static?
    
    Acked-by: Tero Kristo <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit f645f72d876586c4950dcd5bf516744db0aeb30b
Author: Stephen Boyd <[email protected]>
Date:   Wed Jul 15 11:55:42 2015 -0700

    clk: ti: Check kzalloc() for failures
    
    smatch reports a failure to check kzalloc() here:
    
    drivers/clk/ti/clk.c:232
    omap2_clk_provider_init() error: potential null dereference 'io'.
    (kzalloc returns null)
    
    Check for an allocation failure and return -ENOMEM.
    
    Acked-by: Tero Kristo <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit e306479ac252928b84cc563c6e790f9b7e7ae427
Author: Axel Lin <[email protected]>
Date:   Sat Jun 20 15:27:03 2015 +0800

    clk: h8300: Fix signness bug
    
    of_clk_get_parent_count() may return negative error code, so num_parents
    needs to be int rather than unsigned int.
    
    Signed-off-by: Axel Lin <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit d7a304e9d018c99dda80f4c16ec0fe817b5be4a1
Author: Stephen Boyd <[email protected]>
Date:   Tue Jul 14 16:57:29 2015 -0700

    clk: qcom: Set CLK_SET_RATE_PARENT on ce1 clocks
    
    The other ce clocks have the flag set, but ce1 doesn't, so
    clk_set_rate() doesn't propagate up the tree to the ce1_src_clk.
    Set the flag as this is supported.
    
    Reported-by: Bjorn Andersson <[email protected]>
    Tested-by: Bjorn Andersson <[email protected]>
    Fixes: 02824653200b ("clk: qcom: Add APQ8084 Global Clock Controller support")
    Fixes: d33faa9ead8d ("clk: qcom: Add support for MSM8974's global clock controller (GCC)")
    Signed-off-by: Stephen Boyd <[email protected]>

commit c5e857a46af24a772f445edcc01a861ee2d6a713
Author: Stephen Boyd <[email protected]>
Date:   Tue Jul 14 12:45:19 2015 -0700

    clk: gpio: Unlock mutex on error path
    
    We don't unlock the mutex if we fail to allocate the parent names
    array. Unlock it and return an error in this case as well.
    
    Reported-by: kbuild test robot <[email protected]>
    Acked-by: Julia Lawall <[email protected]>
    Cc: Sergej Sawazki <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 006cb8b66e18ce7aff934883f6c50e3b85052681
Author: Stephen Boyd <[email protected]>
Date:   Mon Jul 13 17:06:53 2015 -0700

    clk: h8300: Use standard Linux I/O accessors
    
    There doesn't seem to be any reason why we can't use the standard
    readb()/writeb() accessors here because ctrl_inb() and
    ctrl_outb() match the generic implementation of readb() and
    writeb() that the h8300 architecture uses. This allows us to test
    compile this driver on other architectures besides h8300.
    
    Cc: Yoshinori Sato <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit 9298f0267c7ed620f8d8261ded8518ebf8e89f9e
Author: Stephen Boyd <[email protected]>
Date:   Mon Jul 13 16:54:04 2015 -0700

    clk: h8300: Drop allocation printk and cleanup sizeof style
    
    We don't need to print an error on allocation failures, drop it.
    While we're here, change the sizeof() to be sizeof(*<ptr>) to
    make code more future proof.
    
    Cc: Yoshinori Sato <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>

commit a8a7af8607a2551ce9699ffea7ccc7bd54b59064
Author: Daniel Vetter <[email protected]>
Date:   Tue Jul 28 13:18:42 2015 +0200

    drm: Remove __drm_modeset_lock_all
    
    The last user is gone, no need for trylocking any more in this legacy
    helper.
    
    Reviewed-by: Rob Clark <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit d553fca625bb9a147c5eadcede7e40c9ba2bd8eb
Author: Daniel Vetter <[email protected]>
Date:   Tue Jul 28 13:18:41 2015 +0200

    drm/fb-helper: Stop using trylocks in force_restore
    
    Since the panic handling is gone this is only used for force-restoring
    the fbdev/fbcon from sysrq, and that's done with a work item. No need
    any more to do trylocks, we can just do normal locking.
    
    Reviewed-by: Rob Clark <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 3828c43eb59d13f7105950021102bc0c787090fe
Author: Daniel Vetter <[email protected]>
Date:   Tue Jul 28 13:18:40 2015 +0200

    drm/fbdev: Return -EBUSY when oopsing
    
    Trying to do anything with kms drivers when oopsing has become a
    failing proposition. But since we can end up in the fbdev code simply
    due to the console unblanking that's done unconditionally just
    removing our panic handler isn't enough. We need to block all fbdev
    callbacks when oopsing.
    
    There was already one in the blank handler, but it failed silently.
    That makes it impossible for drivers (like i915) who subclass these
    functions to figure this out.
    
    Instead consistently return -EBUSY so that everyone knows that we
    really don't want to be bothered right now. This also allows us to
    remove a pile of FIXMEs from the i915 fbdev code (since due to the
    failure code they now won't attempt to grab dangerous locks any more).
    
    Cc: Dave Airlie <[email protected]>
    Cc: Rodrigo Vivi <[email protected]>
    Reviewed-by: Rob Clark <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 5de3bd463534117dc95e27c7f318e49e41985eff
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:20 2015 +0530

    drm/fb_cma_helper: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cc: Lars-Peter Clausen <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit e71570b47816b841c163d3a7a5bd540165523884
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:16 2015 +0530

    drm/udl: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    v2:
    - remove unused variable device in udlfb_create
    
    Cc: David Airlie <[email protected]>
    Cc: Haixia Shi <[email protected]>
    Cc: "Stéphane Marchesin" <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit dad4e3022391fa560f9062599764db993eb81af7
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:13 2015 +0530

    drm/qxl: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cc: David Airlie <[email protected]>
    Cc: Frediano Ziglio <[email protected]>
    Cc: Maarten Lankhorst <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 2115744d7b2f05bacdc069d0b49c307c6bcdbdfe
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:10 2015 +0530

    drm/gma500: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    v2:
    - removed unused variable 'device' in psbfb_create
    
    Cc: Patrik Jakobsson <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Reviewed-by: Patrik Jakobsson <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 1011f98d86dc6d6efe98ef04468d046189ce6ccb
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:09 2015 +0530

    drm/exynos: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    v2:
    - Remove unnecessary dealloc cmap in error handling path
    
    Cc: Inki Dae <[email protected]>
    Cc: Joonyoung Shim <[email protected]>
    Cc: Seung-Woo Kim <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 4960d05ef9f626e1e42ae0c0b4bdb65ce37fba0d
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:08 2015 +0530

    drm/msm: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cc: Rob Clark <[email protected]>
    Cc: Stephane Viau <[email protected]>
    Cc: Hai Li <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit b756ecb40a01b8d85bc7662d2bfb77da05d813c5
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:07 2015 +0530

    drm/tegra: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    v2:
    - Fix up error handling path in tegra_fbdev_probe
    
    Cc: Thierry Reding <[email protected]>
    Cc: "Terje Bergström" <[email protected]>
    Cc: Stephen Warren <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 377eb331375f54fb908a8d90b0807b184b639b14
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:06 2015 +0530

    drm/omap: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cc: Tomi Valkeinen <[email protected]>
    Cc: Laurent Pinchart <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit d0bda2cd4e30a65f671152e59d296f70f4cef8c2
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:05 2015 +0530

    drm/ast: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cleaned up the error handling in astfb_create a bit.
    
    v2:
    - removed unused variable 'device' in astfb_create
    
    Cc: David Airlie <[email protected]>
    Cc: "Y.C. Chen" <[email protected]>
    Cc: Alex Deucher <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 6d7906fce79a6606c35022d7f9f839ad3e403bec
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:04 2015 +0530

    drm/armada: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    Cc: Russell King <[email protected]>
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 27f8f10314120ca55a2a2a2ff455228aca6980f1
Author: Archit Taneja <[email protected]>
Date:   Wed Jul 22 14:58:03 2015 +0530

    drm/rockchip: Use new drm_fb_helper functions
    
    Use the newly created wrapper drm_fb_helper functions instead of calling
    core fbdev functions directly. They also simplify the fb_info creation.
    
    This is an effort to create a top level drm fbdev emulation option.
    
    Cc: Mark Yao <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: Rob Clark <[email protected]>
    Cc: Daniel Kurtz <[email protected]>
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 8b34fe593ec6392aaef74c244fe2c091f424dee8
Author: Florian Fainelli <[email protected]>
Date:   Tue Jul 14 13:03:33 2015 -0700

    ata: ahci_brcmstb: Fix warnings with CONFIG_PM_SLEEP=n
    
    When CONFIG_PM_SLEEP is disabled, brcm_ahci_{suspend,resume} are not
    used, which causes such a build warning to occur:
    
      CC      drivers/ata/ahci_brcmstb.o
    drivers/ata/ahci_brcmstb.c:212:12: warning: 'brcm_ahci_suspend' defined
    but not used [-Wunused-function]
     static int brcm_ahci_suspend(struct device *dev)
                ^
    drivers/ata/ahci_brcmstb.c:224:12: warning: 'brcm_ahci_resume' defined
    but not used [-Wunused-function]
     static int brcm_ahci_resume(struct device *dev)
                ^
      LD      drivers/ata/built-in.o
    
    Fixes: 766a2d979632 ("ata: add Broadcom AHCI SATA3 driver for STB chips")
    Signed-off-by: Florian Fainelli <[email protected]>
    Acked-by: Brian Norris <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit c7906acec31005324b461195478dae5a65904630
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:15:14 2015 +0530

    drm/msm/dsi: Modify dsi manager bridge ops to work with external bridges
    
    The dsi bridge ops call drm_panel functions to set up the connected
    drm_panel. Add checks to make sure these aren't called when we're
    connected to an external bridge.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 77eb5ee6944ea00f10100f46ce521d247f573d48
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:15:13 2015 +0530

    drm/msm/dsi: Allow dsi to connect to an external bridge
    
    There are platforms where the DSI output can be connected to another
    encoder bridge chip (DSI to HDMI, DSI to LVDS etc).
    
    Add support for external bridge support to the dsi driver. We assume that
    the external bridge chip would be of the type drm_bridge. The dsi driver's
    internal drm_bridge (msm_dsi->bridge) is linked to the external bridge's
    drm_bridge struct.
    
    In the case we're connected to an external bridge, we don't need to create
    and manage a connector within our driver, it's the bridge driver's
    responsibility to create one.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 3213afb8bf5cf8d8c68a2c2376bf1dda52afae5d
Author: Dmitry Torokhov <[email protected]>
Date:   Tue Jul 28 10:25:03 2015 -0700

    Revert "Input: zforce - don't overwrite the stack"
    
    This reverts commit 7d01cd261c76f95913c81554a751968a1d282d3a because
    with given FRAME_MAXSIZE of 257 the check will never trigger and it
    causes warnings from GCC (with -Wtype-limits). Also the check was
    incorrect as it was not accounting for the already read 2 bytes of data
    stored in the buffer.

commit 40747338f97226962accfb5f70da193e750b398f
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:15:12 2015 +0530

    drm/msm/dsi: Create a helper to check if there is a connected device
    
    Create a helper msm_dsi_device_connected() which checks whether we have a
    device connected to the dsi host or not. This check gets messy when we
    have support external bridges too. Having an inline function makes it
    more legible.
    
    For now, the check only consists of msm_dsi->panel being non-NULL. Later,
    this will check if we have an external bridge or not.
    
    This helper isn't used in dsi_connector related code as that's specific
    to only when a drm_panel is connected.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 7a771d4b0d5827ff5528eab48b5e63f41ab15a37
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:15:11 2015 +0530

    drm/msm/dsi: Refer to connected device as 'device' instead of 'panel'
    
    We currently support only panels connected to dsi output. We're going to
    also support external bridge chips now.
    
    Change 'panel_node' to 'device_node' in the struct msm_dsi_host and
    'panel_flags' to 'device_flags' in msm_dsi. This makes things sound a
    bit more generic.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 2111491b81933189c9e8d0bc34de1ec5e4b52b33
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:15:10 2015 +0530

    drm/msm/dsi: Make TE gpio optional
    
    Platforms containing only DSI video mode devices don't need a TE gpio.
    Make TE gpio optional.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit c5d6f02944d27afabd5b474930031e933058da14
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:13:05 2015 +0530

    drm/msm: mdp4 lvds: get panel node via of graph parsing
    
    We currently get the output connected to LVDS by looking for a phandle
    called 'qcom,lvds-panel' under the mdp DT node.
    
    Use the more standard of_graph approach to create an lvds output port,
    and retrieve the panel node from the port's endpoint data.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit c3f502202f958661d197fc6cd4a2f43979cc7814
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:13:04 2015 +0530

    drm/msm: dsi host: Use device graph parsing to parse connected panel
    
    The dsi host looks for the connected panel node by parsing for a child
    named 'panel'. This hierarchy isn't very flexible. The connected
    panel is forced to be a child to the dsi host, and hence, a mipi dsi
    device. This isn't suitable for dsi devices that don't use mipi dsi
    as their control bus.
    
    Follow the of_graph approach of creating ports and endpoints to
    represent the connections between the dsi host and the panel connected
    to it. In our case, the dsi host will only have one output port, linked
    to the panel's input port.
    
    Update DT binding documentation with device graph usage info.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 50af680c113dd41c46cd1fd5b7f1dbfca956c0b1
Author: jilai wang <[email protected]>
Date:   Thu Jun 25 17:37:42 2015 -0400

    drm/msm/mdp5: Add plane blending operation support for MDP5 (v2)
    
    This change is to add properties alpha/zpos/blend_mode to mdp5 plane
    for alpha blending operation to generate the blended output.
    v1: Initial change
    v2: Change "premultilied" property to enum (Rob's comment)
    
    Signed-off-by: Jilai Wang <[email protected]>
    [Don't actually expose alpha/premultiplied props to userspace yet
    pending a chance for discussion and some userspace to exercise it]
    Signed-off-by: Rob Clark <[email protected]>

commit 967f092ae15206bdc89e1a204593116a1d470500
Author: Olof Johansson <[email protected]>
Date:   Tue Jul 28 18:31:18 2015 +0200

    arm-soc: document merges
    
    Signed-off-by: Olof Johansson <[email protected]>

commit 76f90d76c27aaf1408378cd2009002859a79da92
Author: Thierry Reding <[email protected]>
Date:   Fri Aug 1 15:50:44 2014 +0200

    of: Add vendor prefix for Sharp Microelectronics
    
    Use "sharp" as the vendor prefix for Sharp Microelectronics in device
    tree compatible strings.
    
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Rob Herring <[email protected]>

commit 0e3d05cf83a896268108f118c486916aafe86177
Author: Olof Johansson <[email protected]>
Date:   Tue Jul 28 17:32:43 2015 +0200

    arm-soc: document merges
    
    Signed-off-by: Olof Johansson <[email protected]>

commit 227942809b52f23cda414858b635c0285f11de00
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:23 2015 +0530

    cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling
    
    If frequency is throttled due to OCC reset then cpus will be in Psafe
    frequency, so restore the frequency on all cpus to policy->cur when
    OCCs are active again. And if frequency is throttled due to Pmax
    capping then restore the frequency of all the cpus  in the chip on
    unthrottling.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 3dd3ebe5bb3837aeac28a23f8f22b97cb84abab6
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:22 2015 +0530

    cpufreq: powernv: Report Psafe only if PMSR.psafe_mode_active bit is set
    
    On a reset cycle of OCC, although the system retires from safe
    frequency state the local pstate is not restored to Pmin or last
    requested pstate. Now if the cpufreq governor initiates a pstate
    change, the local pstate will be in Psafe and we will be reporting a
    false positive when we are not throttled.
    
    So in powernv_cpufreq_throttle_check() remove the condition which
    checks if local pstate is less than Pmin while checking for Psafe
    frequency. If the cpus are forced to Psafe then PMSR.psafe_mode_active
    bit will be set. So, when OCCs become active this bit will be cleared.
    Let us just rely on this bit for reporting throttling.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Reviewed-by: Preeti U Murthy <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 735366fc407755626058218fc8d0430735a669ac
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:21 2015 +0530

    cpufreq: powernv: Call throttle_check() on receiving OCC_THROTTLE
    
    Re-evaluate the chip's throttled state on recieving OCC_THROTTLE
    notification by executing *throttle_check() on any one of the cpu on
    the chip. This is a sanity check to verify if we were indeed
    throttled/unthrottled after receiving OCC_THROTTLE notification.
    
    We cannot call *throttle_check() directly from the notification
    handler because we could be handling chip1's notification in chip2. So
    initiate an smp_call to execute *throttle_check(). We are irq-disabled
    in the notification handler, so use a worker thread to smp_call
    throttle_check() on any of the cpu in the chipmask.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit cb166fa937a2fbc14badcafca86202354c34a213
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:20 2015 +0530

    cpufreq: powernv: Register for OCC related opal_message notification
    
    OCC is an On-Chip-Controller which takes care of power and thermal
    safety of the chip. During runtime due to power failure or
    overtemperature the OCC may throttle the frequencies of the CPUs to
    remain within the power budget.
    
    We want the cpufreq driver to be aware of such situations to be able
    to report the reason to the user. We register to opal_message_notifier
    to receive OCC messages from opal.
    
    powernv_cpufreq_throttle_check() reports any frequency throttling and
    this patch will report the reason or event that caused throttling. We
    can be throttled if OCC is reset or OCC limits Pmax due to power or
    thermal reasons. We are also notified of unthrottling after an OCC
    reset or if OCC restores Pmax on the chip.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 196ba2d514a13f6af1b3d78de71ce74ed2fc8bdc
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:19 2015 +0530

    powerpc/powernv: Add definition of OPAL_MSG_OCC message type
    
    Add OPAL_MSG_OCC message definition to opal_message_type to receive
    OCC events like reset, load and throttled. Host performance can be
    affected when OCC is reset or OCC throttles the max Pstate.
    We can register to opal_message_notifier to receive OPAL_MSG_OCC type
    of message and report it to the userspace so as to keep the user
    informed about the reason for a performance drop in workloads.
    
    The reset and load OCC events are notified to kernel when FSP sends
    OCC_RESET and OCC_LOAD commands.  Both reset and load messages are
    sent to kernel on successful completion of reset and load operation
    respectively.
    
    The throttle OCC event indicates that the Pmax of the chip is reduced.
    The chip_id and throttle reason for reducing Pmax is also queued along
    with the message.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 053819e0bf8407746cc5febf7a4947bee50377b4
Author: Shilpasri G Bhat <[email protected]>
Date:   Thu Jul 16 13:34:18 2015 +0530

    cpufreq: powernv: Handle throttling due to Pmax capping at chip level
    
    The On-Chip-Controller(OCC) can throttle cpu frequency by reducing the
    max allowed frequency for that chip if the chip exceeds its power or
    temperature limits. As Pmax capping is a chip level condition report
    this throttling behavior at chip level and also do not set the global
    'throttled' on Pmax capping instead set the per-chip throttled
    variable. Report unthrottling if Pmax is restored after throttling.
    
    This patch adds a structure to store chip id and throttled state of
    the chip.
    
    Signed-off-by: Shilpasri G Bhat <[email protected]>
    Reviewed-by: Preeti U Murthy <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit a34e63b14486e98cf78c99bf8ef141de7508dbc2
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:50 2015 +0200

    cpufreq: Pass CPU number to cpufreq_policy_alloc()
    
    Change cpufreq_policy_alloc() to take a CPU number instead of a CPU
    device pointer as its argument, as it is the only function called by
    cpufreq_add_dev() taking a device pointer argument at this point.
    
    That will allow us to split the CPU online part from cpufreq_add_dev()
    more cleanly going forward.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit 4d1f3a5bcb489cc6f7cbc128e0c292fed7868d32
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:44 2015 +0200

    cpufreq: Do not update related_cpus on every policy activation
    
    The related_cpus mask includes CPUs whose cpufreq_cpu_data per-CPU
    pointers have been set the the given policy.  Since those pointers
    are only set at the policy creation time and unset when the policy
    is deleted, the related_cpus should not be updated between those
    two operations.
    
    For this reason, avoid updating it whenever the first of the
    "related" CPUs goes online.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit d9612a495b0bc93f5db0e0033fe4ee7abb7167c7
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:37 2015 +0200

    cpufreq: Drop unused dev argument from two functions
    
    The dev argument of cpufreq_add_policy_cpu() and
    cpufreq_add_dev_interface() is not used by any of them,
    so drop it.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit d4d854d6c7706e6a5cda297e350e3626d55e9bc9
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:30 2015 +0200

    cpufreq: Drop unnecessary label from cpufreq_add_dev()
    
    The leftover out_release_rwsem label in cpufreq_add_dev() is not
    necessary any more and confusing, so drop it.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit 11ce707e6c2aea05e1f54680fb89a8a44ded5db4
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:21 2015 +0200

    cpufreq: Drop cpufreq_policy_restore()
    
    Notice that when cpufreq_policy_restore() is called, its per-CPU
    cpufreq_cpu_data variable has been already dereferenced and if that
    variable is not NULL, the policy local pointer in cpufreq_add_dev()
    contains its value.
    
    Therefore it is not necessary to dereference it again and the
    policy pointer can be used directly.  Moreover, if that pointer
    is not NULL, the policy is inactive (or the previous check would
    have made us return from cpufreq_add_dev()) so the restoration
    code from cpufreq_policy_restore() can be moved to that point
    in cpufreq_add_dev().
    
    Do that and drop cpufreq_policy_restore().
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit 15c0b4d222f83672407419f9c9e167e996d8ad2b
Author: Rafael J. Wysocki <[email protected]>
Date:   Mon Jul 27 23:11:09 2015 +0200

    cpufreq: Rework two functions related to CPU offline
    
    Since __cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish()
    are about CPU offline rather than about CPU removal, rename them to
    cpufreq_offline_prepare() and cpufreq_offline_finish(), respectively.
    
    Also change their argument from a struct device pointer to a CPU
    number, because they use the CPU number only internally anyway
    and make them void as their return values are ignored.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit ede76209c1f166af8a6b8fb2c5e0f2fc0e2e317b
Author: Rob Clark <[email protected]>
Date:   Tue Jul 28 11:05:03 2015 -0400

    drm/msm: don't install plane properties on crtc
    
    This was a hold-over from the pre-atomic days and legacy userspace that
    only understood CRTCs.  Fortunately we don't have any properties, so
    this doesn't change anything.  But before we start growing some plane
    properties, we should fix this.
    
    Signed-off-by: Rob Clark <[email protected]>

commit 559ed40752dc63e68f9b9ad301b20e6a3fe5cf21
Author: Rafael J. Wysocki <[email protected]>
Date:   Sun Jul 26 02:07:47 2015 +0200

    cpufreq: Avoid attempts to create duplicate symbolic links
    
    After commit 87549141d516 (cpufreq: Stop migrating sysfs files on
    hotplug) there is a problem with CPUs that share cpufreq policy
    objects with other CPUs and are initially offline.
    
    Say CPU1 shares a policy with CPU0 which is online and is registered
    first.  As part of the registration process, cpufreq_add_dev() is
    called for it.  It creates the policy object and a symbolic link
    to it from the CPU1's sysfs directory.  If CPU1 is registered
    subsequently and it is offline at that time, cpufreq_add_dev() will
    attempt to create a symbolic link to the policy object for it, but
    that link is present already, so a warning about that will be
    triggered.
    
    To avoid that warning, make cpufreq use an additional CPU mask
    containing related CPUs that are actually present for each policy
    object.  That mask is initialized when the policy object is populated
    after its creation (for the first online CPU using it) and it includes
    CPUs from the "policy CPUs" mask returned by the cpufreq driver's
    ->init() callback that are physically present at that time.  Symbolic
    links to the policy are created only for the CPUs in that mask.
    
    If cpufreq_add_dev() is invoked for an offline CPU, it checks the
    new mask and only creates the symlink if the CPU was not in it (the
    CPU is added to the mask at the same time).
    
    In turn, cpufreq_remove_dev() drops the given CPU from the new mask,
    removes its symlink to the policy object and returns, unless it is
    the CPU owning the policy object.  In that case, the policy object
    is moved to a new CPU's sysfs directory or deleted if the CPU being
    removed was the last user of the policy.
    
    While at it, notice that cpufreq_remove_dev() can't fail, because
    its return value is ignored, so make it ignore return values from
    __cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish()
    and prevent these functions from aborting on errors returned by
    __cpufreq_governor().  Also drop the now unused sif argument from
    them.
    
    Fixes: 87549141d516 (cpufreq: Stop migrating sysfs files on hotplug)
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reported-and-tested-by: Russell King <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>

commit 766ffb69803943c2b580a44ac14a189b875d21f6
Author: Will Deacon <[email protected]>
Date:   Tue Jul 28 16:14:03 2015 +0100

    arm64: pgtable: fix definition of pte_valid
    
    pte_valid should check if the PTE_VALID bit (1 << 0) is set in the pte,
    so fix the macro definition to use bitwise & instead of logical &&.
    
    Signed-off-by: Will Deacon <[email protected]>

commit 5dbaf90a6780b2989515212cb2584b7771cecad1
Author: David Woodhouse <[email protected]>
Date:   Tue Mar 24 14:54:56 2015 +0000

    iommu/vt-d: Add initial shell of SVM support
    
    Add CONFIG_INTEL_IOMMU_SVM, and allocate PASID tables.
    
    Signed-off-by: David Woodhouse <[email protected]>

commit 15bbdec3931e617231c12b0920e497e87ec8c2c6
Author: Sakari Ailus <[email protected]>
Date:   Mon Jul 13 14:31:30 2015 +0300

    iommu: Make the iova library a module
    
    The iova library has use outside the intel-iommu driver, thus make it a
    module.
    
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: David Woodhouse <[email protected]>

commit 9b41760b03816b34f4c9eee2cbb8fda8439920fc
Author: Sakari Ailus <[email protected]>
Date:   Mon Jul 13 14:31:29 2015 +0300

    iommu: iova: Export symbols
    
    Use EXPORT_SYMBOL_GPL() to export the iova library symbols. The symbols
    include:
    
    	init_iova_domain();
    	iova_cache_get();
    	iova_cache_put();
    	iova_cache_init();
    	alloc_iova();
    	find_iova();
    	__free_iova();
    	free_iova();
    	put_iova_domain();
    	reserve_iova();
    	copy_reserved_iova();
    
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: David Woodhouse <[email protected]>

commit ae1ff3d623905947158fd3394854c23026337810
Author: Sakari Ailus <[email protected]>
Date:   Mon Jul 13 14:31:28 2015 +0300

    iommu: iova: Move iova cache management to the iova library
    
    This is necessary to separate intel-iommu from the iova library.
    
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: David Woodhouse <[email protected]>

commit 8f6429c7cb59f28433253575cc8e3262eed63592
Author: Robin Murphy <[email protected]>
Date:   Thu Jul 16 19:40:12 2015 +0100

    iommu/iova: Avoid over-allocating when size-aligned
    
    Currently, allocating a size-aligned IOVA region quietly adjusts the
    actual allocation size in the process, returning a rounded-up
    power-of-two-sized allocation. This results in mismatched behaviour in
    the IOMMU driver if the original size was not a power of two, where the
    original size is mapped, but the rounded-up IOVA size is unmapped.
    
    Whilst some IOMMUs will happily unmap already-unmapped pages, others
    consider this an error, so fix it by computing the necessary alignment
    padding without altering the actual allocation size. Also clean up by
    making pad_size unsigned, since its callers always pass unsigned values
    and negative padding makes little sense here anyway.
    
    Signed-off-by: Robin Murphy <[email protected]>
    Signed-off-by: David Woodhouse <[email protected]>

commit d169ba3e093c0932f466ba68314555317e072def
Author: Archit Taneja <[email protected]>
Date:   Fri Jun 26 13:13:03 2015 +0530

    drm/msm: dsi host: add missing of_node_put()
    
    Decrement device node refcount if of_get_child_by_name is successfully
    called.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 71b65445f0ed04c2afe3660f829779fddb2890c1
Author: Mika Westerberg <[email protected]>
Date:   Tue Jul 28 13:51:21 2015 +0300

    ACPI / PM: Use target_state to set the device power state
    
    Commit 20dacb71ad28 ("ACPI / PM: Rework device power management to follow
    ACPI 6") changed the device power management to use D3ho…
torvalds pushed a commit that referenced this pull request Aug 1, 2015
Dynamically allocated sysfs attributes should be initialized with
sysfs_attr_init() otherwise lockdep will be angry with us:

[   45.468653] BUG: key ffffffc030fad4e0 not in .data!
[   45.468655] ------------[ cut here ]------------
[   45.468666] WARNING: CPU: 0 PID: 1176 at /mnt/host/source/src/third_party/kernel/v3.18/kernel/locking/lockdep.c:2991 lockdep_init_map+0x12c/0x490()
[   45.468672] DEBUG_LOCKS_WARN_ON(1)
[   45.468672] CPU: 0 PID: 1176 Comm: iptables Tainted: G     U  W 3.18.0 #43
[   45.468674] Hardware name: XXX
[   45.468675] Call trace:
[   45.468680] [<ffffffc0002072b4>] dump_backtrace+0x0/0x10c
[   45.468683] [<ffffffc0002073d0>] show_stack+0x10/0x1c
[   45.468688] [<ffffffc000a86cd4>] dump_stack+0x74/0x94
[   45.468692] [<ffffffc000217ae0>] warn_slowpath_common+0x84/0xb0
[   45.468694] [<ffffffc000217b84>] warn_slowpath_fmt+0x4c/0x58
[   45.468697] [<ffffffc0002530a4>] lockdep_init_map+0x128/0x490
[   45.468701] [<ffffffc000367ef0>] __kernfs_create_file+0x80/0xe4
[   45.468704] [<ffffffc00036862c>] sysfs_add_file_mode_ns+0x104/0x170
[   45.468706] [<ffffffc00036870c>] sysfs_create_file_ns+0x58/0x64
[   45.468711] [<ffffffc000930430>] idletimer_tg_checkentry+0x14c/0x324
[   45.468714] [<ffffffc00092a728>] xt_check_target+0x170/0x198
[   45.468717] [<ffffffc000993efc>] check_target+0x58/0x6c
[   45.468720] [<ffffffc000994c64>] translate_table+0x30c/0x424
[   45.468723] [<ffffffc00099529c>] do_ipt_set_ctl+0x144/0x1d0
[   45.468728] [<ffffffc0009079f0>] nf_setsockopt+0x50/0x60
[   45.468732] [<ffffffc000946870>] ip_setsockopt+0x8c/0xb4
[   45.468735] [<ffffffc0009661c0>] raw_setsockopt+0x10/0x50
[   45.468739] [<ffffffc0008c1550>] sock_common_setsockopt+0x14/0x20
[   45.468742] [<ffffffc0008bd190>] SyS_setsockopt+0x88/0xb8
[   45.468744] ---[ end trace 41d156354d18c039 ]---

Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Jul 5, 2024
commit eeb25a0 upstream.

.probe() (ahci_init_one()) calls sysfs_add_file_to_group(), however,
if probe() fails after this call, we currently never call
sysfs_remove_file_from_group().

(The sysfs_remove_file_from_group() call in .remove() (ahci_remove_one())
does not help, as .remove() is not called on .probe() error.)

Thus, if probe() fails after the sysfs_add_file_to_group() call, the next
time we insmod the module we will get:

sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/remapped_nvme'
CPU: 11 PID: 954 Comm: modprobe Not tainted 6.10.0-rc5 torvalds#43
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x5d/0x80
 sysfs_warn_dup.cold+0x17/0x23
 sysfs_add_file_mode_ns+0x11a/0x130
 sysfs_add_file_to_group+0x7e/0xc0
 ahci_init_one+0x31f/0xd40 [ahci]

Fixes: 894fba7 ("ata: ahci: Add sysfs attribute to show remapped NVMe device count")
Cc: [email protected]
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Niklas Cassel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
tombriden pushed a commit to tombriden/linux that referenced this pull request Jul 5, 2024
commit eeb25a0 upstream.

.probe() (ahci_init_one()) calls sysfs_add_file_to_group(), however,
if probe() fails after this call, we currently never call
sysfs_remove_file_from_group().

(The sysfs_remove_file_from_group() call in .remove() (ahci_remove_one())
does not help, as .remove() is not called on .probe() error.)

Thus, if probe() fails after the sysfs_add_file_to_group() call, the next
time we insmod the module we will get:

sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/remapped_nvme'
CPU: 11 PID: 954 Comm: modprobe Not tainted 6.10.0-rc5 torvalds#43
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x5d/0x80
 sysfs_warn_dup.cold+0x17/0x23
 sysfs_add_file_mode_ns+0x11a/0x130
 sysfs_add_file_to_group+0x7e/0xc0
 ahci_init_one+0x31f/0xd40 [ahci]

Fixes: 894fba7 ("ata: ahci: Add sysfs attribute to show remapped NVMe device count")
Cc: [email protected]
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Niklas Cassel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ilstam pushed a commit to ilstam/linux that referenced this pull request Jul 10, 2024
.probe() (ahci_init_one()) calls sysfs_add_file_to_group(), however,
if probe() fails after this call, we currently never call
sysfs_remove_file_from_group().

(The sysfs_remove_file_from_group() call in .remove() (ahci_remove_one())
does not help, as .remove() is not called on .probe() error.)

Thus, if probe() fails after the sysfs_add_file_to_group() call, the next
time we insmod the module we will get:

sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/remapped_nvme'
CPU: 11 PID: 954 Comm: modprobe Not tainted 6.10.0-rc5 torvalds#43
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x5d/0x80
 sysfs_warn_dup.cold+0x17/0x23
 sysfs_add_file_mode_ns+0x11a/0x130
 sysfs_add_file_to_group+0x7e/0xc0
 ahci_init_one+0x31f/0xd40 [ahci]

Fixes: 894fba7 ("ata: ahci: Add sysfs attribute to show remapped NVMe device count")
Cc: [email protected]
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Niklas Cassel <[email protected]>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this pull request Jul 16, 2024
commit eeb25a0 upstream.

.probe() (ahci_init_one()) calls sysfs_add_file_to_group(), however,
if probe() fails after this call, we currently never call
sysfs_remove_file_from_group().

(The sysfs_remove_file_from_group() call in .remove() (ahci_remove_one())
does not help, as .remove() is not called on .probe() error.)

Thus, if probe() fails after the sysfs_add_file_to_group() call, the next
time we insmod the module we will get:

sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/remapped_nvme'
CPU: 11 PID: 954 Comm: modprobe Not tainted 6.10.0-rc5 torvalds#43
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x5d/0x80
 sysfs_warn_dup.cold+0x17/0x23
 sysfs_add_file_mode_ns+0x11a/0x130
 sysfs_add_file_to_group+0x7e/0xc0
 ahci_init_one+0x31f/0xd40 [ahci]

Fixes: 894fba7 ("ata: ahci: Add sysfs attribute to show remapped NVMe device count")
Cc: [email protected]
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Niklas Cassel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
panantoni01 pushed a commit to panantoni01/linux that referenced this pull request Jul 17, 2024
commit eeb25a0 upstream.

.probe() (ahci_init_one()) calls sysfs_add_file_to_group(), however,
if probe() fails after this call, we currently never call
sysfs_remove_file_from_group().

(The sysfs_remove_file_from_group() call in .remove() (ahci_remove_one())
does not help, as .remove() is not called on .probe() error.)

Thus, if probe() fails after the sysfs_add_file_to_group() call, the next
time we insmod the module we will get:

sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/remapped_nvme'
CPU: 11 PID: 954 Comm: modprobe Not tainted 6.10.0-rc5 torvalds#43
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x5d/0x80
 sysfs_warn_dup.cold+0x17/0x23
 sysfs_add_file_mode_ns+0x11a/0x130
 sysfs_add_file_to_group+0x7e/0xc0
 ahci_init_one+0x31f/0xd40 [ahci]

Fixes: 894fba7 ("ata: ahci: Add sysfs attribute to show remapped NVMe device count")
Cc: [email protected]
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Niklas Cassel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this pull request Aug 1, 2024
This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ torvalds#43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   <TASK>
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   </TASK>
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Fixes: 12bb21a ("fscache: Implement cookie user counting and resource pinning")
Signed-off-by: Max Kellermann <[email protected]>
Signed-off-by: David Howells <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
cc: Jeff Layton <[email protected]>
cc: [email protected]
cc: [email protected]
cc: [email protected]
Signed-off-by: Christian Brauner <[email protected]>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this pull request Aug 1, 2024
This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ torvalds#43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   <TASK>
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   </TASK>
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Fixes: 12bb21a ("fscache: Implement cookie user counting and resource pinning")
Signed-off-by: Max Kellermann <[email protected]>
Signed-off-by: David Howells <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
cc: Jeff Layton <[email protected]>
cc: [email protected]
cc: [email protected]
cc: [email protected]
Signed-off-by: Christian Brauner <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Aug 13, 2024
This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ torvalds#43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   <TASK>
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   </TASK>
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Fixes: 12bb21a ("fscache: Implement cookie user counting and resource pinning")
Signed-off-by: Max Kellermann <[email protected]>
Signed-off-by: David Howells <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
cc: Jeff Layton <[email protected]>
cc: [email protected]
cc: [email protected]
cc: [email protected]
Signed-off-by: Christian Brauner <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Aug 20, 2024
CAM (legacy) host drivers also need to refer to pci_ecam_add_bus and
pci_ecam_remove_bus functions to get mapped resources on 32-bit systems.
This is because 32-bit systems have separate iomap resources per bus
segment and pci_ecam_add_bus is the one that sets that up. Move the
pci_ecam_ops for CAM mode to ecam.c so we can refer the static functions.

This fixes :

[    1.356001] pci-host-generic 30000000.pci: host bridge /soc/pci@30000000 ranges:
[    1.365324] pci-host-generic 30000000.pci:      MEM 0x0040000000..0x004fffffff -> 0x0040000000
[    1.375556] pci-host-generic 30000000.pci:      MEM 0x0050000000..0x006fffffff -> 0x0050000000
[    1.386132] pci-host-generic 30000000.pci: ECAM at [mem 0x30000000-0x30ffffff] for [bus 00-ff]
[    1.399490] pci-host-generic 30000000.pci: PCI host bridge to bus 0000:00
[    1.407073] pci_bus 0000:00: root bus resource [bus 00-ff]
[    1.413648] pci_bus 0000:00: root bus resource [mem 0x40000000-0x4fffffff]
[    1.421718] pci_bus 0000:00: root bus resource [mem 0x50000000-0x6fffffff pref]
[    1.430647] Unable to handle kernel NULL pointer dereference at virtual address 00000800
[    1.439441] Oops [#1]
[    1.442152] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ torvalds#43
[    1.448753] Hardware name: Digilent Nexys-Video-A7 RV32 (DT)
[    1.454968] epc : pci_generic_config_read+0x40/0xb0
[    1.460652]  ra : pci_generic_config_read+0x2c/0xb0
[    1.466322] epc : c038db9c ra : c038db88 sp : c1c3bc20
[    1.472095]  gp : c18726d0 tp : c1c5c000 t0 : 0000006e
[    1.477859]  t1 : 00000063 t2 : 00000000 s0 : c1c3bc30
[    1.483604]  s1 : 00000004 a0 : 00000800 a1 : 00000800
[    1.489348]  a2 : 00000000 a3 : 00000008 a4 : c1d15800
[    1.495090]  a5 : 00000002 a6 : 0000008a a7 : c1809ec0
[    1.500844]  s2 : c1c3bc38 s3 : 0000ea60 s4 : 00000008
[    1.506600]  s5 : c1ce4a00 s6 : 00000006 s7 : c11c7460
[    1.512353]  s8 : 00000008 s9 : c0800108 s10: 00000000
[    1.518095]  s11: 00000000 t3 : 3ffff7ff t4 : 00000000
[    1.523833]  t5 : 00000001 t6 : 00000000
[    1.528252] status: 00000100 badaddr: 00000800 cause: 0000000d
[    1.534729] [<c038db9c>] pci_generic_config_read+0x40/0xb0
[    1.541096] [<c038da04>] pci_bus_read_config_dword+0x50/0xb0
[    1.547623] [<c0391e94>] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec
[    1.555010] [<c039245c>] pci_scan_single_device+0xa4/0x11c
[    1.561273] [<c0392570>] pci_scan_slot+0x9c/0x23c
[    1.566716] [<c039388c>] pci_scan_child_bus_extend+0x58/0x2f4
[    1.573275] [<c0393db0>] pci_scan_root_bus_bridge+0x64/0xe8
[    1.579650] [<c0393e54>] pci_host_probe+0x20/0xc8
[    1.585104] [<c03bc6f4>] pci_host_common_probe+0x144/0x1e4
[    1.591396] [<c042ec20>] platform_probe+0x54/0x9c
[    1.596957] [<c042b5c8>] really_probe+0xbc/0x418
[    1.602367] [<c042bb0c>] __driver_probe_device+0x70/0xfc
[    1.608507] [<c042bbe0>] driver_probe_device+0x48/0xf0
[    1.614487] [<c042be98>] __driver_attach+0xbc/0x264
[    1.620190] [<c0428d04>] bus_for_each_dev+0x84/0xf8
[    1.625868] [<c042aeec>] driver_attach+0x28/0x38
[    1.631269] [<c042a510>] bus_add_driver+0x140/0x278
[    1.636956] [<c042cf48>] driver_register+0x70/0x15c
[    1.642666] [<c042e8f8>] __platform_driver_register+0x28/0x38
[    1.649332] [<c081b694>] gen_pci_driver_init+0x24/0x34
[    1.655241] [<c0801424>] do_one_initcall+0x88/0x164
[    1.660943] [<c0801768>] kernel_init_freeable+0x1dc/0x264
[    1.667199] [<c0699f34>] kernel_init+0x28/0x138
[    1.672578] [<c06a0b5c>] ret_from_fork+0x14/0x24
[    1.678399] Code: 0463 0605 0793 0010 8663 04f4 0793 0020 8663 02f4 (2503) 0005
[    1.686462] ---[ end trace 0000000000000000 ]---
[    1.691591] Kernel panic - not syncing: Fatal exception

Signed-off-by: Steffen Persvold <[email protected]>
jhautbois pushed a commit to YoseliSAS/linux that referenced this pull request Aug 21, 2024
.probe() (ahci_init_one()) calls sysfs_add_file_to_group(), however,
if probe() fails after this call, we currently never call
sysfs_remove_file_from_group().

(The sysfs_remove_file_from_group() call in .remove() (ahci_remove_one())
does not help, as .remove() is not called on .probe() error.)

Thus, if probe() fails after the sysfs_add_file_to_group() call, the next
time we insmod the module we will get:

sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/remapped_nvme'
CPU: 11 PID: 954 Comm: modprobe Not tainted 6.10.0-rc5 torvalds#43
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x5d/0x80
 sysfs_warn_dup.cold+0x17/0x23
 sysfs_add_file_mode_ns+0x11a/0x130
 sysfs_add_file_to_group+0x7e/0xc0
 ahci_init_one+0x31f/0xd40 [ahci]

Fixes: 894fba7 ("ata: ahci: Add sysfs attribute to show remapped NVMe device count")
Cc: [email protected]
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Niklas Cassel <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Aug 27, 2024
commit f71aa06 upstream.

This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ torvalds#43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   <TASK>
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   </TASK>
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Fixes: 12bb21a ("fscache: Implement cookie user counting and resource pinning")
Signed-off-by: Max Kellermann <[email protected]>
Signed-off-by: David Howells <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
cc: Jeff Layton <[email protected]>
cc: [email protected]
cc: [email protected]
cc: [email protected]
Signed-off-by: Christian Brauner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Aug 27, 2024
commit f71aa06 upstream.

This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ torvalds#43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   <TASK>
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   </TASK>
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Fixes: 12bb21a ("fscache: Implement cookie user counting and resource pinning")
Signed-off-by: Max Kellermann <[email protected]>
Signed-off-by: David Howells <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
cc: Jeff Layton <[email protected]>
cc: [email protected]
cc: [email protected]
cc: [email protected]
Signed-off-by: Christian Brauner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Kaz205 pushed a commit to Kaz205/linux that referenced this pull request Aug 29, 2024
commit f71aa06 upstream.

This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ torvalds#43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   <TASK>
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   </TASK>
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Fixes: 12bb21a ("fscache: Implement cookie user counting and resource pinning")
Signed-off-by: Max Kellermann <[email protected]>
Signed-off-by: David Howells <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
cc: Jeff Layton <[email protected]>
cc: [email protected]
cc: [email protected]
cc: [email protected]
Signed-off-by: Christian Brauner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
klarasm pushed a commit to klarasm/linux that referenced this pull request Aug 29, 2024
commit f71aa06 upstream.

This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ torvalds#43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   <TASK>
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   </TASK>
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Fixes: 12bb21a ("fscache: Implement cookie user counting and resource pinning")
Signed-off-by: Max Kellermann <[email protected]>
Signed-off-by: David Howells <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
cc: Jeff Layton <[email protected]>
cc: [email protected]
cc: [email protected]
cc: [email protected]
Signed-off-by: Christian Brauner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
olafhering pushed a commit to olafhering/linux that referenced this pull request Aug 29, 2024
commit f71aa06 upstream.

This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ torvalds#43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   <TASK>
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   </TASK>
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Fixes: 12bb21a ("fscache: Implement cookie user counting and resource pinning")
Signed-off-by: Max Kellermann <[email protected]>
Signed-off-by: David Howells <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
cc: Jeff Layton <[email protected]>
cc: [email protected]
cc: [email protected]
cc: [email protected]
Signed-off-by: Christian Brauner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this pull request Aug 30, 2024
commit f71aa06 upstream.

This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ torvalds#43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   <TASK>
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   </TASK>
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Fixes: 12bb21a ("fscache: Implement cookie user counting and resource pinning")
Signed-off-by: Max Kellermann <[email protected]>
Signed-off-by: David Howells <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
cc: Jeff Layton <[email protected]>
cc: [email protected]
cc: [email protected]
cc: [email protected]
Signed-off-by: Christian Brauner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Sep 4, 2024
commit eeb25a0 upstream.

.probe() (ahci_init_one()) calls sysfs_add_file_to_group(), however,
if probe() fails after this call, we currently never call
sysfs_remove_file_from_group().

(The sysfs_remove_file_from_group() call in .remove() (ahci_remove_one())
does not help, as .remove() is not called on .probe() error.)

Thus, if probe() fails after the sysfs_add_file_to_group() call, the next
time we insmod the module we will get:

sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/remapped_nvme'
CPU: 11 PID: 954 Comm: modprobe Not tainted 6.10.0-rc5 torvalds#43
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x5d/0x80
 sysfs_warn_dup.cold+0x17/0x23
 sysfs_add_file_mode_ns+0x11a/0x130
 sysfs_add_file_to_group+0x7e/0xc0
 ahci_init_one+0x31f/0xd40 [ahci]

Fixes: 894fba7 ("ata: ahci: Add sysfs attribute to show remapped NVMe device count")
Cc: [email protected]
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Niklas Cassel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Mr-Bossman pushed a commit to Mr-Bossman/linux that referenced this pull request Sep 16, 2024
This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ torvalds#43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   <TASK>
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   </TASK>
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Fixes: 12bb21a ("fscache: Implement cookie user counting and resource pinning")
Signed-off-by: Max Kellermann <[email protected]>
Signed-off-by: David Howells <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
cc: Jeff Layton <[email protected]>
cc: [email protected]
cc: [email protected]
cc: [email protected]
Signed-off-by: Christian Brauner <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Sep 26, 2024
Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

Reproducer:
    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt
    # dd if=/mnt/largefile of=/dev/null
    ...
    [  194.196391] ==================================================================
    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
    [  194.197707]
    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty torvalds#43
    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
    [  194.200032] Call Trace:
    [  194.200191]  <TASK>
    [  194.200327]  dump_stack_lvl+0x4e/0x70
    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.200809]  print_report+0x174/0x505
    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [  194.201352]  ? srso_return_thunk+0x5/0x5f
    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0
    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202128]  kasan_report+0xc8/0x150
    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202616]  gf128mul_4k_lle+0xc1/0x110
    [  194.202863]  ghash_update+0x184/0x210
    [  194.203103]  shash_ahash_update+0x184/0x2a0
    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10
    [  194.203651]  ? srso_return_thunk+0x5/0x5f
    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340
    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140
    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]
    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]
    [  194.208507]  ? srso_return_thunk+0x5/0x5f
    [  194.209205]  ? srso_return_thunk+0x5/0x5f
    [  194.209925]  ? srso_return_thunk+0x5/0x5f
    [  194.210443]  ? srso_return_thunk+0x5/0x5f
    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]
    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
    [  194.214670]  ? srso_return_thunk+0x5/0x5f
    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.

Signed-off-by: Enzo Matsumiya <[email protected]>
1054009064 pushed a commit to 1054009064/linux that referenced this pull request Sep 27, 2024
Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

Reproducer:
    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt
    # dd if=/mnt/largefile of=/dev/null
    ...
    [  194.196391] ==================================================================
    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
    [  194.197707]
    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty torvalds#43
    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
    [  194.200032] Call Trace:
    [  194.200191]  <TASK>
    [  194.200327]  dump_stack_lvl+0x4e/0x70
    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.200809]  print_report+0x174/0x505
    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [  194.201352]  ? srso_return_thunk+0x5/0x5f
    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0
    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202128]  kasan_report+0xc8/0x150
    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202616]  gf128mul_4k_lle+0xc1/0x110
    [  194.202863]  ghash_update+0x184/0x210
    [  194.203103]  shash_ahash_update+0x184/0x2a0
    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10
    [  194.203651]  ? srso_return_thunk+0x5/0x5f
    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340
    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140
    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]
    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]
    [  194.208507]  ? srso_return_thunk+0x5/0x5f
    [  194.209205]  ? srso_return_thunk+0x5/0x5f
    [  194.209925]  ? srso_return_thunk+0x5/0x5f
    [  194.210443]  ? srso_return_thunk+0x5/0x5f
    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]
    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
    [  194.214670]  ? srso_return_thunk+0x5/0x5f
    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.

Signed-off-by: Enzo Matsumiya <[email protected]>
Signed-off-by: Steve French <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Sep 27, 2024
Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

Reproducer:
    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt
    # dd if=/mnt/largefile of=/dev/null
    ...
    [  194.196391] ==================================================================
    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
    [  194.197707]
    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty torvalds#43
    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
    [  194.200032] Call Trace:
    [  194.200191]  <TASK>
    [  194.200327]  dump_stack_lvl+0x4e/0x70
    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.200809]  print_report+0x174/0x505
    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [  194.201352]  ? srso_return_thunk+0x5/0x5f
    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0
    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202128]  kasan_report+0xc8/0x150
    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202616]  gf128mul_4k_lle+0xc1/0x110
    [  194.202863]  ghash_update+0x184/0x210
    [  194.203103]  shash_ahash_update+0x184/0x2a0
    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10
    [  194.203651]  ? srso_return_thunk+0x5/0x5f
    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340
    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140
    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]
    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]
    [  194.208507]  ? srso_return_thunk+0x5/0x5f
    [  194.209205]  ? srso_return_thunk+0x5/0x5f
    [  194.209925]  ? srso_return_thunk+0x5/0x5f
    [  194.210443]  ? srso_return_thunk+0x5/0x5f
    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]
    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
    [  194.214670]  ? srso_return_thunk+0x5/0x5f
    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.

Signed-off-by: Enzo Matsumiya <[email protected]>
Signed-off-by: Steve French <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Oct 14, 2024
[ Upstream commit b0abcd6 ]

Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

Reproducer:
    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt
    # dd if=/mnt/largefile of=/dev/null
    ...
    [  194.196391] ==================================================================
    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
    [  194.197707]
    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty torvalds#43
    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
    [  194.200032] Call Trace:
    [  194.200191]  <TASK>
    [  194.200327]  dump_stack_lvl+0x4e/0x70
    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.200809]  print_report+0x174/0x505
    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [  194.201352]  ? srso_return_thunk+0x5/0x5f
    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0
    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202128]  kasan_report+0xc8/0x150
    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202616]  gf128mul_4k_lle+0xc1/0x110
    [  194.202863]  ghash_update+0x184/0x210
    [  194.203103]  shash_ahash_update+0x184/0x2a0
    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10
    [  194.203651]  ? srso_return_thunk+0x5/0x5f
    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340
    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140
    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]
    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]
    [  194.208507]  ? srso_return_thunk+0x5/0x5f
    [  194.209205]  ? srso_return_thunk+0x5/0x5f
    [  194.209925]  ? srso_return_thunk+0x5/0x5f
    [  194.210443]  ? srso_return_thunk+0x5/0x5f
    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]
    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
    [  194.214670]  ? srso_return_thunk+0x5/0x5f
    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.

Signed-off-by: Enzo Matsumiya <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Oct 14, 2024
[ Upstream commit b0abcd6 ]

Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

Reproducer:
    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt
    # dd if=/mnt/largefile of=/dev/null
    ...
    [  194.196391] ==================================================================
    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
    [  194.197707]
    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty torvalds#43
    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
    [  194.200032] Call Trace:
    [  194.200191]  <TASK>
    [  194.200327]  dump_stack_lvl+0x4e/0x70
    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.200809]  print_report+0x174/0x505
    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [  194.201352]  ? srso_return_thunk+0x5/0x5f
    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0
    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202128]  kasan_report+0xc8/0x150
    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202616]  gf128mul_4k_lle+0xc1/0x110
    [  194.202863]  ghash_update+0x184/0x210
    [  194.203103]  shash_ahash_update+0x184/0x2a0
    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10
    [  194.203651]  ? srso_return_thunk+0x5/0x5f
    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340
    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140
    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]
    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]
    [  194.208507]  ? srso_return_thunk+0x5/0x5f
    [  194.209205]  ? srso_return_thunk+0x5/0x5f
    [  194.209925]  ? srso_return_thunk+0x5/0x5f
    [  194.210443]  ? srso_return_thunk+0x5/0x5f
    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]
    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
    [  194.214670]  ? srso_return_thunk+0x5/0x5f
    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.

Signed-off-by: Enzo Matsumiya <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
KexyBiscuit pushed a commit to AOSC-Tracking/linux that referenced this pull request Oct 15, 2024
[ Upstream commit b0abcd6 ]

Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

Reproducer:
    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt
    # dd if=/mnt/largefile of=/dev/null
    ...
    [  194.196391] ==================================================================
    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
    [  194.197707]
    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty torvalds#43
    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
    [  194.200032] Call Trace:
    [  194.200191]  <TASK>
    [  194.200327]  dump_stack_lvl+0x4e/0x70
    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.200809]  print_report+0x174/0x505
    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [  194.201352]  ? srso_return_thunk+0x5/0x5f
    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0
    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202128]  kasan_report+0xc8/0x150
    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202616]  gf128mul_4k_lle+0xc1/0x110
    [  194.202863]  ghash_update+0x184/0x210
    [  194.203103]  shash_ahash_update+0x184/0x2a0
    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10
    [  194.203651]  ? srso_return_thunk+0x5/0x5f
    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340
    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140
    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]
    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]
    [  194.208507]  ? srso_return_thunk+0x5/0x5f
    [  194.209205]  ? srso_return_thunk+0x5/0x5f
    [  194.209925]  ? srso_return_thunk+0x5/0x5f
    [  194.210443]  ? srso_return_thunk+0x5/0x5f
    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]
    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
    [  194.214670]  ? srso_return_thunk+0x5/0x5f
    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.

Signed-off-by: Enzo Matsumiya <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
KexyBiscuit pushed a commit to AOSC-Tracking/linux that referenced this pull request Oct 15, 2024
[ Upstream commit b0abcd6 ]

Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

Reproducer:
    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt
    # dd if=/mnt/largefile of=/dev/null
    ...
    [  194.196391] ==================================================================
    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
    [  194.197707]
    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty torvalds#43
    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
    [  194.200032] Call Trace:
    [  194.200191]  <TASK>
    [  194.200327]  dump_stack_lvl+0x4e/0x70
    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.200809]  print_report+0x174/0x505
    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [  194.201352]  ? srso_return_thunk+0x5/0x5f
    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0
    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202128]  kasan_report+0xc8/0x150
    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202616]  gf128mul_4k_lle+0xc1/0x110
    [  194.202863]  ghash_update+0x184/0x210
    [  194.203103]  shash_ahash_update+0x184/0x2a0
    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10
    [  194.203651]  ? srso_return_thunk+0x5/0x5f
    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340
    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140
    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]
    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]
    [  194.208507]  ? srso_return_thunk+0x5/0x5f
    [  194.209205]  ? srso_return_thunk+0x5/0x5f
    [  194.209925]  ? srso_return_thunk+0x5/0x5f
    [  194.210443]  ? srso_return_thunk+0x5/0x5f
    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]
    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
    [  194.214670]  ? srso_return_thunk+0x5/0x5f
    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.

Signed-off-by: Enzo Matsumiya <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Oct 16, 2024
The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging
tosend bytes, which is either msg->sg.size or a smaller value apply_bytes.
Potential problems with this strategy are as follows:
- If the actual sent bytes are smaller than tosend, we need to charge some
bytes back, as in line 487, which is okay but seems not clean.
- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may
miss uncharging (msg->sg.size - apply_bytes) bytes.

415 tosend = msg->sg.size;
416 if (psock->apply_bytes && psock->apply_bytes < tosend)
417   tosend = psock->apply_bytes;
...
443 sk_msg_return(sk, msg, tosend);
444 release_sock(sk);
446 origsize = msg->sg.size;
447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,
448                             msg, tosend, flags);
449 sent = origsize - msg->sg.size;
...
454 lock_sock(sk);
455 if (unlikely(ret < 0)) {
456   int free = sk_msg_free_nocharge(sk, msg);
458   if (!cork)
459     *copied -= free;
460 }
...
487 if (eval == __SK_REDIRECT)
488   sk_mem_charge(sk, tosend - sent);

When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,
the following warning will be reported,
------------[ cut here ]------------
WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0
Modules linked in:
CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ torvalds#43
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Workqueue: events sk_psock_destroy
RIP: 0010:inet_sock_destruct+0x190/0x1a0
RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206
RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800
RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900
RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0
R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400
R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100
FS:  0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
? __warn+0x89/0x130
? inet_sock_destruct+0x190/0x1a0
? report_bug+0xfc/0x1e0
? handle_bug+0x5c/0xa0
? exc_invalid_op+0x17/0x70
? asm_exc_invalid_op+0x1a/0x20
? inet_sock_destruct+0x190/0x1a0
__sk_destruct+0x25/0x220
sk_psock_destroy+0x2b2/0x310
process_scheduled_works+0xa3/0x3e0
worker_thread+0x117/0x240
? __pfx_worker_thread+0x10/0x10
kthread+0xcf/0x100
? __pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
---[ end trace 0000000000000000 ]---

In __SK_REDIRECT, a more concise way is delaying the uncharging after sent
bytes are finalized, and uncharge this value. When (ret < 0), we shall
invoke sk_msg_free.

Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,
we may miss uncharging (msg->sg.size - apply_bytes) bytes. The same
warning will be reported in selftest.

468 case __SK_DROP:
469 default:
470 sk_msg_free_partial(sk, msg, tosend);
471 sk_msg_apply_bytes(psock, tosend);
472 *copied -= (tosend + delta);
473 return -EACCES;

So instead of sk_msg_free_partial we can do sk_msg_free here.

Fixes: 604326b ("bpf, sockmap: convert to generic sk_msg interface")
Fixes: 8ec95b9 ("bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues")
Signed-off-by: Zijian Zhang <[email protected]>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this pull request Oct 17, 2024
[ Upstream commit b0abcd6 ]

Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

Reproducer:
    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt
    # dd if=/mnt/largefile of=/dev/null
    ...
    [  194.196391] ==================================================================
    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
    [  194.197707]
    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty torvalds#43
    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
    [  194.200032] Call Trace:
    [  194.200191]  <TASK>
    [  194.200327]  dump_stack_lvl+0x4e/0x70
    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.200809]  print_report+0x174/0x505
    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [  194.201352]  ? srso_return_thunk+0x5/0x5f
    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0
    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202128]  kasan_report+0xc8/0x150
    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202616]  gf128mul_4k_lle+0xc1/0x110
    [  194.202863]  ghash_update+0x184/0x210
    [  194.203103]  shash_ahash_update+0x184/0x2a0
    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10
    [  194.203651]  ? srso_return_thunk+0x5/0x5f
    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340
    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140
    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]
    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]
    [  194.208507]  ? srso_return_thunk+0x5/0x5f
    [  194.209205]  ? srso_return_thunk+0x5/0x5f
    [  194.209925]  ? srso_return_thunk+0x5/0x5f
    [  194.210443]  ? srso_return_thunk+0x5/0x5f
    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]
    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
    [  194.214670]  ? srso_return_thunk+0x5/0x5f
    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.

Signed-off-by: Enzo Matsumiya <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ptr1337 pushed a commit to CachyOS/linux that referenced this pull request Oct 17, 2024
[ Upstream commit b0abcd6 ]

Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

Reproducer:
    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt
    # dd if=/mnt/largefile of=/dev/null
    ...
    [  194.196391] ==================================================================
    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
    [  194.197707]
    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty torvalds#43
    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
    [  194.200032] Call Trace:
    [  194.200191]  <TASK>
    [  194.200327]  dump_stack_lvl+0x4e/0x70
    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.200809]  print_report+0x174/0x505
    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [  194.201352]  ? srso_return_thunk+0x5/0x5f
    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0
    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202128]  kasan_report+0xc8/0x150
    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202616]  gf128mul_4k_lle+0xc1/0x110
    [  194.202863]  ghash_update+0x184/0x210
    [  194.203103]  shash_ahash_update+0x184/0x2a0
    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10
    [  194.203651]  ? srso_return_thunk+0x5/0x5f
    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340
    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140
    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]
    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]
    [  194.208507]  ? srso_return_thunk+0x5/0x5f
    [  194.209205]  ? srso_return_thunk+0x5/0x5f
    [  194.209925]  ? srso_return_thunk+0x5/0x5f
    [  194.210443]  ? srso_return_thunk+0x5/0x5f
    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]
    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
    [  194.214670]  ? srso_return_thunk+0x5/0x5f
    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.

Signed-off-by: Enzo Matsumiya <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Nov 27, 2024
The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging
tosend bytes, which is either msg->sg.size or a smaller value apply_bytes.

Potential problems with this strategy are as follows:

- If the actual sent bytes are smaller than tosend, we need to charge some
  bytes back, as in line 487, which is okay but seems not clean.

- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may
  miss uncharging (msg->sg.size - apply_bytes) bytes.

[...]
415 tosend = msg->sg.size;
416 if (psock->apply_bytes && psock->apply_bytes < tosend)
417   tosend = psock->apply_bytes;
[...]
443 sk_msg_return(sk, msg, tosend);
444 release_sock(sk);
446 origsize = msg->sg.size;
447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,
448                             msg, tosend, flags);
449 sent = origsize - msg->sg.size;
[...]
454 lock_sock(sk);
455 if (unlikely(ret < 0)) {
456   int free = sk_msg_free_nocharge(sk, msg);
458   if (!cork)
459     *copied -= free;
460 }
[...]
487 if (eval == __SK_REDIRECT)
488   sk_mem_charge(sk, tosend - sent);
[...]

When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,
the following warning will be reported:

------------[ cut here ]------------
WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0
Modules linked in:
CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ torvalds#43
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Workqueue: events sk_psock_destroy
RIP: 0010:inet_sock_destruct+0x190/0x1a0
RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206
RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800
RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900
RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0
R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400
R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100
FS:  0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
? __warn+0x89/0x130
? inet_sock_destruct+0x190/0x1a0
? report_bug+0xfc/0x1e0
? handle_bug+0x5c/0xa0
? exc_invalid_op+0x17/0x70
? asm_exc_invalid_op+0x1a/0x20
? inet_sock_destruct+0x190/0x1a0
__sk_destruct+0x25/0x220
sk_psock_destroy+0x2b2/0x310
process_scheduled_works+0xa3/0x3e0
worker_thread+0x117/0x240
? __pfx_worker_thread+0x10/0x10
kthread+0xcf/0x100
? __pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
---[ end trace 0000000000000000 ]---

In __SK_REDIRECT, a more concise way is delaying the uncharging after sent
bytes are finalized, and uncharge this value. When (ret < 0), we shall
invoke sk_msg_free.

Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,
we may miss uncharging (msg->sg.size - apply_bytes) bytes. The same
warning will be reported in selftest.

[...]
468 case __SK_DROP:
469 default:
470 sk_msg_free_partial(sk, msg, tosend);
471 sk_msg_apply_bytes(psock, tosend);
472 *copied -= (tosend + delta);
473 return -EACCES;
[...]

So instead of sk_msg_free_partial we can do sk_msg_free here.

Fixes: 604326b ("bpf, sockmap: convert to generic sk_msg interface")
Fixes: 8ec95b9 ("bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues")
Signed-off-by: Zijian Zhang <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: John Fastabend <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
klarasm pushed a commit to klarasm/linux that referenced this pull request Dec 3, 2024
The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging
tosend bytes, which is either msg->sg.size or a smaller value apply_bytes.

Potential problems with this strategy are as follows:

- If the actual sent bytes are smaller than tosend, we need to charge some
  bytes back, as in line 487, which is okay but seems not clean.

- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may
  miss uncharging (msg->sg.size - apply_bytes) bytes.

[...]
415 tosend = msg->sg.size;
416 if (psock->apply_bytes && psock->apply_bytes < tosend)
417   tosend = psock->apply_bytes;
[...]
443 sk_msg_return(sk, msg, tosend);
444 release_sock(sk);
446 origsize = msg->sg.size;
447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,
448                             msg, tosend, flags);
449 sent = origsize - msg->sg.size;
[...]
454 lock_sock(sk);
455 if (unlikely(ret < 0)) {
456   int free = sk_msg_free_nocharge(sk, msg);
458   if (!cork)
459     *copied -= free;
460 }
[...]
487 if (eval == __SK_REDIRECT)
488   sk_mem_charge(sk, tosend - sent);
[...]

When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,
the following warning will be reported:

------------[ cut here ]------------
WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0
Modules linked in:
CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ torvalds#43
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Workqueue: events sk_psock_destroy
RIP: 0010:inet_sock_destruct+0x190/0x1a0
RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206
RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800
RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900
RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0
R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400
R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100
FS:  0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
? __warn+0x89/0x130
? inet_sock_destruct+0x190/0x1a0
? report_bug+0xfc/0x1e0
? handle_bug+0x5c/0xa0
? exc_invalid_op+0x17/0x70
? asm_exc_invalid_op+0x1a/0x20
? inet_sock_destruct+0x190/0x1a0
__sk_destruct+0x25/0x220
sk_psock_destroy+0x2b2/0x310
process_scheduled_works+0xa3/0x3e0
worker_thread+0x117/0x240
? __pfx_worker_thread+0x10/0x10
kthread+0xcf/0x100
? __pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
---[ end trace 0000000000000000 ]---

In __SK_REDIRECT, a more concise way is delaying the uncharging after sent
bytes are finalized, and uncharge this value. When (ret < 0), we shall
invoke sk_msg_free.

Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,
we may miss uncharging (msg->sg.size - apply_bytes) bytes. The same
warning will be reported in selftest.

[...]
468 case __SK_DROP:
469 default:
470 sk_msg_free_partial(sk, msg, tosend);
471 sk_msg_apply_bytes(psock, tosend);
472 *copied -= (tosend + delta);
473 return -EACCES;
[...]

So instead of sk_msg_free_partial we can do sk_msg_free here.

Fixes: 604326b ("bpf, sockmap: convert to generic sk_msg interface")
Fixes: 8ec95b9 ("bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues")
Signed-off-by: Zijian Zhang <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: John Fastabend <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant