Skip to content
New issue

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

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update aliasing-test.c #34

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

Update aliasing-test.c #34

wants to merge 1 commit into from

Conversation

smeaime
Copy link

@smeaime smeaime commented May 18, 2013

i'm studying seminario de actualizacion at UCV, Greetings from Lima. by Marcelino Estrada

swarren pushed a commit to swarren/linux-tegra that referenced this pull request Oct 14, 2013
@suryasaimadhu
x86: Improve the printout of the SMP bootup CPU table
646e29a 
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
@bp3tk0v
x86/boot: Further compress CPUs bootup message
a17bce4 
Turn it into (for example):

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

and drop useless elements.

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

Signed-off-by: Borislav Petkov <[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]>
swarren pushed a commit to swarren/linux-tegra that referenced this pull request Oct 14, 2013
@gregkh
imx-drm: imx-drm-core: Fix circular locking dependency
c35d6a3 
Booting a mx6 with CONFIG_PROVE_LOCKING we get:

======================================================
[ INFO: possible circular locking dependency detected ]
3.12.0-rc4-next-20131009+ torvalds#34 Not tainted
-------------------------------------------------------
swapper/0/1 is trying to acquire lock:
 (&imx_drm_device->mutex){+.+.+.}, at: [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98

but task is already holding lock:
 (&crtc->mutex){+.+...}, at: [<802fe778>] drm_modeset_lock_all+0x40/0x54

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&crtc->mutex){+.+...}:
       [<800777d0>] __lock_acquire+0x18d4/0x1c24
       [<80077fec>] lock_acquire+0x68/0x7c
       [<805ead5c>] _mutex_lock_nest_lock+0x58/0x3a8
       [<802fec50>] drm_crtc_init+0x48/0xa8
       [<80457c88>] imx_drm_add_crtc+0xd4/0x144
       [<8045e2e8>] ipu_drm_probe+0x114/0x1fc
       [<80312278>] platform_drv_probe+0x20/0x50
       [<80310c68>] driver_probe_device+0x110/0x22c
       [<80310e20>] __driver_attach+0x9c/0xa0
       [<8030f218>] bus_for_each_dev+0x5c/0x90
       [<80310750>] driver_attach+0x20/0x28
       [<8031034c>] bus_add_driver+0xdc/0x1dc
       [<803114d8>] driver_register+0x80/0xfc
       [<80312198>] __platform_driver_register+0x50/0x64
       [<808172fc>] ipu_drm_driver_init+0x18/0x20
       [<800088c0>] do_one_initcall+0xfc/0x160
       [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
       [<805e2930>] kernel_init+0x10/0xec
       [<8000ea68>] ret_from_fork+0x14/0x2c

-> #1 (&dev->mode_config.mutex){+.+.+.}:
       [<800777d0>] __lock_acquire+0x18d4/0x1c24
       [<80077fec>] lock_acquire+0x68/0x7c
       [<805eb100>] mutex_lock_nested+0x54/0x3a4
       [<802fe758>] drm_modeset_lock_all+0x20/0x54
       [<802fead4>] drm_encoder_init+0x20/0x7c
       [<80457ae4>] imx_drm_add_encoder+0x88/0xec
       [<80459838>] imx_ldb_probe+0x344/0x4fc
       [<80312278>] platform_drv_probe+0x20/0x50
       [<80310c68>] driver_probe_device+0x110/0x22c
       [<80310e20>] __driver_attach+0x9c/0xa0
       [<8030f218>] bus_for_each_dev+0x5c/0x90
       [<80310750>] driver_attach+0x20/0x28
       [<8031034c>] bus_add_driver+0xdc/0x1dc
       [<803114d8>] driver_register+0x80/0xfc
       [<80312198>] __platform_driver_register+0x50/0x64
       [<8081722c>] imx_ldb_driver_init+0x18/0x20
       [<800088c0>] do_one_initcall+0xfc/0x160
       [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
       [<805e2930>] kernel_init+0x10/0xec
       [<8000ea68>] ret_from_fork+0x14/0x2c

-> #0 (&imx_drm_device->mutex){+.+.+.}:
       [<805e510c>] print_circular_bug+0x74/0x2e0
       [<80077ad0>] __lock_acquire+0x1bd4/0x1c24
       [<80077fec>] lock_acquire+0x68/0x7c
       [<805eb100>] mutex_lock_nested+0x54/0x3a4
       [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98
       [<80459a98>] imx_ldb_encoder_prepare+0x34/0x114
       [<802ef724>] drm_crtc_helper_set_mode+0x1f0/0x4c0
       [<802f0344>] drm_crtc_helper_set_config+0x828/0x99c
       [<802ff270>] drm_mode_set_config_internal+0x5c/0xdc
       [<802eebe0>] drm_fb_helper_set_par+0x50/0xb4
       [<802af580>] fbcon_init+0x490/0x500
       [<802dd104>] visual_init+0xa8/0xf8
       [<802df414>] do_bind_con_driver+0x140/0x37c
       [<802df764>] do_take_over_console+0x114/0x1c4
       [<802af65c>] do_fbcon_takeover+0x6c/0xd4
       [<802b2b30>] fbcon_event_notify+0x7c8/0x818
       [<80049954>] notifier_call_chain+0x4c/0x8c
       [<80049cd8>] __blocking_notifier_call_chain+0x50/0x68
       [<80049d10>] blocking_notifier_call_chain+0x20/0x28
       [<802a75f0>] fb_notifier_call_chain+0x1c/0x24
       [<802a9224>] register_framebuffer+0x188/0x268
       [<802ee994>] drm_fb_helper_initial_config+0x2bc/0x4b8
       [<802f118c>] drm_fbdev_cma_init+0x7c/0xec
       [<80817288>] imx_fb_helper_init+0x54/0x90
       [<800088c0>] do_one_initcall+0xfc/0x160
       [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
       [<805e2930>] kernel_init+0x10/0xec
       [<8000ea68>] ret_from_fork+0x14/0x2c

other info that might help us debug this:

Chain exists of:
  &imx_drm_device->mutex --> &dev->mode_config.mutex --> &crtc->mutex

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&crtc->mutex);
                               lock(&dev->mode_config.mutex);
                               lock(&crtc->mutex);
  lock(&imx_drm_device->mutex);

 *** DEADLOCK ***

6 locks held by swapper/0/1:
 #0:  (registration_lock){+.+.+.}, at: [<802a90bc>] register_framebuffer+0x20/0x268
 #1:  (&fb_info->lock){+.+.+.}, at: [<802a7a90>] lock_fb_info+0x20/0x44
 #2:  (console_lock){+.+.+.}, at: [<802a9218>] register_framebuffer+0x17c/0x268
 #3:  ((fb_notifier_list).rwsem){.+.+.+}, at: [<80049cbc>] __blocking_notifier_call_chain+0x34/0x68
 #4:  (&dev->mode_config.mutex){+.+.+.}, at: [<802fe758>] drm_modeset_lock_all+0x20/0x54
 #5:  (&crtc->mutex){+.+...}, at: [<802fe778>] drm_modeset_lock_all+0x40/0x54

In order to avoid this lockdep warning, remove the locking from
imx_drm_encoder_get_mux_id() and imx_drm_crtc_panel_format_pins().

Tested on a mx6sabrelite and mx53qsb.

Reported-by: Russell King <[email protected]>
Tested-by: Russell King <[email protected]>
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
swarren pushed a commit to swarren/linux-tegra that referenced this pull request May 1, 2014
@bebarino
clk: Fix double free due to devm_clk_register()
8489be7 
Now that clk_unregister() frees the struct clk we're
unregistering we'll free memory twice: first we'll call kfree()
in __clk_release() with an address kmalloc doesn't know about and
second we'll call kfree() in the devres layer. Remove the
allocation of struct clk in devm_clk_register() and let
clk_release() handle it. This fixes slab errors like:

=============================================================================
BUG kmalloc-128 (Not tainted): Invalid object pointer 0xed08e8d0
-----------------------------------------------------------------------------

Disabling lock debugging due to kernel taint
INFO: Slab 0xeec503f8 objects=25 used=15 fp=0xed08ea00 flags=0x4081
CPU: 2 PID: 73 Comm: rmmod Tainted: G    B         3.14.0-11032-g526e9c764381 torvalds#34
[<c0014be0>] (unwind_backtrace) from [<c0012240>] (show_stack+0x10/0x14)
[<c0012240>] (show_stack) from [<c04b74dc>] (dump_stack+0x70/0xbc)
[<c04b74dc>] (dump_stack) from [<c00f6778>] (slab_err+0x74/0x84)
[<c00f6778>] (slab_err) from [<c04b6278>] (free_debug_processing+0x2cc/0x31c)
[<c04b6278>] (free_debug_processing) from [<c04b6300>] (__slab_free+0x38/0x41c)
[<c04b6300>] (__slab_free) from [<c03931bc>] (clk_unregister+0xd4/0x140)
[<c03931bc>] (clk_unregister) from [<c02fb774>] (release_nodes+0x164/0x1d8)
[<c02fb774>] (release_nodes) from [<c02f8698>] (__device_release_driver+0x60/0xb0)
[<c02f8698>] (__device_release_driver) from [<c02f9080>] (driver_detach+0xb4/0xb8)
[<c02f9080>] (driver_detach) from [<c02f8480>] (bus_remove_driver+0x5c/0xc4)
[<c02f8480>] (bus_remove_driver) from [<c008c9b8>] (SyS_delete_module+0x148/0x1d8)
[<c008c9b8>] (SyS_delete_module) from [<c000ef80>] (ret_fast_syscall+0x0/0x48)
FIX kmalloc-128: Object at 0xed08e8d0 not freed

Fixes: fcb0ee6 (clk: Implement clk_unregister)
Cc: Jiada Wang <[email protected]>
Cc: Sylwester Nawrocki <[email protected]>
Cc: Kyungmin Park <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Mike Turquette <[email protected]>
Cc: [email protected]
ddstreet referenced this pull request in ddstreet/linux May 2, 2014
@hnaz
linux-next
3baca4f 
GIT bdd4c30bd51d9037bf66f22af3fb3e0ec7a69c51

commit 4985c32ee4241d1aba1beeac72294faa46aaff10
Author: Lan Tianyu <[email protected]>
Date:   Wed Apr 30 15:46:33 2014 +0800

    ACPI / processor: Fix failure of loading acpi-cpufreq driver
    
    According commit d640113fe (ACPI: processor: fix acpi_get_cpuid for UP
    processor),  BIOS may not provide _MAT or MADT tables and acpi_get_apicid()
    always returns -1. For these cases, original code will pass apic_id with
    vaule of -1 to acpi_map_cpuid() and it will check the acpi_id. If acpi_id
    is equal to zero, ignores apic_id and return zero for CPU0.
    
    Commit b981513 (ACPI / scan: bail out early if failed to parse APIC
    ID for CPU) changed the behavior. Return ENODEV when find apic_id is
    less than zero after calling acpi_get_apicid(). This causes acpi-cpufreq
    driver fails to be loaded on some machines. This patch is to fix it.
    
    Fixes: b981513f806d (ACPI / scan: bail out early if failed to parse APIC ID for CPU)
    References: https://bugzilla.kernel.org/show_bug.cgi?id=73781
    Cc: 3.14+ <[email protected]> # 3.14+
    Reported-and-tested-by: KATO Hiroshi <[email protected]>
    Reported-and-tested-by: Stuart Foster <[email protected]>
    Signed-off-by: Lan Tianyu <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit f2cc34cbaee306d8ea6ece0dcbbaf4c19444faf5
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 30 13:13:18 2014 +0200

    MIPS: math-emu: Don't needlessly pass a struct around.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 5ffb0e1858aa21ae1f5ded65430cd5e248463890
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 30 11:09:44 2014 +0200

    MIPS: math-emu: Reduce mipsMIPS bloat.
    
    Move microMIPS32_to_MIPS32() to a separate file which only gets built
    for mipsMIPS configurations; for other configurations the optimizer
    eleminates calls to microMIPS32_to_MIPS32().
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit da217aaa16d053ee3f99ee81fbe8a90a29de8a9f
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 30 11:21:55 2014 +0200

    MIPS: math-emu: Switch to using the MIPS rounding modes.
    
    Previously math-emu was using the IEEE-754 constants internally.  These
    were differing by having the constants for rounding to +/- infinity
    switched, so a conversion was necessary.  This would be entirely
    avoidable if the MIPS constants were used throughout, so get rid of
    the bloat.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 90e839aa32328adce70ecf7f8aecc8e329b18d45
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 30 01:17:19 2014 +0200

    MIPS: math-emu: Nuke alternative names for IEEE-754 rounding modes.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 4c6b4072da43920309df8dc4372bb61967b3e741
Author: Ralf Baechle <[email protected]>
Date:   Tue Apr 29 15:21:24 2014 +0200

    MIPS: Sort out mm_isBranchInstr.
    
    mm_isBranchInstr() did reside in the math emu code even though it logically
    is separate and also is used outside the math emu code.  In addition GCC 4.9.0
    leaves the following unnnecessarily bloated function body for a non-microMIPS
    configuration:
    
    <mm_isBranchInstr>:
        105c:       afa50004        sw      a1,4(sp)
        1060:       afa60008        sw      a2,8(sp)
        1064:       afa7000c        sw      a3,12(sp)
        1068:       03e00008        jr      ra
        106c:       00001021        move    v0,zero
    
    which stores arguments that are never going to be used on the stack frame.
    
    Move mm_isBranchInstr() from cp1emu.c to branch.c, then split mm_isBranchInstr()
    into a __mm_isBranchInstr() core and a mm_isBranchInstr() wrapper inline function
    which only invokes __mm_isBranchInstr() on microMIPS configurations.
    
    This shaves off 112 bytes off the kernel and improves code flow a bit.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 1972ff35bcb83355e9829a54226451bd3419de5b
Author: Ralf Baechle <[email protected]>
Date:   Tue Apr 29 01:49:24 2014 +0200

    MIPS: Diable MIPS16/microMIPS crap for platforms not supporting these ASEs.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit be2ad4ab594139a09c7a71972752a53bdd5a9541
Author: Ralf Baechle <[email protected]>
Date:   Mon Apr 28 22:34:01 2014 +0200

    MIPS: math-emu: Inline fpu_emulator_init_fpu()
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 205eed26395b15621ee27f535b142d4a30b5e2af
Author: Ralf Baechle <[email protected]>
Date:   Sat Apr 26 01:49:14 2014 +0200

    MIPS: math-emu: Cleanup coding style.
    
     o Only define variables in the outermost block
     o One empty line at most
     o Format comments as per CodingStyle
     o Update FSF address in licensing term comment
     o Spell FPU and MIPS in all capitals.
     o Remove ####-type of lines in comments.
     o Try to make things a bit most consistent between sp_*.c / dp_*.c files.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 716ead6c3d519e012e66b069a3ad70c4bfe5545f
Author: Ralf Baechle <[email protected]>
Date:   Fri Apr 25 15:48:40 2014 +0200

    MIPS: math-emu: Cleanup definition of structs describe sp/dp floats.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit d9d29fb7b97c41233036ea3f748e179b87765066
Author: Ralf Baechle <[email protected]>
Date:   Fri Apr 25 10:54:06 2014 +0200

    MIPS: math-emu: Rename get_rounding() functions.
    
    There are two version of get_rounding(), one for single precision, one
    for double precision.  Add a ieee754sp_ rsp. ieee754dp_ prefix for
    clarity.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit d8a30e453168fbf27366a0501561fab10a14483a
Author: Ralf Baechle <[email protected]>
Date:   Fri Apr 25 03:19:57 2014 +0200

    MIPS: math-emu: Get rid of the useless parts of exception handling.
    
    All it really did was throw a printk for no obvious reason.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 00102ccacf0b4ddedf920fd90936efc3bc28fdf8
Author: Ralf Baechle <[email protected]>
Date:   Fri Apr 25 01:52:46 2014 +0200

    MIPS: math-emu: Move various objects into an ar library.
    
    ieee754d.o contains only debug code and dp_sqrt.o and sp_sqrt.o contain
    code which for MIPS I/II/III systems we don't want to link.  Again the
    savings can be considerable for some systems:
    
    $ mips-linux-size --totals ieee754d.o dp_sqrt.o sp_sqrt.o
       text	   data	    bss	    dec	    hex	filename
       1624	      0	      0	   1624	    658	ieee754d.o
       2016	      0	      0	   2016	    7e0	dp_sqrt.o
        736	      0	      0	    736	    2e0	sp_sqrt.o
       4376	      0	      0	   4376	   1118	(TOTALS)
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit ba72c2bff9799daf98b9e41474830b14ae4f0235
Author: Ralf Baechle <[email protected]>
Date:   Fri Apr 25 00:40:42 2014 +0200

    MIPS: math-emu: Inline ieee754sp_issnan and ieee754dp_issnan.
    
    Shaves another 16 bytes off but more importantly avoids function calls.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 901615320d62a23f8fbf6066ea111bb919ae6d77
Author: Ralf Baechle <[email protected]>
Date:   Fri Apr 25 00:29:50 2014 +0200

    MIPS: math-emu: Remove unused code.
    
    Shrinks the FPU emulator by 4528 bytes.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 686c7831f0c9884682197f4963262251d0e59b72
Author: Ralf Baechle <[email protected]>
Date:   Tue Apr 22 17:11:01 2014 +0200

    MIPS: math-emu: Remove unused ieee754sp_bestnan() and ieee754dp_bestnan().
    
    Both are unused since lmo commit fdffbafbb38723618626c70ffdc6ff9175cdffa2
    [Lots of FPU bug fixes from Kjeld Borch Egevang.]
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit e9e6315f4c9e51dfba1d6d04a39a4d4203a18bd8
Author: Ralf Baechle <[email protected]>
Date:   Tue Apr 22 16:52:01 2014 +0200

    MIPS: math-emu: Inline ieee754dp_finite and ieee754dp_finite().
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 0efd4e5319ca8063c00d1c4abfe6af3976942006
Author: Ralf Baechle <[email protected]>
Date:   Tue Apr 22 16:33:07 2014 +0200

    MIPS: math-emu: Eleminate duplicate definitions of identical macros.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit ebce471716566929d7741d3749465e662b8b7eb6
Author: Ralf Baechle <[email protected]>
Date:   Tue Apr 22 16:02:03 2014 +0200

    MIPS: math-emu: Use SPSIGN() rather than DPSIGN() in ieee754sp_sub().
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 4736f6c82064c48d8e8fda544fdb755dd2d6e3a2
Author: Ralf Baechle <[email protected]>
Date:   Tue Apr 22 15:51:55 2014 +0200

    MIPS: math-emu: Replace DP_MBITS with DP_FBITS and SP_MBITS with SP_FBITS.
    
    Both were defined as 23 rsp. 52 though the mentissa is actually a bit more
    than the fraction.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit dd562af3b03c3ff4129c0b4ab962643935a5762c
Author: Ralf Baechle <[email protected]>
Date:   Tue Apr 22 13:31:24 2014 +0200

    MIPS: math-emu: Call ieee754di_xcpt, not ieee754si_xcpt in ieee754dp_cmp.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 28c80109e8ddd31a640786f119fd737fcc21d673
Author: Ralf Baechle <[email protected]>
Date:   Sun Apr 20 01:20:08 2014 +0200

    MIPS: math-emu: Cleanup stdarg usage including apparently bogus comment.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit ed51751f2a8c5070050e567e26471a1851af0f6a
Author: Ralf Baechle <[email protected]>
Date:   Sat Apr 19 23:01:34 2014 +0200

    MIPS: math-emu: Remove #if 1 and dead code from its #else branch.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 7d377570c86ec27db24e118b6db7e23c0c7dee30
Author: Ralf Baechle <[email protected]>
Date:   Sat Apr 19 14:20:54 2014 +0200

    MIPS: math-emu: Cleanup ieee754si_indef() / ieee754di_indef().
    
    LONG_LONG_MAX is a symbol defined in <limits.h> which may not be available
    so better rely on something provided by a kernel header.  While at it,
    turn these function-like macros into inline functions.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 47afdfb05fc1ada6dab0dce0b56318c46191237e
Author: Ralf Baechle <[email protected]>
Date:   Sat Apr 19 14:03:37 2014 +0200

    MIPS: math-emu: Convert debug printks to pr_debug getting.
    
    And another bunch of #ifdefs bite the dust.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 14806c44887eba0e08a82571a248bfa10d3d5ce0
Author: Ralf Baechle <[email protected]>
Date:   Sat Apr 19 13:18:08 2014 +0200

    MIPS: math-emu: Get rid of unuable extended precision support.
    
    No usable functionality and nothig does ever define IEEE854_XP anyway.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit cd4f463270109c1af32de2f252500832de3f542a
Author: Ralf Baechle <[email protected]>
Date:   Fri Apr 25 15:52:18 2014 +0200

    MIPS: IP22: This platform may come with either MIPS III or MIPS IV CPUs.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit f5d9f0d858c453177b65bf5c1fc4dc2bac60ec78
Author: Ralf Baechle <[email protected]>
Date:   Sat Apr 19 13:11:37 2014 +0200

    MIPS: math-emu: Remove most ifdefery.
    
    Most of these tests should be runtime tests.  This also finally means
    that on a MIPS III systems MIPS IV opcodes are going to result in an
    exception as they're supposed to.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 77780b5f2b07ea492b116d4b6869763bb40691dc
Author: Ralf Baechle <[email protected]>
Date:   Sat Apr 19 00:36:32 2014 +0200

    MIPS: math-emu: Turn macros into functions where possible.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 9285476701712dd9c10fd5b0ac6b149d87a576cc
Author: Ralf Baechle <[email protected]>
Date:   Sat Apr 19 00:15:40 2014 +0200

    MIPS: math-emu: Harden ieee754int.h against multiple inclusion.
    
    The header file had no include guards; this only happened to work because
    the file only contains macro definitions and protypes.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 25c5450fa5de273285c3ffece87e962432984b3f
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 11:00:12 2014 +0200

    MIPS: math-emu: Reformat code according to coding style.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit ef3b11ea239ba6b5cc8ffc6abea54d9af27d4565
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 02:46:11 2014 +0200

    MIPS: math-emu: Move all debug fs code to a separate file.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit c387da86eb331e1b60c97023d8d01c8a9adeb816
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 02:24:08 2014 +0200

    MIPS: math-emu: Remove fine example of cargo cult programming.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 245d8273576c9abc0d8114eb8fe6899ea4f90674
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 02:09:53 2014 +0200

    MIPS: math-emu: Header file weeding.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 06d38d9c0764cc47cdbee808f657726d90a66ea9
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 02:09:04 2014 +0200

    MIPS: branch: Make inclusion of <asm/branch.h> safe.
    
    It was relying on other headers having been included before.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit b1bd59690e8a31303ae68f00ef88d25b27a3a18e
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 01:59:03 2014 +0200

    MIPS: math-emu: Use helpers to manipulate CAUSEF_BD flag.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 9266256b4b17a59937171516e8e0990df74a4e96
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 01:52:32 2014 +0200

    MIPS: branch: New helpers to modify branch delay slot flag in struct pt_regs
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit a7375a04fdd80fad105fc4394e2df1400f9547c2
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 01:31:11 2014 +0200

    MIPS: math-emu: Get rid of typedefs.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit a43bbf810e9d5d07902b958085b3bb9da938f836
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 01:16:02 2014 +0200

    MIPS: math-emu: Use English spelling of `constant' rather than Danish.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 4bed0701d3f817c5727a7f7c693e50cbd4f85854
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 00:47:59 2014 +0200

    MIPS: math-emu: Mark exception handling functions as __cold.
    
    Optimizes the code flow and shaves of half a percent of the math-emu
    code size.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 2055b05e09d9afb04a1b0a65e2e092a53b52b14a
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 00:40:02 2014 +0200

    MIPS: math-emu: Use __BITFIELD_FIELD to eleminate redundant definitions.
    
    Union _ieee754sp was even duplicated even though there are no endian
    dependencies in it all.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 3a8e0f1b5c26ec41dded7e3b870e6f079f130ee6
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 00:39:02 2014 +0200

    MIPS: Move definition of __BITFIELD_FIELD to sharable header.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 96bc2c97ecf70f51b70fe201b27caff3f2543f11
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 00:31:51 2014 +0200

    MIPS: inst.h: Rename BITFIELD_FIELD to __BITFIELD_FIELD.
    
    <uapi/asm/inst.h> is exported to userland so the macro name BITFIELD_FIELD
    pollutes the namespace.  Prefix the name with __ fixes this.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit 2c9b25c59796e9e5f01193d15dde501e9af59714
Author: Christian Engelmayer <[email protected]>
Date:   Sat Feb 8 20:02:21 2014 +0100

    drm: qxl: Remove unused device pointer
    
    Remove occurrences of unused struct qxl_device pointer in functions
    qxl_ttm_fault() and qxl_init_mem_type().
    
    Detected by Coverity: CID 1019128, CID 1019129.
    
    Signed-off-by: Christian Engelmayer <[email protected]>
    Signed-off-by: Dave Airlie <[email protected]>

commit 3723aaa123147dc777bf86d7104b8fc4b3b56ff3
Author: Ralf Baechle <[email protected]>
Date:   Wed Apr 16 00:31:51 2014 +0200

    MIPS: inst.h: Rename BITFIELD_FIELD to __BITFIELD_FIELD.
    
    <uapi/asm/inst.h> is exported to userland so the macro name BITFIELD_FIELD
    pollutes the namespace.  Prefix the name with __ fixes this.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit d7f369636745788e64ac217f610dad381fb5431c
Author: Ralf Baechle <[email protected]>
Date:   Fri Apr 11 18:28:00 2014 +0200

    MIPS: Remove file missed when removing rm9k support a while ago.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit a68ce6507a4545f1fc83c035603234d7898a0dc3
Author: Aaro Koskinen <[email protected]>
Date:   Thu Apr 3 22:24:01 2014 +0300

    MIPS/loongson2_cpufreq: Fix CPU clock rate setting
    
    Loongson2 has been using (incorrectly) kHz for cpu_clk rate. This has
    been unnoticed, as loongson2_cpufreq was the only place where the rate
    was set/get. After commit 652ed95d5fa6074b3c4ea245deb0691f1acb6656
    (cpufreq: introduce cpufreq_generic_get() routine) things however broke,
    and now loops_per_jiffy adjustments are incorrect (1000 times too long).
    The patch fixes this by changing cpu_clk rate to Hz.
    
    Signed-off-by: Aaro Koskinen <[email protected]>
    Cc: [email protected]
    Cc: Rafael J. Wysocki <[email protected]>
    Cc: Viresh Kumar <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Cc: Aaro Koskinen <[email protected]>
    Patchwork: https://patchwork.linux-mips.org/patch/6678/
    Signed-off-by: Ralf Baechle <[email protected]>

commit d3b8acbdaaaebe2dd85d96f4c49b63bf6cc35896
Author: Paul Bolle <[email protected]>
Date:   Thu Apr 3 11:10:20 2014 +0200

    MIPS: Loongson: No need to select GENERIC_HARDIRQS_NO__DO_IRQ
    
    Commit 0e476d91244e ("MIPS: Loongson: Add Loongson-3 Kconfig options")
    added "select GENERIC_HARDIRQS_NO__DO_IRQ". But the Kconfig symbol
    GENERIC_HARDIRQS_NO__DO_IRQ was already removed in v2.6.38, so that
    select is a nop. Drop it.
    
    Signed-off-by: Paul Bolle <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Patchwork: https://patchwork.linux-mips.org/patch/6677/
    Signed-off-by: Ralf Baechle <[email protected]>

commit fa3357d9e109352f42c231fc3833e10951845185
Author: Maciej W. Rozycki <[email protected]>
Date:   Fri Apr 4 03:32:54 2014 +0100

    MIPS: csum_partial.S CPU_DADDI_WORKAROUNDS bug fix
    
    This change reverts most of commit
    60724ca59eda766a30be57aec6b49bc3e2bead91 [MIPS: IP checksums: Remove
    unncessary .set pseudos] that introduced warnings with the
    CPU_DADDI_WORKAROUNDS option set:
    
    arch/mips/lib/csum_partial.S: Assembler messages:
    arch/mips/lib/csum_partial.S:467: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:467: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:467: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:467: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:467: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:467: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:467: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:467: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:467: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:467: Warning: used $3 with ".set at=$3"
    [...]
    arch/mips/lib/csum_partial.S:577: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:577: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:577: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:601: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:601: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:601: Warning: used $3 with ".set at=$3"
    arch/mips/lib/csum_partial.S:601: Warning: used $3 with ".set at=$3"
    [and so on, and so on...]
    
    The warnings are benign and good code is produced regardless because no
    macros that'd use the assembler's temporary register are involved, however
    the `.set noat' directives removed by the commit referred are crucial to
    guarantee this is still going to be the case after any changes in the
    future.  Therefore they need to be brought back to place which this
    change does.
    
    Signed-off-by: Maciej W. Rozycki <[email protected]>
    Cc: [email protected]
    Patchwork: https://patchwork.linux-mips.org/patch/6686/
    Signed-off-by: Ralf Baechle <[email protected]>

commit 8faecff616e986f26651fe7d762d3a7ef52a659c
Author: Maciej W. Rozycki <[email protected]>
Date:   Fri Apr 4 03:32:29 2014 +0100

    MIPS: __strncpy_from_user_asm CPU_DADDI_WORKAROUNDS bug fix
    
    This corrects assembler warnings and broken code generated in
    __strncpy_from_user_asm:
    
    arch/mips/lib/strncpy_user.S: Assembler messages:
    arch/mips/lib/strncpy_user.S:52: Warning: Macro instruction expanded into
    multiple instructions in a branch delay slot
    
    with the CPU_DADDI_WORKAROUNDS option set.  The function schedules delay
    slots manually where there is really no need to as GAS is happy to do it
    all itself, so undo it all and remove `.set noreorder'.
    
    Signed-off-by: Maciej W. Rozycki <[email protected]>
    Cc: [email protected]
    Patchwork: https://patchwork.linux-mips.org/patch/6685/
    Signed-off-by: Ralf Baechle <[email protected]>

commit 32da28eff6b732b64d4ab4c3d511e7fe718ff3d9
Author: Maciej W. Rozycki <[email protected]>
Date:   Tue Apr 1 00:57:28 2014 +0100

    MIPS: __delay CPU_DADDI_WORKAROUNDS bug fix
    
    With CPU_DADDI_WORKAROUNDS enabled __delay assembles with a macro in a
    branch delay slot:
    
    {standard input}: Assembler messages:
    {standard input}:18: Warning: Macro instruction expanded into multiple
    instructions in a branch delay slot
    
    and broken code results:
    
    0000000000000000 <__delay>:
       0:	1480ffff 	bnez	a0,0 <__delay>
       4:	24010001 	li	at,1
       8:	0081202f 	dsubu	a0,a0,at
       c:	03e00008 	jr	ra
      10:	00000000 	nop
      14:	00000000 	nop
    
    Consequently the function loops indefinitely, showing up prominently as a
    hang in the delay loop calibration at bootstrap.
    
    This change corrects the problem by forcing the immediate 1 into a
    register while keeping code produced identical where CPU_DADDI_WORKAROUNDS
    is disabled.
    
    Signed-off-by: Maciej W. Rozycki <[email protected]>
    Cc: [email protected]
    Patchwork: https://patchwork.linux-mips.org/patch/6669/
    Signed-off-by: Ralf Baechle <[email protected]>

commit 5da3e85530328543c66313d4dbbb3b426f838eb5
Author: Maciej W. Rozycki <[email protected]>
Date:   Tue Apr 1 00:14:41 2014 +0100

    MIPS: DEC/SNI: O32 wrapper stack switching fixes
    
    Commit 231a35d37293ab88d325a9cb94e5474c156282c0 [[MIPS] RM: Collected
    changes] broke DECstation support by introducing an incompatible copy of
    arch/mips/dec/prom/call_o32.S in arch/mips/fw/lib/, built unconditionally.
    The copy happens to land earlier of the two among the modules used in the
    link and is therefore chosen for the DECstation rather than the intended
    original.  As a result random kernel data is corrupted because a pointer
    to the "%s" formatted output template is used as a temporary stack pointer
    rather than being passed down to prom_printf.  This also explains why
    prom_printf still works, up to a point -- the next argument is the actual
    string to output so it works just fine as the output template until enough
    kernel data has been corrupted to cause a crash.
    
    This change adjusts the modified wrapper in arch/mips/fw/lib/call_o32.S to
    let callers request no stack switching by passing a null temporary stack
    pointer in $a1, reworks the DECstation callers to work with the updated
    interface and removes the old copy from arch/mips/dec/prom/call_o32.S.  A
    few minor readability adjustments are included as well, most importantly
    O32_SZREG is now used throughout where applicable rather than hardcoded
    multiplies of 4 and $fp is used to access the argument save area as a more
    usual register to operate the stack with rather than $s0.
    
    Finally an update is made to the temporary stack space used by the SNI
    platform to guarantee 8-byte alignment as per o32 requirements.
    
    Signed-off-by: Maciej W. Rozycki <[email protected]>
    Cc: Thomas Bogendoerfer <[email protected]>
    Cc: [email protected]
    Patchwork: https://patchwork.linux-mips.org/patch/6668/
    Signed-off-by: Ralf Baechle <[email protected]>

commit 54777d14e2ab5703c212ef0a9913db76d03f158d
Author: Maciej W. Rozycki <[email protected]>
Date:   Mon Mar 31 23:51:30 2014 +0100

    MIPS: DEC: Bus error handler <asm/cpu-type.h> fixes
    
    Commit 69f24d1784b631b81a54eb57c49bf46536dd2382 [MIPS: Optimize
    current_cpu_type() for better code.] missed an update for two DECstation
    bus error support files that now do not build, this is a fix.
    
    Signed-off-by: Maciej W. Rozycki <[email protected]>
    Cc: [email protected]
    Patchwork: https://patchwork.linux-mips.org/patch/6667/
    Signed-off-by: Ralf Baechle <[email protected]>

commit c5a8cf7a7ad5ab022660015597380b554f4358e5
Author: Ralf Baechle <[email protected]>
Date:   Thu Apr 3 13:29:06 2014 +0200

    MAINTAINERS: TURBOchannel: Update entry
    
    Add mailing list and patchwork URL so patches now have a defined path.
    Also add myself as a TURBOchannel maintainer.  However Maciej is going
    to the the resident TURBOchannel guru.
    
    Signed-off-by: Ralf Baechle <[email protected]>
    Acked-by: "Maciej W. Rozycki" <[email protected]>

commit 8c6dbb589be1fe83bd0d8db8681a37e9d2f17bd9
Author: Ralf Baechle <[email protected]>
Date:   Thu Apr 3 13:14:05 2014 +0200

    Revert "MIPS: MT: proc: Add support for printing VPE and TC ids"
    
    Reverts commit 795038a6910937fa167d47f6f6183db0eb8fb706 because
    d6d3c9afaab47418ab2d7f874fb8aeac1f067104 provides the same functionality
    in a more generic way.  Both patches applied however means that the
    VPE and TC IDs get printed twice currently.

commit b87577b7c768683736eea28f70779e8c75b4df62
Author: Dave Airlie <[email protected]>
Date:   Thu May 1 09:26:53 2014 +1000

    drm: try harder to avoid regression when merging mode bits
    
    For QXL hw we really want the bits to be replaced as we change
    the preferred mode on the fly, and the same goes for virgl when
    I get to it, however the original fix for this seems to have caused
    a wierd regression on Intel G33 that in a stunning display of failure
    at opposition to his normal self, Daniel failed to diagnose.
    
    So we are left doing this, ugly ugly ugly ugly, Daniel you fixed
    that G33 yet?, ugly, ugly.
    
    Tested-by: Marc-André Lureau <[email protected]>
    Signed-off-by: Dave Airlie <[email protected]>

commit 28c015a9daabe4ed3aeb0ccf669a3f1c2b8b81d5
Author: Murali Karicheri <[email protected]>
Date:   Thu Mar 20 22:08:32 2014 +0200

    mtd: davinci-nand: disable subpage write for keystone-nand
    
    Sub page write doesn't work because of hw issue in controller found on
    Keystone SOCs. AEMIF controller is also used on DaVinci SOCs which
    don't seems to have any issue. So add "ti,keysone-nand" compatible
    to nand driver in order to set NAND_NO_SUBPAGE_WRITE option.
    
    Cc: Warner Losh <[email protected]>
    Signed-off-by: Murali Karicheri <[email protected]>
    Signed-off-by: Ivan Khoronzhuk <[email protected]>
    Acked-by: Santosh Shilimkar <[email protected]>
    Signed-off-by: Brian Norris <[email protected]>

commit 5a4e58bc693f04aa650219784e5e339e0db6b902
Author: Liu Ping Fan <[email protected]>
Date:   Thu Nov 21 10:17:54 2013 +0800

    powerpc/mm: use macro PGTABLE_EADDR_SIZE instead of digital
    
    In case of extending the eaddr in future, use this macro
    PGTABLE_EADDR_SIZE to ease the maintenance of the code.
    
    Signed-off-by: Liu Ping Fan <[email protected]>
    Signed-off-by: Benjamin Herrenschmidt <[email protected]>

commit d5b35cffe3d3c2bc297b7c1fb997a6139de02e12
Author: Alistair Popple <[email protected]>
Date:   Mon Feb 24 18:00:56 2014 +1100

    ppc476: Enable a linker work around for IBM errata #46
    
    This patch adds an option to enable a work around for an icache bug on
    476 that can cause execution of stale instructions when falling
    through pages (IBM errata #46). It requires a recent version of
    binutils which supports the --ppc476-workaround option.
    
    The work around enables the appropriate linker options and ensures
    that all module output sections are aligned to 4K page boundaries. The
    work around is only required when building modules.
    
    Signed-off-by: Alistair Popple <[email protected]>
    Signed-off-by: Benjamin Herrenschmidt <[email protected]>

commit e2c37d908336dc27c8b405f063c2a163124947fa
Author: Alistair Popple <[email protected]>
Date:   Thu Mar 6 14:52:28 2014 +1100

    powerpc: Added PCI MSI support using the HSTA module
    
    The PPC476GTR SoC supports message signalled interrupts (MSI) by writing
    to special addresses within the High Speed Transfer Assist (HSTA) module.
    
    This patch adds support for PCI MSI with a new system device. The DMA
    window is also updated to allow access to the entire 42-bit address range
    to allow PCI devices write access to the HSTA module.
    
    Signed-off-by: Alistair Popple <[email protected]>
    Signed-off-by: Benjamin Herrenschmidt <[email protected]>

commit 2a2c74b2efcb1a0ca3fdcb5fbb96ad8de6a29177
Author: Alistair Popple <[email protected]>
Date:   Thu Mar 6 14:52:27 2014 +1100

    IBM Akebono: Add the Akebono platform
    
    This patch adds support for the IBM Akebono board.
    
    Signed-off-by: Alistair Popple <[email protected]>
    Signed-off-by: Benjamin Herrenschmidt <[email protected]>

commit 6b11930f726c1d8a7c054f7a293621bce4c684c5
Author: Alistair Popple <[email protected]>
Date:   Thu Mar 6 14:52:26 2014 +1100

    IBM Currituck: Clean up board specific code before adding Akebono code
    
    The IBM Akebono code uses the same initialisation functions as the
    earlier Currituck board. Rather than create a copy of this code for
    Akebono we will instead integrate support for it into the same file as
    the Currituck code.
    
    This patch just renames the board support file and updates the Makefile.
    
    Signed-off-by: Alistair Popple <[email protected]>
    Signed-off-by: Benjamin Herrenschmidt <[email protected]>

commit 983d8a6dda1d477f3ffa23a04cc2fa4d66fd93d1
Author: Tony Breeds <[email protected]>
Date:   Wed Mar 12 19:17:07 2014 +1100

    powerpc/le: Show the endianess of the LPAR under PowerVM.
    
    Signed-off-by: Tony Breeds <[email protected]>
    Signed-off-by: Benjamin Herrenschmidt <[email protected]>

commit 9048e648bc22d7b59093f8ca1978c5767893aaa5
Author: Alexander Graf <[email protected]>
Date:   Tue Apr 1 15:46:05 2014 +0200

    powerpc: Use 64k io pages when we never see an HEA
    
    When we never get around to seeing an HEA ethernet adapter, there's
    no point in restricting ourselves to 4k IO page size.
    
    This speeds up IO maps when CONFIG_IBMEBUS is disabled.
    
    [ Updated the test to also lift the restriction on arch 2.07
      (Power 8) which cannot have an HEA
     -- BenH ]
    
    Signed-off-by: Alexander Graf <[email protected]>
    Signed-off-by: Benjamin Herrenschmidt <[email protected]>
    
    foo

commit 605ee08ffa84e385e11ca85346d4fa7892aebc76
Author: Helge Deller <[email protected]>
Date:   Wed Apr 30 23:26:02 2014 +0200

    parisc,metag: Do not hardcode maximum userspace stack size
    
    This patch affects only architectures where the stack grows upwards
    (currently parisc and metag only). On those do not hardcode the maximum
    initial stack size to 1GB, but make it configurable via a config option.
    
    The main problem with the hardcoded stack size is, that we have two
    memory regions which grow upwards: stack and heap. To keep most of the
    memory available for heap in a flexmap memoy layout, it makes no sense
    to hard allocate up to 1GB of the memory for stack which can't be used
    as heap then.
    
    This patch makes the stack size configurable and uses 80MB as default
    value which has been in use during the last few years on parisc and
    which didn't showed any problems yet.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: John David Anglin <[email protected]>

commit a8d22396302b7e4e5f0a594c1c1594388c29edaf
Author: Rafael J. Wysocki <[email protected]>
Date:   Wed Apr 30 22:36:33 2014 +0200

    PNP / ACPI: Do not return errors if _DIS or _SRS are not present
    
    The ACPI PNP subsystem returns errors from pnpacpi_set_resources()
    and pnpacpi_disable_resources() if the _SRS or _DIS methods are not
    present, respectively, but it should not do that, because those
    methods are optional.  For this reason, modify pnpacpi_set_resources()
    and pnpacpi_disable_resources(), respectively, to ignore missing _SRS
    or _DIS.
    
    This problem has been uncovered by commit 202317a573b2 (ACPI / scan:
    Add acpi_device objects for all device nodes in the namespace) and
    manifested itself by causing serial port suspend to fail on some
    systems.
    
    Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
    References: https://bugzilla.kernel.org/show_bug.cgi?id=74371
    Reported-by: wxg4net <[email protected]>
    Reported-and-tested-by: <[email protected]>
    Cc: 3.14+ <[email protected]> # 3.14+
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 22041fb05b66387b2854f789d1e1f55c7d07b4f4
Author: KY Srinivasan <[email protected]>
Date:   Wed Apr 30 11:58:25 2014 -0700

    hyperv: Properly handle checksum offload
    
    Do checksum offload only if the client of the driver wants checksum to be
    offloaded.
    
    In V1 version of this patch, I  addressed comments from
    Stephen Hemminger <[email protected]> and
    Eric Dumazet <[email protected]>.
    
    In this version of the patch I have addressed comments from
    David Miller.
    
    This patch fixes a bug that is exposed in gateway scenarios.
    
    Signed-off-by: K. Y. Srinivasan <[email protected]>
    Reviewed-by: Haiyang Zhang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 6ce29b0e2a04ea85617cd21099af67449a76f589
Author: Claudiu Manoil <[email protected]>
Date:   Wed Apr 30 14:27:21 2014 +0300

    gianfar: Avoid unnecessary reg accesses in adjust_link()
    
    For phy devices that don't issue interrupts upon link
    state changes, phylib polls the link state resulting in
    repeated calls to adjust_link(), even if the link state
    didn't change.  As a result, some mac registers are
    repeatedly read and written with the same values, which
    is not ok.
    
    To fix this, adjust_link() has been refactored to check
    first whether the link state has changed and to take action
    only if needed, updating mac registers and local state
    variables.  The 'new_state' local flag, set if one of the
    link params changed (link, speed or duplex), has been
    rendered useless and removed by this refactoring.
    
    Signed-off-by: Claudiu Manoil <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 0cda345d1b2201dd15591b163e3c92bad5191745
Author: Liu Yu <[email protected]>
Date:   Wed Apr 30 17:34:09 2014 +0800

    tcp_cubic: fix the range of delayed_ack
    
    commit b9f47a3aaeab (tcp_cubic: limit delayed_ack ratio to prevent
    divide error) try to prevent divide error, but there is still a little
    chance that delayed_ack can reach zero. In case the param cnt get
    negative value, then ratio+cnt would overflow and may happen to be zero.
    As a result, min(ratio, ACK_RATIO_LIMIT) will calculate to be zero.
    
    In some old kernels, such as 2.6.32, there is a bug that would
    pass negative param, which then ultimately leads to this divide error.
    
    commit 5b35e1e6e9c (tcp: fix tcp_trim_head() to adjust segment count
    with skb MSS) fixed the negative param issue. However,
    it's safe that we fix the range of delayed_ack as well,
    to make sure we do not hit a divide by zero.
    
    CC: Stephen Hemminger <[email protected]>
    Signed-off-by: Liu Yu <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Acked-by: Neal Cardwell <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit e5744fe9d262d11131916d04ea79ea539fe296c0
Author: Brendan Hickey <[email protected]>
Date:   Wed Apr 30 10:24:38 2014 +0200

    bpf_dbg: fix wrong register usage
    
    The AND instruction is erroneously using the X register instead
    of the K register.
    
    Signed-off-by: Brendan Hickey <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit f114890cdf84d753f6b41cd0cc44ba51d16313da
Author: Vlad Yasevich <[email protected]>
Date:   Tue Apr 29 10:09:51 2014 -0400

    Revert "macvlan : fix checksums error when we are in bridge mode"
    
    This reverts commit 12a2856b604476c27d85a5f9a57ae1661fc46019.
    The commit above doesn't appear to be necessary any more as the
    checksums appear to be correctly computed/validated.
    
    Additionally the above commit breaks kvm configurations where
    one VM is using a device that support checksum offload (virtio) and
    the other VM does not.
    In this case, packets leaving virtio device will have CHECKSUM_PARTIAL
    set.  The packets is forwarded to a macvtap that has offload features
    turned off.  Since we use CHECKSUM_UNNECESSARY, the host does does not
    update the checksum and thus a bad checksum is passed up to
    the guest.
    
    CC: Daniel Lezcano <[email protected]>
    CC: Patrick McHardy <[email protected]>
    CC: Andrian Nord <[email protected]>
    CC: Eric Dumazet <[email protected]>
    CC: Michael S. Tsirkin <[email protected]>
    CC: Jason Wang <[email protected]>
    Signed-off-by: Vlad Yasevich <[email protected]>
    Acked-by: Michael S. Tsirkin <[email protected]>
    Acked-by: Jason Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit cbdb04279ccaefcc702c8757757eea8ed76e50cf
Author: Vlad Yasevich <[email protected]>
Date:   Tue Apr 29 10:09:50 2014 -0400

    mactap: Fix checksum errors for non-gso packets in bridge mode
    
    The following is a problematic configuration:
    
     VM1: virtio-net device connected to macvtap0@eth0
     VM2: e1000 device connect to macvtap1@eth0
    
    The problem is is that virtio-net supports checksum offloading
    and thus sends the packets to the host with CHECKSUM_PARTIAL set.
    On the other hand, e1000 does not support any acceleration.
    
    For small TCP packets (and this includes the 3-way handshake),
    e1000 ends up receiving packets that only have a partial checksum
    set.  This causes TCP to fail checksum validation and to drop
    packets.  As a result tcp connections can not be established.
    
    Commit 3e4f8b787370978733ca6cae452720a4f0c296b8
    	macvtap: Perform GSO on forwarding path.
    fixes this issue for large packets wthat will end up undergoing GSO.
    This commit adds a check for the non-GSO case and attempts to
    compute the checksum for partially checksummed packets in the
    non-GSO case.
    
    CC: Daniel Lezcano <[email protected]>
    CC: Patrick McHardy <[email protected]>
    CC: Andrian Nord <[email protected]>
    CC: Eric Dumazet <[email protected]>
    CC: Michael S. Tsirkin <[email protected]>
    CC: Jason Wang <[email protected]>
    Signed-off-by: Vlad Yasevich <[email protected]>
    Acked-by: Jason Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit fc9f35010641ea85dd19d144b86cdd93156f1a1e
Author: Eric Dumazet <[email protected]>
Date:   Mon Apr 28 22:00:29 2014 -0700

    tcp: increment retransmit counters in tlp and fast open
    
    Both TLP and Fast Open call __tcp_retransmit_skb() instead of
    tcp_retransmit_skb() to avoid changing tp->retrans_out.
    
    This has the side effect of missing SNMP counters increments as well
    as tcp_info tcpi_total_retrans updates.
    
    Fix this by moving the stats increments of into __tcp_retransmit_skb()
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Acked-by: Nandita Dukkipati <[email protected]>
    Acked-by: Neal Cardwell <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 3dc638d13aced7baad40517a3d70b3b43bf6b90f
Author: Byungho An <[email protected]>
Date:   Tue Apr 29 13:15:27 2014 +0900

    net: sxgbe: Added set function for interrupt on complete
    
    This patch adds set_rx_int_on_com function for interrupt when
    dma is completed.
    
    Signed-off-by: Byungho An <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 325b94f7e63080f3e371e35f063a8be138c1873b
Author: Byungho An <[email protected]>
Date:   Tue Apr 29 13:15:17 2014 +0900

    net: sxgbe: Added rxqueue enable function
    
    This patch adds rxqueue enable function according to number of rxqueue
    and adds rxqueue disable function for removing.
    
    Signed-off-by: Byungho An <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 0a0347b1e65d0757024d9db0ffdeafb41a9d14f4
Author: Byungho An <[email protected]>
Date:   Tue Apr 29 13:15:15 2014 +0900

    net: sxgbe: sw reset moved to probe function
    
    This patch moves sw reset to probe function because
    sw reset is needed early stage before open function.
    
    Signed-off-by: Byungho An <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit d2e752db6d05374a35dddb2e17864fe310fbcf69
Author: Roland Dreier <[email protected]>
Date:   Mon Apr 28 17:36:20 2014 -0700

    cxgb4: Decode PCIe Gen3 link speed
    
    Add handling for " 8 GT/s" in print_port_info().
    
    Signed-off-by: Roland Dreier <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 652f99ead8319941216c64d7f92c8dcdc9b95970
Author: Tobias Klauser <[email protected]>
Date:   Mon Apr 28 23:23:13 2014 +0200

    Altera TSE: Add missing include to silence sparse warnings
    
    This fixes the following sparse warnings:
    
    drivers/net/ethernet/altera/altera_msgdma.c:23:5: warning: symbol 'msgdma_initialize' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:28:6: warning: symbol 'msgdma_uninitialize' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:32:6: warning: symbol 'msgdma_reset' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:77:6: warning: symbol 'msgdma_disable_rxirq' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:83:6: warning: symbol 'msgdma_enable_rxirq' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:89:6: warning: symbol 'msgdma_disable_txirq' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:95:6: warning: symbol 'msgdma_enable_txirq' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:101:6: warning: symbol 'msgdma_clear_rxirq' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:107:6: warning: symbol 'msgdma_clear_txirq' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:114:5: warning: symbol 'msgdma_tx_buffer' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:129:5: warning: symbol 'msgdma_tx_completions' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:154:5: warning: symbol 'msgdma_add_rx_desc' was not declared. Should it be static?
    drivers/net/ethernet/altera/altera_msgdma.c:181:5: warning: symbol 'msgdma_rx_status' was not declared. Should it be static?
    
    Signed-off-by: Tobias Klauser <[email protected]>
    Acked-by: Vince Bridgers <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 1b4448815ee746f878ca4c6b8fffa23441f6d16c
Author: Tobias Klauser <[email protected]>
Date:   Mon Apr 28 23:23:01 2014 +0200

    Altera TSE: Fix DMA secriptor length initialization
    
    sgdma_descrip is a function name as well as the name of a struct. In
    sgdma_initialize(), we should initialize the descriptor length field
    with the actual length of a descriptor not with the size of the
    function. In order to prevent such things from happening in the future,
    rename the function to sgdma_setup_descrip().
    
    Found by sparse which yields the following warning:
    
    drivers/net/ethernet/altera/altera_sgdma.c:74:30: warning: expression using sizeof on a function
    
    Signed-off-by: Tobias Klauser <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit ec4a340789be16831ae96be5f7552238a7a6e903
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:35 2014 +0200

    drbd: use list_first_entry_or_null in first_peer_device/first_connection
    
    If there are no peer_devices or connections, I'd rather have NULL
    than some "arbitrary" address pretending to point to a struct.
    
    Helps to avoid hard to debug symptoms, in case we ever try to use
    and dereference a drbd_connection or drbd_peer_device
    where we in fact don't have any connection at all.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit babea49ebe010d0a533b5db20fa63c327402a71c
Author: Philipp Reisner <[email protected]>
Date:   Mon Apr 28 18:43:34 2014 +0200

    drbd: Allow attaching of a newly created device to any backing device
    
    A newly created device was never exposed before, i.e. has a
    exposed_data_uuid of 0. Then it is valid to attach to any current_uuid
    of a backing device (of course also to a newly created one (4))
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 02df6fe145715f1d3858c0c65aed991f148b70b4
Author: Philipp Reisner <[email protected]>
Date:   Mon Apr 28 18:43:33 2014 +0200

    drbd: Test cstate while holding req_lock
    
    In case a connection transitions into C_TIMEOUT within the timer
    function (request_timer_fn()) we need to make sure that the receiver
    thread (potentially running on a different CPU) sees the updated
    cstate later on.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit c1b3156f121fd301191e0b4c5fa2fec42cd17871
Author: Philipp Reisner <[email protected]>
Date:   Mon Apr 28 18:43:32 2014 +0200

    drbd: use blk_set_stacking_limits()
    
    ...instead directly assigning to q->limits.discard_zeroes_data
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 08535466bce6bd91320990b9a614d52a3dc0f21d
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:31 2014 +0200

    drbd: evaluate disk and network timeout on different requests
    
    Just because it is the oldest not yet completed request
    does not make it the oldest request waiting for disk.
    Or waiting for the peer.
    
    And we completely missed already completed requests
    that would still hold references to activity log extents,
    waiting only for the barrier ack.
    
    Find two oldest not yet completely processed requests,
    one that is still waiting for local completion,
    and one that is still waiting for some response from the peer.
    These may or may not be the same request object.
    
    Then separately apply the network and disk timeouts, respectively.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 67cca286caa6e33f3134bd36834d2484538f4f78
Author: Philipp Reisner <[email protected]>
Date:   Mon Apr 28 18:43:30 2014 +0200

    drbd: Fix a hole in the challange-response connection authentication
    
    In the implementation as it was, the two peers sent each other
    a challenge, and expects the challenge hashed with the shared
    secret back.
    
    A attacker could simply wait for the challenge of the peer, and
    send the same challenge back. Then it waits for the response, and
    sends the same response back.
    
    Prevent this by not accepting a challenge from the peer that is
    the same as the challenge sent to the peer.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit f9c78128f833ae3057884ca219259c8ae5db8898
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:29 2014 +0200

    drbd: always implicitly close last epoch when idle
    
    Once our sender thread needs to wait_for_work(),
    and actually needs to schedule(), just before we do that,
    we already check if it is useful to implicitly close the last epoch.
    
    The condition was too strict: only implicitly close the epoch,
    if there have been no new (write) requests at all.
    
    The assumption was that if there were new requests, they would
    always be communicated one way or another, and would send necessary
    epoch separating barriers explicitly.
    
    This is not always true, e.g. when becoming diskless,
    or while explicitly starting a full resync.
    
    The last communicated epoch could stay open for a long time,
    locking down corresponding activity log extents.
    
    It is safe to always implicitly send that last barrier, as soon as we
    determin that there cannot be more requests in the last communicated
    epoch, even if there have been (uncommunicated) new requests in new
    epochs meanwhile.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit e4d7d6f4d36daff6aad84f96e48debde8e6ed09e
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:28 2014 +0200

    drbd: add back some fairness to AL transactions
    
    When batching more updates to the activity log into single transactions,
    we lost the ability for new requests to force themselves into the active
    set: all preparation steps became non-blocking, and if all currently
    hot extents keep busy, they could starve out new incoming requests
    to cold extents for quite a while.
    
    This can only happen if your IO backend accepts more IO operations per
    average DRBD replication round trip time than you have al-extents
    configured.
    
    If we have incoming requests to cold extents,
    at least do one blocking update per transaction.
    
    In an artificial worst-case workload on SSD with an asynchronous 600 ms
    replication link, with al-extents = 7 (the minimum we allow), and
    concurrent full resynch, without this patch, some write requests have
    been observed to be starved for 40 seconds.
    With this patch, application observed a worst case latency of twice the
    replication round trip time.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit fa090e708a72f0ea9cbe067fba28cfb2b8b787af
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:27 2014 +0200

    drbd: keep max-bio size during detach/attach on disconnected primary
    
    We want to store in persistent meta data what the peer DRBD can handle,
    which, due to spreading requests to multiple bios,
    may be more than its backing device can handle.
    
    Otherwise, if a disconnected Primary temporarily loses access to its local data
    as well, we may accidentally shrink the max-bio setting, portentially causing
    already assembled, but not yet processed, application bios to be spuriously
    failed due to device limits.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 074f4afeb2277bd5ecb9fa7f91eaffa55e262126
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:26 2014 +0200

    drbd: fix a race between start_resync and send_and_submit
    
    In the drbd make request function, specifically in
    drbd_send_and_submit(), we decide whether we want to send the actual
    write request, or only a "set this block out of sync" information.
    
    We do so based on the current connection state, while holding the req_lock.
    The connection state is not supposed to change while holding the req_lock.
    
    But in drbd_start_resync, we did change that state anyways,
    while only holding the global_state_lock, which is enough to change
    sync-after dependencies (paused vs active resync), but
    not good enough to change the connection state.
    
    Fix: in drbd_start_resync, first grab the req_lock to serialize with
    drbd_send_and_submit(), before grabbing the global_state_lock
    to be able to evaluate the sync-after dependencies.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 20c68fdea1646ed746abf19122d7699493927005
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:25 2014 +0200

    drbd: Enable QUEUE_FLAG_DISCARD only if the peer can recieve P_TRIM
    
    Allow the user of REQ_DISCARD.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 2f632aeb5302da93f760d965e970600b35907026
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:24 2014 +0200

    drbd: prepare sending side for REQ_DISCARD
    
    Note that I do NOT call __drbd_chk_io_error for failed REQ_DISCARD.
    That may be wrong, though, or needs to differ between EOPNOTSUPP and
    other errors...
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit a0fb3c47a1aae5d38a88ea858f14d6d088d05e07
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:23 2014 +0200

    drbd: prepare receiving side for REQ_DISCARD
    
    If the receiver needs to serve a discard request on a queue that does
    not announce to be discard cabable, it falls back to do synchronous
    blkdev_issue_zeroout().
    
    We expect only "reasonably" large (up to one activity log extent?)
    discard requests.
    
    We do this to not to not block the receiver for too long in this
    fallback code path, and to not set/clear too many bits inside one
    spinlock_irq_save() in drbd_set_in_sync/drbd_set_out_of_sync,
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 9e276872fe1665ea158f0c6f40df13008fed2908
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:22 2014 +0200

    drbd: allow parallel promote/demote actions
    
    We plan to use genl_family->parallel_ops = true in the future,
    but need to review all possible interactions first.
    
    For now, only selectively drop genl_lock() in drbd_set_role(),
    instead serializing on our own internal resource->conf_update mutex.
    
    We now can be promoted/demoted on many resources in parallel,
    which may significantly improve cluster failover times
    when fencing is required.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit a910b12352f5ddee712c3423c31fbb8b312dde88
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:21 2014 +0200

    drbd: perpare for genetlink parallel_ops
    
    Because all administrative requests via genetlink have been globally
    serialized via genl_lock(), we used to have one static struct
    drbd_config_context "admin context".
    
    Move this on-stack to the respective callback functions.
    
    This will allow us to selectively drop the genl_lock()
    (or use genl_family->parallel_ops) in the future.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 88ea685d33c75932fe90ed0b5d2cf68845462876
Author: Philipp Reisner <[email protected]>
Date:   Mon Apr 28 18:43:20 2014 +0200

    drbd: Do not BUG() when connection breaks in a special way
    
    When a 'cluster wide' disconnect executes, the result comes back
    from the peer, and immediately after that the connection breaks
    then _conn_rq_cond() reported back SS_CW_SUCCESS.
    Therefore _conn_request_state() calls conn_set_state(), which
    has a BUG() in it.
    The BUG() is hit because conn_is_valid_transition() does not like
    the transaction. Which goes back to is_valid_soft_transition()
    returning SS_OUTDATE_WO_CONN.
    
    This fix is to consider an error reported by is_valid_soft_transition()
    even when the peer agreed to the transaction.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit e82998743385ca861b9ec919eb2ba8177ce72180
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:19 2014 +0200

    drbd: don't let application IO pre-empt resync too often
    
    Before, application IO could pre-empt resync activity
    for up to hardcoded 20 seconds per resync request.
    A very busy server could throttle the effective resync bandwidth
    down to one request per 20 seconds.
    
    Now, we only let application IO pre-empt resync traffic
    while the current resync rate estimate is above c-min-rate.
    
    If you disable the c-min-rate throttle feature (set c-min-rate = 0),
    application IO will no longer pre-empt resync traffic at all.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 0e49d7b014c5d591a053d08888a455bd74a88646
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:18 2014 +0200

    drbd: fix potential distributed deadlock during verify or resync
    
    If max-buffers and socket buffer sizes are "too small" for the chosen
    resync rate, this could lead potentially lead to a distributed deadlock,
    which may or may not resolve itself via the "ko-count" and request
    timeout mechanism, or could be resolved by forced disconnect.
    
    One option to deal with this is proper configuration:
    use larger max-buffer and socket buffers settings,
    or reduce the resync rate.
    
    But even with bad configuration we should not deadlock,
    but "gracefully" recover.
    
    The issue is avoided by using only up to max-buffers/2 for resync
    requests, and by using max-buffers not as a hard limit for data buffer
    allocations, but as a throttle threshold only.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 6377b9235056452cd5d592c3739baa379a8735fe
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:17 2014 +0200

    drbd: resync: fix too large bursts for very slow rates
    
    While merging adjacent dirty blocks into resync requests,
    the resync rate throttle was disregarded.
    For very low resync rates, the effective rate may have exceeded
    the intended rate by a larger margin.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 9ae472605ad333d4db07da95cc42c68063d2cc0d
Author: Lars Ellenberg <[email protected]>
Date:   Mon Apr 28 18:43:16 2014 +0200

    drbd: fix stalled resync detection in /proc/drbd
    
    If we don't make resync or verify progress for "too long",
    we want to flag it as "stalled".
    
    Since 2010, "use rolling marks for resync speed calculation"
    this "too long" was wrong by a factor of HZ.
    With HZ 250, it would have been flagged as stalled
    after 100 minutes.
    
    Hardcode 3 minutes instead.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit cdc6af8df42313d632cb9ed79dd455daecbd8478
Author: Philipp Reisner <[email protected]>
Date:   Mon Apr 28 18:43:15 2014 +0200

    drbd: Allow online layout change of AL while peer is not connected
    
    If a user forces the operation he takes the blame in case
    the peer does not have enough space. No reason to dey this...
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit d40e567149c7ac250344d1537261c87b2c3e852c
Author: Philipp Reisner <[email protected]>
Date:   Mon Apr 28 18:43:14 2014 +0200

    drbd: Remove drbd_wrappers.h
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit d7fe69c6a1940c3f9c5bed08634b6dd868612cdf
Author: Philipp Reisner <[email protected]>
Date:   Mon Apr 28 18:43:13 2014 +0200

    drbd: Leave IO suspended if the fence handler find the peer primary
    
    Actually we are clearing the susp_fen flag if we are not going
    to call a fencing handler.
    
    For setting the susp_fen flag needs to be edge-triggerd, and not
    level triggered.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 31007745a5f328b8d70d865c4a6118be01421b8c
Author: Philipp Reisner <[email protected]>
Date:   Mon Apr 28 18:43:12 2014 +0200

    drbd: Break a deadlock while concurrent fencing and establishing a connection
    
    When we need to outdate the peer while being promoted to primary,
    and the connection gets established at the same time, we deadlock
    in drbd_try_outdate_peer() when trying to clear the susp_fen
    bit.
    
    Fix this by setting the STATE_SENT bit while holding the mutex.
    
    Using drbd_change_state(.. , CS_HARD, ..) which does not block
    until STATE_SENT is cleared, is only for clearness. It does
    not contribute anything to the fix.
    
    Signed-off-by: Philipp Reisner <[email protected]>
    Signed-off-by: Lars Ellenberg <[email protected]>
    Signed-off-by: …
ddstreet referenced this pull request in ddstreet/linux May 6, 2014
@hnaz
linux-next
d900f68 
GIT feed28415e95fbfad6dae876e927622db253672e

commit eb9672f4a14bb7058c44efcc31c89737a7724d2c
Author: Daniel Borkmann <[email protected]>
Date:   Thu May 1 18:34:20 2014 +0200

    net: filter: misc/various cleanups
    
    This contains only some minor misc cleanpus. We can spare us the
    extra variable declaration in __skb_get_pay_offset(), the cast in
    __get_random_u32() is rather unnecessary and in __sk_migrate_realloc()
    we can remove the memcpy() and do a direct assignment of the structs.
    Latter was suggested by Fengguang Wu found with coccinelle. Also,
    remaining pointer casts of long should be unsigned long instead.
    
    Suggested-by: Fengguang Wu <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 30743837dd204d2b04fd4e9d3db78cc7b118c81a
Author: Daniel Borkmann <[email protected]>
Date:   Thu May 1 18:34:19 2014 +0200

    net: filter: make register naming more comprehensible
    
    The current code is a bit hard to parse on which registers can be used,
    how they are mapped and all play together. It makes much more sense to
    define this a bit more clearly so that the code is a bit more intuitive.
    This patch cleans this up, and makes naming a bit more consistent among
    the code. This also allows for moving some of the defines into the header
    file. Clearing of A and X registers in __sk_run_filter() do not get a
    particular register name assigned as they have not an 'official' function,
    but rather just result from the concrete initial mapping of old BPF
    programs. Since for BPF helper functions for BPF_CALL we already use
    small letters, so be consistent here as well. No functional changes.
    
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 5bcfedf06f7fdf9efcf65dc11198e9012f7530f4
Author: Daniel Borkmann <[email protected]>
Date:   Thu May 1 18:34:18 2014 +0200

    net: filter: simplify label names from jump-table
    
    This patch simplifies label naming for the BPF jump-table.
    When we define labels via DL(), we just concatenate/textify
    the combination of instruction opcode which consists of the
    class, subclass, word size, target register and so on. Each
    time we leave BPF_ prefix intact, so that e.g. the preprocessor
    generates a label BPF_ALU_BPF_ADD_BPF_X for DL(BPF_ALU, BPF_ADD,
    BPF_X) whereas a label name of ALU_ADD_X is much more easy
    to grasp. Pure cleanup only.
    
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit f6a082fed1e6407c2f4437d0d963b1bcbe5f9f58
Author: John Fastabend <[email protected]>
Date:   Thu May 1 09:23:06 2014 -0700

    net: sched: lock imbalance in hhf qdisc
    
    hhf_change() takes the sch_tree_lock and releases it but misses the
    error cases. Fix the missed case here.
    
    To reproduce try a command like this,
    
    # tc qdisc change dev p3p2 root hhf quantum 40960 non_hh_weight 300000
    
    Signed-off-by: John Fastabend <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit dfee07cceff94af498a8465353554e0b63c3b152
Author: Alexei Starovoitov <[email protected]>
Date:   Thu May 1 08:16:03 2014 -0700

    net: filter: doc: expand and improve BPF documentation
    
    In particular, this patch tries to clarify internal BPF calling
    convention and adds internal BPF examples, JIT guide, use cases.
    
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit a3464ed2f14d19ba923930f7c0c284499d64eb5b
Author: Thomas Petazzoni <[email protected]>
Date:   Tue Apr 15 17:00:03 2014 +0200

    ata: ahci_mvebu: new driver for Marvell Armada 380 AHCI interfaces
    
    The Marvell Armada 380 SoC includes two AHCI compatible
    interfaces. However, like all DMA-capable Marvell interface, they
    require special handling to configure MBus windows. Therefore, this
    commit adds a new ahci_mvebu driver, which relies on the
    libahci_platform.c code recently introduced.
    
    Signed-off-by: Thomas Petazzoni <[email protected]>
    Acked-by: Jason Cooper <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 5799d6d4cf86c11503aee909a1ec555453c7f22a
Author: Thomas Petazzoni <[email protected]>
Date:   Tue Apr 15 17:00:02 2014 +0200

    Documentation: dt-bindings: reformat and order list of ahci-platform compatibles
    
    The ahci-platform.txt Device Tree binding documentation is gaining a
    growing number of compatible strings, and it will gain one more with
    the addition of the Marvell Armada 380 AHCI support. It is therefore
    time to reformat this list into a proper bullet list, and more
    importantly order it alphabetically;
    
    Signed-off-by: Thomas Petazzoni <[email protected]>
    Acked-by: Andrew Lunn <[email protected]>
    Acked-by: Jason Cooper <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit f5f3cf6f7e49b9529fc00a2c4629fa92cf2755fe
Author: Aristeu Rozanski <[email protected]>
Date:   Thu Apr 24 15:33:21 2014 -0400

    device_cgroup: fix the comment format for recently added functions
    
    Moving more extensive explanations to the end of the comment.
    
    Cc: Li Zefan <[email protected]>
    Signed-off-by: Aristeu Rozanski <[email protected]>
    Acked-by: Serge Hallyn <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 15a4c835e4ed3e60dd68727cd1907e3dd89563f4
Author: Tejun Heo <[email protected]>
Date:   Sun May 4 15:09:14 2014 -0400

    cgroup, memcg: implement css->id and convert css_from_id() to use it
    
    Until now, cgroup->id has been used to identify all the associated
    csses and css_from_id() takes cgroup ID and returns the matching css
    by looking up the cgroup and then dereferencing the css associated
    with it; however, now that the lifetimes of cgroup and css are
    separate, this is incorrect and breaks on the unified hierarchy when a
    controller is disabled and enabled back again before the previous
    instance is released.
    
    This patch adds css->id which is a subsystem-unique ID and converts
    css_from_id() to look up by the new css->id instead.  memcg is the
    only user of css_from_id() and also converted to use css->id instead.
    
    For traditional hierarchies, this shouldn't make any functional
    difference.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Acked-by: Michal Hocko <[email protected]>
    Cc: Johannes Weiner <[email protected]>
    Cc: Jianyu Zhan <[email protected]>
    Acked-by: Li Zefan <[email protected]>

commit ddfcadab35dda6e5bc23ccf1c3055ecb63a71e49
Author: Tejun Heo <[email protected]>
Date:   Sun May 4 15:09:14 2014 -0400

    cgroup: update init_css() into init_and_link_css()
    
    init_css() takes the cgroup the new css belongs to as an argument and
    initializes the new css's ->cgroup and ->parent pointers but doesn't
    acquire the matching reference counts.  After the previous patch,
    create_css() puts init_css() and reference acquisition right next to
    each other.  Let's move reference acquistion into init_css() and
    rename the function to init_and_link_css().  This makes sense and is
    easier to follow.  This makes the root csses to hold a reference on
    cgrp_dfl_root.cgrp, which is harmless.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Acked-by: Li Zefan <[email protected]>

commit a2bed8209a3afc3b2cf1c28383fb48155c1fea46
Author: Tejun Heo <[email protected]>
Date:   Sun May 4 15:09:14 2014 -0400

    cgroup: use RCU free in create_css() failure path
    
    Currently, when create_css() fails in the middle, the half-initialized
    css is freed by invoking cgroup_subsys->css_free() directly.  This
    patch updates the function so that it invokes RCU free path instead.
    As the RCU free path puts the parent css and owning cgroup, their
    references are now acquired right after a new css is successfully
    allocated.
    
    This doesn't make any visible difference now but is to enable
    implementing css->id and RCU protected lookup by such IDs.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Acked-by: Li Zefan <[email protected]>

commit 6fa4918d03c39351aef3573ac3e7958d6a5ad9b6
Author: Tejun Heo <[email protected]>
Date:   Sun May 4 15:09:13 2014 -0400

    cgroup: protect cgroup_root->cgroup_idr with a spinlock
    
    Currently, cgroup_root->cgroup_idr is protected by cgroup_mutex, which
    ends up requiring cgroup_put() to be invoked under sleepable context.
    This is okay for now but is an unusual requirement and we'll soon add
    css->id which will have the same problem but won't be able to simply
    grab cgroup_mutex as removal will have to happen from css_release()
    which can't sleep.
    
    Introduce cgroup_idr_lock and idr_alloc/replace/remove() wrappers
    which protects the idr operations with the lock and use them for
    cgroup_root->cgroup_idr.  cgroup_put() no longer needs to grab
    cgroup_mutex and css_from_id() is updated to always require RCU read
    lock instead of either RCU read lock or cgroup_mutex, which doesn't
    affect the existing users.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Acked-by: Li Zefan <[email protected]>

commit 7d699ddb2b181a2c76e5ea18b1bdf102c4bebe4b
Author: Tejun Heo <[email protected]>
Date:   Sun May 4 15:09:13 2014 -0400

    cgroup, memcg: allocate cgroup ID from 1
    
    Currently, cgroup->id is allocated from 0, which is always assigned to
    the root cgroup; unfortunately, memcg wants to use ID 0 to indicate
    invalid IDs and ends up incrementing all IDs by one.
    
    It's reasonable to reserve 0 for special purposes.  This patch updates
    cgroup core so that ID 0 is not used and the root cgroups get ID 1.
    The ID incrementing is removed form memcg.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Acked-by: Michal Hocko <[email protected]>
    Cc: Johannes Weiner <[email protected]>
    Acked-by: Li Zefan <[email protected]>

commit 69dfa00ccb72a37f3810687ca110e5a8154c6eed
Author: Tejun Heo <[email protected]>
Date:   Sun May 4 15:09:13 2014 -0400

    cgroup: make flags and subsys_masks unsigned int
    
    There's no reason to use atomic bitops for cgroup_subsys_state->flags,
    cgroup_root->flags and various subsys_masks.  This patch updates those
    to use bitwise and/or operations instead and converts them form
    unsigned long to unsigned int.
    
    This makes the fields occupy (marginally) smaller space and makes it
    clear that they don't require atomicity.
    
    This patch doesn't cause any behavior difference.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Acked-by: Li Zefan <[email protected]>

commit e783c51cce94521c10e599e991acdcfd9a996c4a
Author: Shawn Guo <[email protected]>
Date:   Sun May 4 21:48:06 2014 +0800

    ahci: imx: software workaround for phy reset issue in resume
    
    When suspending imx6q systems which have rootfs on SATA, the following
    error will likely be seen in resume.  The SATA link will fail to come
    up, and it results in an unusable system across the suspend/resume
    cycle.
    
    $ echo mem > /sys/power/state
    PM: Syncing filesystems ... done.
    PM: Preparing system for mem sleep
    Freezing user space processes ... (elapsed 0.002 seconds) done.
    Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
    PM: Entering mem sleep
    sd 0:0:0:0: [sda] Synchronizing SCSI cache
    sd 0:0:0:0: [sda] Stopping disk
    PM: suspend of devices complete after 61.914 msecs
    PM: suspend devices took 0.070 seconds
    PM: late suspend of devices complete after 4.906 msecs
    PM: noirq suspend of devices complete after 4.521 msecs
    Disabling non-boot CPUs ...
    CPU1: shutdown
    CPU2: shutdown
    CPU3: shutdown
    Enabling non-boot CPUs ...
    CPU1: Booted secondary processor
    CPU1 is up
    CPU2: Booted secondary processor
    CPU2 is up
    CPU3: Booted secondary processor
    CPU3 is up
    PM: noirq resume of devices complete after 10.486 msecs
    PM: early resume of devices complete after 4.679 msecs
    sd 0:0:0:0: [sda] Starting disk
    PM: resume of devices complete after 22.674 msecs
    PM: resume devices took 0.030 seconds
    PM: Finishing wakeup.
    Restarting tasks ... done.
    $ ata1: SATA link down (SStatus 1 SControl 300)
    ata1: SATA link down (SStatus 1 SControl 300)
    ata1: limiting SATA link speed to 1.5 Gbps
    ata1: SATA link down (SStatus 1 SControl 310)
    ata1.00: disabled
    ata1: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen t4
    ata1: irq_stat 0x00000040, connection status changed
    ata1: SError: { CommWake DevExch }
    ata1: hard resetting link
    sd 0:0:0:0: rejecting I/O to offline device
    sd 0:0:0:0: killing request
    sd 0:0:0:0: rejecting I/O to offline device
    Aborting journal on device sda2-8.
    sd 0:0:0:0: rejecting I/O to offline device
    EXT4-fs warning (device sda2): ext4_end_bio:317: I/O error writing to inode 132577 (offset 0 size 0 starting block 26235)
    Buffer I/O error on device sda2, logical block 10169
    ...
    
    It's caused by a silicon issue that SATA phy does not get reset by
    controller when coming back from LPM.  The patch adds a software
    workaround for this issue.  It enforces a software reset on SATA phy
    in imx_sata_enable() function, so that we can ensure SATA link will
    come up properly in both power-on and resume.
    
    The software reset is implemented by writing phy reset register through
    the phy control register bus interface.  Functions
    imx_phy_reg_[addressing|write|read]() implement this bus interface, while
    imx_sata_phy_reset() performs the actually reset operation.
    
    Signed-off-by: Richard Zhu <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 24a9ad5b82929cdeaff70018d82263de0c34c45d
Author: Shawn Guo <[email protected]>
Date:   Sun May 4 21:48:05 2014 +0800

    ahci: imx: add namespace for register enums
    
    Update register enums a little bit to add proper namespace prefix, and
    have the names match i.MX reference manual.
    
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 8612b4b4f964b935029c3388c8484a66e41bf71e
Author: Paul Bolle <[email protected]>
Date:   Sun May 4 13:50:29 2014 +0200

    libata-sff: remove dead code
    
    Ever since v2.6.19 the code contains a check for CONFIG_NO_ATA_LEGACY.
    But that macro has never been defined. Apparently no one ran into
    problems on platforms that do not support compatibility mode. So remove
    this code that has been dead for over seven years.
    
    Signed-off-by: Paul Bolle <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 84d93b5e605324679cffb6d28c7339dd18165fd4
Author: Sebastian Reichel <[email protected]>
Date:   Fri Sep 20 22:42:22 2013 +0200

    HSI: hsi-char: fix driver for multiport scenarios
    
    Fix return code check of alloc_chrdev_region, which
    returns 0 on success.
    
    Signed-off-by: Sebastian Reichel <[email protected]>
    Reviewed-by: Pavel Machek <[email protected]>

commit 56459ea9aada1ba228cd0dd75accb56b95e07d73
Author: Sebastian Reichel <[email protected]>
Date:   Fri Mar 28 19:57:59 2014 +0100

    MAINTAINERS: update HSI entry
    
    Add git tree for hsi subsystem, update Sebastian Reichel's e-mail
    address and add Documentation/hsi.txt as maintained file.
    
    Signed-off-by: Sebastian Reichel <[email protected]>
    Reviewed-by: Pavel Machek <[email protected]>

commit 3a8ab8af08cad8d3cf1ceff7e5a5da365ac6b63e
Author: Sebastian Reichel <[email protected]>
Date:   Sat Mar 1 01:07:54 2014 +0100

    Documentation: HSI: Add some general description for the HSI subsystem
    
    Add a document, which gives a rough introduction about what HSI
    is and how its handled by the Linux kernel.
    
    Signed-off-by: Sebastian Reichel <[email protected]>
    Reviewed-by: Pavel Machek <[email protected]>

commit 16ce8a30e6102d7aabd4e4518d255f330290fa3f
Author: David S. Miller <[email protected]>
Date:   Sat May 3 22:25:33 2014 -0700

    sparc64: Normalize NMI watchdog logging and behavior.
    
    Bring this code in line with the perf based generic NMI watchdog
    in kernel/watchdog.c (which we should convert over to at some
    point).
    
    In particular, don't do anything super fancy when the watchdog
    triggers, and specifically don't do a do_exit() which only makes
    things worse.
    
    Either panic(), or WARN().  The latter of which will do all of
    the actions such as give us a stack backtrace.
    
    Signed-off-by: David S. Miller <[email protected]>

commit caec4ba8ff360f094e5a80e938ba0946bbe6b5f5
Author: Fabian Frederick <[email protected]>
Date:   Sat May 3 22:28:43 2014 +0200

    fs/locks.c: replace seq_printf by seq_puts
    
    Replace seq_printf where possible
    
    Cc: Jeff Layton <[email protected]>
    Cc: Alexander Viro <[email protected]>
    Cc: Andrew Morton <[email protected]>
    Signed-off-by: Fabian Frederick <[email protected]>
    Signed-off-by: Jeff Layton <[email protected]>

commit 09c3fbba88b444f5e46702cc90fd014d2df7b36d
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:32 2014 +0530

    staging: rtl8188eu: Remove 'u8 *pbuf' from struct recv_buf
    
    Instead of using pbuf to pass sbk data pointer to usb_fill_bulk_urb(),
    we can use precvbuf->pskb->data to do that.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit acfd19e70701dd1ba49653193eab88e379572e92
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:31 2014 +0530

    staging: rtl8188eu: Remove rtl8188eu_init_recvbuf() function
    
    rtl8188eu_init_recvbuf() function definition is empty now,
    so remove it.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a1f3b3fdba2ab124c1e8c2b6aa17cfcf5c99d756
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:30 2014 +0530

    staging: rtl8188eu: Remove 'u32 ref_cnt' from struct recv_buf
    
    Driver isn't making any use of value stored in variable ref_cnt.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 74e250e479cb79b0cd58a810ed1a6f630877b4ad
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:29 2014 +0530

    staging: rtl8188eu: Remove 'u32 len' from struct recv_buf
    
    Remove unused variable 'u32 len'.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1b2a4fc7a55415a7afc5baa21986dbd25345e782
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:28 2014 +0530

    staging: rtl8188eu: Remove 'alloc_sz' from struct recv_buf
    
    Driver isn't making any use of value stored in alloc_sz variable.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f0f4499d703d73c8c9dac77e3fff9cd71c04db9a
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:27 2014 +0530

    staging: rtl8188eu: Remove 'pallocated_buf' from struct recv_buf
    
    pallocated_buf is not being used by driver.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e205cae24d0845b39502dafc3c3abe4b265035d3
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:26 2014 +0530

    staging: rtl8188eu: Remove 'irp_pending' from struct recv_buf
    
    irp_pending is initialized to false inside rtw_os_recvbuf_resource_alloc()
    and value of irq_pending never changed after that, so 'if (!precvbuf->irp_pending)'
    inside rtw_os_read_port() function will be always true.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c11f3fff320540e7d84a3bbb2d7d3918465589b5
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:25 2014 +0530

    staging: rtl8188eu: Remove pdata, phead, ptail and pend from struct recv_buf
    
    Driver is not making use of value stored in removed variables.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit afdd36ef9cb0392a701ee8940d1d9f7e01735643
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:24 2014 +0530

    staging: rtl8188eu: Remove 'int transfer_len' from struct recv_buf
    
    Driver is not making any use of value stored in this variable.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 498562560a351cd483bc5d6013a6a33c70e15043
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:23 2014 +0530

    staging: rtl8188eu: Remove 'dma_addr_t dma_transfer_addr' from struct recv_buf
    
    Remove unused variable dma_transfer_addr.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4337ff2f8fed9230af7acb447f8c1e5a82087d97
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:22 2014 +0530

    staging: rtl8188eu: Remove 'spinlock_t recvbuf_lock' from struct recv_buf
    
    recvbuf_lock is initialized inside rtl8188eu_init_recv_priv() but never used.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9a4429ea62834d4e5e4e677b11b64a881da99b99
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:21 2014 +0530

    staging: rtl8188eu: Remove 'struct list_head list' from struct recv_buf
    
    Users of 'struct list_head list' variable e.g. rtw_enqueue_recvbuf(),
    rtw_enqueue_recvbuf_to_head() and rtw_dequeue_recvbuf() are
    already removed.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5fe2f910f44a49856245a79b7e4d711d4d9ce670
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:20 2014 +0530

    staging: rtl8188eu: Remove function rtw_enqueue_recvbuf()
    
    rtw_enqueue_recvbuf() is not being used by driver.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0521a2a6f9bceca23b38a8cad76ffa0e381600e2
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:19 2014 +0530

    staging: rtl8188eu: Remove function rtw_enqueue_recvbuf_to_head()
    
    rtw_enqueue_recvbuf_to_head() is not being used by driver.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d27ab0b9df6c2961da5d814e5f183318a1489c9c
Author: navin patidar <[email protected]>
Date:   Sat May 3 17:15:18 2014 +0530

    staging: rtl8188eu: Remove function rtw_dequeue_recvbuf()
    
    rtw_dequeue_recvbuf() is not being used by driver.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b9fb433072ebeffe9ae30c819f8032e8583d16fe
Author: Jan Moskyto Matejka <[email protected]>
Date:   Wed Apr 30 15:22:17 2014 +0200

    rtl8821ae: fixed defined-not-used warning
    
    by cleaning up BT_AUTO_REPORT_ONLY_8192E_2ANT
    (always set to 0, never used as constant)
    
    halbtc8192e2ant_iswifi_status_changed was called only from the unused code
    
    Signed-off-by: Jan Moskyto Matejka <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2930d0b977e6b9f66e8f090c685a18991944fca6
Author: Rui Miguel Silva <[email protected]>
Date:   Mon Apr 28 12:12:54 2014 +0100

    staging: rtl8192u: fix checkpatch braces warning
    
    fix some code style related to the use of braces in a one statement block
    
    Signed-off-by: Rui Miguel Silva <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7626e3d0d4731ccd3f556533b93c4cd3e8cbf5e6
Author: Dominique van den Broeck <[email protected]>
Date:   Sun Apr 27 19:11:15 2014 +0200

    staging/rtl8192e: Erroneous return codes (types and values)
    
    This function returns a bool, that is supposed to be false when something
    goes wrong. It's assumed this way by its lone calling function (which is
    SetRFPowerState8190(), line 1445 of rtl8192e/rtl8192e/r8192E_phy.c)
    
    Despite of this, this procedure returns non-null enumerations values or
    negative codes instead. This patch fixes this.
    
    Signed-off-by: Dominique van den Broeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 73fbfbfecbeb7c8642dd96a12ef991881492f051
Author: navin patidar <[email protected]>
Date:   Tue Apr 29 06:55:13 2014 +0530

    staging: rtl8188eu: Use USB subsystem functions to check endpoint type
    
    Use inline functions provided by USB subsystem to check endpoint type,
    instead of inline functions implemented by driver to do the same.
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 213351448f9dc5f43f155cb23ab9fafe8a9577ed
Author: navin patidar <[email protected]>
Date:   Tue Apr 29 06:55:12 2014 +0530

    staging: rtl8188eu: Remove debugging messages from usb_dvobj_init()
    
    Unnecessary debugging messages are removed from usb_dvobj_init().
    
    Signed-off-by: navin patidar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5f888cb7b1722412170728df2c9168d47596459c
Author: Thomas Vegas <[email protected]>
Date:   Tue Apr 1 18:29:37 2014 +0200

    staging: serqt_usb2: Clean up initializations of variables
    
    Use a more common kernel coding style.
    
    Signed-off-by: Thomas Vegas <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f5a7856ec94ce0c1aeeac841d3fa05853f5f53fb
Author: Thomas Vegas <[email protected]>
Date:   Tue Apr 1 18:28:33 2014 +0200

    staging: serqt_usb2: Add blank line after declaration
    
    Use a more common kernel coding style.
    
    Signed-off-by: Thomas Vegas <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c46e961e5ad19d5595dfe07d77c26eced8093ec9
Author: Thomas Vegas <[email protected]>
Date:   Tue Apr 1 18:27:34 2014 +0200

    staging: serqt_usb2: Remove useless variable
    
    Use a more common kernel coding style.
    
    Signed-off-by: Thomas Vegas <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 482f0a21904583923d5c37f84586839c026a734b
Author: Ian Abbott <[email protected]>
Date:   Fri May 2 13:50:14 2014 +0100

    staging: comedi: remove async parameter from resize_async_buffer()
    
    The `struct comedi_async *async` parameter of `resize_async_buffer()` is
    redundant as its value can be easily derived from the `struct
    comedi_subdevice *s` parameter as `s->async`.  Remove the parameter.
    
    Signed-off-by: Ian Abbott <[email protected]>
    Reviewed-by: H Hartley Sweeten <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0ce016d0986ae618e0686489ad7b858fa13b885d
Author: Ian Abbott <[email protected]>
Date:   Fri May 2 13:50:13 2014 +0100

    staging: comedi: remove redundant pointer dereference in comedi_poll()
    
    `s->async->subdevice` in `comedi_poll()` points to the same `struct
    comedi_subdevice` as `s`, so the double pointer reference is redundant.
    Just use `s`.
    
    (`s->async->subdevice` is initialized by
    `__comedi_device_postconfig_async()` in
    "drivers/staging/comedi/drivers.c" and doesn't change.)
    
    Signed-off-by: Ian Abbott <[email protected]>
    Reviewed-by: H Hartley Sweeten <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6e2954e801d7d93fe6f54eff988ddf25836fee0a
Author: Ian Abbott <[email protected]>
Date:   Thu May 1 17:38:24 2014 +0100

    staging: comedi: amplc_dio200_common: correct bound on counter mode
    
    For the mode configured by the `INSN_CONFIG_SET_COUNTER_MODE` comedi
    instruction for the counter subdevice channels supported by this module,
    the upper bound should be `I8254_MODE5 | I8254_BCD` ((5 << 1) | 1)
    rather than `I8254_MODE5 | I8254_BINARY` ((5 << 1) | 0).  Fix it.
    
    Reported-by: Hartley Sweeten <[email protected]>
    Signed-off-by: Ian Abbott <[email protected]>
    Reviewed-by: H Hartley Sweeten <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7d52477ef5e66a43fe54e5737179e4e670db260d
Author: Ian Abbott <[email protected]>
Date:   Thu May 1 17:38:23 2014 +0100

    staging: comedi: drivers: correct mode check for i8254_set_mode()
    
    The upper bound check on the `mode` parameter of `i8254_set_mode()` and
    `i8254_mm_set_mode()` is incorrect.  The `mode` parameter value consists
    of a mode number in the range 0 to 5 in bits 3..1 {represented by the
    constants `I8254_MODE0` (0 << 1) through to `I8254_MODE5` (2 << 1)} ORed
    with a BCD/binary flag in bit 0 {represented by the constants
    `I8254_BINARY` (0) and `I8254_BCD` (1)}.  The maximum allowed value
    ought to be `I8254_MODE5 | I8254_BCD` ((5 << 1) | 1), but is currently
    `I8254_MODE5 | I8254_BINARY` ((5 << 1) | 0).  Fix it.
    
    None of the comedi drivers use `I8254_BCD` but some of the low-level
    drivers allow user-space to configure the counter mode, so all legal
    values ought to be allowed.  However, it's pretty unlikely anyone would
    want to set the counters to count in BCD (binary coded decimal) so the
    bug is not that significant.
    
    Reported-by: Hartley Sweeten <[email protected]>
    Signed-off-by: Ian Abbott <[email protected]>
    Reviewed-by: H Hartley Sweeten <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a1f6c2afed3f4c96194f131373b1e914b285c76b
Author: Luca Ellero <[email protected]>
Date:   Wed Apr 30 11:22:07 2014 +0200

    staging: comedi: fix checkpatch warnings
    
    Signed-off-by: Luca Ellero <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8383b8c4a9b81ad5fa446a9b4c9bd5ac4b382c2a
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:59 2014 -0700

    staging: comedi: das16: clarify 8254 timer programming
    
    Refactor the 8254 timer programming to use the i8254_set_mode()
    and i8254_write() helpers instead of i8254_load(). This allows
    us to use the I8254_MODE* defines to clarify the code.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bef74ba884be09144f13b7132c060c2e5b0ec415
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:58 2014 -0700

    staging: comedi: das16m1: clarify 8254 timer programming
    
    Refactor the 8254 timer programming to use the i8254_set_mode()
    and i8254_write() helpers instead of i8254_load(). This allows
    us to use the I8254_MODE* defines to clarify the code.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 22e09dff089fe93d6e3ef7cc0fb8f645a87153c6
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:57 2014 -0700

    staging: comedi: ni_at_a2150: clarify 8254 timer programming
    
    Refactor the 8254 timer programming to use the i8254_set_mode()
    and i8254_write() helpers instead of i8254_load(). This allows
    us to use the I8254_MODE* defines to clarify the code.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e74e98993da8dff62190c937d4371eda962e64b9
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:56 2014 -0700

    staging: comedi: ni_labpc: fix 8254 timer programming
    
    As pointed out by Ian Abbott, the i8254_load() function does not
    use the I8254_MODE* values to specify the "mode".
    
    The labpc_counter_load() function in this driver is passed an
    I8254_MODE* value so we need to use the i8254_set_mode() and
    i8254_write() helpers instead of i8254_load() to program the
    timers.
    
    The calls to labpc_counter_load() will not fail so change the
    return to void and remove all the unnecessary error handling.
    
    Similarly, change the return type of labpc_counter_set_mode() to
    void and remove the unnecessary error handling.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 52c9e62cf3247cb0599197e7a27356e6a2513a80
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:55 2014 -0700

    staging: comedi: das800: clarify 8254 timer programming
    
    Refactor the 8254 timer programming to use the i8254_set_mode()
    and i8254_write() helpers instead of i8254_load(). This allows
    us to use the I8254_MODE* defines to clarify the code.
    
    The das800_set_frequency() function will not fail. For aesthetics
    change the return to a void and remove the error handling.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 90c32ce300fb79f45d55803bc021c4e49ed9b85f
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:54 2014 -0700

    staging: comedi: amplc_pci244: clarify 8254 timer programming
    
    Refactor the 8254 timer programming to use the i8254_set_mode()
    and i8254_write() helpers instead of i8254_load(). This allows
    us to use the I8254_MODE* defines to clarify the code.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e72f7ad46e73b5cd372cdf6834d0dd0e0000d7ad
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:53 2014 -0700

    staging: comedi: me4000: fix 8254 timer programming
    
    As pointed out by Ian Abbott, the i8254_load() function does not
    use the I8254_MODE* values to specify the "mode".
    
    Refactor the 8254 timer programming to use the i8254_set_mode()
    and i8254_write() helpers instead of i8254_load(). This allows
    us to use the I8254_MODE* defines to clarify the code.
    
    Also, use the CR_CHAN() macro to make sure the only the channel is
    used in the insh->chanspec to specify the counter number.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4f161fc756a086f56b200a5a9e7ef60c28265a4c
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:52 2014 -0700

    staging: comedi: ni_at_ao: fix 8254 timer programming
    
    As pointed out by Ian Abbott, the i8254_load() function does not
    use the I8254_MODE* values to specify the "mode".
    
    Refactor the 8254 timer programming to use the i8254_set_mode()
    and i8254_write() helpers instead of i8254_load(). This allows
    us to use the I8254_MODE* defines to clarify the code.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d7c0dcb65abda2842a1bff678a5297ed68431421
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:51 2014 -0700

    staging: comedi: pcl711: fix 8254 timer programming
    
    As pointed out by Ian Abbott, the i8254_load() function does not
    use the I8254_MODE* values to specify the "mode".
    
    Refactor the 8254 timer programming to use the i8254_set_mode()
    and i8254_write() helpers instead of i8254_load(). This allows
    us to use the I8254_MODE* defines to clarify the code.
    
    For aesthetics, factor the timer programming out as a separate
    function.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 241f1c96441f7539459f159a099115a6d21e9f3e
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:50 2014 -0700

    staging: comedi: hwdrv_apci3120: remove clearing of 'b_OutputMemoryStatus'
    
    This private data member is not used by this driver. Remove the unnecessary
    clearing of it.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 204563198e729cb9c12131a77a1bfdeaacd2a497
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:49 2014 -0700

    staging: comedi: hwdrv_apci3120: fix 'b_AiCyclicAcquisition' usage
    
    This private data member is set when an analog input async command is
    started by apci3120_cyclic_ai() and cleared when the command finishes
    or is canceled.
    
    Rename the CamelCase member to 'ai_running' and convert it to a
    bit-field flag.
    
    Remove the unnecessary clearing of the flag before or after calling
    apci3120_cancel().
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a19f71615875b207813fee32db983903a0ec5729
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:48 2014 -0700

    staging: comedi: hwdrv_apci3120: cmd->convert_src is always TRIG_TIMER
    
    The (*do_cmdtest) validates that the cmd->convert_src can only be
    TRIG_TIMER. Remove the unnecessay checks.
    
    THis also simplifies the (*do_cmd) a bit since "mode 3" (whatever that
    is) is never a valid mode.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2f673c5d10511e790de97ab885878cbad1678245
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:47 2014 -0700

    staging: comedi: addi_common.h: remove 'b_AiContinuous' from private data
    
    This member of the private data can be determined by checking the cmd->stop_src.
    Do that instead.
    
    Fix the b_AiContinuous check in apci3120_ai_cmd(). The (*do_cmdtest) validates
    that the cmd->stop_arg os >= 1 for TRIG_COUNT and 0 for TRIG_NONE. The correct
    test to set this flag is (cmd->stop_src == TRIG_NONE).
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit eaca0032f1b5be78b0e8fe55934fd8db5d95d2d1
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:46 2014 -0700

    staging: comedi: addi_common.h: remove 'ui_AiNbrofScans' from private data
    
    This member of the private data is a copy of the cmd->stop_arg. Use that
    instead.
    
    Fix the b_AiContinuous check in apci3120_ai_cmd(). The (*do_cmdtest) validates
    that the cmd->stop_arg os >= 1 for TRIG_COUNT and 0 for TRIG_NONE. The correct
    test to set this flag is (cmd->stop_src == TRIG_NONE).
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5d6babe36ef3f2cc8cd3a2cef2fdb8bf4c144ed4
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:45 2014 -0700

    staging: comedi: addi_common.h: remove 'ui_AiDataLength' from private data
    
    This member of the private data is a copy of the s->async->prealloc_bufsz.
    Use that instead.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a1b986e88976e2ca566fa2726c2346b5fbd1903c
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:44 2014 -0700

    staging: comedi: addi_common.h: remove 'ui_AiTimer1' from private data
    
    This member of the private data is a copy of the cmd->scan_begin_arg.
    Use that instead.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 596c5a6e76eb1e24e049d85795050fd0ad20b947
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:43 2014 -0700

    staging: comedi: addi_common.h: remove 'ui_AiTimer0' from private data
    
    This member of the private data is a copy of the cmd->convert_arg. Use
    that instead.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bda88cd47559348d747dcf4741c6067e1348fa3c
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:42 2014 -0700

    staging: comedi: addi_common.h: remove 'pui_AiChannelList' from private data
    
    This member of the private data is a copy of the cmd->chanlist. Use that
    instead.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 72af0c4ed598419b908f12307cdac7151f622209
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:41 2014 -0700

    staging: comedi: addi_common.h: remove 'ui_AiScanLength' from private data
    
    This member of the private data is a copy of the cmd->scan_end_arg. Use that
    instead.
    
    Use a local variable in apci3120_cyclic_ai() for the DMA 'scan_bytes', which
    is the cmd->scan_end_arg * 2. Replace the open-coded '2' with sizeof(short).
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ffadead4e67899fd9ca0e33ce1a6bb1453e8b091
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:40 2014 -0700

    staging: comedi: addi_common.h: remove 'ui_AiFlags' from private data
    
    This member of the private data is a copy of the cmd->flags. Use that instead.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7586fd6b3e2df042ce2b45cf4ab43a92af1a27ac
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:39 2014 -0700

    staging: comedi: amplc_pci230: remove 'ao_continuous' from private data
    
    This member of the private data can be determined by checking the cmd->stop_src.
    Do that instead.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bca4eac8fd36e8ab2990d513a9d6a34d2a5bd502
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:38 2014 -0700

    staging: comedi: amplc_pci230: remove 'ai_continuous' from private data
    
    This member of the private data can be determined by checking the cmd->stop_src.
    Do that instead.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 96410e7a3316a61ec509865ec76e7d033f8096eb
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:37 2014 -0700

    staging: comedi: amplc_pci224: remove 'ai_stop_continuous' from private data
    
    This member of the private data can be determined by checking the cmd->stop_src.
    Do that instead.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 56e781203f055e93e2ff510d87a986e2b367c071
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:36 2014 -0700

    staging: comedi: addi_apci_2032: tidy up cmd use in apci2032_interrupt()
    
    Use a local variable for the comedi_cmd and tidy up this function a bit.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f1c51faabc4d974cd118603e237aa5381437e634
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:35 2014 -0700

    staging: comedi: adl_pci9111: tidy up (*do_cmdtest) Step 4
    
    This step in the (*do_cmdtest) fixes the comedi_cmd arguments, usually
    for TRIG_TIMER sources.
    
    Tidy up this step to clarify the code and remove the extra local
    variables. All the arguments are unsigned long so change the 'tmp'
    local variable type and rename it for aesthetics.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8412a96127d2866a78dc8d73eeaedac688977f4f
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:34 2014 -0700

    staging: comedi: 8253.h: remove the unused i8253_cascade_ns_to_timer_*()
    
    None of the comedi drivers use the i8253_cascade_ns_to_timer_2div_old()
    or i8253_cascade_ns_to_timer_power() helpers to calculate the cascaded
    divisors. Remove them to avoid any confusion.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d33f88581d2bb06470cb12eb048d70ebdec6fee2
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:33 2014 -0700

    staging: comedi: 8253.h: rename i8253_cascade_ns_to_timer_2div()
    
    All of the comedi drivers use the i8253_cascade_ns_to_timer macro
    when calculating the divisors for the cascaded timers. This macro
    just causes the i8253_cascade_ns_to_timer_2div() inline to be used.
    
    Rename i8253_cascade_ns_to_timer_2div() and remove the macro.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1265c22fc8575e857f0a0573db263b507988f420
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:32 2014 -0700

    staging: comedi: das1800: don't calc pacer divisors twice
    
    The analog input async command can use the pacer for the scan_begin_src
    or the convert_src. The (*do_cmdtest) calculates the divisors when
    validating the cmd argument.
    
    There is no reason to recalc the divisors in the (*do_cmd). Just use the
    values from the private data.
    
    For aesthetics, rename the setup_counters() function so it has namespace
    associated with the driver. Refactor the function to use the values from
    the private data and absorb das1800_set_frequency() to clarify the code.
    Refactor the function to use the i8254_set_mode() and i8254_write()
    helpers instead of i8254_load(). This allows us to use the I8254_* defines
    when setting the mode to clarify the code.
    
    This function will not fail so change the return type to void to simplify
    the (*do_cmd) a bit.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 66fea98e6251e15d25965ef805786e8e0b1c5ee4
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:31 2014 -0700

    staging: comedi: das1800: refactor Step 4 of das1800_ai_do_cmdtest()
    
    Refactor this code to reduce the indent level and the > 80 char
    lines.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 863e07c9f83c9674c0176771c40b56b48657e1e5
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:30 2014 -0700

    staging: comedi: das16m1: don't calc pacer divisors twice
    
    The analog input async command can use the pacer for the convert_src. The
    (*do_cmdtest) calculates the divisors when validating the cmd argument.
    
    There is no reason to recalc the divisors in the (*do_cmd). Just use the
    values from the private data.
    
    Refactor das16m1_set_pacer() to use the i8254_set_mode() and i8254_write()
    helpers instead of i8254_load(). This allows us to use the I8254_* defines
    when setting the mode to clarify the code.
    
    Tidy up das16m1_cmd_exec() a bit. The pacer only needs to be set when the
    convert_src is TRIG_TIMER.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 33eafb7761d244a3d41a25b56dd17ba05634907e
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:29 2014 -0700

    staging: comedi: cb_pcidas: don't calc ao pacer divisors twice
    
    The analog output async command can use the pacer for the scan_begin_src.
    The (*do_cmdtest) calculates the divisors when validating the cmd argument.
    
    There is no reason to recalc the divisors in the (*do_cmd). Just use the
    values from the private data.
    
    For aesthetics, factor out the code that loads the counters to match the
    analog input. Refactor the code to use the i8254_set_mode() and i8254_write()
    helpers instead of i8254_load(). This allows us to use the I8254_* defines
    when setting the mode to clarify the code.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f513b63f73e8bebc67a74dd46917788bfdf9c7cd
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 12:59:28 2014 -0700

    staging: comedi: cb_pcidas: don't calc ai pacer divisors twice
    
    The analog input async command can use the pacer for the scan_bagin_src
    or the convert_src. The (*do_cmdtest) validates that only one of these
    sources has the TRIG_TIMER selected and calculates the divisors when
    validating the cmd argument.
    
    There is no reason to recalc the divisors in the (*do_cmd). Just use
    the values from the private data.
    
    Also, refactor cb_pcidas_load_counters() to use the i8254_set_mode()
    and i8254_write() helpers instead of i8254_load(). This allows us to
    use the I8254_* defines when setting the mode to clarify the code.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8673804de08f047769d33858ad60a252b241bc76
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:43 2014 -0700

    staging: comedi: adv_pci1710: remove 'ai_act_chan' from private data
    
    This member of the private data is not ued by the driver. Remove it.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 576a09f01bea680e46df033634541f33a70640cf
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:42 2014 -0700

    staging: comedi: adv_pci1710: remove 'i8254_osc_base' from private data
    
    This member of the private data is always set to I8254_OSC_BASE_10MHZ. Remove
    it from the private data and just open code the value.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 16c7eb6047bb0261124dfc4b5e63873a9ca5c442
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:41 2014 -0700

    staging: comedi: adv_pci1710: always enable PCI171x_PARANOIDCHECK code
    
    This define enables code that checks for analog input channel dropout
    when reading samples. The define is enabled so we might as well always
    enable the code and remove the define.
    
    Factor out the common channel dropout detect code as a helper function
    and cleanup the code.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e2d8c43b4eed79dee4248b040e6d66c447ccac3b
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:40 2014 -0700

    staging: comedi: adv_pci1710: rename interrupt helper functions
    
    For aesthetics, rename the helper functions that are called by
    the interrupt function to handle reading the analog input samples.
    
    Also, change the parameters to the helpers to the comedi_device
    and comedi_subdevice pointers.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 925ddefce0e9eec2412d03ceaa40f57323d09fec
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:39 2014 -0700

    staging: comedi: adv_pci1710: tidy up start_pacer()
    
    For aesthetics, rename this function so it has namespace associated
    with the driver.
    
    Change the parameters to the function. The 'mode' is really a flag to
    load the counters and the divisors can be found in the private data.
    
    To clarify the code and remove the magic numbers, use the 8253.h
    helpers to set the timer mode and load the counters.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 335733438f703a4a54478360759b75ff1d24ebda
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:38 2014 -0700

    staging: comedi: adv_pci1710: remove local var in pci171x_ai_cmd()
    
    The local variable 'mode' is not necessary. We can determine the mode
    by checking the cmd->convert_src and cmd->start_src. Do this instead
    to clarify the code.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 73bcf01cb8c57c699c2a194fef3bad9bd39d6e1a
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:37 2014 -0700

    staging: comedi: adv_pci1710: only calc the pacer divisors once
    
    When the cmd->convert_src == TRIG_TIMER the divisors needed to
    generate the pacer time are calculated in the (*do_cmdtest) to
    validate the cmd->convert_arg. The core always does the (*do_cmdtest)
    before the (*do_cmd) so there is no reason to recalc the divisors.
    
    Save the calculated divisors in the private data as 'next_divisor[12]'.
    The (*do_cmd) then transfers them to the private data 'divisor[12]' so
    that they can be used to set the timer for the command immediately or
    later when the cmd->start_src is TRIG_EXT (mode 2 in this driver).
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5297a6ba0aba3d8c8238b53525a231a65fced0bf
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:36 2014 -0700

    staging: comedi: adv_pci1710: remove 'ai_eos' from private data
    
    This member of the private data is is not necessary. We can just check the
    cmd->flags for TRIG_WAKE_EOS when needed. Remvoe the member.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 17ac5ecf20e77833adbc01dcf82cb74c1e4c6896
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:35 2014 -0700

    staging: comedi: adv_pci1710: remove 'ai_buf_ptr' from private data
    
    This member of the private data is set to 0 but never used. Just remove it.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b4720286248acb7b696d95c72641c80bced6b3d3
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:34 2014 -0700

    staging: comedi: adv_pci1710: remove 'neverending_ai' from private data
    
    This member of the private data is not necessary. We can determine if
    the analog input command is neverending by checking the cmd->stop_src:
    
      TRIG_COUNT -> !neverending_ai
      TRIG_NONE -> neverending_ai
    
    Do that instead and remove the unnecessary member.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 56556577d9c4b4528935ddfc5635953c956d7fc9
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:33 2014 -0700

    staging: comedi: adv_pci1710: don't check the chanlist twice
    
    The chanlist is checked in Step 5 of the (*do_cmdtest) there is no
    reason to check it again in the (*do_cmd). The only reason its done
    again is to get the actual 'seglen', the non-repeating length of the
    chanlist.
    
    Save the 'seglen' found by pci171x_ai_check_chanlist() in the private
    data and use that in the (*do_cmd). Rename the private data member to
    clarify it. Also, remove the unused 'act_chanlist_pos' member from the
    private data.
    
    Refactor the error handling in pci171x_ai_check_chanlist() so it returns
    and errno for failure and 0 for success.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b5a7a466932e9d6da6221785b34854b1838a7061
Author: H Hartley Sweeten <[email protected]>
Date:   Tue Apr 29 11:08:32 2014 -0700

    staging: comedi: adv_pci1710: tidy up pci171x_ai_check_chanlist()
    
    Tidy up this function to clarify what the chanlist is being checked for.
    
    Signed-off-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4bac39f6c9b00c9cfc3e418ea1d0afcd1c113c2f
Author: Raghavendra Ganiga <[email protected]>
Date:   Thu May 1 13:53:12 2014 +0530

    staging: comedi: fix coding style issues in comedi_fops.c
    
    This is a patch to fix coding style
    warnings found by checkpatch.pl tool
    
    Signed-off-by: Raghavendra Chandra Ganiga <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 66d76f19d6aa863ac5b3e38be345daf9b609f226
Author: Chase Southwood <[email protected]>
Date:   Sat May 3 02:49:15 2014 -0500

    staging: comedi: addi_apci_1564: remove use of devpriv->s_EeParameters
    
    This driver no longer reads the eeprom to find the board specific data,
    all the necessary data is in the boardinfo. Use the boardinfo directly
    instead of passing through devpriv->s_EeParameters.
    
    Signed-off-by: Chase Southwood <[email protected]>
    Cc: Ian Abbott <[email protected]>
    Reviewed-by: H Hartley Sweeten <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a7e04a080831087e1413e5651c0bf59f5dcfa409
Author: Chase Southwood <[email protected]>
Date:   Tue Apr 29 03:37:17 2014 -0500

    staging: comedi: addi_apci_1564: remove unnecessary info from boardinfo
    
    The i_IorangeBase1, i_PCIEeprom, and pc_EepromChip data in the boardinfo
    was only needed to work out the usage of the PCI bars.  Now that that is
    squared away, this info is no longer needed and can be removed.
    
    Signed-off-by: Chase Southwood <[email protected]>
    Reviewed-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 128f798918c398b5ae84e5734c3b5df8c35d5d94
Author: Chase Southwood <[email protected]>
Date:   Wed Apr 30 02:57:59 2014 -0500

    staging: comedi: addi_apci_1564: simplify the PCI bar reading and don't read the unused bars
    
    This driver only uses PCI bar 0 (devpriv->i_IobaseAmcc), and PCI bar 1
    (dev->iobase), don't bother reading the unused PCI bars.
    
    Signed-off-by: Chase Southwood <[email protected]>
    Reviewed-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cffd83b6d1e6e403a77c5babf1443cdfd1a080ef
Author: Chase Southwood <[email protected]>
Date:   Tue Apr 29 03:34:23 2014 -0500

    staging: comedi: addi_apci_1564: board has 32 digital inputs
    
    This board always has 32 digital inputs. Remove the test when
    initializing the subdevice.
    
    Also, since this board is the only one supported by this driver,
    remove the boardinfo about the digital inputs and just use the
    data directly in the subdevice init.
    
    Signed-off-by: Chase Southwood <[email protected]>
    Reviewed-by: H Hartley Sweeten <[email protected]>
    Reviewed-by: Ian Abbott <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6aa4f14c1febf0f602c5516857303de9cc05d6e6
Author: Chase Southwood <[email protected]>
Date:   Sat Apr 26 20:36:44 2014 -0500

    staging: comedi: addi_apci_1564: remove unnecessary include
    
    This include is no longer needed.
    
    Signed-off-by: Chase Southwood <[email protected]>
    Cc: Ian Abbott <[email protected]>
    Reviewed-by: H Hartley Sweeten <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4ae63178637d03bca6b58336ad3e4b3af9e60339
Author: Chase Southwood <[email protected]>
Date:   Sat Apr 26 20:35:58 2014 -0500

    staging: comedi: addi_apci_1564: remove eeprom support code
    
    Reading the eeprom on this board is not necessary.  All information
    required is in the boardinfo.
    
    Remove the eeprom support code which is not really useful here.
    
    Signed-off-by: Chase So…
ddstreet referenced this pull request in ddstreet/linux May 12, 2014
@hnaz
linux-next
49de33b 
GIT 1297af7d710acda27fb289277866e0bcd81c72c8

commit 10d4c6736ea6e6ff293dd588551270bca00ca45d
Author: Petri Gynther <[email protected]>
Date:   Thu May 8 15:50:01 2014 -0700

    Bluetooth: btusb: Add Broadcom patch RAM support
    
    After hardware reset, some BCM Bluetooth adapters obtain their initial firmware
    from OTPROM chip. Once this initial firmware is running, the firmware can be
    further upgraded over HCI interface with .hcd files provided by Broadcom. This
    is also known as "patch RAM" support. This change implements that.
    
    If the .hcd file is not found in /lib/firmware, BCM Bluetooth adapter continues
    to operate with the initial firmware. Sample kernel log:
      hotplug: sys=firmware act=add fw=brcm/BCM20702A0-0a5c-22be.hcd dev=...
      Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-22be.hcd not found
    
    If the .hcd file is found, btusb driver pushes it to the BCM Bluetooth adapter and
    it starts using the new firmware. Sample kernel log:
      hotplug: sys=firmware act=add fw=brcm/BCM20702A0-0a5c-22be.hcd dev=...
      Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=1000 lmp_ver=06 lmp_subver=220e
      Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=1389 lmp_ver=06 lmp_subver=220e
    
    Above, we can see that hci_rev goes from 1000 to 1389 as a result of the upgrade.
    
    Signed-off-by: Petri Gynther <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit 79bc7681c2880e57f07556263b862bbf383ad209
Author: Seungwon Jeon <[email protected]>
Date:   Fri May 9 07:02:33 2014 +0900

    ARM: dts: disable MDMA1 node for exynos5420
    
    This change places MDMA1 in disabled node for Exynos5420.
    If MDMA1 region is configured with secure mode, it makes
    the boot failure with the following on smdk5420 board.
    ("Unhandled fault: imprecise external abort (0x1406) at 0x00000000")
    Thus, arndale-octa board don't need to do the same thing anymore.
    
    Signed-off-by: Seungwon Jeon <[email protected]>
    Tested-by: Javi Merino <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 88072246315301323b777465f5c9b643db87aff7
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:57:35 2014 +0900

    ARM: EXYNOS: Move the driver to drivers/cpuidle directory
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 5695f45e38ec1a861551f7d1cd177b5e81984b83
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:57:30 2014 +0900

    ARM: EXYNOS: Cleanup all unneeded headers from cpuidle.c
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 17c643ecf1219cf8d3b375bdfdc377b9cbc372ae
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:56:29 2014 +0900

    ARM: EXYNOS: Pass the AFTR callback to the platform_data
    
    No more dependency on the arch code. The platform_data field is used to set the
    PM callback as the other cpuidle drivers.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 7e4401689ed8c63cfb3f063107b1a07c58bb5830
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:56:24 2014 +0900

    ARM: EXYNOS: Move S5P_CHECK_SLEEP into pm.c
    
    This macro is only used there.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit f75751d7a1ddf0c3ccc71e0a7117a4be823303d1
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:55:12 2014 +0900

    ARM: EXYNOS: Move the power sequence call in the cpu_pm notifier
    
    The code to initiate and exit the powerdown sequence is the same in
    pm.c and cpuidle.c.
    
    Let's split the common part in the pm.c and reuse it from the cpu_pm notifier.
    
    That is one more step forward to make the cpuidle driver arch indenpendant.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 7ef8dd93099a531fc579648c17125d623e727262
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:53:00 2014 +0900

    ARM: EXYNOS: Move the AFTR state function into pm.c
    
    In order to remove depedency on pm code, let's move the 'exynos_enter_aftr'
    function into the pm.c file as well as the other helper functions.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 9c63359488c69a2ab5e0077baa747a9a03eeb909
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:52:59 2014 +0900

    ARM: EXYNOS: Encapsulate the AFTR code into a function
    
    Let's encapsulate the AFTR state specific call into a single function.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit d9679e49311b7138fa1cbcb20f6c8c3675cc6c1f
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:52:59 2014 +0900

    ARM: EXYNOS: Disable cpuidle for exynos5440
    
    There is no point to register the cpuidle driver for the 5440 as it has only
    one WFI state which is the default idle function when the cpuidle driver is
    disabled.
    
    By disabling cpuidle we prevent to enter to the governor computation for
    nothing, thus saving a lot of processing time.
    
    The only drawback is the statistic via sysfs on this state which is lost but
    it is meaningless and it could be retrieved from the ftrace easily.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Acked-by: Amit Kucheria <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 63f3ab27db4312c903bc268ac1f5a20a0a28119c
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:52:59 2014 +0900

    ARM: EXYNOS: Encapsulate boot vector code into a function for cpuidle
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit b00ca44f02e46a638a92608f257dceeefea1d54f
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:52:59 2014 +0900

    ARM: EXYNOS: Pass wakeup mask parameter to function for cpuidle
    
    Pass the wakeup mask to 'exynos_set_wakeupmask' as this function could
    be used for different idle states with different mask.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit ac5369f51081126692fc44ab637ed3c3681ea79a
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:53:26 2014 +0900

    ARM: EXYNOS: Remove ifdef for scu_enable in pm
    
    The scu_enable function is already a noop in the scu's header file is
    CONFIG_SMP=n, so no need to use these macros in the code.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit efb148f681d8376122ff60d5c36aa3592d4c2c0d
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:50:16 2014 +0900

    ARM: EXYNOS: Move scu_enable in the cpu_pm notifier
    
    We make the cpuidle code less arch dependent.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 5e5ee768f80860605ec66fe9e4052db82a7166c5
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:43:27 2014 +0900

    ARM: EXYNOS: Use the cpu_pm notifier for pm
    
    Use the cpu_pm_enter/exit notifier to group some pm code inside the
    pm file.
    
    The save and restore code is duplicated across pm.c and cpuidle.c. By
    using the cpu_pm notifier, we can factor out the routine.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 04d2981f15dc93bd52a2c8431afb1456dae7c8fc
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:43:27 2014 +0900

    ARM: EXYNOS: Fix S5P_WAKEUP_STAT call for cpuidle
    
    This function should be called only when the powerdown sequence fails.
    
    Even if the current code does not hurt, by moving this line, we have
    the same code than the one in pm.c.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit ff15bf49dcce85acd4220512dc30523a12e3bb81
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:43:27 2014 +0900

    ARM: EXYNOS: Move some code inside the idle_finisher for cpuidle
    
    Move the code around to differentiate different section of code and
    prepare it to be factored out in the next patches.
    
    The call order changed but hat doesn't have a side effect because
    they are independent. The important call is cpu_do_idle() which must
    be done the last.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit e102ca61840e80ef6e347e81b17b2eff088290e9
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:43:27 2014 +0900

    ARM: EXYNOS: Encapsulate register access inside a function for pm
    
    That makes the code cleaner and encapsulted. The function will be
    reused in the next patch.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 905e625e9411841cfc1ede8886f8df6153babd19
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:43:26 2014 +0900

    ARM: EXYNOS: Change function name prefix for cpuidle
    
    The driver was initially written for exynos4 but the driver is used
    also for exynos5.
    
    Change the function prefix name exynos4 -> exynos
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit c60cdc63176588a0e715e4da3984a3ea0efc5858
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:43:26 2014 +0900

    ARM: EXYNOS: Use cpuidle_register
    
    Use the cpuidle generic function 'cpuidle_register'. That saves us
    from some extra lines of code and unneeded variables.
    
    A side effect of this change is a bug fix where before the cpuidle
    driver was registered for each_online_cpu and now it is for
    each_possible_cpu.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 59b52960dac2e4d35959a459f5ef2895927e95c1
Author: Daniel Lezcano <[email protected]>
Date:   Fri May 9 06:43:26 2014 +0900

    ARM: EXYNOS: Prevent forward declaration for cpuidle
    
    Move the structure below the 'exynos4_enter_lowpower' function so no
    more need of forward declaration.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Reviewed-by: Viresh Kumar <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit cfbad697765dea7eb0478ae4234dd3a35cbb8f16
Author: Amit Daniel Kachhap <[email protected]>
Date:   Fri May 9 06:43:26 2014 +0900

    ARM: EXYNOS: Move arm core power down clock to exynos5250 common clock
    
    Now with common clock support added for exynos5250 it is necessary to
    move this code to exynos5250 common clock driver as clock registers
    should be handled there. This change is tested in exynos5250 based
    arndale platform.
    
    Cc: Abhilash Kesavan <[email protected]>
    Cc: Thomas Abraham <[email protected]>
    Acked-by: Kukjin Kim <[email protected]>
    Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]>
    Signed-off-by: Amit Daniel Kachhap <[email protected]>
    [t.figa: Rebased onto current kernel sources.]
    Signed-off-by: Tomasz Figa <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 9c88669c2cfc91158f157b5584103ff7e5b6bedb
Author: Axel Lin <[email protected]>
Date:   Wed Apr 9 17:21:26 2014 +0800

    pwm: twl: Really disable twl6030 PWMs
    
    Current twl6030_pwm_disable() implementation writes TWL6030_TOGGLE3_REG
    twice, the second write sets TWL6030_PWMXEN bits so the PWM clock does
    not disable.
    
    Signed-off-by: Axel Lin <[email protected]>
    Acked-by: Peter Ujfalusi <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>

commit 29a61d83ad2da88bbbadb554b72fdd2c3bb36c63
Author: Ivan Khoronzhuk <[email protected]>
Date:   Thu May 8 17:31:01 2014 -0400

    ARM: dts: k2l-evm: add AEMIF/NAND device entry
    
    Add AEMIF/NAND device entry.
    
    Signed-off-by: Ivan Khoronzhuk <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 81141a027c5d0c49373e4af7d068b0ca5ad6442a
Author: Rahul Sharma <[email protected]>
Date:   Fri May 9 06:26:44 2014 +0900

    ARM: dts: add dts files for exynos5260-xyref5260 board
    
    The patch adds the dts files for xyref5260 board which
    is based on exynos5260 SoC.
    
    Signed-off-by: Rahul Sharma <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit af6cf11c31763c49c8f0a64e4be23fab58bb019e
Author: Rahul Sharma <[email protected]>
Date:   Fri May 9 06:26:41 2014 +0900

    ARM: dts: add dts files for exynos5260 SoC
    
    The patch adds the dts files for exynos5260.
    
    Signed-off-by: Pankaj Dubey <[email protected]>
    Signed-off-by: Rahul Sharma <[email protected]>
    Signed-off-by: Arun Kumar K <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Reviewed-by: Sachin Kamat <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 95711059c5286b320ca08ebc33966994ac26d5aa
Author: Jens Axboe <[email protected]>
Date:   Thu May 8 15:26:30 2014 -0600

    blk-mq: cleanup some leftover code from the double tagging scheme
    
    Don't need ->use_bitmap_tags anymore, and we need not print
    what kind of tagging type we selected.
    
    Signed-off-by: Jens Axboe <[email protected]>

commit 8b144ffd7b6c8edbdc881b0a32858e1447fa441f
Author: Ivan Khoronzhuk <[email protected]>
Date:   Thu May 8 17:19:08 2014 -0400

    ARM: dts: k2e-evm: add AEMIF/NAND device entry
    
    Add AEMIF/NAND device entry.
    
    Signed-off-by: Ivan Khoronzhuk <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 4bfb5edef0cc4387d0760f5eb2d0dcfabc237b95
Author: Kyungmin Park <[email protected]>
Date:   Fri May 9 06:19:18 2014 +0900

    ARM: EXYNOS: Support secondary CPU boot of exynos4212
    
    This patch fix the offset of CPU boot address and change parameter of smc call
    of SMC_CMD_CPU1BOOT command for Exynos4212.
    
    Signed-off-by: Kyungmin Park <[email protected]>
    Signed-off-by: Chanwoo Choi <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit b10fd728b985ae2d18ce9bf4c2161a6eb002683c
Author: Jens Axboe <[email protected]>
Date:   Thu May 8 15:12:07 2014 -0600

    mtip32xx: convert to use blk-mq
    
    This rips out timeout handling, requeueing, etc in converting
    it to use blk-mq instead.
    
    Signed-off-by: Jens Axboe <[email protected]>

commit 437ec65fa3c937b5f8b9c0573f60a327320937e3
Author: Jens Axboe <[email protected]>
Date:   Thu May 8 15:05:12 2014 -0600

    blk-mq: implement new and more efficient tagging scheme
    
    blk-mq currently uses percpu_ida for tag allocation. But that only
    works well if the ratio between tag space and number of CPUs is
    sufficiently high. For most devices and systems, that is not the
    case. The end result if that we either only utilize the tag space
    partially, or we end up attempting to fully exhaust it and run
    into lots of lock contention with stealing between CPUs. This is
    not optimal.
    
    This new tagging scheme is a hybrid bitmap allocator. It uses
    two tricks to both be SMP friendly and allow full exhaustion
    of the space:
    
    1) We cache the last allocated (or freed) tag on a per blk-mq
       software context basis. This allows us to limit the space
       we have to search. The key element here is not caching it
       in the shared tag structure, otherwise we end up dirtying
       more shared cache lines on each allocate/free operation.
    
    2) The tag space is split into cache line sized groups, and
       each context will start off randomly in that space. Even up
       to full utilization of the space, this divides the tag users
       efficiently into cache line groups, avoiding dirtying the same
       one both between allocators and between allocator and freeer.
    
    This scheme shows drastically better behaviour, both on small
    tag spaces but on large ones as well. It has been tested extensively
    to show better performance for all the cases blk-mq cares about.
    
    Signed-off-by: Jens Axboe <[email protected]>

commit 78bb0b8c61ab00fb1c61653464ab6c26e8b47558
Author: Jens Axboe <[email protected]>
Date:   Thu May 8 15:03:42 2014 -0600

    wait: make prepare_to_wait() return if it added task to wait queue
    
    The caller can make some decisions based on whether or not the
    task was already on the waitqueue. blk-mq will use this for
    batched wakeups on tag frees.
    
    Signed-off-by: Jens Axboe <[email protected]>

commit 3528dd34b2d3dc642669fd12399e18a16e3aacc8
Author: Arun Kumar K <[email protected]>
Date:   Fri May 9 06:06:25 2014 +0900

    ARM: dts: Add exynos5420 peach-pit board support
    
    Adds the google peach-pit board dts file which uses
    exynos5420 SoC.
    
    Signed-off-by: Arun Kumar K <[email protected]>
    Signed-off-by: Doug Anderson <[email protected]>
    Reviewed-by: Doug Anderson <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 8e371a91d98e8d8d032c6032eb0ac6e2bbcb231f
Author: Arun Kumar K <[email protected]>
Date:   Fri May 9 06:06:24 2014 +0900

    ARM: dts: Add node labels to exynos5420
    
    Adding labels to nodes which do not have it yet in exynos5420.
    This is done so as to use reference based node updation in board
    files.
    
    Signed-off-by: Arun Kumar K <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Reviewed-by: Doug Anderson <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit c4539e88e758901c298ee1f6c0e19471be693f54
Author: Arun Kumar K <[email protected]>
Date:   Fri May 9 06:06:10 2014 +0900

    ARM: dts: Add pwmX_out pinctrl nodes to exynos5420
    
    Adds the PWM nodes to 5420 pinctrl dtsi file.
    
    Signed-off-by: Arun Kumar K <[email protected]>
    Reviewed-by: Doug Anderson <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 4cb378646ef85e76745225912025871f3dc93ca3
Author: Sylwester Nawrocki <[email protected]>
Date:   Fri May 9 06:01:40 2014 +0900

    ARM: dts: Add rear camera nodes for exynos4412-trats2
    
    This patch enables the rear facing camera (s5c73m3) on TRATS2 board
    by adding the I2C0 bus controller, s5c73m3 sensor, MIPI CSI-2 receiver
    and the sensor's voltage regulator supply nodes.
    
    Signed-off-by: Andrzej Hajda <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Sylwester Nawrocki <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit ee5eda64af051097c00534db7c5432c4a061d355
Author: Sylwester Nawrocki <[email protected]>
Date:   Fri May 9 06:00:35 2014 +0900

    ARM: dts: Update camera nodes for exynos4 and exynos4412-trats2
    
    Remove unused /camera/clock-controller node and add required clock
    properties to the camera node. This is required for a clock provider
    that will be referenced by image sensor devices.
    Also add required clock related changes to s5k6a3 device node and
    afvdd regulator supply.
    
    Signed-off-by: Sylwester Nawrocki <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 6af2ba90818f9e9c4b8711e1f896e797c5da151c
Author: Tomasz Stanislawski <[email protected]>
Date:   Fri May 9 05:58:59 2014 +0900

    ARM: dts: rename alias for i2c_ak8975 label for exynos4412-trats2
    
    The i2c_ak8975 controller uses label i2c8.
    This alias is already used for I2C controller 8 defined
    in file arch/arm/boot/dts/exynos4.dtsi.
    
    This patch renames a label for i2c_ak8975 to i2c9.
    
    Signed-off-by: Tomasz Stanislawski <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 9c869d1f07852b47ae8578c14161ec2821682464
Author: Tomasz Stanislawski <[email protected]>
Date:   Fri May 9 05:55:42 2014 +0900

    ARM: dts: add missing pinctrls for I2C of exynos4
    
    This patch adds missing pinctrls for I2C controllers 2-7.
    
    Signed-off-by: Tomasz Stanislawski <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit c92ecf94d3156f79825a994e509aa070ceebae88
Author: Christoph Hellwig <[email protected]>
Date:   Tue May 6 12:12:45 2014 +0200

    blk-mq: initialize struct request fields individually
    
    This allows us to avoid a non-atomic memset over ->atomic_flags as well
    as killing lots of duplicate initializations.
    
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit face4c34519c38eda4020ab9964e5b55fcfbaa4a
Author: Heiko Stuebner <[email protected]>
Date:   Fri May 9 05:51:43 2014 +0900

    ARM: S3C24XX: remove SAMSUNG_CLOCK remnants after ccf conversion
    
    This finally removes all remaining SAMSUNG_CLOCK conditional code
    from s3c24xx architectures.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 8fb211f9c6c32e938ebbc03e6de6300156f911d7
Author: Jens Axboe <[email protected]>
Date:   Thu May 8 14:50:19 2014 -0600

    blk-mq: update a hotplug comment for grammar
    
    Signed-off-by: Jens Axboe <[email protected]>

commit 597000cf07742cd218d1c16bc7600fa2a6a884cd
Author: Heiko Stuebner <[email protected]>
Date:   Fri May 9 05:49:36 2014 +0900

    ARM: S3C24XX: remove legacy clock code
    
    With the move to the common clock framework completed for s3c2410, s3c2440
    and s3c2442, the legacy clock code for these machines can go away too.
    
    This also includes the legacy dclk code, as all legacy users are converted.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 355c9f77a6d9f41f390bb776b7e561458afbcf39
Author: Heiko Stuebner <[email protected]>
Date:   Fri May 9 05:49:29 2014 +0900

    ARM: S3C24XX: convert s3c2410 to common clock framework
    
    Convert the machines using the s3c2410 to use the new driver based
    on the common clock framework instead of the legacy Samsung clock driver.
    
    As with the s3c244x, machines using the clkout output will need a fixup
    from someone with the hardware.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit abe9f29b0471d1e7ff1ef4ae94bcc6b1525e15f9
Author: Heiko Stuebner <[email protected]>
Date:   Fri May 9 05:49:19 2014 +0900

    ARM: S3C24XX: convert s3c2440 and s3c2442 to common clock framework
    
    Convert all machines using these cpus to use the ccf clock driver
    instead of the legacy Samsung clock implementation.
    
    Some of the more esotheric machines will probably need a fixup, as they
    do strange things to the clkout outputs, that I did not really understand
    nor have the hardware to check.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 1a54e4342c42e01f0117c05d8bb2c9309cc435e8
Author: Heiko Stuebner <[email protected]>
Date:   Fri May 9 05:49:14 2014 +0900

    ARM: S3C24XX: add platform code for conversion to the common clock framework
    
    This adds the necessary init functions to init the clocks from the common
    clock framework and necessary CONFIG_SAMSUNG_CLOCK ifdefs around the legacy
    clock code.
    
    This also includes empty stubs for the *_setup_clocks functions that are
    called from the cpufreq driver on resume.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 6dc8f9c7783546483d0b86e18e78896c2d31ae86
Author: Heiko Stuebner <[email protected]>
Date:   Fri May 9 05:49:10 2014 +0900

    clk: samsung: add clock controller driver for s3c2410, s3c2440 and s3c2442
    
    This driver can handle the clock controllers of the socs mentioned above,
    as they share a common clock tree with only small differences.
    
    The clock structure is built according to the manuals of the included
    SoCs and might include changes in comparison to the previous clock
    structure.
    
    As pll-rate-tables only the 12mhz variants are currently included.
    The original code was wrongly checking for 169mhz xti values [a 0 to much
    at the end], so the original 16mhz pll table would have never been
    included and its values are so obscure that I have no possibility to
    at least check their sane-ness. When using the formula from the manual
    the resulting frequency is near the table value but still slightly off.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Acked-by: Mike Turquette <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 639335c0f488b948c8946f2ba421113544905587
Author: Heiko Stuebner <[email protected]>
Date:   Fri May 9 05:49:05 2014 +0900

    dt-bindings: add documentation for s3c2410 clock controller
    
    Describe the clock controller of s3c2410, s3c2440 and s3c2442.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Acked-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 4d4cfe75853f61219b08244748d1d4f9634726db
Author: Heiko Stuebner <[email protected]>
Date:   Fri May 9 05:48:57 2014 +0900

    ARM: S3C24XX: enable usage of common dclk if common clock framework is enabled
    
    Add platform device and select the correct implementation automatically
    depending on wether the old samsung_clock or the common clock framework
    is enabled.
    
    This is only done for machines already using the old dclk implementation,
    as everybody else should move to use dt anyway.
    
    The machine-specific settings for the external clocks will have to be set
    by somebody with knowledge about the specific hardware.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 5799ea12a41286d9588155a1abd828f43bc63d6b
Author: Heiko Stuebner <[email protected]>
Date:   Fri May 9 05:48:51 2014 +0900

    clk: samsung: add clock driver for external clock outputs
    
    This adds a driver for controlling the external clock outputs of
    s3c24xx architectures including the dclk muxes and dividers.
    
    The driver at the moment only supports the legacy non-dt boards using these
    clock outputs. The clock-output control itself is part of the system-controller
    mainly controlled by the pinctrl drivers. So it should most likely be
    integrated there for dt platforms.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Acked-by: Mike Turquette <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit d8b532578f39fdec159105bc415938910351a699
Author: Heiko Stuebner <[email protected]>
Date:   Fri May 9 05:48:44 2014 +0900

    ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf
    
    The s3c24xx cpufreq driver needs to change the mpll speed and was doing
    this by writing raw values from a translation table into the MPLLCON
    register.
    
    Change this to use a regular clk_set_rate call when using the common
    clock framework and only write the raw value in the samsung_clock case.
    
    The s3c cpufreq driver does already aquire the mpll, so simply add a reference
    to struct s3c_cpufreq_config to let set_fvco access it.
    
    While struct clk is opaque the differenciation between samsung clock and
    common clock is kept, as the samsung-clock mpll clk does not implement a
    real set_rate.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Acked-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 1eaade629f5c479f5f043c8c24e5daa7029b5e2e
Author: Jens Axboe <[email protected]>
Date:   Thu May 8 14:46:27 2014 -0600

    blk-mq: track software context online status seperately
    
    By separating it from the system notion of a specific CPU
    being online or not, we get away from problems with ordering
    of the CPU hotplug notifiers.
    
    Signed-off-by: Jens Axboe <[email protected]>

commit 14f3791439b5a6cf12127fb80204265533d92664
Author: Santosh Shilimkar <[email protected]>
Date:   Mon Feb 24 17:32:59 2014 +0200

    ARM: keystone: Update the dma offset for non-dt platform devices
    
    Tested-by: Grygorii Strashko <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 5eb3da7246a5b2dfac9f38a7be62b1a0295584c7
Author: Santosh Shilimkar <[email protected]>
Date:   Thu Jun 13 19:24:39 2013 -0400

    ARM: keystone: Switch over to coherent memory address space
    
    With late code patching updates for LPAE machines has merged now and
    memblock conversion from bootmem is on its way, Keystone can switch to
    the coherent memory address space which starts beyond 4GB boundary.
    The idmap alias needs are managed via virt_to_idmap() for boot purpose.
    
    Tested-by: Grygorii Strashko <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 27379350a9cb6f39e136325d33b9cc9357da263e
Author: Brian Norris <[email protected]>
Date:   Thu May 8 15:34:28 2014 -0400

    ARM: configs: keystone: add MTD_SPI_NOR (new dependency for M25P80)
    
    This defconfig contains the CONFIG_M25P80 symbol, which is now
    dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to satisfy
    the new dependency.
    
    Signed-off-by: Brian Norris <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit efdd1946c44e0d5fdf36e03176705260145d122b
Author: Lad Prabhakar <[email protected]>
Date:   Thu May 8 15:32:46 2014 -0400

    ARM: configs: keystone: drop CONFIG_COMMON_CLK_DEBUG
    
    this patch removes COMMON_CLK_DEBUG config option
    from defconfig file as this config option is obsolete.
    
    Signed-off-by: Lad, Prabhakar <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 86156978a398dfc92294653c49c9374aaa6e5316
Author: Santosh Shilimkar <[email protected]>
Date:   Mon Feb 24 16:42:19 2014 -0500

    ARM: dts: keystone: Update USB node for dma properties
    
    Keystone supports dma-coherent on USB master and also needs
    dma-ranges to specify the hardware alias memory range in which DMA
    can be operational.
    
    Cc: Russell King <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Olof Johansson <[email protected]>
    Cc: Grant Likely <[email protected]>
    Cc: Rob Herring <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 4d46596d789d86441eeb1f02bb6d9ea10215fa5d
Author: Grygorii Strashko <[email protected]>
Date:   Wed Feb 12 19:20:16 2014 +0200

    ARM: dts: keystone: Use dma-ranges property
    
    The dma-ranges property has to be specified per bus and has format:
     < DMA addr > - Base DMA address for Bus (Bus format 32-bits)
     < CPU addr > - Corresponding base CPU address (CPU format 64-bits)
     < DMA range size > - Size of supported DMA range
    
    Cc: Russell King <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Olof Johansson <[email protected]>
    Cc: Grant Likely <[email protected]>
    Cc: Rob Herring <[email protected]>
    Signed-off-by: Grygorii Strashko <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 509046a7b00cf540e49d3072b1efe7cb0b1bdc20
Author: Grygorii Strashko <[email protected]>
Date:   Mon Apr 28 15:20:22 2014 +0300

    ARM: dts: keystone: add cell's information to spi nodes
    
    SPI nodes should always have #address-cells and #size-cells defined,
    otherwise warnings will be produced in case of adding any child
    nodes to the SPI bus in DT:
    Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/spi@21000400/n25q128a11@0
    Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/spi@21000400/n25q128a11@0
    
    Hence, ensure that all SPIx nodes have #address-cells and #size-cells
    properties defined.
    
    Signed-off-by: Grygorii Strashko <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit e42d8a7f966b7b3b817adece0573d07754a647d2
Author: Grygorii Strashko <[email protected]>
Date:   Tue Apr 8 14:46:07 2014 +0300

    ARM: dts: keystone: move i2c0 device node from SoC to board files
    
    I2C devices are not the part of Keystone SoC and have to be
    defined in board DTS files.
    Hence, move i2c0 EEPROM device node from Keystone SoC to
    k2hk, k2e, k2l EVM files as they all have similar EEPROM SoCs
    installed.
    
    Signed-off-by: Grygorii Strashko <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 3953505afbb80bfcf0e9dc2ba7199e63b0fef69f
Author: Grygorii Strashko <[email protected]>
Date:   Tue Apr 8 14:46:06 2014 +0300

    ARM: dts: keystone: add cell's information to i2c nodes
    
    I2C nodes should always have #address-cells and #size-cells defined,
    otherwise warnings will be produced in case of adding child
    nodes to the I2C bus in DT:
    Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/i2c@2530800/pca@20
    Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/i2c@2530800/pca@20
    
    Hence, ensure that all i2cX nodes have #address-cells and #size-cells
    properties defined.
    
    Signed-off-by: Grygorii Strashko <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 5e014d0c020d37af897a0867bc1840f098bf3cee
Author: Lucas Stach <[email protected]>
Date:   Mon Apr 14 16:18:13 2014 +0200

    ARM: dts: keystone: drop address and size cells from GIC node
    
    This is likely a copy-and-paste error from the
    ARM GIC documentation, that has already been fixed.
    
    address-cells should have been set to 0, as with the size
    cells. As having those properties set to 0 is the
    same thing as not specifying them, drop them completely.
    
    Signed-off-by: Lucas Stach <[email protected]>
    Acked-by: Rob Herring <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 9fa1959e976f7a6ae84f616ca669359028070c61
Author: Kinglong Mee <[email protected]>
Date:   Tue Apr 8 13:06:28 2014 +0800

    NFSD: Get rid of empty function nfs4_state_init
    
    Signed-off-by: Kinglong Mee <[email protected]>
    Signed-off-by: J. Bruce Fields <[email protected]>

commit f3e41ec5ef0f5d2e10b6bfd3a13dc29f6d260d79
Author: Kinglong Mee <[email protected]>
Date:   Tue Apr 8 13:04:01 2014 +0800

    NFSD: Use simple_read_from_buffer for coping data to userspace
    
    Signed-off-by: Kinglong Mee <[email protected]>
    Signed-off-by: J. Bruce Fields <[email protected]>

commit ecca063b31b88d31ee79e9d958ea78023659554e
Author: Kinglong Mee <[email protected]>
Date:   Tue Apr 15 17:13:56 2014 +0800

    SUNRPC: Fix printk that is not only for nfsd
    
    Signed-off-by: Kinglong Mee <[email protected]>
    Signed-off-by: J. Bruce Fields <[email protected]>

commit c5c0903b2cda930c76d296419d290137294779f2
Author: Borislav Petkov <[email protected]>
Date:   Thu May 8 20:37:07 2014 +0200

    EDAC, MCE, AMD: Remove leftover unused mask
    
    295d8cda2689 ("EDAC, MCE, AMD: Drop local coreid reporting") removed the
    code snippet which used that mask but forgot to drop the mask itself. Do
    that now.
    
    Signed-off-by: Borislav Petkov <[email protected]>

commit 0cac6fc3eb5218fe40d1c2910abc643ab21d9f19
Author: Vinod Koul <[email protected]>
Date:   Mon May 5 14:27:52 2014 +0530

    ASoC: Intel: rename pcm dias to media dai
    
    this is for further updates to driver which supports DPCM :)
    
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 6f46c0d33e76db2c820c47e9af61e0e3dba10a68
Author: Vinod Koul <[email protected]>
Date:   Mon May 5 14:27:51 2014 +0530

    ASoC: Intel: remove unused sst-mfld platform dais
    
    With DPCM we have media dai used and no seperate headset and speaker dai so
    remove the speaker dai
    The vibra is no longer supported thru audio, so remove
    
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 4b68b4e1c564f32e4eb18186749b29c9a78772f4
Author: Vinod Koul <[email protected]>
Date:   Mon May 5 14:27:50 2014 +0530

    ASoC: Intel: split the pcm and compress to different files
    
    For manging them and adding support for more platforms
    Code move only
    
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 4496ffab7dade2206f3d5dea86b9928a5f173de2
Author: Vinod Koul <[email protected]>
Date:   Mon May 5 14:27:49 2014 +0530

    ASoC: Intel: mark sst_set_stream_status as non static
    
    as this will be used in compressed split file in subsequent patch
    
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit e11fd7c3ac49e2294f9562b6329ca50923e56fa7
Author: Vinod Koul <[email protected]>
Date:   Mon May 5 14:27:48 2014 +0530

    ASoc: Intel: rename sst-mfld-platform.c
    
    to sst-mfld-platform-pcm.c so that we can split pcm and compress to different
    files for upcoming changes to support more platforms
    
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 300f53bf199f660bea3ed7afe9fd938064f19c15
Author: Vinod Koul <[email protected]>
Date:   Mon May 5 14:27:47 2014 +0530

    ASoC: Intel: remove FSF snail mail address
    
    As this address can move
    
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 2b4c78df056a7231635cf629380486a074daf56b
Author: Vinod Koul <[email protected]>
Date:   Mon May 5 22:19:25 2014 +0530

    ASoC: Intel: move component registration blob
    
    to the place near it is used
    
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 555f8a80c397b1a6ffccb294525df6ca2d721585
Author: Liam Girdwood <[email protected]>
Date:   Mon May 5 17:31:37 2014 +0100

    ASoC: Intel: Add support to unload/reload firmware modules.
    
    Add some SST API calls to unload and reload firmware modules. This can be used
    by PM code to restore state and also allow modular FW to unload and release
    memory blocks.
    
    Signed-off-by: Liam Girdwood <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 6f1c9c57b4e0783acca9c0fe53850f24d30785a3
Author: Charles Keepax <[email protected]>
Date:   Thu May 8 17:17:38 2014 +0100

    regulator: arizona-micsupp: Add missing #include
    
    of.h is presently being included through asm-generic/gpio.h so will not
    be included on some architectures, causing implicit declaration errors
    for of_get_child_by_name, of_parse_phandle and of_node_put.
    
    This patch adds the direct include that should be there.
    
    Reported-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Charles Keepax <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 9f0affcf3e21fc56d8bce625bb3d5800b7a7d284
Author: Vincent Stehlé <[email protected]>
Date:   Tue May 6 22:23:02 2014 +0200

    ARM: mvebu: Fix pmsu compilation when ARMv6 is selected
    
    When compiling for multiplatform for both ARMv6 and ARMv7, the default compiler
    flags are for ARMv6, and we will get:
    
      /tmp/ccwDEzd0.s: Assembler messages:
      /tmp/ccwDEzd0.s:639: Error: selected processor does not support ARM mode `isb '
      /tmp/ccwDEzd0.s:645: Error: selected processor does not support ARM mode `isb '
      /tmp/ccwDEzd0.s:646: Error: selected processor does not support ARM mode `dsb '
      /tmp/ccwDEzd0.s:695: Error: selected processor does not support ARM mode `isb '
      make[1]: *** [arch/arm/mach-mvebu/pmsu.o] Error 1
    
    Fix this in a similar manner than done previously in commit
    72533b77d30c2be02672e26b5dde1263d7b4c2be, by specifying ARMv7 flags for pmsu.o.
    
    Signed-off-by: Vincent Stehlé <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Cc: Jason Cooper <[email protected]>
    Cc: Andrew Lunn <[email protected]>
    Cc: Gregory Clement <[email protected]>
    Cc: Sebastian Hesselbarth <[email protected]>
    Cc: Russell King <[email protected]>
    Signed-off-by: Jason Cooper <[email protected]>

commit 5409e46f1bcf960c651f3fff35f2f25e539655cf
Author: Christoph Hellwig <[email protected]>
Date:   Wed May 7 13:49:44 2014 +0200

    nfsd: clean up fh_auth usage
    
    Use fh_fsid when reffering to the fsid part of the filehandle.  The
    variable length auth field envisioned in nfsfh wasn't ever implemented.
    Also clean up some lose ends around this and document the file handle
    format better.
    
    Btw, why do we even export nfsfh.h to userspace?  The file handle very
    much is kernel private, and nothing in nfs-utils include the header
    either.
    
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: J. Bruce Fields <[email protected]>

commit ecc7455d8eb1860f5aa6b9ad82a9a81f93eb11d1
Author: Kinglong Mee <[email protected]>
Date:   Wed May 7 23:08:04 2014 +0800

    NFSD: cleanup unneeded including linux/export.h
    
    commit 4ac7249ea5a0ceef9f8269f63f33cc873c3fac61 have remove all EXPORT_SYMBOL,
    linux/export.h is not needed, just clean it.
    
    Signed-off-by: Kinglong Mee <[email protected]>
    Signed-off-by: J. Bruce Fields <[email protected]>

commit aa07c713ecfc0522916f3cd57ac628ea6127c0ec
Author: Kinglong Mee <[email protected]>
Date:   Fri Apr 18 20:49:04 2014 +0800

    NFSD: Call ->set_acl with a NULL ACL structure if no entries
    
    After setting ACL for directory, I got two problems that caused
    by the cached zero-length default posix acl.
    
    This patch make sure nfsd4_set_nfs4_acl calls ->set_acl
    with a NULL ACL structure if there are no entries.
    
    Thanks for Christoph Hellwig's advice.
    
    First problem:
    ............ hang ...........
    
    Second problem:
    [ 1610.167668] ------------[ cut here ]------------
    [ 1610.168320] kernel BUG at /root/nfs/linux/fs/nfsd/nfs4acl.c:239!
    [ 1610.168320] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
    [ 1610.168320] Modules linked in: nfsv4(OE) nfs(OE) nfsd(OE)
    rpcsec_gss_krb5 fscache ip6t_rpfilter ip6t_REJECT cfg80211 xt_conntrack
    rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
    ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
    ip6table_mangle ip6table_security ip6table_raw ip6table_filter
    ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
    nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw
    auth_rpcgss nfs_acl snd_intel8x0 ppdev lockd snd_ac97_codec ac97_bus
    snd_pcm snd_timer e1000 pcspkr parport_pc snd parport serio_raw joydev
    i2c_piix4 sunrpc(OE) microcode soundcore i2c_core ata_generic pata_acpi
    [last unloaded: nfsd]
    [ 1610.168320] CPU: 0 PID: 27397 Comm: nfsd Tainted: G           OE
    3.15.0-rc1+ #15
    [ 1610.168320] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
    VirtualBox 12/01/2006
    [ 1610.168320] task: ffff88005ab653d0 ti: ffff88005a944000 task.ti:
    ffff88005a944000
    [ 1610.168320] RIP: 0010:[<ffffffffa034d5ed>]  [<ffffffffa034d5ed>]
    _posix_to_nfsv4_one+0x3cd/0x3d0 [nfsd]
    [ 1610.168320] RSP: 0018:ffff88005a945b00  EFLAGS: 00010293
    [ 1610.168320] RAX: 0000000000000001 RBX: ffff88006700bac0 RCX:
    0000000000000000
    [ 1610.168320] RDX: 0000000000000000 RSI: ffff880067c83f00 RDI:
    ffff880068233300
    [ 1610.168320] RBP: ffff88005a945b48 R08: ffffffff81c64830 R09:
    0000000000000000
    [ 1610.168320] R10: ffff88004ea85be0 R11: 000000000000f475 R12:
    ffff880068233300
    [ 1610.168320] R13: 0000000000000003 R14: 0000000000000002 R15:
    ffff880068233300
    [ 1610.168320] FS:  0000000000000000(0000) GS:ffff880077800000(0000)
    knlGS:0000000000000000
    [ 1610.168320] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [ 1610.168320] CR2: 00007f5bcbd3b0b9 CR3: 0000000001c0f000 CR4:
    00000000000006f0
    [ 1610.168320] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000
    [ 1610.168320] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400
    [ 1610.168320] Stack:
    [ 1610.168320]  ffffffff00000000 0000000b67c83500 000000076700bac0
    0000000000000000
    [ 1610.168320]  ffff88006700bac0 ffff880068233300 ffff88005a945c08
    0000000000000002
    [ 1610.168320]  0000000000000000 ffff88005a945b88 ffffffffa034e2d5
    000000065a945b68
    [ 1610.168320] Call Trace:
    [ 1610.168320]  [<ffffffffa034e2d5>] nfsd4_get_nfs4_acl+0x95/0x150 [nfsd]
    [ 1610.168320]  [<ffffffffa03400d6>] nfsd4_encode_fattr+0x646/0x1e70 [nfsd]
    [ 1610.168320]  [<ffffffff816a6e6e>] ? kmemleak_alloc+0x4e/0xb0
    [ 1610.168320]  [<ffffffffa0327962>] ?
    nfsd_setuser_and_check_port+0x52/0x80 [nfsd]
    [ 1610.168320]  [<ffffffff812cd4bb>] ? selinux_cred_prepare+0x1b/0x30
    [ 1610.168320]  [<ffffffffa0341caa>] nfsd4_encode_getattr+0x5a/0x60 [nfsd]
    [ 1610.168320]  [<ffffffffa0341e07>] nfsd4_encode_operation+0x67/0x110
    [nfsd]
    [ 1610.168320]  [<ffffffffa033844d>] nfsd4_proc_compound+0x21d/0x810 [nfsd]
    [ 1610.168320]  [<ffffffffa0324d9b>] nfsd_dispatch+0xbb/0x200 [nfsd]
    [ 1610.168320]  [<ffffffffa00850cd>] svc_process_common+0x46d/0x6d0 [sunrpc]
    [ 1610.168320]  [<ffffffffa0085433>] svc_process+0x103/0x170 [sunrpc]
    [ 1610.168320]  [<ffffffffa032472f>] nfsd+0xbf/0x130 [nfsd]
    [ 1610.168320]  [<ffffffffa0324670>] ? nfsd_destroy+0x80/0x80 [nfsd]
    [ 1610.168320]  [<ffffffff810a5202>] kthread+0xd2/0xf0
    [ 1610.168320]  [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40
    [ 1610.168320]  [<ffffffff816c1ebc>] ret_from_fork+0x7c/0xb0
    [ 1610.168320]  [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40
    [ 1610.168320] Code: 78 02 e9 e7 fc ff ff 31 c0 31 d2 31 c9 66 89 45 ce
    41 8b 04 24 66 89 55 d0 66 89 4d d2 48 8d 04 80 49 8d 5c 84 04 e9 37 fd
    ff ff <0f> 0b 90 0f 1f 44 00 00 55 8b 56 08 c7 07 00 00 00 00 8b 46 0c
    [ 1610.168320] RIP  [<ffffffffa034d5ed>] _posix_to_nfsv4_one+0x3cd/0x3d0
    [nfsd]
    [ 1610.168320]  RSP <ffff88005a945b00>
    [ 1610.257313] ---[ end trace 838254e3e352285b ]---
    
    Signed-off-by: Kinglong Mee <[email protected]>
    Cc: [email protected]
    Signed-off-by: J. Bruce Fields <[email protected]>

commit 39438567179536c9f32e85d19586a11aebe1f860
Author: Thomas Petazzoni <[email protected]>
Date:   Mon May 5 17:05:26 2014 +0200

    ARM: mvebu: conditionalize Armada 375 coherency workaround
    
    The Armada 375 coherency workaround only needs to be applied to the Z1
    revision of the SoC. The A0 and later revisions have been fixed, and
    no longer need this workaround.
    
    Signed-off-by: Thomas Petazzoni <[email protected]>
    Link: https://lkml.kernel.org/r/1399302326-6917-6-git-send-email-thomas.petazzoni@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit a58d5af7d992a5e6dd8e55b3e618bd77f0368b57
Author: Thomas Petazzoni <[email protected]>
Date:   Mon May 5 17:05:25 2014 +0200

    ARM: mvebu: conditionalize Armada 375 SMP workaround
    
    The Armada 375 SMP workaround only needs to be applied to the Z1
    revision of the SoC. The A0 and later revisions have been fixed, and
    no longer need this workaround.
    
    Note that the initialization of the SMP workaround is delayed from
    ->smp_prepare_cpus() to ->smp_boot_secondary() because when
    ->smp_prepare_cpus() is called, the early initcalls have not be
    called, so the mvebu-soc-id mechanism is not operational. Since the
    workaround is anyway not needed before the secondary CPU is started,
    we can delay its implementation until the ->smp_boot_secondary() call.
    
    Signed-off-by: Thomas Petazzoni <[email protected]>
    Link: https://lkml.kernel.org/r/1399302326-6917-5-git-send-email-thomas.petazzoni@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit 5093dcfb422d212ccdd22450bd986a2fb03cfb9f
Author: Thomas Petazzoni <[email protected]>
Date:   Mon May 5 17:05:24 2014 +0200

    ARM: mvebu: add Armada 375 A0 revision definition
    
    Now that we have access to Armada 375 A0 platforms, we can add the
    corresponding revision definition in mvebu-soc-id.h.
    
    Signed-off-by: Thomas Petazzoni <[email protected]>
    Link: https://lkml.kernel.org/r/1399302326-6917-4-git-send-email-thomas.petazzoni@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit 73c3c79137f05de2ffcfec3469e4110e40dd1522
Author: Thomas Petazzoni <[email protected]>
Date:   Mon May 5 17:05:23 2014 +0200

    ARM: mvebu: initialize mvebu-soc-id earlier
    
    Currently, the mvebu-soc-id logic is initialized through a
    core_initcall(). However, we will soon need to know the SoC revision
    before booting secondary CPUs, because a workaround affects Armada 375
    Z1 steppings, but should not be applied on Armada 375 A0 steppings.
    
    Unfortunately, core_initcall() are called way too late compared to the
    SMP initialization. Therefore, the mvebu-soc-id initialization is move
    to an early_initcall(), which is called before the SMP initialization.
    
    Signed-off-by: Thomas Petazzoni <[email protected]>
    Link: https://lkml.kernel.org/r/1399302326-6917-3-git-send-email-thomas.petazzoni@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit c1a01a0360f6744c9c1735e5db7b208df819156e
Author: Thomas Petazzoni <[email protected]>
Date:   Mon May 5 17:05:22 2014 +0200

    ARM: mvebu: fix thermal quirk SoC revision check
    
    In commit 54fe26a900bc528f3df1e4235cb6b9ca5c6d4dc2 ('ARM: mvebu: Add
    thermal quirk for the Armada 375 DB board'), a check on the Armada SoC
    revision was added to decide whether a quirk for the thermal device
    should be applied or not.
    
    However, the quirk implementation has a bug: it assumes
    mvebu_get_soc_id() returns true on success, but it returns
    0. Therefore, the condition:
    
      if (mvebu_get_soc_id(&dev, &rev) && rev > ARMADA_375_Z1_REV)
    
    is always false (as long as mvebu-soc-id is properly initialized). As
    a consequence, the quirk is always applied, even on A0 steppings, for
    which the quirk should not be applied.
    
    This was spotted by testing the thermal driver on Armada 375 A0, which
    Ezequiel could not do since he does not have access to the A0 revision
    of the SoC for the moment.
    
    Signed-off-by: Thomas Petazzoni <[email protected]>
    Link: https://lkml.kernel.org/r/1399302326-6917-2-git-send-email-thomas.petazzoni@free-electrons.com
    Fixes: 54fe26a900bc528f3df1e4235cb6b9ca5c6d4dc2 ('ARM: mvebu: Add thermal quirk for the Armada 375 DB board')
    Acked-by: Ezequiel Garcia <[email protected]>
    Signed-off-by: Jason Cooper <[email protected]>

commit efdf811d82b8001781087fd9174bb90a9530e578
Author: Andrew Lunn <[email protected]>
Date:   Sat May 3 20:30:16 2014 +0200

    ARM: Kirkwood: t5325: Remove platform device to instantiate audio
    
    Remove platform device instantiating of the audio, which results in
    board-t5325.c being removed. A DT node will be added to take its
    place.
    
    Signed-off-by: Andrew Lunn <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Jason Cooper <[email protected]>

commit 7745b2512898e23507753513f7b5262ea1458135
Author: Andrew Lunn <[email protected]>
Date:   Sat May 3 20:30:12 2014 +0200

    ARM: Kirkwood: Remove platform driver for codec
    
    Remove the platform driver and platform data for the audio codec.
    A DT node will replace it.
    
    Signed-off-by: Andrew Lunn <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Jason Cooper <[email protected]>

commit 5fd62066d2900b25a4fb3295ad13e3ee31474a51
Author: Ezequiel Garcia <[email protected]>
Date:   Thu Apr 24 17:23:22 2014 -0300

    ARM: mvebu: Add thermal quirk for the Armada 375 DB board
    
    The initial release of the Armada 375 DB board has an Armada 375
    Z1 stepping silicon. This commit introduces a quirk that allows
    to workaround a series of issues with the thermal sensor in this
    stepping, but updating the devicetree:
    
      * Updates the compatible string for the thermal, so the driver
        can perform a specific initialization of the sensor.
    
      * Moves the offset of the thermal control register. This quirk
        allows to specifiy the correct (A0 stepping) offset in the
        devicetree.
    
    Signed-off-by: Ezequiel Garcia <[email protected]>
    Link: https://lkml.kernel.org/r/1398371004-15807-9-git-send-email-ezequiel.garcia@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit e9d3c849a8dc92e1019a6c7ced98f6ac231a2703
Author: Ezequiel Garcia <[email protected]>
Date:   Thu Apr 24 08:34:36 2014 -0300

    ARM: mvebu: Select HAVE_ARM_TWD only if SMP is enabled
    
    HAVE_ARM_TWD depends on SMP, so we should only select it if
    SMP is enabled, as the others platforms do.
    
    Signed-off-by: Ezequiel Garcia <[email protected]>
    Link: https://lkml.kernel.org/r/1398339276-5754-1-git-send-email-ezequiel.garcia@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit 8eee0f81cdaafb2fc78dcd5087a15c7f428d7751
Author: Gregory CLEMENT <[email protected]>
Date:   Sat Apr 19 18:32:50 2014 +0200

    ARM: mvebu: fix the name of the parameter used in mvebu_get_soc_id
    
    The name of the two parameters of mvebu_get_soc_id were inverted. This
    patch fix it in order to have a more readable code.
    
    Reported-by: Ezequiel Garcia <[email protected]>
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Link: https://lkml.kernel.org/r/1397925170-8202-3-git-send-email-gregory.clement@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit c42e1ffa269f098133629adf54cabe242596b647
Author: Gregory CLEMENT <[email protected]>
Date:   Sat Apr 19 18:32:49 2014 +0200

    ARM: mvebu: remove unnecessary ifdef around l2x0_of_init
    
    l2x0_of_init function is always defined
    arch/arm/include/asm/hardware/cache-l2x0.h: in case of
    CONFIG_CACHE_L2X0 is not selected then a placeholder is defined.
    Then there is no need to have ifdef around  l2x0_of_init.
    
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Reviewed-by: Thomas Petazzoni <[email protected]>
    Link: https://lkml.kernel.org/r/1397925170-8202-2-git-send-email-gregory.clement@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit 8c16babc6476111efabafbb262b47f8309942403
Author: Gregory CLEMENT <[email protected]>
Date:   Mon Apr 14 17:10:14 2014 +0200

    ARM: mvebu: register the cpuidle driver for the Armada XP SoCs
    
    The cpuidle is a platform driver so we register the device just after
    the initialization of the board in an arch_initcall.
    
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Link: https://lkml.kernel.org/r/1397488214-20685-12-git-send-email-gregory.clement@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit b858fbc1919720f7f54360098ece03b383e961fa
Author: Gregory CLEMENT <[email protected]>
Date:   Mon Apr 14 17:10:13 2014 +0200

    cpuidle: mvebu: Add initial CPU idle support for Armada 370/XP SoC
    
    Add the wfi, cpu idle and cpu deep idle power states support for the
    Armada XP SoCs.
    
    All the latencies and the power consumption values used at the
    "armada_370_xp_idle_driver" structure are preliminary and will be
    modified in the future after running some measurements and analysis.
    
    Based on the work of Nadav Haklai.
    
    Signed-off-by: Nadav Haklai <[email protected]>
    Link: https://lkml.kernel.org/r/1397488214-20685-11-git-send-email-gregory.clement@free-electrons.com
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Link: https://lkml.kernel.org/r/1397488214-20685-11-git-send-email-gregory.clement@free-electrons.com
    Acked-by: Daniel Lezcano <[email protected]>
    Signed-off-by: Jason Cooper <[email protected]>

commit d163ee165bd49a51f77bae632ebf37eda4899d0e
Author: Gregory CLEMENT <[email protected]>
Date:   Mon Apr 14 17:10:12 2014 +0200

    ARM: mvebu: Register notifier callback for the cpuidle transition
    
    In order to have well encapsulated code, we use notifier callbacks for
    CPU_PM_ENTER and CPU_PM_EXIT inside the mvebu power management code.
    
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Link: https://lkml.kernel.org/r/1397488214-20685-10-git-send-email-gregory.clement@free-electrons.com
    Acked-by: Daniel Lezcano <[email protected]>
    Signed-off-by: Jason Cooper <[email protected]>

commit 0041464ceeccd4718de228141438335e2d92f91b
Author: Thomas Petazzoni <[email protected]>
Date:   Mon Apr 28 20:20:39 2014 +0200

    ARM: mvebu: refine which files are build in mach-mvebu
    
    Following the integration into mach-mvebu of the Kirkwood ARMv5
    support, we need to be more careful about which files get built. For
    example, the pmsu.c file now calls wfi(), which only exists on ARMv7
    platforms.
    
    Therefore, this commit changes mach-mvebu/Makefile to build the Armada
    370/XP/375/38x specific files only when CONFIG_MACH_MVEBU_V7 is
    enabled.
    
    Signed-off-by: Thomas Petazzoni <[email protected]>
    Link: https://lkml.kernel.org/r/1398709239-6126-1-git-send-email-thomas.petazzoni@free-electrons.com
    Acked-by: Gregory CLEMENT <[email protected]>
    Signed-off-by: Jason Cooper <[email protected]>

commit c3e04cabb135625df8ff4b71ef4130f0ccbcc669
Author: Gregory CLEMENT <[email protected]>
Date:   Mon Apr 14 17:10:11 2014 +0200

    ARM: mvebu: Add the PMSU related part of the cpu idle functions
    
    The cpu idle support will need to access to Power Management Service
    Unit. This commit adds the architecture related functions that will be
    used in the idle path of the cpuidle driver.
    
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Link: https://lkml.kernel.org/r/1397488214-20685-9-git-send-email-gregory.clement@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit f713c7e7421d6945c977c8d8813e8089f925de41
Author: Gregory CLEMENT <[email protected]>
Date:   Mon Apr 14 17:10:10 2014 +0200

    ARM: mvebu: Allow to power down L2 cache controller in idle mode
    
    This commit adds a function which adjusts the PMSU configuration to
    automatically power down the L2 and coherency fabric when we enter a
    certain idle state.
    
    This feature is part of the Power Management Service Unit of the
    Armada 370 and Armada XP SoCs.
    
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Link: https://lkml.kernel.org/r/1397488214-20685-8-git-send-email-gregory.clement@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit 1a6bfbc339b6a2b59a8f88fa494fe70073cdb85a
Author: Gregory CLEMENT <[email protected]>
Date:   Mon Apr 14 17:10:09 2014 +0200

    ARM: mvebu: Low level function to disable HW coherency support
    
    When going to deep idle we need to disable the SoC snooping (aka
    hardware coherency support). Playing with the coherency fabric
    requires to use assembly code to be sure that the compiler doesn't
    reorder the instructions nor do wrong optimization.
    
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Link: https://lkml.kernel.org/r/1397488214-20685-7-git-send-email-gregory.clement@free-electrons.com
    Signed-off-by: Jason Cooper <[email protected]>

commit 2e8a5942f8751c03fdd50228a02909654d13f01d
Author: Gregory CLEMENT <[email protected]>
Date:   Mon Apr 14 17:10:08 2014 +0200

    ARM: mvebu: Split low level functions to manipulate HW coherency
    
    Actually enabling coherency and adding a CPU on a SMP group are two
    different operations…
ddstreet pushed a commit to ddstreet/linux that referenced this pull request May 13, 2014
@bebarino
clk: Fix double free due to devm_clk_register()
293ba3b 
Now that clk_unregister() frees the struct clk we're
unregistering we'll free memory twice: first we'll call kfree()
in __clk_release() with an address kmalloc doesn't know about and
second we'll call kfree() in the devres layer. Remove the
allocation of struct clk in devm_clk_register() and let
clk_release() handle it. This fixes slab errors like:

=============================================================================
BUG kmalloc-128 (Not tainted): Invalid object pointer 0xed08e8d0
-----------------------------------------------------------------------------

Disabling lock debugging due to kernel taint
INFO: Slab 0xeec503f8 objects=25 used=15 fp=0xed08ea00 flags=0x4081
CPU: 2 PID: 73 Comm: rmmod Tainted: G    B         3.14.0-11032-g526e9c764381 torvalds#34
[<c0014be0>] (unwind_backtrace) from [<c0012240>] (show_stack+0x10/0x14)
[<c0012240>] (show_stack) from [<c04b74dc>] (dump_stack+0x70/0xbc)
[<c04b74dc>] (dump_stack) from [<c00f6778>] (slab_err+0x74/0x84)
[<c00f6778>] (slab_err) from [<c04b6278>] (free_debug_processing+0x2cc/0x31c)
[<c04b6278>] (free_debug_processing) from [<c04b6300>] (__slab_free+0x38/0x41c)
[<c04b6300>] (__slab_free) from [<c03931bc>] (clk_unregister+0xd4/0x140)
[<c03931bc>] (clk_unregister) from [<c02fb774>] (release_nodes+0x164/0x1d8)
[<c02fb774>] (release_nodes) from [<c02f8698>] (__device_release_driver+0x60/0xb0)
[<c02f8698>] (__device_release_driver) from [<c02f9080>] (driver_detach+0xb4/0xb8)
[<c02f9080>] (driver_detach) from [<c02f8480>] (bus_remove_driver+0x5c/0xc4)
[<c02f8480>] (bus_remove_driver) from [<c008c9b8>] (SyS_delete_module+0x148/0x1d8)
[<c008c9b8>] (SyS_delete_module) from [<c000ef80>] (ret_fast_syscall+0x0/0x48)
FIX kmalloc-128: Object at 0xed08e8d0 not freed

Fixes: fcb0ee6 (clk: Implement clk_unregister)
Cc: Jiada Wang <[email protected]>
Cc: Sylwester Nawrocki <[email protected]>
Cc: Kyungmin Park <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Mike Turquette <[email protected]>
Cc: [email protected]
ddstreet referenced this pull request in ddstreet/linux May 19, 2014
@hnaz
linux-next
1a9bf46 
GIT 0856ad1ef175c45dc6a0bc629ca355fdfbb1001e

commit 8b1cbef71a7e83afa78455451d59d96d4228e6a9
Author: Dan Carpenter <[email protected]>
Date:   Fri May 16 09:36:14 2014 +1000

    These days most people use git to send patches so I have added a section
    about that.
    
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>

commit ded80c15f78fb796a7fd1d664abbef5c6f42ff97
Author: Randy Dunlap <[email protected]>
Date:   Fri May 16 09:36:13 2014 +1000

    Note that I don't maintain Documentation/ABI/,
    Documentation/devicetree/, or the language translation files.
    
    Signed-off-by: Randy Dunlap <[email protected]>

commit eafaebd987fcd001e2c123c050939a29c625d673
Author: Sebastian Reichel <[email protected]>
Date:   Fri Mar 28 20:19:44 2014 +0100

    HSI: Introduce Nokia N900 modem driver
    
    The Nokia N900's modem is connected via Synchronous Serial Interface (SSI),
    which is a legacy version of MIPI's High-speed Synchronous Serial Interface
    (HSI).
    
    The handles the GPIOs for enabling and resetting the modem and instanciates
    ssi-protocol for data exchange. It does not yet support exchanging voice data
    with the modem.
    
    Signed-off-by: Sebastian Reichel <[email protected]>
    Reviewed-by: Pavel Machek <[email protected]>
    Tested-By: Ivaylo Dimitrov <[email protected]>

commit dc7bf5d7186849aa36b9f0e42e250a813a7b0bdb
Author: Sebastian Reichel <[email protected]>
Date:   Fri Nov 15 10:50:32 2013 +0000

    HSI: Introduce driver for SSI Protocol
    
    This adds a driver for the SSI McSAAB protocol as used in
    the Nokia N900.
    
    Signed-off-by: Carlos Chinea <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Tested-By: Ivaylo Dimitrov <[email protected]>

commit dc9df3154c082873591acf95036632e97215212e
Author: Sebastian Reichel <[email protected]>
Date:   Sun Dec 15 23:43:10 2013 +0100

    Documentation: DT: omap-ssi binding documentation
    
    Create device tree binding documentation for
    OMAP Synchronous Serial Interface (SSI) device.
    
    Signed-off-by: Sebastian Reichel <[email protected]>
    Reviewed-by: Pavel Machek <[email protected]>

commit b209e047bc743247f74ce79e8827ae1ed556bae0
Author: Sebastian Reichel <[email protected]>
Date:   Sun Dec 15 23:38:58 2013 +0100

    HSI: Introduce OMAP SSI driver
    
    Add OMAP SSI driver to the HSI subsystem.
    
    The Synchronous Serial Interface (SSI) is a legacy version
    of HSI. As in the case of HSI, it is mainly used to connect
    Application engines (APE) with cellular modem engines (CMT)
    in cellular handsets.
    
    It provides a multichannel, full-duplex, multi-core communication
    with no reference clock. The OMAP SSI block is capable of reaching
    speeds of 110 Mbit/s.
    
    Signed-off-by: Carlos Chinea <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Tested-By: Ivaylo Dimitrov <[email protected]>

commit a2aa24734d9dbbd3b9062c2459936c336278fa6a
Author: Sebastian Reichel <[email protected]>
Date:   Fri Mar 28 22:59:43 2014 +0100

    HSI: Add common DT binding for HSI client devices
    
    Implement and document generic DT bindings for HSI clients.
    
    Signed-off-by: Sebastian Reichel <[email protected]>
    Reviewed-by: Pavel Machek <[email protected]>
    Tested-By: Ivaylo Dimitrov <[email protected]>

commit 8491451024bcfabdcebd772ce9ec2fc5757acd42
Author: Sebastian Reichel <[email protected]>
Date:   Fri Mar 28 22:54:25 2014 +0100

    HSI: export method to (un)register clients
    
    Expose method for registering and unregistering HSI clients, so that
    client drivers can register other client drivers.
    
    This is useful for HSI drivers, which want to use the functionality
    of other HSI drivers. For example the N900 modem driver can load HSI
    drivers for mcsaab protocol and speech protocol.
    
    Signed-off-by: Sebastian Reichel <[email protected]>
    Reviewed-by: Pavel Machek <[email protected]>
    Tested-By: Ivaylo Dimitrov <[email protected]>

commit a088cf161cc87b39e83c7c53b9f239773422d212
Author: Sebastian Reichel <[email protected]>
Date:   Fri Mar 28 22:48:23 2014 +0100

    HSI: Add channel resource support to HSI clients
    
    Make HSI channel ids platform data, which can be provided
    by platform data.
    
    Signed-off-by: Sebastian Reichel <[email protected]>
    Tested-By: Ivaylo Dimitrov <[email protected]>

commit a0bf37edb4d34c21bdaa19a1624378924b917491
Author: Sebastian Reichel <[email protected]>
Date:   Sun Oct 6 20:23:49 2013 +0200

    HSI: method to unregister clients from an hsi port
    
    This exports a method to unregister all clients from
    an hsi port.
    
    Signed-off-by: Sebastian Reichel <[email protected]>
    Reviewed-by: Pavel Machek <[email protected]>
    Tested-By: Ivaylo Dimitrov <[email protected]>

commit ba8f073281fe0b6d50332bf005dd023ecf51efa9
Author: Fabio Falzoi <[email protected]>
Date:   Tue Apr 22 23:23:04 2014 +0200

    Staging: rts5139: More appropriate use of sizeof operand
    
    Use the pointer rts51x to get the size of the struct.
    
    Signed-off-by: Fabio Falzoi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c606525d76d16702de1b40fcf017e63f31c270c1
Author: Fabio Falzoi <[email protected]>
Date:   Tue Apr 22 23:23:03 2014 +0200

    Staging: rts5139: Removed OOM messages
    
    All allocation Out Of Memory messages removed.
    We rely on the generic OOM message in dump_stack().
    
    Signed-off-by: Fabio Falzoi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4b3ef391c320b112d140f991dbde5da9c651a690
Author: Fabio Falzoi <[email protected]>
Date:   Tue Apr 22 23:23:02 2014 +0200

    Staging: rts5139: Use standard pr_<level> prefixing
    
    Define pr_fmt macro to prefix every pr_<level> function in standard way.
    
    Signed-off-by: Fabio Falzoi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7cb61930110358a62b6ef0564707ba9e201a535e
Author: Fabio Falzoi <[email protected]>
Date:   Tue Apr 22 23:23:01 2014 +0200

    Staging: rts5139: Splitted one-line multiple assignment
    
    Splitted a multiple assignment on two separate lines.
    
    Signed-off-by: Fabio Falzoi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 307a433e3d3072df727aba851595eac328d1ab4d
Author: Fabio Falzoi <[email protected]>
Date:   Tue Apr 22 23:23:00 2014 +0200

    Staging: rts5139: Fixed multi-line code alignment
    
    Multi-line code aligned with open parenthesis.
    
    Signed-off-by: Fabio Falzoi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fd09d1de70480e0534eb57b0c8eb19ffbdab1d95
Author: Fabio Falzoi <[email protected]>
Date:   Tue Apr 22 23:22:59 2014 +0200

    Staging: rts5139: Camel case labels replaced
    
    Replace camel case labels with linux coding style compliant names.
    
    Signed-off-by: Fabio Falzoi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2787b99fd62f01af33bea5a076b665e128c67177
Author: Camille Bordignon <[email protected]>
Date:   Sun Apr 6 18:21:27 2014 +0200

    staging: sep: Fix coding style
    
    Fix coding style warning "Missing a blank line after declarations"
    
    Signed-off-by: Camille Bordignon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3136b5fee2be0c177b381b62aa5da8dd8eb3ef94
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:24 2014 +0100

    staging: vt6656: Remove PIPEnsControlOutAsyn/CONTROLnsRequestOutAsyn
    
    This now the same as PIPEnsControlOut.
    
    Replace with PIPEnsControlOut/CONTROLnsRequestOut.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0fb2af353f11ea939b29c8cf07ce70a3882824cc
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:23 2014 +0100

    staging: vt6656: PIPEnsControlIn use usb_control_msg
    
    Now that this function is nolonger atomic useusb_control_msg.
    
    Return STATUS_FAILURE if ntStatus less than wLength
    
    Remove the old struct urb and struct usb_ctrlrequest structures.
    
    Remove fMP_CONTROL_READS flag.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7021b684eb1efa9a349785f919e177c1b63af313
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:22 2014 +0100

    staging: vt6656: usbpipe.c PIPEnsControlOut use usb_control_msg
    
    Now that this fucntion is nolonger atomic change to usb_control_msg
    
    Return STATUS_FAILURE if ntStatus less than wLength.
    
    Remove fMP_CONTROL_WRITES flag
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3c647642f6658c693d090b12c1b5bf901f3b7440
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:21 2014 +0100

    staging: vt6656: lock changes device_xmit
    
    Replace locks with the spin_lock_irqsave and spin_unlock_irqrestore
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 29b02373f44d0d873a4f645b53c3cddce2f40f7b
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:20 2014 +0100

    staging: vt6656: lock changes: s_nsBulkInUsbIoCompleteRead.
    
    Use spin_lock_irqsave/spin_unlock_irqrestore
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c91b1869fb6f6d58f6321b8a88bd39577b0413a7
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:19 2014 +0100

    staging: vt6656: lock changes: usbpipe.c add mutex lock.
    
    PIPEnsControlOut and PIPEnsControlIn are nolonger
    atomic but they do need a usb lock.
    
    Add new mutex lock for these functions and PIPEnsControlOutAsyn.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 97641ca2b284ddc9870afdcfe22487702ee27b3e
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:18 2014 +0100

    staging: vt6656: lock changes: vRunCommand nsDMA_tx_packet
    
    vRunCommand is nolonger atomic add lock for nsDMA_tx_packet.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8783a1a4afa4e14cf134afc7838b23fcd745b996
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:17 2014 +0100

    staging: vt6656: lock changes: bMgrPrepareBeaconToSend add lock.
    
    bMgrPrepareBeaconToSend is nolonger atomic
    
    csBeacon_xmit must be locked add spin lock.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3bc552a1a0757d97cdbb04227536c101848b6a94
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:16 2014 +0100

    staging: vt6656: lock changes: vDMA0_tx_80211
    
    vDMA0_tx_80211 is atomically called.
    
    RFbSetPower can not be called atomically.
    
    If wCurrentRate is different to pDevice->wCurrentRate call
    bScheduleCommand WLAN_CMD_SETPOWER.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 931cb9ff6eefb5c0e92c1b170ba68f5453aab32f
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:15 2014 +0100

    staging: vt6656: lock changes: csMgmt_xmit.
    
    csMgmt_xmit is nolonger atomically called but part of must be.
    
    Reorder the function so that RFbSetPower is called first.
    
    Add new lock spinlock for the remainder of the function.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e03ce8393e41ddff574c95ac72378ed1f02cef54
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:14 2014 +0100

    staging: vt6656: lock changes: RXvMngWorkItem.
    
    Narrow atomic locks in RXvMngWorkItem.
    
    We must lock the DequeueRCB and RXvFreeRCB so that
    they are in sync.
    
    vMgrRxManagePacket can nolonger be atomically called.
    
    There is no need for an overall lock.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d1d4120f7fab69b32d40780b766109d377d743a7
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:13 2014 +0100

    staging: vt6656: lock changes: vRunCommand remove locks.
    
    Removing atomic locked paths to usbpipe.c PIPEnsControlOut and PIPEnsControlIn
    
    This function will nolonger need any locking.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7af94000fecf67ebea144a2a0427bdb6a795f890
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:12 2014 +0100

    staging: vt6656: lock changes: Remove spin locks.
    
    Remove atomic paths to usbpipe.c PIPEnsControlOut and PIPEnsControlIn
    
    Remove from
    PIPEnsControlOut
    PIPEnsControlIn
    BSSvSecondCallBack
    vt6656_hostap_ioctl
    iwctl_siwmode
    iwctl_siwencode
    iwctl_siwpower
    iwctl_siwencodeext
    KeyvInitTable
    device_init_registers
    device_open
    device_close
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 30a05b397ce410685532120e97c6cc378dd31a1f
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:11 2014 +0100

    staging: vt6656: struct vnt_usb_send_context remove camel case.
    
    Camel case changes
    pDevice -> priv
    pPacket -> skb
    pUrb -> urb
    uBufLen -> buf_len;
    bBoolInUse -> in_use
    Data -> data
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b674ee142296b84ea8514da52e9185dab4070b72
Author: Malcolm Priestley <[email protected]>
Date:   Thu May 15 22:49:10 2014 +0100

    staging: vt6656: nsDMA_tx_packet Move pContext later.
    
    call s_vGetFreeContext later in function skiping large
    chunk of code.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ccc3a5986daefdf0aef76f3664ac6848e3d9515e
Author: Denis Pithon <[email protected]>
Date:   Mon May 12 17:22:46 2014 +0200

    staging/wlan-ng: code refactoring
    
    Extract new static function from p80211netdev_rx_bh() to fix coding
    style issue (too many leading tabs).
    
    Signed-off-by: Denis Pithon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 05d39beeb865940852f469f1ce067cc7fa607a72
Author: Denis Pithon <[email protected]>
Date:   Mon May 12 17:22:45 2014 +0200

    staging/wlan-ng: remove function declaration
    
    Removed useless function prototype: static function p80211netdev_rx_bh()
    is defined before being used.
    
    Signed-off-by: Denis Pithon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 67c4ded5a3cfc666f149f2dee3ad5ae2f06f1736
Author: Denis Pithon <[email protected]>
Date:   Mon May 12 17:22:44 2014 +0200

    staging/wlan-ng: update function header comment
    
    Header comment of p80211netdev_rx_bh() does not match function
    prototype. Fixed.
    
    Signed-off-by: Denis Pithon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8cf22fda6272e5240a118f003d9222da5489af38
Author: Neil Armstrong <[email protected]>
Date:   Fri Apr 11 15:00:49 2014 +0200

    staging: wlan-ng: fix bad symbol declaration
    
    With sparse, the following error appears :
      CHECK   drivers/staging/wlan-ng/p80211netdev.c
    drivers/staging/wlan-ng/cfg80211.c:710:6: warning: symbol 'prism2_connect_result' was not declared. Should it be static?
    drivers/staging/wlan-ng/cfg80211.c:719:6: warning: symbol 'prism2_disconnected' was not declared. Should it be static?
    drivers/staging/wlan-ng/cfg80211.c:725:6: warning: symbol 'prism2_roamed' was not declared. Should it be static?
    
    Move functions declaration to coherent internal header file.
    
    Signed-off-by: Neil 'Superna' Armstrong <[email protected]>
    Reviewed-by: Josh Triplett <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5d85fe346fc34e1d5932974a95440297cd7a009f
Author: Sherif Shehab Aldin <[email protected]>
Date:   Sat Apr 5 23:35:15 2014 +0200

    driver: staging: wlan-ng: Removed unnecessary spaces after cast from hfa384x_usb.c
    
    Fixed: No space is necessary after a cast
    
    Signed-off-by: Sherif Shehab Aldin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 638f81b849a306e4a897f99f51e22ba515338e21
Author: Sherif Shehab Aldin <[email protected]>
Date:   Sat Apr 5 23:35:06 2014 +0200

    driver: staging: wlan-ng: Removed #if 0 lines from hfa384x_usb.c
    
    Removed lines that were ignored by #if 0
    
    Signed-off-by: Sherif Shehab Aldin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 96b1971ace70c563048d341bfc1bd55754b95183
Author: Sherif Shehab Aldin <[email protected]>
Date:   Sat Apr 5 23:34:56 2014 +0200

    driver: staging: wlan-ng: Removed multiple assignments
    
    Removed multiple assignments from hfa384x_usb.c
    
    Signed-off-by: Sherif Shehab Aldin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a3542e664bb10c10c52088efc460371225a939b0
Author: Sherif Shehab Aldin <[email protected]>
Date:   Sat Apr 5 23:34:48 2014 +0200

    driver: staging: wlan-ng: Fixed white spaces issues
    
    In hfa384x_usb.c:
    Moved Logical continuations to the correct lines
    Removed unnecessary blank lines
    
    Signed-off-by: Sherif Shehab Aldin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3f2d656481c64bad30f1f92b3834c6c2b5851916
Author: Sherif Shehab Aldin <[email protected]>
Date:   Sat Apr 5 23:34:40 2014 +0200

    driver: staging: wlan-ng: Fixed Alignment to match open parenthesis
    
    Fixed Alignment to match open parenthesis in hfa384x_usb.c
    
    Signed-off-by: Sherif Shehab Aldin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 83f91687b0922511eceddb9831e9f86c08bb3873
Author: Sherif Shehab Aldin <[email protected]>
Date:   Sat Apr 5 23:34:12 2014 +0200

    driver: staging: wlan-ng: Removed Unnecessary space after function pointer name
    
    Removed Unnecessary space after function pointer name
    
    Signed-off-by: Sherif Shehab Aldin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d6ae4a9995fa19ecde23f425a027f445074ba1ec
Author: Sherif Shehab Aldin <[email protected]>
Date:   Sat Apr 5 23:34:01 2014 +0200

    driver: staging: wlan-ng: Setting character pointers as const
    
    changed declaration of ctlx_str to:
    static const char * const ctlx_str[]
    
    Signed-off-by: Sherif Shehab Aldin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit baa8a6c008329de5dd6909658c7f892340e4b5f0
Author: Sherif Shehab Aldin <[email protected]>
Date:   Sat Apr 5 23:33:53 2014 +0200

    driver: staging: wlan-ng: switched to pr_warn
    
    changed printk(KERN_WARNING .. to pr_warn
    
    Signed-off-by: Sherif Shehab Aldin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a03742ac96fceac7b103aff7b9714605a21b8a3e
Author: Sherif Shehab Aldin <[email protected]>
Date:   Sat Apr 5 23:33:45 2014 +0200

    driver: staging: wlan-ng: Removed unnecessary typedefs from hfa384x_usb.c
    
    Removed unnecessary typedefs from hfa384x_usb.c
    
    Signed-off-by: Sherif Shehab Aldin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a21201369568a4e5bd23fb5cb9a966a1008637a6
Author: Sherif Shehab Aldin <[email protected]>
Date:   Sat Apr 5 23:33:16 2014 +0200

    driver: staging: wlan-ng: Fixed Breaking long lines and strings style rule
    
    Fixed coding style rule "Breaking long lines and strings" for hfa384x_usb.c
    
    Signed-off-by: Sherif Shehab Aldin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1b2a9d3fd4fec79876349ffdda088651af7b2119
Author: Vivek Gautam <[email protected]>
Date:   Fri May 16 06:38:15 2014 +0900

    ARM: dts: Update DWC3 usb controller to use new phy driver for exynos5250
    
    Removing the dt node for older usb3 phy driver from Exynos5250
    device tree and updating the dt node for DWC3 controller to
    use new phy driver based on generic phy framework.
    
    Signed-off-by: Vivek Gautam <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit dd47964d780a96ae3957f6c4d1243bf5d39a4118
Author: Vivek Gautam <[email protected]>
Date:   Fri May 16 06:38:10 2014 +0900

    ARM: dts: Enable support for generic USB DRD phy for exynos5250
    
    Add device tree node for new usbdrd-phy driver, which
    is based on generic phy framework.
    
    Signed-off-by: Vivek Gautam <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit bf963efe024e04d90396a6464bb179c68b2edbcb
Author: Vivek Gautam <[email protected]>
Date:   Fri May 16 06:38:01 2014 +0900

    ARM: dts: Enable support for DWC3 controller for exynos5420
    
    Add device tree nodes for DWC3 controller present on
    Exynos 5420 SoC, to enable support for USB 3.0.
    
    Signed-off-by: Vivek Gautam <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit d102e35f1cd364466ea848791a12a1229d4a9c39
Author: Vivek Gautam <[email protected]>
Date:   Fri May 16 06:37:03 2014 +0900

    ARM: dts: Enable support for USB 3.0 PHY controller for exynos5420
    
    Add device tree nodes for USB 3.0 PHY present alongwith
    USB 3.0 controller Exynos 5420 SoC. This phy driver is
    based on generic phy framework.
    
    Signed-off-by: Vivek Gautam <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit b7bb243924e9284f605368e22c3aa4ca3c980d81
Author: Mika Kuoppala <[email protected]>
Date:   Thu May 15 20:58:11 2014 +0300

    drm/i915: Enable rc6 with bdw
    
    Everything should be in place so enable rc6/rps for bdw.
    
    Reviewed-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Mika Kuoppala <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 8fd9c1a9d7f490c9f530b7a6108322b6789e02c4
Author: Mika Kuoppala <[email protected]>
Date:   Thu May 15 20:58:10 2014 +0300

    drm/i915: Fix rc6 options debug info
    
    by correctly displaying result and requested.
    
    Suggested-by: Imre Deak <[email protected]>
    Reviewed-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Mika Kuoppala <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit baccd4586ed948569207de83f28772376d5c3772
Author: Deepak S <[email protected]>
Date:   Thu May 15 20:58:09 2014 +0300

    drm/i915: Enable PM Interrupts target via Display Interface.
    
    In BDW, Apart from unmasking up/down threshold interrupts. we need
    to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
    Interface.
    
    v2: Add (1<<31) mask (Ville)
    
    v3: Add Gen check for the mask (ville)
    
    Reviewed-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Deepak S <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 0961021aef788e9d0d4e34256655d6c761ef716b
Author: Ben Widawsky <[email protected]>
Date:   Thu May 15 20:58:08 2014 +0300

    drm/i915/bdw: Implement a basic PM interrupt handler
    
    Almost all of it is reusable from the existing code. The primary
    difference is we need to do even less in the interrupt handler, since
    interrupts are not shared in the same way.
    
    The patch is mostly a copy-paste of the existing snb+ code, with updates
    to the relevant parts requiring changes to the interrupt handling. As
    such it /should/ be relatively trivial. It's highly likely that I missed
    some places where I need a gen8 version of the PM interrupts, but it has
    become invisible to me by now.
    
    This patch could probably be split into adding the new functions,
    followed by actually handling the interrupts. Since the code is
    currently disabled (and broken) I think the patch stands better by
    itself.
    
    v2: Move the commit about not touching the ringbuffer interrupt to the
    snb_* function where it belongs (Rodrigo)
    
    v3: Rebased on Paulo's runtime PM changes
    
    v4: Not well validated, but rebase on
    commit 730488b2eddded4497f63f70867b1256cd9e117c
    Author: Paulo Zanoni <[email protected]>
    Date:   Fri Mar 7 20:12:32 2014 -0300
    
        drm/i915: kill dev_priv->pm.regsave
    
    v5: Rebased on latest code base. (Deepak)
    
    v6: Remove conflict markers, Unnecessary empty line and use right
    IIR interrupt (Ville)
    
    v7: mask modified without rmw (Ville Syrjälä)
    
    Reviewed-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Ben Widawsky <[email protected]>
    Signed-off-by: Deepak S <[email protected]>
    Signed-off-by: Mika Kuoppala <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 6e450ab24dc645d776e65bbb91fc5f6788087c32
Author: Mika Kuoppala <[email protected]>
Date:   Thu May 15 20:58:07 2014 +0300

    drm/i915: Bail out early on gen6_signal if no semaphores
    
    If we dont have semaphores enabled, we allocate 4
    dwords for signalling. But end up emitting more regardless.
    
    Fix this by bailing out early if semaphores are not enabled.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78274
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78283
    Signed-off-by: Mika Kuoppala <[email protected]>
    Reviewed-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 47dd0b76ace953bd2c0479076db0d3e3b9594003
Author: Dave Jones <[email protected]>
Date:   Thu May 15 15:03:53 2014 -0400

    selinux: conditionally reschedule in hashtab_insert while loading selinux policy
    
    After silencing the sleeping warning in mls_convert_context() I started
    seeing similar traces from hashtab_insert. Do a cond_resched there too.
    
    Signed-off-by: Dave Jones <[email protected]>
    Acked-by: Stephen Smalley <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>

commit 612c353178c45250fbec271e7e8e75596d5cbbea
Author: Dave Jones <[email protected]>
Date:   Thu May 15 15:02:53 2014 -0400

    selinux: conditionally reschedule in mls_convert_context while loading selinux policy
    
    On a slow machine (with debugging enabled), upgrading selinux policy may take
    a considerable amount of time. Long enough that the softlockup detector
    gets triggered.
    
    The backtrace looks like this..
    
     > BUG: soft lockup - CPU#2 stuck for 23s! [load_policy:19045]
     > Call Trace:
     >  [<ffffffff81221ddf>] symcmp+0xf/0x20
     >  [<ffffffff81221c27>] hashtab_search+0x47/0x80
     >  [<ffffffff8122e96c>] mls_convert_context+0xdc/0x1c0
     >  [<ffffffff812294e8>] convert_context+0x378/0x460
     >  [<ffffffff81229170>] ? security_context_to_sid_core+0x240/0x240
     >  [<ffffffff812221b5>] sidtab_map+0x45/0x80
     >  [<ffffffff8122bb9f>] security_load_policy+0x3ff/0x580
     >  [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
     >  [<ffffffff810786dd>] ? sched_clock_local+0x1d/0x80
     >  [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
     >  [<ffffffff8103096a>] ? __change_page_attr_set_clr+0x82a/0xa50
     >  [<ffffffff810786dd>] ? sched_clock_local+0x1d/0x80
     >  [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
     >  [<ffffffff8103096a>] ? __change_page_attr_set_clr+0x82a/0xa50
     >  [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
     >  [<ffffffff81534ddc>] ? retint_restore_args+0xe/0xe
     >  [<ffffffff8109c82d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
     >  [<ffffffff81279a2e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
     >  [<ffffffff810d28a8>] ? rcu_irq_exit+0x68/0xb0
     >  [<ffffffff81534ddc>] ? retint_restore_args+0xe/0xe
     >  [<ffffffff8121e947>] sel_write_load+0xa7/0x770
     >  [<ffffffff81139633>] ? vfs_write+0x1c3/0x200
     >  [<ffffffff81210e8e>] ? security_file_permission+0x1e/0xa0
     >  [<ffffffff8113952b>] vfs_write+0xbb/0x200
     >  [<ffffffff811581c7>] ? fget_light+0x397/0x4b0
     >  [<ffffffff81139c27>] SyS_write+0x47/0xa0
     >  [<ffffffff8153bde4>] tracesys+0xdd/0xe2
    
    Stephen Smalley suggested:
    
     > Maybe put a cond_resched() within the ebitmap_for_each_positive_bit()
     > loop in mls_convert_context()?
    
    That seems to do the trick. Tested by downgrading and re-upgrading selinux-policy-targeted.
    
    Signed-off-by: Dave Jones <[email protected]>
    Acked-by: Stephen Smalley <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>

commit bf2ec0f9ada1db6778851fcc9f736b5ca00c97ec
Author: Micky Ching <[email protected]>
Date:   Wed Apr 2 17:58:52 2014 +0800

    staging: rts5208: fix static checker warnings
    
    The patch fa590c222fba: "staging: rts5208: add support for rts5208
    and rts5288" from Nov 12, 2013, leads to the following static checker
    warning:
    	drivers/staging/rts5208/rtsx_chip.c:107 rtsx_enable_bus_int()
    	warn: add curly braces?
    This warning is produced because incorrect code indent.
    
    Signed-off-by: Micky Ching <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5535c4dd475ff936d36ad4d3f85d8be74f30245f
Author: Rocco Folino <[email protected]>
Date:   Thu Apr 3 00:47:46 2014 +0200

    staging: gs_fpgaboot: Fixed code style issues
    
    Fixed missing a blank line after declarations warning
    
    Signed-off-by: Rocco Folino <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f3c5261e04b9ace521e9392f7b6a28f62b28b9fc
Author: Jerry Snitselaar <[email protected]>
Date:   Thu Apr 24 00:31:48 2014 -0700

    staging/line6: blank line after declaration cleanup
    
    Fix coding style warnings reported by checkpath.
    
    Signed-off-by: Jerry Snitselaar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 62ca89a1d014623b1a59aa60b6055d022f1f8836
Author: Artem Fetishev <[email protected]>
Date:   Sun May 11 21:14:30 2014 +0300

    drivers: staging: ft1000: Fix lines over 80 characters
    
    ..plus some function arg indentation which I haven't noticed at first.
    
    Signed-off-by: Artem Fetishev <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 48d1e475363638b58f76ee0bd3887082990ea0f9
Author: Artem Fetishev <[email protected]>
Date:   Sun May 11 21:14:29 2014 +0300

    drivers: staging: ft1000: Remove typedefs
    
    Remove typedefs according to the "Chapter 5: Typedefs" from
    Documentation/CodingStyle.
    
    Signed-off-by: Artem Fetishev <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5df466cd66159826276f7b807a7e729f6a40c09d
Author: Artem Fetishev <[email protected]>
Date:   Sun May 11 21:14:28 2014 +0300

    drivers: staging: ft1000: Use pr_info instead of printk
    
    Improve coding style by fixing this checkstyle warning:
    
    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    
    Signed-off-by: Artem Fetishev <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b4da658ea91f8813f3eee8f40c82a7937449a741
Author: Artem Fetishev <[email protected]>
Date:   Sun May 11 21:14:27 2014 +0300

    drivers: staging: ft1000: Fix IOCTL_FT1000_* marcos
    
    Fixes include:
     - Add closing brackets;
     - Remove sizeof (_IOR and _IOW macro can accept types);
     - Replace _IOW which size of 0 (the last arg) with _IO.
     - Actually these macros are not used anywhere and might be removed.
    
    Signed-off-by: Artem Fetishev <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5fd29b013b0df6bcb411c54f21a2661c142a118e
Author: Artem Fetishev <[email protected]>
Date:   Sun May 11 21:14:26 2014 +0300

    drivers: staging: ft1000: Fix indentation
    
    Fixes indentation in header files.
    
    Signed-off-by: Artem Fetishev <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit dab531b4305bc2852ce6f934dc283464d46871a5
Author: Florian Fainelli <[email protected]>
Date:   Wed May 14 19:32:14 2014 -0700

    net: systemport: pad packets to a minimum of 68 bytes
    
    Packets need to be at least 64 bytes to enter the switch port logic,
    including the FCS, otherwise they will be discarded as RUNT packets.
    
    With packets having Broadcom tags, the 4-bytes tag is first stripped
    off the packet, and the packet length is then checked, so we need to
    make sure that the packet length with FCS is at least 64 bytes.
    
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit d5e32cc7c997d1d4f18031f5ff88512bd65118f7
Author: Florian Fainelli <[email protected]>
Date:   Wed May 14 19:32:13 2014 -0700

    net: systemport: only update UMAC_CMD if something changed
    
    The link adjustment callback can be called as frequently as desired by
    the PHY library, as such, let's avoid doing a Read/Modify/Write sequence
    if nothing changed, which is more than likely since we are interfaced
    with a switch device.
    
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 77a6f000a1a22d295b87a1a767ffe75b98f1775f
Author: Angus Gibson <[email protected]>
Date:   Mon Apr 7 12:29:30 2014 +1000

    staging: ft1000: remove explicit static initialisation
    
    Fix checkpatch.pl error where a static variable was explicitly
    initialised to false
    
    Signed-off-by: Angus Gibson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 248b6a67567778123bf635945659e64cfe272e3b
Author: Paul McQuade <[email protected]>
Date:   Thu Apr 3 17:21:22 2014 +0100

    Staging:ft1000_debug.c:Renaming __FUNCTION__
    
    __Function__ gets renamed with __func__
    
    Signed-off-by: Paul McQuade <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a713cd594117c6841dbd56b608fa8629673f6617
Author: Anders Darander <[email protected]>
Date:   Tue Apr 1 08:29:40 2014 +0200

    Staging: ft1000-usb: use netdev_warn
    
    Fix coding style issue by replacing printk with netdev_warn.
    
    Signed-off-by: Anders Darander <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 87a76301091f8ff0c24e31c8befc6a4f699536f1
Author: Anders Darander <[email protected]>
Date:   Tue Apr 1 08:29:39 2014 +0200

    Staging: ft1000-usb: wrap macros in do while
    
    Fix coding style issue by wrapping the macro in a do {} while (0).
    
    Signed-off-by: Anders Darander <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d91e5c02555ae838e9d783b9e83e125fd10dca73
Author: Vince Bridgers <[email protected]>
Date:   Wed May 14 14:38:37 2014 -0500

    Altera TSE: Disable Multicast filtering to workaround problem
    
    This patch disables multicast hash filtering if present in the hardware
    and uses promiscuous mode instead until the problem with multicast
    filtering has been debugged, integrated and tested.
    
    Signed-off-by: Vince Bridgers <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 898305806ad56ae11dc2c80931062e6a2c7bba48
Author: Vince Bridgers <[email protected]>
Date:   Wed May 14 14:38:36 2014 -0500

    Altera TSE: Fix sparse errors and warnings
    
    This patch fixes the many sparse errors and warnings contained in the
    initial submission of the Altera Triple Speed Ethernet driver, and a
    few minor cppcheck warnings. Changes are tested on ARM and NIOS2
    example designs, and compile tested against multiple architectures.
    Typical issues addressed were as follows:
    
    altera_tse_ethtool.c:136:19: warning: incorrect type in argument
        1 (different address spaces)
    altera_tse_ethtool.c:136:19:    expected void const volatile
        [noderef] <asn:2>*addr
    altera_tse_ethtool.c:136:19:    got unsigned int *<noident>
    ...
    altera_sgdma.c:129:31: warning: cast removes address space of
        expression
    
    Signed-off-by: Vince Bridgers <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit c80561e96b81a01c3e4988fc08093479a1f0c914
Author: Dan Carpenter <[email protected]>
Date:   Wed May 14 19:13:07 2014 +0300

    staging: dgnc: UART_IIR_XOFF code is buggy
    
    The UART_IIR_XOFF was supposed to be a no-op but, because there was a
    missing semi-colon, the if statement is not "Empty".  I have just deleted
    this code because it was supposed to be a no-op anyway.  UART_IIR_XOFF
    is a standard define and not something specific to this driver.
    
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0f33ae1ed6ac39da7b1f73972eb4791fe43d15d3
Author: Martin Kepplinger <[email protected]>
Date:   Tue Apr 29 11:43:08 2014 +0200

    staging: dgnc: use dev_err() instead of printk()
    
    Use dev_err() insted of printk() in order to provice userspace with
    more useful information and use the common kernel coding style.
    
    Signed-off-by: Martin Kepplinger <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 36aa10aa018c2ed5571ffd145f39d3fcf993cee0
Author: Vitaly Osipov <[email protected]>
Date:   Sun Apr 27 00:59:17 2014 +1000

    staging: dgnc: redundant NULL checks before kfree()
    
    Removed redundant NULL checks before calling kfree()
    
    Signed-off-by: Vitaly Osipov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3f2889621a6d47c3aa5e4284af808f8d79cc5d5d
Author: Son P. Nguyen <[email protected]>
Date:   Sun Apr 20 18:05:39 2014 +0000

    Staging: dgnc: dgnc_driver: fixed incorrect braces
    
    Fixed incorrect braces (coding style)
    
    Signed-off-by: Son P. Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit df38e6558db777e1e4403a3fc16bf177fe44b79b
Author: Shobhit Kumar <[email protected]>
Date:   Mon Apr 14 11:18:26 2014 +0530

    drm/i915: MIPI PPS delays added
    
    Added as generic parameters which will be initialized in the panel
    driver and are specific to panels.
    
    Backlight delays have also kept as placeholders and will be used used
    once we have MIPI backlight enabling support
    
    Signed-off-by: Shobhit Kumar <[email protected]>
    Reviewed-by: Damien Lespiau <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit cf4dbd2ecb2467d0fdec80e10b2d30cfda3d0de3
Author: Shobhit Kumar <[email protected]>
Date:   Mon Apr 14 11:18:25 2014 +0530

    drm/i915: MIPI init count programming as generic parameter
    
    Signed-off-by: Shobhit Kumar <[email protected]>
    Reviewed-by: Damien Lespiau <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit dfba2e2d3302b509fbf8bccd71ca5b2e0b47fefa
Author: Shobhit Kumar <[email protected]>
Date:   Mon Apr 14 11:18:24 2014 +0530

    drm/i915: Correct MIPI operation mode as per expected values from VBT
    
    In VBT fields operation mode is 0 for Video mode and 1 for command mode.
    This field will be directly used as is in generic panel driver. So
    adjust accordingly.
    
    Signed-off-by: Shobhit Kumar <[email protected]>
    Reviewed-by: Damien Lespiau <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 5f47dfb400d6a82d5ce9cdf537e33969af8278ff
Author: Joe Perches <[email protected]>
Date:   Wed May 14 12:15:13 2014 -0700

    ti: Remove trailing semicolon from do {...} while (0) macro
    
    These should not have trailing semicolons so remove them.
    
    Signed-off-by: Joe Perches <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 2b46be68a1b67f40df4f288b90e79181c387eda6
Author: Antoine Sirinelli <[email protected]>
Date:   Thu Mar 27 22:31:55 2014 +0100

    staging: dgnc: cleanup dgnc_finalize_board_init()
    
    Trivial cleanups:
    - Transform a printk() to a dev_err() call
    - Fix 2 lines over 80 characters
    
    Signed-off-by: Antoine Sirinelli <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 542f3d5af89c15d0b4e80bbf927d252efa0e48c3
Author: Mark Hounschell <[email protected]>
Date:   Fri Apr 25 14:32:15 2014 -0400

    staging: dgap: Add Mark Hounschell to maintainers list for dgap
    
    Add Mark Hounschell to the MAINTAINERs list for the dgap driver
    
    Signed-off-by: Mark Hounschell <[email protected]>
    Suggested-by: Dan Carpenter <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8430466a08341994c39396eb79b68e59ecc127e8
Author: Rahul Sharma <[email protected]>
Date:   Fri May 16 05:06:34 2014 +0900

    ARM: dts: enable hdmi for exynos5800-peach-pi board
    
    Enable hdmi for peach-pi board.
    
    Signed-off-by: Rahul Sharma <[email protected]>
    Acked-by: Tomasz Figa<[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 8f577cadf7181243d336be9aba40c1bcc02c4c54
Author: Alexei Starovoitov <[email protected]>
Date:   Tue May 13 19:50:47 2014 -0700

    seccomp: JIT compile seccomp filter
    
    Take advantage of internal BPF JIT
    
    05-sim-long_jumps.c of libseccomp was used as micro-benchmark:
    
     seccomp_rule_add_exact(ctx,...
     seccomp_rule_add_exact(ctx,...
    
     rc = seccomp_load(ctx);
    
     for (i = 0; i < 10000000; i++)
        syscall(...);
    
    $ sudo sysctl net.core.bpf_jit_enable=1
    $ time ./bench
    real	0m2.769s
    user	0m1.136s
    sys	0m1.624s
    
    $ sudo sysctl net.core.bpf_jit_enable=0
    $ time ./bench
    real	0m5.825s
    user	0m1.268s
    sys	0m4.548s
    
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 622582786c9e041d0bd52bde201787adeab249f8
Author: Alexei Starovoitov <[email protected]>
Date:   Tue May 13 19:50:46 2014 -0700

    net: filter: x86: internal BPF JIT
    
    Maps all internal BPF instructions into x86_64 instructions.
    This patch replaces original BPF x64 JIT with internal BPF x64 JIT.
    sysctl net.core.bpf_jit_enable is reused as on/off switch.
    
    Performance:
    
    1. old BPF JIT and internal BPF JIT generate equivalent x86_64 code.
      No performance difference is observed for filters that were JIT-able before
    
    Example assembler code for BPF filter "tcpdump port 22"
    
    original BPF -> old JIT:            original BPF -> internal BPF -> new JIT:
       0:   push   %rbp                      0:     push   %rbp
       1:   mov    %rsp,%rbp                 1:     mov    %rsp,%rbp
       4:   sub    $0x60,%rsp                4:     sub    $0x228,%rsp
       8:   mov    %rbx,-0x8(%rbp)           b:     mov    %rbx,-0x228(%rbp) // prologue
                                            12:     mov    %r13,-0x220(%rbp)
                                            19:     mov    %r14,-0x218(%rbp)
                                            20:     mov    %r15,-0x210(%rbp)
                                            27:     xor    %eax,%eax         // clear A
       c:   xor    %ebx,%ebx                29:     xor    %r13,%r13         // clear X
       e:   mov    0x68(%rdi),%r9d          2c:     mov    0x68(%rdi),%r9d
      12:   sub    0x6c(%rdi),%r9d          30:     sub    0x6c(%rdi),%r9d
      16:   mov    0xd8(%rdi),%r8           34:     mov    0xd8(%rdi),%r10
                                            3b:     mov    %rdi,%rbx
      1d:   mov    $0xc,%esi                3e:     mov    $0xc,%esi
      22:   callq  0xffffffffe1021e15       43:     callq  0xffffffffe102bd75
      27:   cmp    $0x86dd,%eax             48:     cmp    $0x86dd,%rax
      2c:   jne    0x0000000000000069       4f:     jne    0x000000000000009a
      2e:   mov    $0x14,%esi               51:     mov    $0x14,%esi
      33:   callq  0xffffffffe1021e31       56:     callq  0xffffffffe102bd91
      38:   cmp    $0x84,%eax               5b:     cmp    $0x84,%rax
      3d:   je     0x0000000000000049       62:     je     0x0000000000000074
      3f:   cmp    $0x6,%eax                64:     cmp    $0x6,%rax
      42:   je     0x0000000000000049       68:     je     0x0000000000000074
      44:   cmp    $0x11,%eax               6a:     cmp    $0x11,%rax
      47:   jne    0x00000000000000c6       6e:     jne    0x0000000000000117
      49:   mov    $0x36,%esi               74:     mov    $0x36,%esi
      4e:   callq  0xffffffffe1021e15       79:     callq  0xffffffffe102bd75
      53:   cmp    $0x16,%eax               7e:     cmp    $0x16,%rax
      56:   je     0x00000000000000bf       82:     je     0x0000000000000110
      58:   mov    $0x38,%esi               88:     mov    $0x38,%esi
      5d:   callq  0xffffffffe1021e15       8d:     callq  0xffffffffe102bd75
      62:   cmp    $0x16,%eax               92:     cmp    $0x16,%rax
      65:   je     0x00000000000000bf       96:     je     0x0000000000000110
      67:   jmp    0x00000000000000c6       98:     jmp    0x0000000000000117
      69:   cmp    $0x800,%eax              9a:     cmp    $0x800,%rax
      6e:   jne    0x00000000000000c6       a1:     jne    0x0000000000000117
      70:   mov    $0x17,%esi               a3:     mov    $0x17,%esi
      75:   callq  0xffffffffe1021e31       a8:     callq  0xffffffffe102bd91
      7a:   cmp    $0x84,%eax               ad:     cmp    $0x84,%rax
      7f:   je     0x000000000000008b       b4:     je     0x00000000000000c2
      81:   cmp    $0x6,%eax                b6:     cmp    $0x6,%rax
      84:   je     0x000000000000008b       ba:     je     0x00000000000000c2
      86:   cmp    $0x11,%eax               bc:     cmp    $0x11,%rax
      89:   jne    0x00000000000000c6       c0:     jne    0x0000000000000117
      8b:   mov    $0x14,%esi               c2:     mov    $0x14,%esi
      90:   callq  0xffffffffe1021e15       c7:     callq  0xffffffffe102bd75
      95:   test   $0x1fff,%ax              cc:     test   $0x1fff,%rax
      99:   jne    0x00000000000000c6       d3:     jne    0x0000000000000117
                                            d5:     mov    %rax,%r14
      9b:   mov    $0xe,%esi                d8:     mov    $0xe,%esi
      a0:   callq  0xffffffffe1021e44       dd:     callq  0xffffffffe102bd91 // MSH
                                            e2:     and    $0xf,%eax
                                            e5:     shl    $0x2,%eax
                                            e8:     mov    %rax,%r13
                                            eb:     mov    %r14,%rax
                                            ee:     mov    %r13,%rsi
      a5:   lea    0xe(%rbx),%esi           f1:     add    $0xe,%esi
      a8:   callq  0xffffffffe1021e0d       f4:     callq  0xffffffffe102bd6d
      ad:   cmp    $0x16,%eax               f9:     cmp    $0x16,%rax
      b0:   je     0x00000000000000bf       fd:     je     0x0000000000000110
                                            ff:     mov    %r13,%rsi
      b2:   lea    0x10(%rbx),%esi         102:     add    $0x10,%esi
      b5:   callq  0xffffffffe1021e0d      105:     callq  0xffffffffe102bd6d
      ba:   cmp    $0x16,%eax              10a:     cmp    $0x16,%rax
      bd:   jne    0x00000000000000c6      10e:     jne    0x0000000000000117
      bf:   mov    $0xffff,%eax            110:     mov    $0xffff,%eax
      c4:   jmp    0x00000000000000c8      115:     jmp    0x000000000000011c
      c6:   xor    %eax,%eax               117:     mov    $0x0,%eax
      c8:   mov    -0x8(%rbp),%rbx         11c:     mov    -0x228(%rbp),%rbx // epilogue
      cc:   leaveq                         123:     mov    -0x220(%rbp),%r13
      cd:   retq                           12a:     mov    -0x218(%rbp),%r14
                                           131:     mov    -0x210(%rbp),%r15
                                           138:     leaveq
                                           139:     retq
    
    On fully cached SKBs both JITed functions take 12 nsec to execute.
    BPF interpreter executes the program in 30 nsec.
    
    The difference in generated assembler is due to the following:
    
    Old BPF imlements LDX_MSH instruction via sk_load_byte_msh() helper function
    inside bpf_jit.S.
    New JIT removes the helper and does it explicitly, so ldx_msh cost
    is the same for both JITs, but generated code looks longer.
    
    New JIT has 4 registers to save, so prologue/epilogue are larger,
    but the cost is within noise on x64.
    
    Old JIT checks whether first insn clears A and if not emits 'xor %eax,%eax'.
    New JIT clears %rax unconditionally.
    
    2. old BPF JIT doesn't support ANC_NLATTR, ANC_PAY_OFFSET, ANC_RANDOM
      extensions. New JIT supports all BPF extensions.
      Performance of such filters improves 2-4 times depending on a filter.
      The longer the filter the higher performance gain.
      Synthetic benchmarks with many ancillary loads see 20x speedup
      which seems to be the maximum gain from JIT
    
    Notes:
    
    . net.core.bpf_jit_enable=2 + tools/net/bpf_jit_disasm is still functional
      and can be used to see generated assembler
    
    . there are two jit_compile() functions and code flow for classic filters is:
      sk_attach_filter() - load classic BPF
      bpf_jit_compile() - try to JIT from classic BPF
      sk_convert_filter() - convert classic to internal
      bpf_int_jit_compile() - JIT from internal BPF
    
      seccomp and tracing filters will just call bpf_int_jit_compile()
    
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit f3c2af7ba17a83809806880062c9ad541744fb95
Author: Alexei Starovoitov <[email protected]>
Date:   Tue May 13 19:50:45 2014 -0700

    net: filter: x86: split bpf_jit_compile()
    
    Split bpf_jit_compile() into two functions to improve readability
    of for(pass++) loop. The change follows similar style of JIT compilers
    for arm, powerpc, s390
    
    The body of new do_jit() was not reformatted to reduce noise
    in this patch, since the following patch replaces most of it.
    
    Tested with BPF testsuite.
    
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 721b79d12fef7f13c0ac2cabb7cce39976769fcf
Author: Christian Engelmayer <[email protected]>
Date:   Wed May 7 21:43:37 2014 +0200

    staging: vt6656: fix potential leak in vt6656_hostap_ioctl()
    
    Commit fb841d67 (staging: vt6656: don't leak 'param' in vt6656_hostap_ioctl()
    when returning -EOPNOTSUPP) cleaned up direct returns in the ioctl switch
    statement that leaked already allocated memory. Fix the same issue for
    VIAWGET_HOSTAPD_SCAN_REQ and VIAWGET_HOSTAPD_MLME that are not supported by
    this driver. Detected by Coverity - CID 144381.
    
    Signed-off-by: Christian Engelmayer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 92216fa31ef27bd840e921d1f474213cdbe3fb70
Author: Rahul Sharma <[email protected]>
Date:   Fri May 16 05:23:21 2014 +0900

    ARM: dts: enable hdmi for exynos5420-peach-pit board
    
    Enable hdmi for exynos5420 based peach-pit board.
    
    Signed-off-by: Rahul Sharma <[email protected]>
    Acked-by: Tomasz Figa<[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 62a3f8a10d8dab8bae7565358bee3f923f02b8a0
Author: Malcolm Priestley <[email protected]>
Date:   Wed Apr 30 21:31:13 2014 +0100

    staging: vt6656: desh.h Remove unused macros and structures.
    
    All are dead and of no use.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 05cc617b5db8a6debac873e4dcfbd6d679406730
Author: Malcolm Priestley <[email protected]>
Date:   Wed Apr 30 21:31:12 2014 +0100

    staging: vt6656: rxtx: Remove unused uDMAIdx from driver.
    
    Remove from functions and callers.
    
    Signed-off-by: Malcolm Priestley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ea9a8dae5acca2e2ac0421279de7818e92e4b251
Author: Martin Kepplinger <[email protected]>
Date:   Tue May 6 07:58:39 2014 +0200

    staging: vt6656: make spin_lock_irq() human readable
    
    Don't require FIRMWAREbDownload() to, first off, unlock a held lock.
    Thus do all locking in main_usb.c and hold it for a insignificantly
    shorter period of time. This makes the affected area significantly more
    readable though.
    
    Signed-off-by: Martin Kepplinger <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bc5cf6563576bb36baa7e93417b9a2e29999a5c6
Author: Guido Martínez <[email protected]>
Date:   Sat Apr 19 16:45:00 2014 -0300

    staging: vt6655: fix checkpatch bracing issues
    
    This patchs fixes tons of warnings such as:
    
      WARNING: braces {} are not necessary for single statement blocks
      #354: FILE: drivers/staging/vt6655/wmgr.c:354:
      +       for (ii = 0; ii < WLAN_BSSID_LEN; ii++) {
      +               pMgmt->abyDesireBSSID[ii] = 0xFF;
      +       }
    
    Please note: this patch only fixes bracing issues (and there is still a
    lot to do); so if you run checkpatch it _will_ throw a lot of errors.
    Use --test-only=braces
    
    Signed-off-by: Guido Martínez <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4e8a7e5fc29697f881f5c358f84df52914908703
Author: Guido Martínez <[email protected]>
Date:   Sat Apr 19 16:44:59 2014 -0300

    staging: vt6655: remove dead code
    
    Remove dead code in many places on this driver.
    
    Signed-off-by: Guido Martínez <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3da8a316cfb52bc360960ad293433cba393d2943
Author: Rahul Sharma <[email protected]>
Date:   Fri May 16 05:23:16 2014 +0900

    ARM: dts: change to correct compatible string for exynos5420 hdmi
    
    Replace compatible string for HDMI node in Exynos5420. Since
    latest restructring in Drm hdmi driver, it is agreed to use
    a seperate compatible string for Exynos5420 HDMI IP siince it
    uses APB mapped Phy.
    
    Signed-off-by: Rahul Sharma <[email protected]>
    Acked-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 838c2d6cfc0c2dc8ce136e01e681fc6cf4124c39
Author: Tobias Klauser <[email protected]>
Date:   Fri Apr 25 11:53:58 2014 +0200

    staging: vt6656: Use proper target pointer in memcpy()
    
    The coverity scanner marked these two memcpy()'s as causing a buffer
    overflow in CIDs 142743 and 142744. This is due the h_dest member of
    struct ethhdr being used as a target (size ETH_ALEN) in memcpy, but the
    copy is of size ETH_HLEN. However, the intention here seems to be to
    copy the entire ethernet header. Make that clear by specifying the
    proper destination buffer.
    
    Also remove the unnecessary casts of the source argument.
    
    Signed-off-by: Tobias Klauser <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 34bdb981f7cb446259b0999d40f090c16f732eca
Author: Tobias Klauser <[email protected]>
Date:   Fri Apr 25 15:39:12 2014 +0200

    staging: vt6656: Remove unnecesssary NULL check
    
    pFifoHead points to tx_buffer->fifo_head which can never be NULL.
    We also don't need to check for tx_buffer being NULL instead, since it
    always points to ->Data of struct vnt_usb_send_context - the pointer to
    which was checked before calling s_vGenerateTxParameter().
    
    Silences a dereference before NULL check warning reported by the coverity
    scanner in CID 1127221.
    
    Cc: Dan Carpenter <[email protected]>
    Signed-off-by: Tobias Klauser <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 91ed9a7cddf1130af3a3aef0325d6e6d08eaffb2
Author: Nicolas Del Piano <[email protected]>
Date:   Fri Apr 25 14:36:56 2014 -0300

    Staging: vt6655: tether: fixed a brace coding style issue
    
    Fixed a coding style issue.
    
    Signed-off-by: Nicolas Del Piano <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit db35b140c6f39135a3593044ce5fd384e51a3a35
Author: Rahul Sharma <[email protected]>
Date:   Fri May 16 05:22:41 2014 +0900

    ARM: dts: enable hdmi for exynos5250 based snow board
    
    Enable support for HDMI for exynos5250 based Snow board.
    
    Signed-off-by: Rahul Sharma <[email protected]>
    Acked-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit a99698facdb92adebf4a4ed7691493b7e08ff5b6
Author: Alan <[email protected]>
Date:   Mon May 12 16:57:22 2014 +0100

    goldfish: clean up the pipe driver 64bit ifdefs
    
    Use the 64bit helper method to scrub most of the ifdefs from the driver. The
    pipe reading has a funny case we can't scrub completely.
    
    Signed-off-by: Alan Cox <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d78055dc9c786b392ce7b593c479bb9a3e1da61d
Author: Alan <[email protected]>
Date:   Mon May 12 16:57:14 2014 +0100

    goldfish: clean up the checkpatch warnings
    
    Mostly spacing changes, also making the operations structure const
    
    Signed-off-by: Alan Cox <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e0f682e05f51c9eff68e61ce2350155895cd739e
Author: Alan <[email protected]>
Date:   Mon May 12 16:57:05 2014 +0100

    goldfish: clean up tty 64bit support
    
    Use the helper we now have available.
    
    Signed-off-by: Alan Cox <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f6279717bbb20bf90ec414af17d2a31d843f5eb5
Author: Alan <[email protected]>
Date:   Mon May 12 16:56:56 2014 +0100

    goldfish: clean up staging ifdefs
    
    Use the write helpers and add an audio helper
    
    Signed-off-by: Alan Cox <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9b17aeec232a5f0a61ce3952c2e728a0eeddda8b
Author: Alan <[email protected]>
Date:   Mon May 12 16:55:35 2014 +0100

    goldfish: Allow 64bit builds
    
    We can now enable the 64bit option for the Goldfish 64bit emulator.
    
    Signed-off-by: Alan Cox <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b8658bc81089d656fe54b12e21f0cae5116b6483
Author: Jun Tian <[email protected]>
Date:   Mon May 12 16:55:26 2014 +0100

    goldfish: enable 64-bit tty driver
    
    Signed-off-by: Jun Tian <[email protected]>
    Signed-off-by: Alan Cox <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ec5e34c074793a1f80faaf75e9468dd2f39ec1dc
Author: Nick Kralevich <[email protected]>
Date:   Mon May 12 16:55:16 2014 +0100

    goldfish_nand.c: remove length restrictions
    
    Remove limitations on the size of a read / write request.
    AFAIK, there's no consequence to allowing the upper layers
    to specify different read / write sizes.
    
    This is needed to support running ext4 on goldfish.
    
    Bug: https://code.google.com/p/android/issues/detail?id=38561
    
    Signed-off-by: Nick Kralevich <[email protected]>
    Signed-off-by: Jun Tian <[email protected]>
    Signed-off-by: Alan Cox <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f10d8434201859d5ad7f51032dcd2d0c09e85ee2
Author: Octavian Purdila <[email protected]>
Date:   Mon May 12 16:55:05 2014 +0100

    goldfish: add support for 64bit to the virtual bus
    
    This patchs adds a new register to pass the upper 32bits for the
    device name address when running in 64bit mode.
    
    Signed-off-by: Octavian Purdila <[email protected]>
    Signed-off-by: Jun Tian <[email protected]>
    Signed-off-by: Alan Cox <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 25c72c786cb571cfdf39a31f9f64d143d8623a7a
Author: Jun Tian <[email protected]>
Date:   Mon May 12 16:54:57 2014 +0100

    goldfish: fix kernel panic when using multiple adb connection
    
    When using multiple adb on 64 bit kernel to transfer data,
    the goldfish pipe interrupt will crash the kernel.
    
    Signed-off-by: Jun Tian <[email protected]>
    Signed-off-by: Alan Cox <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 49a75c444fcf07fdde2ec74428b6b1b9ff1c6b15
Author: Jun Tian <[email protected]>
Date:   Mon May 12 16:54:46 2014 +0100

    goldfish: 64-bit pipe driver for goldfish platform
    
    Support 64-bit channel and address for the goldfish pipe driver.
    
    Signed-off-by: Jun Tian <[email protected]>
    Signed-off-by: Octavian Purdila <[email protected]>
    Signed-off-by: Brian Wood <[email protected]>
    Signed-off-by: Alan Cox <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0cc6c3ab3cdbcf8a4a103d27599a6d0b44a6c315
Author: Christian Engelmayer <[email protected]>
Date:   Wed May 7 21:21:58 2014 +0200

    staging: rtl8723au: Remove unused pointer in rtw_wdev_free()
    
    Pointer 'pwdev_priv' in function rtw_wdev_free() is unused - thus remove it.
    
    Signed-off-by: Christian Engelmayer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b16be76f926ff177cb9884be4cd62580c820420b
Author: Doug Anderson <[email protected]>
Date:   Fri May 16 05:16:14 2014 +0900

    ARM: dts: add tps65090 power regulator for exynos5250-snow
    
    Added TPS65090 regulator related nodes to Snow board.
    
    Signed-off-by: Doug Anderson <[email protected]>
    Signed-off-by: Sachin Kamat <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit ecad159a24e587c9f315e561fb509fe1cd9b54ba
Author: Doug Anderson <[email protected]>
Date:   Fri May 16 05:16:11 2014 +0900

    ARM: dts: add pinctrl for EC irq of exynos5250-snow
    
    Added pinctrl node for embedded controller (EC) IRQ
    on Snow board.
    
    Signed-off-by: Doug Anderson <dianders@c…
ddstreet referenced this pull request in ddstreet/linux May 28, 2014
@hnaz
origin
9405964 
GIT fba69f042ad99f68c0268ef1c012f3199f898fac

commit f5c16f29bf5e57ba4051fc7785ba7f035f798c71
Author: Tejun Heo <[email protected]>
Date:   Mon May 19 15:52:10 2014 -0400

    sysfs: make sure read buffer is zeroed
    
    13c589d5b0ac ("sysfs: use seq_file when reading regular files")
    switched sysfs from custom read implementation to seq_file to enable
    later transition to kernfs.  After the change, the buffer passed to
    ->show() is acquired through seq_get_buf(); unfortunately, this
    introduces a subtle behavior change.  Before the commit, the buffer
    passed to ->show() was always zero as it was allocated using
    get_zeroed_page().  Because seq_file doesn't clear buffers on
    allocation and neither does seq_get_buf(), after the commit, depending
    on the behavior of ->show(), we may end up exposing uninitialized data
    to userland thus possibly altering userland visible behavior and
    leaking information.
    
    Fix it by explicitly clearing the buffer.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reported-by: Ron <[email protected]>
    Fixes: 13c589d5b0ac ("sysfs: use seq_file when reading regular files")
    Cc: stable <[email protected]> # 3.13+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3685f2516116c5f3b9d498d531955ad70216ad84
Author: Shawn Guo <[email protected]>
Date:   Sat May 17 20:46:01 2014 +0800

    ahci: imx: PLL clock needs 100us to settle down
    
    The commit e783c51 (ahci: imx: software workaround for phy reset issue
    in resume) calls imx_sata_phy_reset() to reset phy immediately after
    SATA MPLL is enabled.  It seems working fine mostly, but fails in some
    case as below.
    
    ...
    ahci-imx 2200000.sata: failed to reset phy: -110
    ahci-imx: probe of 2200000.sata failed with error -110
    
    After talking to the designer, we learnt that when enabling i.MX6Q SATA
    MPLL, we need to wait 100us for it to settle down for safety.  Add this
    required delay to fix above failure.
    
    Signed-off-by: Shawn Guo <[email protected]>
    Tested-by: Fabio Estevam <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit d0b4cc4e32705ff00d90d32da7783c266c702c04
Author: Gavin Shan <[email protected]>
Date:   Mon May 19 13:06:46 2014 +1000

    PCI: Wrong register used to check pending traffic
    
    The incorrect register offset is passed to pci_wait_for_pending(), which is
    caused by commit 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor
    pci_wait_for_pending_transaction())").
    
    Fixes: 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction())
    Signed-off-by: Gavin Shan <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Acked-by: Alex Williamson <[email protected]>
    CC: [email protected]	# v3.14+

commit 1e1110c43b1cda9fe77fc4a04835e460550e6b3c
Author: Mikulas Patocka <[email protected]>
Date:   Sat May 17 06:49:22 2014 -0400

    target: fix memory leak on XCOPY
    
    On each processed XCOPY command, two "kmalloc-512" memory objects are
    leaked. These represent two allocations of struct xcopy_pt_cmd in
    target_core_xcopy.c.
    
    The reason for the memory leak is that the cmd_kref field is not
    initialized (thus, it is zero because the allocations were done with
    kzalloc). When we decrement zero kref in target_put_sess_cmd, the result
    is not zero, thus target_release_cmd_kref is not called.
    
    This patch fixes the bug by moving kref initialization from
    target_get_sess_cmd to transport_init_se_cmd (this function is called from
    target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be
    easily verified that all code that calls target_get_sess_cmd also calls
    transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce
    any new problems.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Cc: [email protected]	# 3.12+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit f9c6d4987b23e0a514464bae6771933a48e4cd01
Author: Theodore Ts'o <[email protected]>
Date:   Fri May 16 21:40:41 2014 -0400

    random: fix BUG_ON caused by accounting simplification
    
    Commit ee1de406ba6eb1 ("random: simplify accounting logic") simplified
    things too much, in that it allows the following to trigger an
    overflow that results in a BUG_ON crash:
    
    dd if=/dev/urandom of=/dev/zero bs=67108707 count=1
    
    Thanks to Peter Zihlstra for discovering the crash, and Hannes
    Frederic for analyizing the root cause.
    
    Signed-off-by: "Theodore Ts'o" <[email protected]>
    Reported-by: Peter Zijlstra <[email protected]>
    Reported-by: Hannes Frederic Sowa <[email protected]>
    Cc: Greg Price <[email protected]>

commit d2c834abe2b39a2d5a6c38ef44de87c97cbb34b4
Author: Tuomas Tynkkynen <[email protected]>
Date:   Fri May 16 16:50:20 2014 +0300

    clk: tegra: Fix wrong value written to PLLE_AUX
    
    The value written to PLLE_AUX was incorrect due to a wrong variable
    being used. Without this fix SATA does not work.
    
    Cc: [email protected]
    Signed-off-by: Tuomas Tynkkynen <[email protected]>
    Tested-by: Mikko Perttunen <[email protected]>
    Reviewed-by: Thierry Reding <[email protected]>
    Tested-by: Thierry Reding <[email protected]>
    Acked-by: Thierry Reding <[email protected]>
    Signed-off-by: Mike Turquette <[email protected]>
    [[email protected]: improved changelog]

commit bb4e506565cfc0a2f534dfda1fb7ca5c26f7a604
Author: Jes Sorensen <[email protected]>
Date:   Fri May 16 22:59:18 2014 +0200

    staging: rtl8723au: Do not reset wdev->iftype in netdev_close()
    
    wdev->ifdev should be set by .change_virtual_intf(). This solves the
    problem of WARN() messages on module unload.
    
    Signed-off-by: Jes Sorensen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 07d1d29ee1e194b932328ad2dc1d40297062ab7f
Author: Hans de Goede <[email protected]>
Date:   Fri May 16 21:10:41 2014 +0200

    ACPI / video: Revert native brightness quirk for ThinkPad T530
    
    Seems it helps some users, but causes issues for other users:
    https://bugzilla.redhat.com/show_bug.cgi?id=1089545
    
    So lets drop it for now until we've figured out a better fix.
    
    Fixes: 43d949024425 (ACPI / video: Add use_native_backlight quirks for more systems)
    References: https://bugzilla.redhat.com/show_bug.cgi?id=1089545
    Cc: All applicable <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit be02f259fda66bcfc60ecd78a819e1ce28c8bfb9
Author: Jes Sorensen <[email protected]>
Date:   Fri May 16 10:05:04 2014 +0200

    staging: rtl8723au: Use correct pipe type for USB interrupts
    
    Use a correct pipe type when filling un interrupt urbs. This should
    finally take care of the WARN() messages on the console when USB urbs
    are submitted.
    
    Signed-off-by: Jes Sorensen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4797ec2dc83a43be35bad56037d1b53db9e2b5d5
Author: Mark Salter <[email protected]>
Date:   Thu May 15 15:19:22 2014 +0100

    arm64: fix pud_huge() for 2-level pagetables
    
    The following happens when trying to run a kvm guest on a kernel
    configured for 64k pages. This doesn't happen with 4k pages:
    
      BUG: failure at include/linux/mm.h:297/put_page_testzero()!
      Kernel panic - not syncing: BUG!
      CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF            3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1
      Call trace:
      [<fffffe0000096034>] dump_backtrace+0x0/0x16c
      [<fffffe00000961b4>] show_stack+0x14/0x1c
      [<fffffe000066e648>] dump_stack+0x84/0xb0
      [<fffffe0000668678>] panic+0xf4/0x220
      [<fffffe000018ec78>] free_reserved_area+0x0/0x110
      [<fffffe000018edd8>] free_pages+0x50/0x88
      [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40
      [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44
      [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184
      [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c
      [<fffffe00001edc1c>] __fput+0xb0/0x288
      [<fffffe00001ede4c>] ____fput+0xc/0x14
      [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c
      [<fffffe0000095c14>] do_notify_resume+0x54/0x58
    
    In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page()
    on the stage2 pgd which leads to the BUG in put_page_testzero(). This
    happens because a pud_huge() test in unmap_range() returns true when it
    should always be false with 2-level pages tables used by 64k pages.
    This patch removes support for huge puds if 2-level pagetables are
    being used.
    
    Signed-off-by: Mark Salter <[email protected]>
    [[email protected]: removed #ifndef around PUD_SIZE check]
    Signed-off-by: Catalin Marinas <[email protected]>
    Cc: <[email protected]> # v3.11+

commit dfc44f8030653b345fc6fb337558c3a07536823f
Author: Leif Lindholm <[email protected]>
Date:   Thu Apr 17 18:42:00 2014 +0100

    mips: dts: Fix missing device_type="memory" property in memory nodes
    
    A few platforms lack a 'device_type = "memory"' for their memory
    nodes, relying on an old ppc quirk in order to discover its memory.
    Add the missing data so that all parsing code can find memory nodes
    correctly.
    
    Signed-off-by: Leif Lindholm <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: Mark Rutland <[email protected]>
    Cc: <[email protected]>
    Acked-by: John Crispin <[email protected]>
    Signed-off-by: Grant Likely <[email protected]>

commit bfaed5abad998bfc88a66e6e71c7b08dcf82f04e
Author: Leif Lindholm <[email protected]>
Date:   Thu Apr 17 18:41:59 2014 +0100

    arm: dts: Fix missing device_type="memory" for ste-ccu8540
    
    The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for
    its memory node, relying on an old ppc quirk in order to discover its
    memory. Fix the data so that all parsing code can handle it correctly.
    
    Signed-off-by: Leif Lindholm <[email protected]>
    Acked-by: Lee Jones <[email protected]>
    Acked-by: Linus Walleij <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: Mark Rutland <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Grant Likely <[email protected]>

commit 07b8dae38b09bcfede7e726f172e39b5ce8390d9
Author: Andy Grover <[email protected]>
Date:   Wed May 14 15:48:06 2014 -0700

    target: Don't allow setting WC emulation if device doesn't support
    
    Just like for pSCSI, if the transport sets get_write_cache, then it is
    not valid to enable write cache emulation for it. Return an error.
    
    see https://bugzilla.redhat.com/show_bug.cgi?id=1082675
    
    Reviewed-by: Chris Leech <[email protected]>
    Signed-off-by: Andy Grover <[email protected]>
    Cc: [email protected] # 3.10+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 52d0aa7980cfee85c831b2969e659055395386d4
Author: Nicholas Bellinger <[email protected]>
Date:   Wed May 14 20:54:26 2014 +0000

    iscsi-target: Disable Immediate + Unsolicited Data with ISER Protection
    
    This patch explicitly disables Immediate + Unsolicited Data for ISER
    connections during login in iscsi_login_zero_tsih_s2() when protection
    has been enabled for the session by the underlying hardware.
    
    This is currently required because protection / signature memory regions
    (MRs) expect T10 PI to occur on RDMA READs + RDMA WRITEs transfers, and
    not on a immediate data payload associated with ISCSI_OP_SCSI_CMD, or
    unsolicited data-out associated with a ISCSI_OP_SCSI_DATA_OUT.
    
    v2 changes:
      - Add TARGET_PROT_DOUT_INSERT check (Sagi)
      - Add pr_debug noisemaker (Sagi)
      - Add goto to avoid early return from MRDSL check (nab)
    
    Cc: Sagi Grimberg <[email protected]>
    Cc: Or Gerlitz <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit ed8ec8f707ed4760c124d47b27c93df8ec5b1eba
Author: Nicholas Bellinger <[email protected]>
Date:   Mon May 12 12:18:32 2014 -0700

    tcm_fc: Fix free-after-use regression in ft_free_cmd
    
    This patch fixes a free-after-use regression in ft_free_cmd(), where
    ft_sess_put() is called with cmd->sess after percpu_ida_free() has
    already released the tag.
    
    Fix this bug by saving the ft_sess pointer ahead of percpu_ida_free(),
    and pass it directly to ft_sess_put().
    
    The regression was originally introduced in v3.13-rc1 commit:
    
      commit 5f544cfac956971099e906f94568bc3fd1a7108a
      Author: Nicholas Bellinger <[email protected]>
      Date:   Mon Sep 23 12:12:42 2013 -0700
    
          tcm_fc: Convert to per-cpu command map pre-allocation of ft_cmd
    
    Reported-by: Jun Wu <[email protected]>
    Cc: Mark Rustad <[email protected]>
    Cc: Robert Love <[email protected]>
    Cc: <[email protected]> #3.13+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 7cbfcc953789ff864c2bf8365a82a3fba4869649
Author: Nicholas Bellinger <[email protected]>
Date:   Thu May 1 13:44:56 2014 -0700

    iscsi-target: Change BUG_ON to REJECT in iscsit_process_nop_out
    
    This patch changes an incorrect use of BUG_ON to instead generate a
    REJECT + PROTOCOL_ERROR in iscsit_process_nop_out() code.  This case
    can occur with traditional TCP where a flood of zeros in the data
    stream can reach this block for what is presumed to be a NOP-OUT with
    a solicited reply, but without a valid iscsi_cmd pointer.
    
    This incorrect BUG_ON was introduced during the v3.11-rc timeframe
    with the following commit:
    
    commit 778de368964c5b7e8100cde9f549992d521e9c89
    Author: Nicholas Bellinger <[email protected]>
    Date:   Fri Jun 14 16:07:47 2013 -0700
    
        iscsi/isert-target: Refactor ISCSI_OP_NOOP RX handling
    
    Reported-by: Arshad Hussain <[email protected]>
    Cc: [email protected] # 3.11+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 14f4b54fe38f3a8f8392a50b951c8aa43b63687a
Author: Sagi Grimberg <[email protected]>
Date:   Tue Apr 29 13:13:47 2014 +0300

    Target/iscsi,iser: Avoid accepting transport connections during stop stage
    
    When the target is in stop stage, iSER transport initiates RDMA disconnects.
    The iSER initiator may wish to establish a new connection over the
    still existing network portal. In this case iSER transport should not
    accept and resume new RDMA connections. In order to learn that, iscsi_np
    is added with enabled flag so the iSER transport can check when deciding
    weather to accept and resume a new connection request.
    
    The iscsi_np is enabled after successful transport setup, and disabled
    before iscsi_np login threads are cleaned up.
    
    Signed-off-by: Sagi Grimberg <[email protected]>
    Cc: [email protected] # 3.10+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 531b7bf4bd795d9a09eac92504322a472c010bc8
Author: Sagi Grimberg <[email protected]>
Date:   Tue Apr 29 13:13:45 2014 +0300

    Target/iser: Fix iscsit_accept_np and rdma_cm racy flow
    
    RDMA CM and iSCSI target flows are asynchronous and completely
    uncorrelated. Relying on the fact that iscsi_accept_np will be called
    after CM connection request event and will wait for it is a mistake.
    
    When attempting to login to a few targets this flow is racy and
    unpredictable, but for parallel login to dozens of targets will
    race and hang every time.
    
    The correct synchronizing mechanism in this case is pending on
    a semaphore rather than a wait_for_event. We keep the pending
    interruptible for iscsi_np cleanup stage.
    
    (Squash patch to remove dead code into parent - nab)
    
    Reported-by: Slava Shwartsman <[email protected]>
    Signed-off-by: Sagi Grimberg <[email protected]>
    Cc: [email protected] # 3.10+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 9fe63c88b1d59f1ce054d6948ccd3096496ecedb
Author: Sagi Grimberg <[email protected]>
Date:   Tue Apr 29 13:13:44 2014 +0300

    Target/iser: Fix wrong connection requests list addition
    
    Should be adding list_add_tail($new, $head) and not
    the other way around.
    
    Signed-off-by: Sagi Grimberg <[email protected]>
    Cc: [email protected] # 3.10+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 448ba904160f9d8f69217c28a1692cee5afbff88
Author: Andy Grover <[email protected]>
Date:   Tue Apr 15 14:13:12 2014 -0700

    target: Allow non-supporting backends to set pi_prot_type to 0
    
    Userspace tools assume if a value is read from configfs, it is valid
    and will not cause an error if the same value is written back. The only
    valid value for pi_prot_type for backends not supporting DIF is 0, so allow
    this particular value to be set without returning an error.
    
    Reported-by: Krzysztof Chojnowski <[email protected]>
    Signed-off-by: Andy Grover <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Cc: [email protected] # 3.14+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit c776cd89fc705fc8b5c2e5ad906bf5d791620fed
Author: John David Anglin <[email protected]>
Date:   Sun May 11 18:40:50 2014 -0400

    parisc: Improve LWS-CAS performance
    
    The attached change significantly improves the performance of the LWS-CAS code
    in syscall.S.
    This allows a number of packages to build (e.g., zeromq3, gtest and libxs)
    that previously failed because slow LWS-CAS performance under contention. In
    particular, interrupts taken while the lock was taken degraded performance
    significantly.
    
    The change does the following:
    
    1) Disables interrupts around the CAS operation, and
    2) Changes the loads and stores to use the ordered completer, "o", on
    PA 2.0. "o" and "ma" with a zero offset are equivalent. The latter is
    accepted on both PA 1.X and 2.0.
    
    The use of ordered loads and stores probably makes no difference on all
    existing hardware, but it seemed pedantically correct. In particular, the CAS
    operation must complete before LDCW lock is released. As written before, a
    processor could reorder the operations.
    
    I don't believe the period interrupts are disabled is long enough to
    significantly increase interrupt latency. For example, the TLB insert code is
    longer. Worst case is a memory fault in the CAS operation.
    
    Signed-off-by: John David Anglin <[email protected]>
    Cc: [email protected] # 3.13+
    Signed-off-by: Helge Deller <[email protected]>

commit fef47e2a2e1e75fe50a10f634a80f16808348cc6
Author: Helge Deller <[email protected]>
Date:   Mon May 5 18:07:12 2014 +0200

    parisc: ratelimit userspace segfault printing
    
    Ratelimit printing of userspace segfaults and make it runtime
    configurable via the /proc/sys/debug/exception-trace variable. This
    should resolve syslog from growing way too fast and thus prevents
    possible system service attacks.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected] # 3.13+

commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc
Author: Marcel Apfelbaum <[email protected]>
Date:   Thu May 15 12:42:49 2014 -0600

    PCI: shpchp: Check bridge's secondary (not primary) bus speed
    
    When a new device is added below a hotplug bridge, the bridge's secondary
    bus speed and the device's bus speed must match.  The shpchp driver
    previously checked the bridge's *primary* bus speed, not the secondary bus
    speed.
    
    This caused hot-add errors like:
    
      shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch
    
    Check the secondary bus speed instead.
    
    [bhelgaas: changelog]
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251
    Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core")
    Signed-off-by: Marcel Apfelbaum <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Acked-by: Michael S. Tsirkin <[email protected]>
    CC: [email protected]	# v2.6.34+

commit 4c358e15553ed88bf2ddae422624624e1dd663d1
Author: Stephen Rothwell <[email protected]>
Date:   Thu May 15 14:44:30 2014 +1000

    of: fix CONFIG_OF=n prototype of of_node_full_name()
    
    Make the CONFIG_OF=n prototpe of of_node_full_name() mateh the CONFIG_OF=y
    version.
    
    Fixes compile warnings like this:
    
    sound/soc/soc-core.c: In function 'soc_check_aux_dev':
    sound/soc/soc-core.c:1667:3: warning: passing argument 1 of 'of_node_full_name' discards 'const' qualifier from pointer target type [enabled by default]
       codecname = of_node_full_name(aux_dev->codec_of_node);
    
    when CONFIG_OF is not defined.
    
    Signed-off-by: Stephen Rothwell <[email protected]>
    Signed-off-by: Grant Likely <[email protected]>

commit e95a2f7509f5219177d6821a0a8754f93892ca56
Author: Ville Syrjälä <[email protected]>
Date:   Thu May 8 15:09:19 2014 +0300

    drm/i915: Increase WM memory latency values on SNB
    
    On SNB the BIOS provided WM memory latency values seem insufficient to
    handle high resolution displays.
    
    In this particular case the display mode was a 2560x1440@60Hz, which
    makes the pixel clock 241.5 MHz. It was empirically found that a memory
    latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS
    provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec
    is what the typical BIOS provided values are on IVB systems.
    
    Increase the WM memory latency values to at least 1.2 usec on SNB.
    Hopefully this won't have a significant effect on power consumption.
    
    v2: Increase the latency values regardless of the pixel clock
    
    Cc: Robert N <[email protected]>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254
    Tested-by: Robert Navarro <[email protected]>
    Tested-by: Vitaly Minko <[email protected]>
    Cc: [email protected]
    Signed-off-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Jani Nikula <[email protected]>

commit 721e82c08c1afd6b47367b0e0c4a62140b0667f3
Author: Aaron Lu <[email protected]>
Date:   Mon May 12 16:55:45 2014 +0800

    drm/i915: restore backlight precision when converting from ACPI
    
    When we set backlight on behalf of ACPI opregion, we will convert the
    backlight value in the 0-255 range defined in opregion to the actual
    hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow
    when doing scale) is meant to fix the overflow problem when doing the
    conversion, but it also caused a problem that the converted hardware
    level doesn't quite represent the intended value: say user wants maximum
    backlight level(255 in opregion's range), then we will calculate the
    actual hardware level to be: level = freq / max * level, where freq is
    the hardware's max backlight level(937 on an user's box), and max and
    level are all 255. The converted value should be 937 but the above
    calculation will yield 765.
    
    To fix this issue, just use 64 bits to do the calculation to keep the
    precision and avoid overflow at the same time.
    
    Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491
    Reported-by: Nico Schottelius <[email protected]>
    Reviewed-by: Chris Wilson <[email protected]>
    Cc: [email protected]
    Signed-off-by: Aaron Lu <[email protected]>
    Signed-off-by: Jani Nikula <[email protected]>

commit afba0b5a221c0dacbbdf3a778d539fbc90fc6191
Author: Chris Wilson <[email protected]>
Date:   Tue May 13 16:07:37 2014 +0100

    drm/i915: Use the first mode if there is no preferred mode in the EDID
    
    This matches the algorithm used by earlier kernels when selecting the
    mode for the fbcon. And only if there is no modes at all, do we fall
    back to using the BIOS configuration. Seamless transition is still
    preserved (from the BIOS configuration to ours) so long as the BIOS has
    also chosen what we hope is the native configuration.
    
    Reported-by: Knut Petersen <[email protected]>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655
    Reviewed-by: Jesse Barnes <[email protected]>
    Tested-by: Knut Petersen <[email protected]>
    Signed-off-by: Chris Wilson <[email protected]>
    [Jani: applied Chris' "Please imagine that I wrote this correctly."]
    Signed-off-by: Jani Nikula <[email protected]>

commit f4cdbc21444a45d207a8dc175f44d2facfbd0845
Author: Jani Nikula <[email protected]>
Date:   Wed May 14 13:02:19 2014 +0300

    drm/i915/dp: force eDP lane count to max available lanes on BDW
    
    There are certain BDW high res eDP machines that regressed due to
    
    commit 38aecea0ccbb909d635619cba22f1891e589b434
    Author: Daniel Vetter <[email protected]>
    Date:   Mon Mar 3 11:18:10 2014 +0100
    
        drm/i915: reverse dp link param selection, prefer fast over wide again
    
    The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at
    2.7 Gbps on the affected machines. Link training succeeded for both, but
    the screen remained blank with the former config. Further investigation
    showed that 4 lanes at 5.4 Gbps worked also.
    
    The root cause for the blank screen using 2 lanes remains unknown, but
    apparently the driver for a certain other operating system by default
    uses the max available lanes. Follow suit on Broadwell eDP, for at least
    until we figure out what is going on.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711
    Reviewed-by: Daniel Vetter <[email protected]>
    Reviewed-by: Rodrigo Vivi <[email protected]>
    Tested-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Jani Nikula <[email protected]>

commit fa81511bb0bbb2b1aace3695ce869da9762624ff
Author: Linus Torvalds <[email protected]>
Date:   Wed May 14 16:33:54 2014 -0700

    x86-64, modify_ldt: Make support for 16-bit segments a runtime option
    
    Checkin:
    
    b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
    
    disabled 16-bit segments on 64-bit kernels due to an information
    leak.  However, it does seem that people are genuinely using Wine to
    run old 16-bit Windows programs on Linux.
    
    A proper fix for this ("espfix64") is coming in the upcoming merge
    window, but as a temporary fix, create a sysctl to allow the
    administrator to re-enable support for 16-bit segments.
    
    It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
    you hit this issue and care about your old Windows program more than
    you care about a kernel stack address information leak, you can do
    
       echo 1 > /proc/sys/abi/ldt16
    
    as root (add it to your startup scripts), and you should be ok.
    
    The sysctl table is only added if you have COMPAT support enabled on
    x86-64, but I assume anybody who runs old windows binaries very much
    does that ;)
    
    Signed-off-by: H. Peter Anvin <[email protected]>
    Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com
    Cc: <[email protected]>

commit ffe6902b66aaa4ca6694bc19639259c16d84ddb1
Author: James Hogan <[email protected]>
Date:   Thu May 1 15:05:07 2014 +0100

    asm-generic: remove _STK_LIM_MAX
    
    _STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from
    an arch's include/uapi/asm-generic/resource.h file, but is no longer
    used since both parisc and metag removed the override. Therefore remove
    it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY
    directly in include/asm-generic/resource.h.
    
    Signed-off-by: James Hogan <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: [email protected]
    Cc: Helge Deller <[email protected]>
    Cc: John David Anglin <[email protected]>

commit c70458f50cd4271410aa75011f56ffabc0e2d34a
Author: James Hogan <[email protected]>
Date:   Thu May 1 12:31:14 2014 +0100

    metag: Remove _STK_LIM_MAX override
    
    Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to
    256MB, apparently in an attempt to prevent setup_arg_pages's
    STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is
    far too large for Meta's limited virtual address space and hits a BUG_ON
    (stack_top is usually 0x3ffff000).
    
    However the commit "metag: Reduce maximum stack size to 256MB" reduces
    the absolute stack size limit to a safe value for metag. This allows the
    default _STK_LIM_MAX override to be removed, bringing the default
    behaviour in line with all other architectures. Parisc in particular
    recently removed their override of _STK_LIMT_MAX in commit e0d8898d76a7
    (parisc: remove _STK_LIM_MAX override) since it subtly affects stack
    allocation semantics in userland. Meta's uapi/asm/resource.h can now be
    removed and switch to using generic-y.
    
    Suggested-by: Helge Deller <[email protected]>
    Signed-off-by: James Hogan <[email protected]>
    Cc: [email protected]
    Cc: John David Anglin <[email protected]>

commit 042d27acb64924a0e8a43e972485913a32407beb
Author: Helge Deller <[email protected]>
Date:   Wed Apr 30 23:26:02 2014 +0200

    parisc,metag: Do not hardcode maximum userspace stack size
    
    This patch affects only architectures where the stack grows upwards
    (currently parisc and metag only). On those do not hardcode the maximum
    initial stack size to 1GB for 32-bit processes, but make it configurable
    via a config option.
    
    The main problem with the hardcoded stack size is, that we have two
    memory regions which grow upwards: stack and heap. To keep most of the
    memory available for heap in a flexmap memory layout, it makes no sense
    to hard allocate up to 1GB of the memory for stack which can't be used
    as heap then.
    
    This patch makes the stack size for 32-bit processes configurable and
    uses 80MB as default value which has been in use during the last few
    years on parisc and which hasn't showed any problems yet.
    
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: James Hogan <[email protected]>
    Cc: "James E.J. Bottomley" <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: John David Anglin <[email protected]>

commit d71f290b4e98a39f49f2595a13be3b4d5ce8e1f1
Author: James Hogan <[email protected]>
Date:   Tue May 13 23:58:24 2014 +0100

    metag: Reduce maximum stack size to 256MB
    
    Specify the maximum stack size for arches where the stack grows upward
    (parisc and metag) in asm/processor.h rather than hard coding in
    fs/exec.c so that metag can specify a smaller value of 256MB rather than
    1GB.
    
    This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased
    beyond a safe value by root. E.g. when starting a process after running
    "ulimit -H -s unlimited" it will then attempt to use a stack size of the
    maximum 1GB which is far too big for metag's limited user virtual
    address space (stack_top is usually 0x3ffff000):
    
    BUG: failure at fs/exec.c:589/shift_arg_pages()!
    
    Signed-off-by: James Hogan <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: "James E.J. Bottomley" <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: John David Anglin <[email protected]>
    Cc: [email protected] # only needed for >= v3.9 (arch/metag)

commit 2425ce84026c385b73ae72039f90d042d49e0394
Author: Mikulas Patocka <[email protected]>
Date:   Thu May 8 15:51:37 2014 -0400

    metag: fix memory barriers
    
    Volatile access doesn't really imply the compiler barrier. Volatile access
    is only ordered with respect to other volatile accesses, it isn't ordered
    with respect to general memory accesses. Gcc may reorder memory accesses
    around volatile access, as we can see in this simple example (if we
    compile it with optimization, both increments of *b will be collapsed to
    just one):
    
    void fn(volatile int *a, long *b)
    {
    	(*b)++;
    	*a = 10;
    	(*b)++;
    }
    
    Consequently, we need the compiler barrier after a write to the volatile
    variable, to make sure that the compiler doesn't reorder the volatile
    write with something else.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Cc: [email protected]
    Acked-by: Peter Zijlstra <[email protected]>
    Signed-off-by: James Hogan <[email protected]>

commit 4cdd2ad78098244c1bc9ec4374ea1c225fd1cd6f
Author: Mike Snitzer <[email protected]>
Date:   Tue May 13 13:49:39 2014 -0400

    dm mpath: fix lock order inconsistency in multipath_ioctl
    
    Commit 3e9f1be1b40 ("dm mpath: remove process_queued_ios()") did not
    consistently take the multipath device's spinlock (m->lock) before
    calling dm_table_run_md_queue_async() -- which takes the q->queue_lock.
    
    Found with code inspection using hint from reported lockdep warning.
    
    Reported-by: Bart Van Assche <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 85ad643b7e7e52d37620fb272a9fd577a8095647
Author: Joe Thornber <[email protected]>
Date:   Fri May 9 15:59:38 2014 +0100

    dm thin: add timeout to stop out-of-data-space mode holding IO forever
    
    If the pool runs out of data space, dm-thin can be configured to
    either error IOs that would trigger provisioning, or hold those IOs
    until the pool is resized.  Unfortunately, holding IOs until the pool is
    resized can result in a cascade of tasks hitting the hung_task_timeout,
    which may render the system unavailable.
    
    Add a fixed timeout so IOs can only be held for a maximum of 60 seconds.
    If LVM is going to resize a thin-pool that is out of data space it needs
    to be prompt about it.
    
    Signed-off-by: Joe Thornber <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Cc: [email protected] # 3.14+

commit 8d07e8a5f5bc7b90f755d9b427ea930024f4c986
Author: Joe Thornber <[email protected]>
Date:   Tue May 6 16:28:14 2014 +0100

    dm thin: allow metadata commit if pool is in PM_OUT_OF_DATA_SPACE mode
    
    Commit 3e1a0699 ("dm thin: fix out of data space handling") introduced
    a regression in the metadata commit() method by returning an error if
    the pool is in PM_OUT_OF_DATA_SPACE mode.  This oversight caused a thin
    device to return errors even if the default queue_if_no_space ENOSPC
    handling mode is used.
    
    Fix commit() to only fail if pool is in PM_READ_ONLY or PM_FAIL mode.
    
    Reported-by: [email protected]
    Signed-off-by: Joe Thornber <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Cc: [email protected] # 3.14+

commit 610f2de3559c383caf8fbbf91e9968102dff7ca0
Author: Mikulas Patocka <[email protected]>
Date:   Thu Feb 20 18:01:01 2014 -0500

    dm crypt: fix cpu hotplug crash by removing per-cpu structure
    
    The DM crypt target used per-cpu structures to hold pointers to a
    ablkcipher_request structure.  The code assumed that the work item keeps
    executing on a single CPU, so it didn't use synchronization when
    accessing this structure.
    
    If a CPU is disabled by writing 0 to /sys/devices/system/cpu/cpu*/online,
    the work item could be moved to another CPU.  This causes dm-crypt
    crashes, like the following, because the code starts using an incorrect
    ablkcipher_request:
    
     smpboot: CPU 7 is now offline
     BUG: unable to handle kernel NULL pointer dereference at 0000000000000130
     IP: [<ffffffffa1862b3d>] crypt_convert+0x12d/0x3c0 [dm_crypt]
     ...
     Call Trace:
      [<ffffffffa1864415>] ? kcryptd_crypt+0x305/0x470 [dm_crypt]
      [<ffffffff81062060>] ? finish_task_switch+0x40/0xc0
      [<ffffffff81052a28>] ? process_one_work+0x168/0x470
      [<ffffffff8105366b>] ? worker_thread+0x10b/0x390
      [<ffffffff81053560>] ? manage_workers.isra.26+0x290/0x290
      [<ffffffff81058d9f>] ? kthread+0xaf/0xc0
      [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120
      [<ffffffff813464ac>] ? ret_from_fork+0x7c/0xb0
      [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120
    
    Fix this bug by removing the per-cpu definition.  The structure
    ablkcipher_request is accessed via a pointer from convert_context.
    Consequently, if the work item is rescheduled to a different CPU, the
    thread still uses the same ablkcipher_request.
    
    This change may undermine performance improvements intended by commit
    c0297721 ("dm crypt: scale to multiple cpus") on select hardware.  In
    practice no performance difference was observed on recent hardware.  But
    regardless, correctness is more important than performance.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Cc: [email protected]

commit d7653964c590ba846aa11a8f6edf409773cbc492
Author: Wolfram Sang <[email protected]>
Date:   Mon May 5 18:36:21 2014 +0200

    i2c: rcar: bail out on zero length transfers
    
    This hardware does not support zero length transfers. Instead, the
    driver does one (random) byte transfers currently with undefined results
    for the slaves. We now bail out.
    
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Cc: [email protected]

commit fa01d096bfcfd89398b1f3a3f91805dab76f7fe5
Author: Andy Gross <[email protected]>
Date:   Fri May 2 20:54:29 2014 -0500

    i2c: qup: Fix pm_runtime_get_sync usage
    
    This patch corrects the error check on the call to pm_runtime_get_sync.
    
    Signed-off-by: Andy Gross <[email protected]>
    Reviewed-by: Ivan T. Ivanov <[email protected]>
    Acked-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>

commit ce78cc071f5f541480e381cc0241d37590041a9d
Author: Olof Johansson <[email protected]>
Date:   Fri Apr 11 15:19:41 2014 -0700

    i2c: s3c2410: resume race fix
    
    Don't unmark the device as suspended until after it's been re-setup.
    
    The main race would be w.r.t. an i2c driver that gets resumed at the same
    time (asyncronously), that is allowed to do a transfer since suspended
    is set to 0 before reinit, but really should have seen the -EIO return
    instead.
    
    Signed-off-by: Olof Johansson <[email protected]>
    Signed-off-by: Doug Anderson <[email protected]>
    Acked-by: Kukjin Kim <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Cc: [email protected]

commit 37e5eb0bae7bb4d98c2153c3c3400b5c00c3cad1
Author: Ulf Hansson <[email protected]>
Date:   Thu Apr 10 16:19:29 2014 +0200

    i2c: nomadik: Don't use IS_ERR for devm_ioremap
    
    devm_ioremap() returns NULL on error, not an error.
    
    Signed-off-by: Ulf Hansson <[email protected]>
    Acked-by: Linus Walleij <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Cc: [email protected]

commit 47bb27e78867997040a228328f2a631c3c7f2c82
Author: Du, Wenkai <[email protected]>
Date:   Thu Apr 10 23:03:19 2014 +0000

    i2c: designware: Mask all interrupts during i2c controller enable
    
    There have been "i2c_designware 80860F41:00: controller timed out" errors
    on a number of Baytrail platforms. The issue is caused by incorrect value in
    Interrupt Mask Register (DW_IC_INTR_MASK)  when i2c core is being enabled.
    This causes call to __i2c_dw_enable() to immediately start the transfer which
    leads to timeout. There are 3 failure modes observed:
    
    1. Failure in S0 to S3 resume path
    
    The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start
    the first transaction after resuming from system sleep, TX_EMPTY interrupt
    is already unmasked because of the hardware default.
    
    2. Failure in normal operational path
    
    This failure happens rarely and is hard to reproduce. Debug trace showed that
    DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant
    TX_EMPTY was unmasked.
    
    3. Failure in S3 to S0 suspend path
    
    This failure also happens rarely and is hard to reproduce. Adding debug trace
    that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR
    call trace we could conclude TX_EMPTY was unmasked when problem occurred.
    
    The patch masks all interrupts before the controller is enabled to resolve the
    faulty DW_IC_INTR_MASK conditions.
    
    Signed-off-by: Wenkai Du <[email protected]>
    Acked-by: Mika Westerberg <[email protected]>
    [wsa: improved the comment and removed typo in commit msg]
    Signed-off-by: Wolfram Sang <[email protected]>
    Cc: [email protected]

commit 7bb394094080a26de06efcd6a870cb2ba21cfb16
Author: Steven J. Hill <[email protected]>
Date:   Thu Apr 10 14:06:17 2014 -0500

    MIPS: mm: Fix broken microMIPS kernel regression.
    
    Commit f4ae17aa0f2122b52f642985b46210a1f2eceb0a [MIPS: mm: Use scratch for
    PGD when !CONFIG_MIPS_PGD_C0_CONTEXT] broke microMIPS kernel builds. This
    patch refactors that code similar to what was done for the 'clear_page'
    and 'copy_page' functions.
    
    Signed-off-by: Steven J. Hill <[email protected]>
    Cc: [email protected]
    Patchwork: https://patchwork.linux-mips.org/patch/6744/
    Signed-off-by: Ralf Baechle <[email protected]>

commit 665ebe926e7b714369b5329d48745bfef17db512
Author: Dan Carpenter <[email protected]>
Date:   Wed May 14 16:32:21 2014 +0300

    ALSA: sb_mixer: missing return statement
    
    The if condition here was supposed to return on error but the return
    statement is missing.  The effect is that the ->mixername is set to
    "???" instead of "DT019X".
    
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>

commit 582da6527da30f6e21a95c9f3f2810d46a8f406e
Author: Thomas Petazzoni <[email protected]>
Date:   Wed May 14 13:36:36 2014 +0200

    of: make of_update_property() usable earlier in the boot process
    
    Commit 75b57ecf9d1d1e17d099ab13b8f48e6e038676be ('of: Make device
    nodes kobjects so they show up in sysfs') has turned Device Tree nodes
    in kobjects and added a sysfs based representation for Device Tree
    nodes. Since the sysfs logic is only available after the execution of
    a core_initcall(), the patch took precautions in of_add_property() and
    of_remove_property() to not do any sysfs related manipulation early in
    the boot process.
    
    However, it forgot to do the same for of_update_property(), which if
    used early in the boot process (before core_initcalls have been
    called), tries to call sysfs_remove_bin_file(), and crashes:
    
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 0 at /home/thomas/projets/linux-2.6/fs/kernfs/dir.c:1216 kernfs_remove_by_name_ns+0x80/0x88()
    kernfs: can not remove '(null)', no directory
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc1-00127-g1d7e7b2-dirty #423
    [<c0014910>] (unwind_backtrace) from [<c00110ec>] (show_stack+0x10/0x14)
    [<c00110ec>] (show_stack) from [<c04c84b8>] (dump_stack+0x84/0x94)
    [<c04c84b8>] (dump_stack) from [<c001d8c0>] (warn_slowpath_common+0x6c/0x88)
    [<c001d8c0>] (warn_slowpath_common) from [<c001d90c>] (warn_slowpath_fmt+0x30/0x40)
    [<c001d90c>] (warn_slowpath_fmt) from [<c0104468>] (kernfs_remove_by_name_ns+0x80/0x88)
    [<c0104468>] (kernfs_remove_by_name_ns) from [<c0394d98>] (of_update_property+0xc0/0xf0)
    [<c0394d98>] (of_update_property) from [<c0647248>] (mvebu_timer_and_clk_init+0xfc/0x194)
    [<c0647248>] (mvebu_timer_and_clk_init) from [<c0640934>] (start_kernel+0x218/0x350)
    [<c0640934>] (start_kernel) from [<00008070>] (0x8070)
    ---[ end trace 3406ff24bd97382e ]---
    Unable to handle kernel NULL pointer dereference at virtual address 0000003c
    pgd = c0004000
    [0000003c] *pgd=00000000
    Internal error: Oops: 5 [#1] SMP ARM
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W     3.15.0-rc1-00127-g1d7e7b2-dirty #423
    task: c10ad4d8 ti: c10a2000 task.ti: c10a2000
    PC is at kernfs_find_ns+0x8/0xf0
    LR is at kernfs_find_and_get_ns+0x30/0x48
    pc : [<c0103834>]    lr : [<c010394c>]    psr: 600001d3
    sp : c10a3f34  ip : 00000073  fp : 00000000
    r10: 00000000  r9 : cfffc240  r8 : cfdf2980
    r7 : cf812c00  r6 : 00000000  r5 : 00000000  r4 : c10b45e0
    r3 : c10ad4d8  r2 : 00000000  r1 : cf812c00  r0 : 00000000
    Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
    Control: 10c53c7d  Table: 0000404a  DAC: 00000015
    Process swapper/0 (pid: 0, stack limit = 0xc10a2240)
    Stack: (0xc10a3f34 to 0xc10a4000)
    3f20:                                              c10b45e0 00000000 00000000
    3f40: cf812c00 c010394c 00000063 cf812c00 00000001 cf812c00 cfdf29ac c03932cc
    3f60: 00000063 cf812bc0 cfdf29ac cf812c00 ffffffff c03943f8 cfdf2980 c0104468
    3f80: cfdf2a04 cfdf2980 cf812bc0 c06634b0 c10aa3c0 c0394da4 c10f74dc cfdf2980
    3fa0: cf812bc0 c0647248 c10aa3c0 ffffffff c10de940 c10aa3c0 ffffffff c0640934
    3fc0: ffffffff ffffffff c06404ec 00000000 00000000 c06634b0 00000000 10c53c7d
    3fe0: c10aa434 c06634ac c10ae4c8 0000406a 414fc091 00008070 00000000 00000000
    [<c0103834>] (kernfs_find_ns) from [<00000001>] (0x1)
    Code: e5c89001 eaffffcf e92d40f0 e1a06002 (e1d023bc)
    ---[ end trace 3406ff24bd97382f ]---
    Kernel panic - not syncing: Attempted to kill the idle task!
    ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
    
    To fix this problem, we simply skip the sysfs related calls in
    of_update_property(), and rely on of_init() to fix up things when it
    will be called, exactly as is done in of_add_property() and
    of_remove_property().
    
    Signed-off-by: Thomas Petazzoni <[email protected]>
    Fixes: 75b57ecf9d1d ("of: Make device nodes kobjects so they show up in sysfs")
    Signed-off-by: Grant Likely <[email protected]>

commit f2d0801f00b7aff0ac6b3666cbcdab499267418a
Author: Markos Chandras <[email protected]>
Date:   Tue Apr 22 15:40:36 2014 +0100

    MIPS: Add new AUDIT_ARCH token for the N32 ABI on MIPS64
    
    A MIPS64 kernel may support ELF files for all 3 MIPS ABIs
    (O32, N32, N64). Furthermore, the AUDIT_ARCH_MIPS{,EL}64 token
    does not provide enough information about the ABI for the 64-bit
    process. As a result of which, userland needs to use complex
    seccomp filters to decide whether a syscall belongs to the o32 or n32
    or n64 ABI. Therefore, a new arch token for MIPS64/n32 is added so it
    can be used by seccomp to explicitely set syscall filters for this ABI.
    
    Signed-off-by: Markos Chandras <[email protected]>
    Acked-by: Eric Paris <[email protected]>
    Acked-by: Paul Moore <[email protected]>
    Cc: Andy Lutomirski <[email protected]>
    Cc: Ralf Baechle <[email protected]>
    Cc: Andy Lutomirski <[email protected]>
    Cc: [email protected]
    Link: http://sourceforge.net/p/libseccomp/mailman/message/32239040/
    Patchwork: https://patchwork.linux-mips.org/patch/6818/
    Signed-off-by: Ralf Baechle <[email protected]>

commit 9844f5462392b53824e8b86726e7c33b5ecbb676
Author: Anthony Iliopoulos <[email protected]>
Date:   Wed May 14 11:29:48 2014 +0200

    x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow()
    
    The invalidation is required in order to maintain proper semantics
    under CoW conditions. In scenarios where a process clones several
    threads, a thread operating on a core whose DTLB entry for a
    particular hugepage has not been invalidated, will be reading from
    the hugepage that belongs to the forked child process, even after
    hugetlb_cow().
    
    The thread will not see the updated page as long as the stale DTLB
    entry remains cached, the thread attempts to write into the page,
    the child process exits, or the thread gets migrated to a different
    processor.
    
    Signed-off-by: Anthony Iliopoulos <[email protected]>
    Link: http://lkml.kernel.org/r/[email protected]
    Suggested-by: Shay Goikhman <[email protected]>
    Acked-by: Dave Hansen <[email protected]>
    Signed-off-by: H. Peter Anvin <[email protected]>
    Cc: <[email protected]> # v2.6.16+ (!)

commit 97d9d23dda6f37d90aefeec4ed619d52df525382
Author: Guennadi Liakhovetski <[email protected]>
Date:   Sat Apr 26 12:51:31 2014 -0300

    [media] V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode
    
    If a struct contains 64-bit fields, it is aligned on 64-bit boundaries
    within containing structs in 64-bit compilations. This is the case with
    struct v4l2_window, which contains pointers and is embedded into struct
    v4l2_format, and that one is embedded into struct v4l2_create_buffers.
    Unlike some other structs, used as a part of the kernel ABI as ioctl()
    arguments, that are packed, these structs aren't packed. This isn't a
    problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains
    a bug, that triggers in such 64-bit builds. That code wrongly assumes,
    that in struct v4l2_create_buffers, struct v4l2_format immediately follows
    the __u32 memory field, which in fact isn't the case. This bug wasn't
    visible until now, because until recently hardly any applications used
    this ioctl() and mostly embedded 32-bit only drivers implemented it. This
    is changing now with addition of this ioctl() to some USB drivers, e.g.
    UVC. This patch fixes the bug by copying parts of struct
    v4l2_create_buffers separately.
    
    Signed-off-by: Guennadi Liakhovetski <[email protected]>
    Acked-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Cc: [email protected]

commit cfece5857ca51d1dcdb157017aba226f594e9dcf
Author: Guennadi Liakhovetski <[email protected]>
Date:   Mon Apr 14 10:49:34 2014 -0300

    [media] V4L2: ov7670: fix a wrong index, potentially Oopsing the kernel from user-space
    
    Commit 75e2bdad8901a0b599e01a96229be922eef1e488 "ov7670: allow
    configuration of image size, clock speed, and I/O method" uses a wrong
    index to iterate an array. Apart from being wrong, it also uses an
    unchecked value from user-space, which can cause access to unmapped
    memory in the kernel, triggered by a normal desktop user with rights to
    use V4L2 devices.
    
    Signed-off-by: Guennadi Liakhovetski <[email protected]>
    Acked-by: Jonathan Corbet <[email protected]>
    Cc: [email protected]
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>

commit 2ed9fd28c2884e9f41c133f86a7e377d7c0a96bf
Author: Jason Cooper <[email protected]>
Date:   Tue May 13 18:47:01 2014 +0000

    MAINTAINERS: Add co-maintainer for drivers/irqchip
    
    Thomas Gleixner has asked me to assist with the review and merging of
    patches for the irqchip subsystem.
    
    Signed-off-by: Jason Cooper <[email protected]>
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Thomas Gleixner <[email protected]>

commit 44330ab516c15dda8a1e660eeaf0003f84e43e3f
Author: Charles Keepax <[email protected]>
Date:   Tue May 13 13:45:15 2014 +0100

    ASoC: wm8962: Update register CLASS_D_CONTROL_1 to be non-volatile
    
    The register CLASS_D_CONTROL_1 is marked as volatile because it contains
    a bit, DAC_MUTE, which is also mirrored in the ADC_DAC_CONTROL_1
    register. This causes problems for the "Speaker Switch" control, which
    will report an error if the CODEC is suspended because it relies on a
    volatile register.
    
    To resolve this issue mark CLASS_D_CONTROL_1 as non-volatile and
    manually keep the register cache in sync by updating both bits when
    changing the mute status.
    
    Reported-by: Shawn Guo <[email protected]>
    Signed-off-by: Charles Keepax <[email protected]>
    Tested-by: Shawn Guo <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Cc: [email protected]

commit cffd6665f57ed18f4be9185c4330c8c98c22e201
Author: Jarkko Nikula <[email protected]>
Date:   Tue May 13 15:46:06 2014 +0300

    ASoC: Intel: Fix Baytrail SST DSP firmware loading
    
    Commit 10df350977b1 ("ASoC: Intel: Fix Audio DSP usage when IOMMU is
    enabled.") caused following regression in Baytrail SST:
    
    baytrail-pcm-audio baytrail-pcm-audio: error: DMA alloc failed
    baytrail-pcm-audio baytrail-pcm-audio: error: failed to load firmware
    
    Fix this by calling dma_coerce_mask_and_coherent() in sst_byt_init() with
    the same dma_dev device what is now used in sst_fw_new() when allocating the
    DMA buffer.
    
    Signed-off-by: Jarkko Nikula <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 367f0b50e502d2c384277ba2ed43b04add2b8b6f
Author: Ralf Baechle <[email protected]>
Date:   Tue May 13 17:56:41 2014 +0200

    MIPS: Wire up renameat2 syscall.
    
    Signed-off-by: Ralf Baechle <[email protected]>

commit d40a63c45b506b0681918d7c62a15cc9d48c8681
Author: Dirk Brandewie <[email protected]>
Date:   Thu May 8 12:57:24 2014 -0700

    intel_pstate: remove setting P state to MAX on init
    
    Setting the P state of the core to max at init time is a hold over
    from early implementation of intel_pstate where intel_pstate disabled
    cpufreq and loaded VERY early in the boot sequence.  This was to
    ensure that intel_pstate did not affect boot time. This in not needed
    now that intel_pstate is a cpufreq driver.
    
    Removing this covers the case where a CPU has gone through a manual
    CPU offline/online cycle and the P state is set to MAX on init and the
    CPU immediately goes idle.  Due to HW coordination the P state request
    on the idle CPU will drag all cores to MAX P state until the load is
    reevaluated when to core goes non-idle.
    
    Reported-by: Patrick Marlier <[email protected]>
    Signed-off-by: Dirk Brandewie <[email protected]>
    Cc: 3.14+ <[email protected]> # 3.14+
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 36e9d2ebcc15d029b33f42a36146ab5a5bcfcfe7
Author: Tejun Heo <[email protected]>
Date:   Tue May 13 11:28:30 2014 -0400

    cgroup: fix rcu_read_lock() leak in update_if_frozen()
    
    While updating cgroup_freezer locking, 68fafb77d827 ("cgroup_freezer:
    replace freezer->lock with freezer_mutex") introduced a bug in
    update_if_frozen() where it returns with rcu_read_lock() held.  Fix it
    by adding rcu_read_unlock() before returning.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reported-by: kbuild test robot <[email protected]>

commit e5ced8ebb10c20a3b349bd798b69ccabd3b25d21
Author: Tejun Heo <[email protected]>
Date:   Wed May 7 21:31:17 2014 -0400

    cgroup_freezer: replace freezer->lock with freezer_mutex
    
    After 96d365e0b86e ("cgroup: make css_set_lock a rwsem and rename it
    to css_set_rwsem"), css task iterators requires sleepable context as
    it may block on css_set_rwsem.  I missed that cgroup_freezer was
    iterating tasks under IRQ-safe spinlock freezer->lock.  This leads to
    errors like the following on freezer state reads and transitions.
    
      BUG: sleeping function called from invalid context at /work
     /os/work/kernel/locking/rwsem.c:20
      in_atomic(): 0, irqs_disabled(): 0, pid: 462, name: bash
      5 locks held by bash/462:
       #0:  (sb_writers#7){.+.+.+}, at: [<ffffffff811f0843>] vfs_write+0x1a3/0x1c0
       #1:  (&of->mutex){+.+.+.}, at: [<ffffffff8126d78b>] kernfs_fop_write+0xbb/0x170
       #2:  (s_active#70){.+.+.+}, at: [<ffffffff8126d793>] kernfs_fop_write+0xc3/0x170
       #3:  (freezer_mutex){+.+...}, at: [<ffffffff81135981>] freezer_write+0x61/0x1e0
       #4:  (rcu_read_lock){......}, at: [<ffffffff81135973>] freezer_write+0x53/0x1e0
      Preemption disabled at:[<ffffffff81104404>] console_unlock+0x1e4/0x460
    
      CPU: 3 PID: 462 Comm: bash Not tainted 3.15.0-rc1-work+ #10
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       ffff88000916a6d0 ffff88000e0a3da0 ffffffff81cf8c96 0000000000000000
       ffff88000e0a3dc8 ffffffff810cf4f2 ffffffff82388040 ffff880013aaf740
       0000000000000002 ffff88000e0a3de8 ffffffff81d05974 0000000000000246
      Call Trace:
       [<ffffffff81cf8c96>] dump_stack+0x4e/0x7a
       [<ffffffff810cf4f2>] __might_sleep+0x162/0x260
       [<ffffffff81d05974>] down_read+0x24/0x60
       [<ffffffff81133e87>] css_task_iter_start+0x27/0x70
       [<ffffffff8113584d>] freezer_apply_state+0x5d/0x130
       [<ffffffff81135a16>] freezer_write+0xf6/0x1e0
       [<ffffffff8112eb88>] cgroup_file_write+0xd8/0x230
       [<ffffffff8126d7b7>] kernfs_fop_write+0xe7/0x170
       [<ffffffff811f0756>] vfs_write+0xb6/0x1c0
       [<ffffffff811f121d>] SyS_write+0x4d/0xc0
       [<ffffffff81d08292>] system_call_fastpath+0x16/0x1b
    
    freezer->lock used to be used in hot paths but that time is long gone
    and there's no reason for the lock to be IRQ-safe spinlock or even
    per-cgroup.  In fact, given the fact that a cgroup may contain large
    number of tasks, it's not a good idea to iterate over them while
    holding IRQ-safe spinlock.
    
    Let's simplify locking by replacing per-cgroup freezer->lock with
    global freezer_mutex.  This also makes the comments explaining the
    intricacies of policy inheritance and the locking around it as the
    states are protected by a common mutex.
    
    The conversion is mostly straight-forward.  The followings are worth
    mentioning.
    
    * freezer_css_online() no longer needs double locking.
    
    * freezer_attach() now performs propagation simply while holding
      freezer_mutex.  update_if_frozen() race no longer exists and the
      comment is removed.
    
    * freezer_fork() now tests whether the task is in root cgroup using
      the new task_css_is_root() without doing rcu_read_lock/unlock().  If
      not, it grabs freezer_mutex and performs the operation.
    
    * freezer_read() and freezer_change_state() grab freezer_mutex across
      the whole operation and pin the css while iterating so that each
      descendant processing happens in sleepable context.
    
    Fixes: 96d365e0b86e ("cgroup: make css_set_lock a rwsem and rename it to css_set_rwsem")
    Signed-off-by: Tejun Heo <[email protected]>
    Acked-by: Li Zefan <[email protected]>

commit 5024ae29cd285ce9e736776414da645d3a91828c
Author: Tejun Heo <[email protected]>
Date:   Wed May 7 21:31:17 2014 -0400

    cgroup: introduce task_css_is_root()
    
    Determining the css of a task usually requires RCU read lock as that's
    the only thing which keeps the returned css accessible till its
    reference is acquired; however, testing whether a task belongs to the
    root can be performed without dereferencing the returned css by
    comparing the returned pointer against the root one in init_css_set[]
    which never changes.
    
    Implement task_css_is_root() which can be invoked in any context.
    This will be used by the scheduled cgroup_freezer change.
    
    v2: cgroup no longer supports modular controllers.  No need to export
        init_css_set.  Pointed out by Li.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Acked-by: Li Zefan <[email protected]>

commit 85dbd5801f62b66e2aa7826aaefcaebead44c8a6
Author: Lv Zheng <[email protected]>
Date:   Tue May 13 16:50:30 2014 +0800

    ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses.
    
    We need to find a smarter way to switch to 64-bit FADT addresses according
    to the bug report.  This patch reverts Linux to the original behavior.
    
    Fixes: 0249ed2444d6 (ACPICA: Add option to favor 32-bit FADT addresses.)
    References: https://bugzilla.kernel.org/show_bug.cgi?id=74021
    Reported-and-tested-by: Oswald Buddenhagen <[email protected]>
    Signed-off-by: Lv Zheng <[email protected]>
    Cc: 3.14+ <[email protected]> # 3.14+
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 5ff365fb6aed4c7ee5aae7b0239ce0b514aefabc
Author: Aaron Lu <[email protected]>
Date:   Tue May 13 09:51:50 2014 +0800

    ACPI / video: correct DMI tag for Dell Inspiron 7520
    
    The DMI tag used to identify Dell Inspiron 7520 should be product name
    instead of product version.
    
    Fixes: 0e9f81d3b7cd (ACPI / video: Add systems that should favour native backlight interface)
    Reported-and-tested-by: Téo Mazars <[email protected]>
    References: https://bugzilla.redhat.com/show_bug.cgi?id=909552
    Cc: All applicable <[email protected]>
    Signed-off-by: Aaron Lu <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 555724a831b4a146e7bdf16ecc989cda032b076d
Author: Tejun Heo <[email protected]>
Date:   Mon May 12 13:56:27 2014 -0400

    kernfs, sysfs, cgroup: restrict extra perm check on open to sysfs
    
    The kernfs open method - kernfs_fop_open() - inherited extra
    permission checks from sysfs.  While the vfs layer allows ignoring the
    read/write permissions checks if the issuer has CAP_DAC_OVERRIDE,
    sysfs explicitly denied open regardless of the cap if the file doesn't
    have any of the UGO perms of the requested access or doesn't implement
    the requested operation.  It can be debated whether this was a good
    idea or not but the behavior is too subtle and dangerous to change at
    this point.
    
    After cgroup got converted to kernfs, this extra perm check also got
    applied to cgroup breaking libcgroup which opens write-only files with
    O_RDWR as root.  This patch gates the extra open permission check with
    a new flag KERNFS_ROOT_EXTRA_OPEN_PERM_CHECK and enables it for sysfs.
    For sysfs, nothing changes.  For cgroup, root now can perform any
    operation regardless of the permissions as it was before kernfs
    conversion.  Note that kernfs still fails unimplemented operations
    with -EINVAL.
    
    While at it, add comments explaining KERNFS_ROOT flags.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reported-by: Andrey Wagin <[email protected]>
    Tested-by: Andrey Wagin <[email protected]>
    Cc: Li Zefan <[email protected]>
    References: http://lkml.kernel.org/g/CANaxB-xUm3rJ-Cbp72q-rQJO5mZe1qK6qXsQM=vh0U8upJ44+A@mail.gmail.com
    Fixes: 2bd59d48ebfb ("cgroup: convert to kernfs")
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7189eb9b8f7962474956196c301676470542f253
Author: Mengdong Lin <[email protected]>
Date:   Tue May 13 16:57:08 2014 +0800

    ALSA: hda - mask buggy stream DMA0 for Broadwell display controller
    
    Broadwell display controller has 3 stream DMA engines. DMA0 cannot update DMA
    postion buffer properly while DMA1 and DMA2 can work well. So this patch masks
    the buggy DMA0 by keeping it as opened.
    
    This is a tentative workaround, so keep the change small as Takashi suggested.
    
    Signed-off-by: Mengdong Lin <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>

commit ec5fe98886b686f065ef29d8dee1b3ca66f5fd48
Author: Aaron Plattner <[email protected]>
Date:   Mon May 12 20:05:02 2014 -0700

    ALSA: hda - Add new GPU codec ID to snd-hda
    
    Vendor ID 0x10de0071 is used by a yet-to-be-named GPU chip.
    
    Signed-off-by: Aaron Plattner <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>

commit 8e33f91a0b84ae1964bef77cb92f5d41d97530c8
Author: Ben Dooks <[email protected]>
Date:   Tue Apr 15 17:06:34 2014 +0100

    clk: shmobile: clk-mstp: change to using clock-indices
    
    With the addition of clock-indices, we need to change the renesas
    clock implementation to use these instead of the local definition
    of "renesas,clock-indices".
    
    Since this will break booting with older device trees, we add a
    simple auto-detection of which properties are present.
    
    Signed-off-by: Ben Dooks <ben.dooks@codethin…
ddstreet referenced this pull request in ddstreet/linux May 28, 2014
@hnaz
linux-next
af76da1 
GIT b96ba19767320e2b27ceb4e1976ec21f0ab54605

commit fbfad49076646165bbd72de4dccf1d5132ab7856
Author: Lars-Peter Clausen <[email protected]>
Date:   Tue May 20 11:13:28 2014 +0200

    ASoC: neo1973_wm8753: Automatically disconnected non-connected pins
    
    The DAPM routes for this board are complete, hence we can let the core take care
    of disconnecting non-connected pins rather than doing it manually.
    
    Signed-off-by: Lars-Peter Clausen <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 41148c3a728222a885bc2f3ba3ce66831de0b244
Author: Qipan Li <[email protected]>
Date:   Sun May 4 14:32:36 2014 +0800

    spi: sirf: decrease the interrupt count and latency of PIO mode
    
    current PIO tranfer method be described as follows:
    1. fill as much as bytes but no more than 256 bytes(fifo size)
    2. enable oflow/uflow/txfifo_empty interrupt
    3. isr process 3 interrupt signal, do complete works.
    4. after isr done, if there are left bytes go into 1 else go into 5
    5. transfer end
    
    by current PIO transfer method:
    1. reduce interrupt counts in spi interrupt line.
    2. reduce interrupt latency because no do data fill/fetch in isr.
    
    Signed-off-by: Qipan Li <[email protected]>
    Signed-off-by: Barry Song <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit c86d50f9dc525cb0264c25ed5186faf0f1d00477
Author: Sylwester Nawrocki <[email protected]>
Date:   Mon May 19 19:30:38 2014 +0200

    ASoC: samsung: Allow setting OP_CLK of the IIS Multi Audio Interface
    
    This patch adds support for setting source clock of the "Core CLK"
    of the IIS Multi Audio Interface.
    
    Signed-off-by: Sylwester Nawrocki <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit b45281412a6334ab2be5d7e449c98f50fb424a78
Author: Arnd Bergmann <[email protected]>
Date:   Sun May 4 11:25:21 2014 +0800

    ASoC: pxa: remove mach header dependency
    
    As we are moving the mmp platform towards multiplatform support,
    we have to stop including platform header files.
    
    This changes the pxa-ssp sound driver file to no longer depend
    on mach/hardware.h and mach/dma.h. The code using the definitions
    from those headers is actually gone already, the only thing
    that was still being used was the pxa_dma_desc typedef, which
    we can easily work around by using the normal 'struct pxa_dma_desc'
    name.
    
    The pxa2xx-dma driver still uses this header, so we include it
    explicitly there, which is ok because that is only used on pxa,
    not on mmp.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Xia Kaixu <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 7d6d478f38fb1bdef30ae1a4c9d5aefb7cb2bb9b
Author: Andrew Lunn <[email protected]>
Date:   Sat May 3 20:30:11 2014 +0200

    ASoC: alc5623: Add device tree binding
    
    Let the ALC5623 codec be instantiated from DT. Add a simple binding
    for the additional control register and the jack detect register.
    
    Also, add a prompt to the Kconfig entry for this CODEC, so that it can
    be selected. Since kirkwood-t5325.c will no longer be used, we need to
    be able to enable the CODEC in the mvebu_v5_defconfig etc.
    
    Signed-off-by: Andrew Lunn <[email protected]>
    Acked-by: Jason Cooper <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit ee9daad4953418ecf28a6b0b920f982fe0c24814
Author: Sascha Hauer <[email protected]>
Date:   Mon Apr 28 12:54:52 2014 +0200

    ASoC: fsl-ssi: Move fsl_ssi_set_dai_sysclk above fsl_ssi_hw_params
    
    fsl_ssi_set_dai_sysclk will be called from fsl_ssi_hw_params in the
    next patch. Move up to avoid forward declaration and to keep the next patch
    more readable. No functional change.
    
    Signed-off-by: Sascha Hauer <[email protected]>
    Signed-off-by: Markus Pargmann <[email protected]>
    Tested-By: Michael Grzeschik <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 504894799fa122822f5c48be2968e04d3f1af8e8
Author: Markus Pargmann <[email protected]>
Date:   Mon Apr 28 12:54:51 2014 +0200

    ASoC: fsl-ssi: Transmit enable synchronization
    
    When the fsl-ssi unit is used in i2s slave mode, it is possible that the
    SSI unit starts transmitting data on the wrong channel. This happens
    because the SSI does not synchronize with the left-right-clock by
    default.
    
    This patch enables transmit enable synchronization.
    
    Signed-off-by: Markus Pargmann <[email protected]>
    Tested-By: Michael Grzeschik <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 171d683d2ac4ab6f220cc99de08ef9ec2c039966
Author: Markus Pargmann <[email protected]>
Date:   Mon Apr 28 12:54:48 2014 +0200

    ASoC: fsl-ssi: Remove unnecessary variables from ssi_private
    
    There are some variables defined in struct fsl_ssi_private that describe
    states that are also described by other variables.
    
    This patch adds some helper functions that return exactly the same
    information based on available variables. This helps to clean up struct
    fsl_ssi_private and remove them from the probe function.
    
    It also removes some not really used variables (new_binding, name).
    
    Signed-off-by: Markus Pargmann <[email protected]>
    Tested-By: Michael Grzeschik <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 4d9b7926f2ce271e0670cf0e7131a0e2a686690a
Author: Markus Pargmann <[email protected]>
Date:   Mon Apr 28 12:54:47 2014 +0200

    ASoC: fsl-ssi: Cleanup probe function
    
    Reorder the probe function to be able to move the second imx-specific
    block to the seperate imx probe function. The patch also removes some
    comments/variables/code that are not used anymore or could be simply
    replaced by other variables.
    
    Signed-off-by: Markus Pargmann <[email protected]>
    Tested-By: Michael Grzeschik <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit ed0f1604e93c686d8151c5a9bcbe36a2986caf40
Author: Markus Pargmann <[email protected]>
Date:   Mon Apr 28 12:54:46 2014 +0200

    ASoC: fsl-ssi: Remove useless DMA code
    
    Simplify dma DT property handling. fsl,ssi-dma-events is not used
    anymore. It passes invalid data to imx_pcm_dma_params_init_data() which
    copies some data into an imx dma struct. This struct is never used in
    imx-dma or imx-sdma because of generic OF DMA handling. The
    "fsl,ssi-dma-events" is not used anywhere in dts files.
    
    Signed-off-by: Markus Pargmann <[email protected]>
    Tested-By: Michael Grzeschik <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 49da09e26577702516e946ecd537f50b87533315
Author: Markus Pargmann <[email protected]>
Date:   Mon Apr 28 12:54:45 2014 +0200

    ASoC: fsl-ssi: Move imx-specific probe to seperate function
    
    Move imx specific probe code to a seperate function. It reduces the
    size of the probe() function and makes the code and error handling
    easier to understand.
    
    Signed-off-by: Markus Pargmann <[email protected]>
    Tested-By: Michael Grzeschik <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 2a1d102de40a799072309d4d84fa6f214c5ee999
Author: Markus Pargmann <[email protected]>
Date:   Mon Apr 28 12:54:44 2014 +0200

    ASoC: fsl-ssi: Use dev_name for DAI driver struct
    
    Instead of creating a name using string manipulation functions, we can
    simply use the device name for the DAI driver struct.
    
    Signed-off-by: Markus Pargmann <[email protected]>
    Tested-By: Michael Grzeschik <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit f138e6212427d0ea6283e07b706823b657ddf14f
Author: Markus Pargmann <[email protected]>
Date:   Mon Apr 28 12:54:43 2014 +0200

    ASoC: fsl-ssi: Move debugging to seperate file
    
    Move all code that is only used for debugging to a seperate file. This
    makes it easier to see what functions are used for debugging only.
    
    Signed-off-by: Markus Pargmann <[email protected]>
    Tested-By: Michael Grzeschik <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 65c961cc59345fa347173e5a1f5866bc866fd626
Author: Markus Pargmann <[email protected]>
Date:   Mon Apr 28 12:54:42 2014 +0200

    ASoC: fsl-ssi: Fix register values when disabling
    
    The bits we have to clear when disabling are different when the other
    stream is still active.
    
    This patch fixes the calculation of new register values after disabling
    one stream. It also adds a more detailed description of the new register
    value calculation.
    
    Signed-off-by: Markus Pargmann <[email protected]>
    Tested-By: Michael Grzeschik <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 55bc82536960e4749df7ae5666a93702190c53d4
Author: Lars-Peter Clausen <[email protected]>
Date:   Mon May 19 11:41:48 2014 +0200

    ASoC: mop500_ab8500: Replace instances of rtd->codec->card with rtd->card
    
    No need to go via the CODEC to get a pointer to the card. This will help to
    eventually remove the card field from the snd_soc_codec struct.
    
    Signed-off-by: Lars-Peter Clausen <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 0596f70069bb5ab34eea980c14fad1041f2abae5
Author: Lars-Peter Clausen <[email protected]>
Date:   Mon May 19 11:41:46 2014 +0200

    ASoC: omap: Replace instances of rtd->codec->card with rtd->card
    
    No need to go via the CODEC to get a pointer to the card. This will help to
    eventually remove the card field from the snd_soc_codec struct.
    
    Signed-off-by: Lars-Peter Clausen <[email protected]>
    Acked-by: Jarkko Nikula <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit cf7b71f46b1c2f0376c373e10e5eee1b1fa3cd12
Author: Lars-Peter Clausen <[email protected]>
Date:   Tue May 20 14:23:10 2014 +0200

    ASoC: ad1980: Replace goto loop with do-while loop
    
    Using a proper do-while loop here instead of a open-coded goto loop is both
    cleaner and shorter.
    
    Also fixes the following warnings from smatch:
    	sound/soc/codecs/ad1980.c:213 ad1980_reset() info: loop could be replaced with if statement.
    	sound/soc/codecs/ad1980.c:212 ad1980_reset() info: ignoring unreachable code.
    	sound/soc/codecs/ad1980.c:215 ad1980_reset() info: ignoring unreachable code.
    
    While we are at it also change retry_cnt to unsigned int, using u16 for a
    on-stack loop counter doesn't make that much sense.
    
    Signed-off-by: Lars-Peter Clausen <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit da41a589f52464e24ddefe76814ee35bfb07950c
Author: Robert Elliott <[email protected]>
Date:   Tue May 20 16:46:26 2014 -0500

    blk-mq: Micro-optimize blk_queue_nomerges() check
    
    In blk_mq_make_request(), do the blk_queue_nomerges() check
    outside the call to blk_attempt_plug_merge() to eliminate
    function call overhead when nomerges=2 (disabled)
    
    Signed-off-by: Robert Elliott <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit eba7176826ddab1d04c51bb2d5f2bbf22865444c
Author: Jens Axboe <[email protected]>
Date:   Tue May 20 15:17:27 2014 -0600

    blk-mq: initialize q->nr_requests after calling blk_queue_make_request()
    
    blk_queue_make_requests() overwrites our set value for q->nr_requests,
    turning it into the default of 128. Set this appropriately after
    initializing queue values in blk_queue_make_request().
    
    Signed-off-by: Jens Axboe <[email protected]>

commit bc76e320f21f8bd790a72bd5dc06909617432352
Author: Daniel Vetter <[email protected]>
Date:   Tue May 20 22:46:50 2014 +0200

    drm/i915: Drop now misleading DDI comment from dp_link_down
    
    Since
    
    commit 2e82a7203182d0883d0f9450d40ad6e1c6578ad9
    Author: Imre Deak <[email protected]>
    Date:   Fri Jan 17 15:46:43 2014 +0200
    
        drm/i915: don't disable DP port after a failed link training
    
    and
    
    commit 5d6a1116c6475404e6505b708320f9579ae19acd
    Author: Imre Deak <[email protected]>
    Date:   Thu Jan 16 18:35:57 2014 +0200
    
        drm/i915: don't disable the DP port if the link is lost
    
    we no longer call intel_dp_link_down from generic DP code, but only
    from the !HAS_DDI dp encoder functions. hsw/bdw have their own encoder
    disabling callback in intel_ddi.c.
    
    Hence the early return is no longer needed and the big comment just
    confusing, so let's rip it out. To ensure what we don't accidentally
    use this again on ddi encoders add a WARN_ON instead.
    
    Spotted while reading through intel_dp.c
    
    Cc: Imre Deak <[email protected]>
    Cc: Paulo Zanoni <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 96810471673393c931595a013f0f3094b564b1e9
Author: John W. Linville <[email protected]>
Date:   Tue May 20 15:34:37 2014 -0400

    ath9k: fixup "ath9k_htc: fix build with disabled debug"
    
    Apparently Oleksij's compile testing was no better than mine initially
    was... :-(
    
    Cc: Oleksij Rempel <[email protected]>
    Signed-off-by: John W. Linville <[email protected]>

commit 37c492c8f6a99870551fe2964b2dfce5d9e87375
Author: Harald Brinkmann <[email protected]>
Date:   Tue May 20 20:28:00 2014 +0200

    HID: quirk for Saitek RAT7 and MMO7 mices' mode button
    
    Some saitek mice implement a tristate button (for switching button mappings in
    the original driver) by keeping one of three (non-physical)
    buttons constantly pressed.
    
    This breaks X and probably other userspace software.
    
    This patch implements a quirk for the R.A.T.7 and M.M.O.7, tracking the mode
    and generating presses of a single button if it changes.  Also the missing
    release event is generated instantly.
    
    Signed-off-by: Harald Brinkmann <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>

commit 525997e00bd32c3e25d5f77c26703f76c498f424
Author: Jani Nikula <[email protected]>
Date:   Tue Apr 29 23:30:48 2014 +0300

    drm/i915: shuffle panel code
    
    Somehow a few functions have been dropped in the middle of backlight
    code. Move them around. No functional changes.
    
    Signed-off-by: Jani Nikula <[email protected]>
    Reviewed-by: Jesse Barnes <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 9aa7250feb202f246afd90d9525debabe10cc0a5
Author: Ville Syrjälä <[email protected]>
Date:   Mon May 19 19:23:26 2014 +0300

    drm/i915: Clear GDSR after reset on ILK
    
    Clear the reset domain after a succesful GPU reset on ilk. We already
    do that on gen4, so let's try to be a bit more consistent. And if
    ether render or media reset fails, we might use the leftover value
    in the register to pinpoint the culprit.
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Jesse Barnes <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit f73387cb6b1f1534e56669e6aecefae1be867f59
Author: Dylan Reid <[email protected]>
Date:   Tue May 20 11:26:12 2014 -0700

    ALSA: hda/tegra - Fix MODULE_DEVICE_TABLE typo.
    
    I missed a rename during the review process.  Fix the
    MODULE_DEVICE_TABLE to match the structure.
    
    Signed-off-by: Dylan Reid <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>

commit 0f08ffd6633fe8b8306229593027009e90f86c8c
Author: Ville Syrjälä <[email protected]>
Date:   Mon May 19 19:23:25 2014 +0300

    drm/i915: Kill RMW from ILK reset code
    
    All the other bits in the GDSR register are read-only, so we don't have
    to preserve them when we perform a GPU reset.
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Jesse Barnes <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit fc3b7a70ac7c2baee512a1ea8df9e7c4085ac3e5
Author: Joe Thornber <[email protected]>
Date:   Tue May 13 16:14:14 2014 -0400

    dm thin: cleanup noflush_work to use a proper completion
    
    Factor out a pool_work interface that noflush_work makes use of to wait
    for and complete work items (in terms of a proper completion struct).
    Allows discontinuing the use of a custom completion in terms of atomic_t
    and wait_event.
    
    Signed-off-by: Joe Thornber <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 8490cd8ed20f9ff7b54a3fc858a1ff4b98a5593f
Author: Mikulas Patocka <[email protected]>
Date:   Fri Mar 14 18:43:07 2014 -0400

    dm snapshot: do not split read bios sent to snapshot-origin target
    
    Change the snapshot-origin target so that only write bios are split on
    chunk boundary.  Read bios are passed unchanged to the underlying
    device, so they don't have to be split.
    
    Later, we could change the target so that it accepts a larger write bio
    if it spans an area that is completely covered by snapshot exceptions.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit c0d4c8e9d1bb7fdc847e0753cceaf557d19d6223
Author: Mikulas Patocka <[email protected]>
Date:   Fri Mar 14 18:42:12 2014 -0400

    dm snapshot: allocate a per-target structure for snapshot-origin target
    
    Allocate a per-target dm_origin structure.  This is a prerequisite for
    the next commit ("dm snapshot: do not split read bios sent to
    snapshot-origin target") which adds a new member to this structure.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 12f66f49e359a35942b2a3170227132d75d47c32
Author: Mikulas Patocka <[email protected]>
Date:   Fri Mar 14 18:41:24 2014 -0400

    dm: introduce dm_accept_partial_bio
    
    The function dm_accept_partial_bio allows the target to specify how many
    sectors of the current bio it will process.  If the target only wants to
    accept part of the bio, it calls dm_accept_partial_bio and the DM core
    sends the rest of the data in next bio.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit e628835d01fa8e3cc6764948fad1229ba79f08c3
Author: Mikulas Patocka <[email protected]>
Date:   Fri Mar 14 18:40:39 2014 -0400

    dm: change sector_count member in clone_info from sector_t to unsigned
    
    It is impossible to create bios with 2^23 or more sectors (the size is
    stored as a 32-bit byte count in the bio). So we convert some sector_t
    values to unsigned integers.
    
    This is needed for the next commit ("dm: introduce
    dm_accept_partial_bio") that replaces integer value arguments with
    pointers, so the size of the integer must match.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 80c578930ce77ba8bcfb226a184b482020bdda7b
Author: Mike Snitzer <[email protected]>
Date:   Tue May 20 13:38:33 2014 -0400

    dm thin: add 'no_space_timeout' dm-thin-pool module param
    
    Commit 85ad643b ("dm thin: add timeout to stop out-of-data-space mode
    holding IO forever") introduced a fixed 60 second timeout.  Users may
    want to either disable or modify this timeout.
    
    Allow the out-of-data-space timeout to be configured using the
    'no_space_timeout' dm-thin-pool module param.  Setting it to 0 will
    disable the timeout, resulting in IO being queued until more data space
    is added to the thin-pool.
    
    Signed-off-by: Mike Snitzer <[email protected]>
    Cc: [email protected] # 3.14+

commit 5f80ff8eccba50832dcc640ac89add4c7fced963
Author: Sagi Grimberg <[email protected]>
Date:   Tue May 20 13:28:11 2014 +0300

    Target/iser: Gracefully reject T10-PI enabled connect request if not supported
    
    In case user chose to set T10-PI enable on the target while
    the IB device does not support it, gracefully reject the request.
    
    Reported-by: Slava Shwartsman <[email protected]>
    Signed-off-by: Sagi Grimberg <[email protected]>
    Cc: [email protected] # 3.15+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit f5ebec9629cf78eeeea4b8258882a9f439ab2404
Author: Sagi Grimberg <[email protected]>
Date:   Mon May 19 17:44:25 2014 +0300

    Target/iser: Wait for proper cleanup before unloading
    
    disconnected_handler works are scheduled on system_wq.
    When attempting to unload, first make sure all works
    have cleaned up.
    
    Signed-off-by: Sagi Grimberg <[email protected]>
    Cc: [email protected] # 3.10+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 88c4015fda6d014392f76d3b1688347950d7a12d
Author: Sagi Grimberg <[email protected]>
Date:   Mon May 19 17:44:24 2014 +0300

    Target/iser: Improve cm events handling
    
    There are 4 RDMA_CM events that all basically mean that
    the user should teardown the IB connection:
    - DISCONNECTED
    - ADDR_CHANGE
    - DEVICE_REMOVAL
    - TIMEWAIT_EXIT
    
    Only in DISCONNECTED/ADDR_CHANGE it makes sense to
    call rdma_disconnect (send DREQ/DREP to our initiator).
    So we keep the same teardown handler for all of them
    but only indicate calling rdma_disconnect for the relevant
    events.
    
    This patch also removes redundant debug prints for each single
    event.
    
    v2 changes:
     - Call isert_disconnected_handler() for DEVICE_REMOVAL (Or + Sag)
    
    Signed-off-by: Sagi Grimberg <[email protected]>
    Cc: [email protected] # 3.10+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 9b204fbf0987748ec6cc4a3cde0064ecf42accd0
Author: Asai Thambi S P <[email protected]>
Date:   Tue May 20 10:48:56 2014 -0700

    mtip32xx: move error handling to service thread
    
    Move error handling to service thread, and use mtip_set_timeout()
    to set timeouts for HDIO_DRIVE_TASK and HDIO_DRIVE_CMD IOCTL commands.
    
    Signed-off-by: Selvan Mani <[email protected]>
    Signed-off-by: Asai Thambi S P <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit e3a2b3f931f59d5284abd13faf8bded726884ffd
Author: Jens Axboe <[email protected]>
Date:   Tue May 20 11:49:02 2014 -0600

    blk-mq: allow changing of queue depth through sysfs
    
    For request_fn based devices, the block layer exports a 'nr_requests'
    file through sysfs to allow adjusting of queue depth on the fly.
    Currently this returns -EINVAL for blk-mq, since it's not wired up.
    Wire this up for blk-mq, so that it now also always dynamic
    adjustments of the allowed queue depth for any given block device
    managed by blk-mq.
    
    Signed-off-by: Jens Axboe <[email protected]>

commit 463eb599929709d6b53bf6f3bea1189292cd8456
Author: Richard Fitzgerald <[email protected]>
Date:   Tue May 20 13:48:51 2014 +0100

    mfd: arizona: Correct addresses of always-on trigger registers
    
    Update the addresses and names to match current silicon.
    The WM8997 regmap tables have been adjusted to match the new
    names.
    Missing registers have been added to WM5110 default value table.
    
    Signed-off-by: Richard Fitzgerald <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 145894202252809015c3b7d764dc571cfd457f24
Author: Jay Aurabind <[email protected]>
Date:   Sat May 10 17:32:11 2014 +0530

    mfd: abx500-core: Fix compiler warning larger stack frame
    
    On systems with CONFIG_FRAME_WARN=1024, compiler warns the allocation of
    an object of struct device on stack. Make the allocation dynamically to
    fix the warning.
    
    drivers/mfd/abx500-core.c: In function ‘abx500_dump_all_banks’:
    drivers/mfd/abx500-core.c:167:1: warning: the frame size of 1032 bytes
    is larger than 1024 bytes [-Wframe-larger-than=]
    
    Signed-off-by: Aurabindo J <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 43d6a0e7cc04e9d22636fe7ef8896ca906218b24
Author: Boris BREZILLON <[email protected]>
Date:   Thu May 15 19:51:43 2014 +0200

    mfd: axp22x: Add support for APX221 PMIC
    
    This patch introduces preliminary support for the X-Powers AXP221 PMIC.
    The AXP221 is typically used on boards using Allwinner's A31 SoC.
    
    At the moment, this driver only exposes regulator devices, but other
    subdevices.
    
    Signed-off-by: Boris BREZILLON <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit e9ff951e5b4f16f078394555c42c62e73a6eeb5f
Author: Lee Jones <[email protected]>
Date:   Tue May 20 15:37:41 2014 +0100

    mfd: max14577: Cast to architecture agnostic data type
    
    drivers/mfd/max14577.c:334:25:
      warning: cast from pointer to integer of different size
        max14577->dev_type = (unsigned int)of_id->data;
                             ^
    Signed-off-by: Lee Jones <[email protected]>

commit 4e31f780bdebcd23700703fbedf1d3bffd05043f
Author: Lee Jones <[email protected]>
Date:   Tue May 20 15:35:27 2014 +0100

    mfd: axp20x: Remove unnecessary const qualifier from axp20x_supplies[]
    
    drivers/mfd/axp20x.c:159:3:
      warning: initialization discards ‘const’ qualifier from pointer target type
       .parent_supplies = axp20x_supplies,
       ^
    Signed-off-by: Lee Jones <[email protected]>

commit e917e890cf40510d35253034de850410b56a6e20
Author: Doug Anderson <[email protected]>
Date:   Wed Apr 30 10:44:06 2014 -0700

    mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
    
    The cros_ec_spi transfer had two problems with its timeout code:
    
    1. It looked at the timeout even in the case that it found valid data.
    2. If the cros_ec_spi code got switched out for a while, it's possible
       it could get a timeout after a single loop.  Let's be paranoid and
       make sure we do one last transfer after the timeout expires.
    
    Signed-off-by: Doug Anderson <[email protected]>
    Reviewed-by: Simon Glass <[email protected]>
    Tested-by: Andrew Bresticker <[email protected]>
    Tested-by: Stephen Warren <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 626bffd4dd65dccdf0978eff6a3341c1d7b04b9a
Author: Doug Anderson <[email protected]>
Date:   Wed Apr 30 10:44:07 2014 -0700

    mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms
    
    We're adding i2c tunneling to the list of things that goes over
    cros_ec.  i2c tunneling can be slooooooow, so increase our deadline to
    100ms to account for that.
    
    Signed-off-by: Doug Anderson <[email protected]>
    Reviewed-by: Simon Glass <[email protected]>
    Tested-by: Andrew Bresticker <[email protected]>
    Tested-by: Stephen Warren <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit e917e3366c7be56a08d84417b36a143b2e8af716
Author: Doug Anderson <[email protected]>
Date:   Wed Apr 30 10:44:05 2014 -0700

    mfd: cros_ec: spi: Add mutex to cros_ec_spi
    
    The main transfer function for cros_ec_spi can be called by more than
    one client at a time.  Make sure that those clients don't stomp on
    each other by locking the bus for the duration of the transfer
    function.
    
    Signed-off-by: Doug Anderson <[email protected]>
    Reviewed-by: Simon Glass <[email protected]>
    Tested-by: Andrew Bresticker <[email protected]>
    Tested-by: Stephen Warren <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 6bcd21ee2826c978defc9169227e3e850537a519
Author: David Hendricks <[email protected]>
Date:   Wed Apr 30 10:44:04 2014 -0700

    mfd: cros_ec: spi: Calculate delay between transfers correctly
    
    To avoid spamming the EC we calculate the time between the previous
    transfer and the current transfer and force a delay if the time delta
    is too small.
    
    However, a small miscalculation causes the delay period to be
    far too short. Most noticably this impacts commands with a long
    turnaround time such as EC firmware reads and writes.
    
    Signed-off-by: David Hendricks <[email protected]>
    Signed-off-by: Doug Anderson <[email protected]>
    Reviewed-by: Simon Glass <[email protected]>
    Tested-by: Andrew Bresticker <[email protected]>
    Tested-by: Stephen Warren <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit f00fc2588b66d3441ed65aaa7f7f2353df00939a
Author: Bill Richardson <[email protected]>
Date:   Wed Apr 30 10:44:08 2014 -0700

    mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources
    
    This just updates include/linux/mfd/cros_ec_commands.h to match the
    latest EC version (which is the One True Source for such things).  See
    <https://chromium.googlesource.com/chromiumos/platform/ec>
    
    [dianders: took today's ToT version from the Chromium OS EC; deleted
    references to cros_ec_dev and cros_ec_lpc since those aren't upstream
    yet]
    
    Signed-off-by: Bill Richardson <[email protected]>
    Signed-off-by: Doug Anderson <[email protected]>
    Reviewed-by: Simon Glass <[email protected]>
    Tested-by: Andrew Bresticker <[email protected]>
    Tested-by: Stephen Warren <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit d46144d7bc9f9e1121fe83edf7a9cc9f19b41d9d
Author: Doug Anderson <[email protected]>
Date:   Wed Apr 30 10:44:09 2014 -0700

    i2c: ChromeOS EC tunnel driver
    
    On ARM Chromebooks we have a few devices that are accessed by both the
    AP (the main "Application Processor") and the EC (the Embedded
    Controller).  These are:
    * The battery (sbs-battery).
    * The power management unit tps65090.
    
    On the original Samsung ARM Chromebook these devices were on an I2C
    bus that was shared between the AP and the EC and arbitrated using
    some extranal GPIOs (see i2c-arb-gpio-challenge).
    
    The original arbitration scheme worked well enough but had some
    downsides:
    * It was nonstandard (not using standard I2C multimaster)
    * It only worked if the EC-AP communication was I2C
    * It was relatively hard to debug problems (hard to tell if i2c issues
      were caused by the EC, the AP, or some device on the bus).
    
    On the HP Chromebook 11 the design was changed to:
    * The AP/EC comms were still i2c, but the battery/tps65090 were no
      longer on the bus used for AP/EC communication.  The battery was
      exposed to the AP through a limited i2c tunnel and tps65090 was
      exposed to the AP through a custom Linux driver.
    
    On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
    * The AP/EC comms are now using SPI for faster speeds.
    * The EC's i2c bus is exposed to the AP through a full i2c tunnel.
    
    The upstream "tegra124-venice2" uses the same scheme as the Samsung
    ARM Chromebook 2, though it has a different set of components on the
    other side of the bus.
    
    This driver supports the scheme used by the Samsung ARM Chromebook 2.
    Future patches to this driver could add support for the battery tunnel
    on the HP Chromebook 11 (and perhaps could even be used to access
    tps65090 on the HP Chromebook 11 instead of using a special driver,
    but I haven't researched that enough).
    
    Signed-off-by: Vincent Palatin <[email protected]>
    Signed-off-by: Simon Glass <[email protected]>
    Signed-off-by: Doug Anderson <[email protected]>
    Reviewed-by: Wolfram Sang <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 4bdc72930743b35f23b6c80426a2c9f6dda5e9b6
Author: Imre Deak <[email protected]>
Date:   Tue May 20 19:47:20 2014 +0300

    drm/i915: add missing unregister_oom_notifier to the error/unload path
    
    I'm trying to reduce the WARNs during driver reload and this was one of
    them. Also while at it remove the redundant condition from before
    unregister_shrinker().
    
    v2:
    - fix the error path too and move the unregister to its logical place
    (Chris)
    - remove redundant condition from before unregister_shrinker()
    
    Signed-off-by: Imre Deak <[email protected]>
    Reviewed-by: Chris Wilson <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 5cfb17828d877a5541171087b9d746befdf2a126
Author: Bart Van Assche <[email protected]>
Date:   Tue May 20 15:08:34 2014 +0200

    IB/srp: Add fast registration support
    
    Certain HCA types (e.g. Connect-IB) and certain configurations (e.g.
    ConnectX VF) support fast registration but not FMR. Hence add fast
    registration support.
    
    In function srp_rport_reconnect(), move the the srp_finish_req()
    loop from after to before the srp_create_target_ib() call. This is
    needed to avoid that srp_finish_req() tries to queue any
    invalidation requests for rkeys associated with the old queue pair
    on the newly allocated queue pair. Invoking srp_finish_req() before
    the queue pair has been reallocated is safe since srp_claim_req()
    handles completions correctly that arrive after srp_finish_req()
    has been invoked.
    
    Signed-off-by: Bart Van Assche <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 52ede08f00ebfc21d50a1f3e5908a78655900519
Author: Bart Van Assche <[email protected]>
Date:   Tue May 20 15:07:45 2014 +0200

    IB/srp: Rename FMR-related variables
    
    The next patch will cause the renamed variables to be shared between
    the code for FMR and for FR memory registration. Make the names of
    these variables independent of the memory registration mode. This
    patch does not change any functionality. The start of this patch was
    the changes applied via the following shell command:
    
    sed -i.orig 's/SRP_FMR_SIZE/SRP_MAX_PAGES_PER_MR/g; \
        s/fmr_page_mask/mr_page_mask/g;s/fmr_page_size/mr_page_size/g; \
        s/fmr_page_shift/mr_page_shift/g;s/fmr_max_size/mr_max_size/g; \
        s/max_pages_per_fmr/max_pages_per_mr/g;s/nfmr/nmdesc/g; \
        s/fmr_len/dma_len/g' drivers/infiniband/ulp/srp/ib_srp.[ch]
    
    Signed-off-by: Bart Van Assche <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit d1b4289e16477fe13e95b88ffb7067c87b10ab6e
Author: Bart Van Assche <[email protected]>
Date:   Tue May 20 15:07:20 2014 +0200

    IB/srp: One FMR pool per SRP connection
    
    Allocate one FMR pool per SRP connection instead of one SRP pool
    per HCA. This improves scalability of the SRP initiator.
    
    Only request the SCSI mid-layer to retry a SCSI command after a
    temporary mapping failure (-ENOMEM) but not after a permanent
    mapping failure. This avoids that SCSI commands are retried
    indefinitely if a permanent memory mapping failure occurs.
    
    Tell the SCSI mid-layer to reduce queue depth temporarily in the
    unlikely case where an application is queuing many requests with
    more than max_pages_per_fmr sg-list elements.
    
    For FMR pool allocation, base the max_pages_per_fmr parameter on
    the HCA memory registration limit. Only try to allocate an FMR
    pool if FMR is supported.
    
    Signed-off-by: Bart Van Assche <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit b1b8854d1622b99b64cd98ed307ffd168c6d3ebd
Author: Bart Van Assche <[email protected]>
Date:   Tue May 20 15:06:41 2014 +0200

    IB/srp: Introduce the 'register_always' kernel module parameter
    
    Add a kernel module parameter that enables memory registration also for SG-lists
    that can be processed without memory registration. This makes it easier for kernel
    developers to test the memory registration code.
    
    Signed-off-by: Bart Van Assche <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 539dde6fc5c30cfa76439de03ed3ba444d2579b3
Author: Bart Van Assche <[email protected]>
Date:   Tue May 20 15:05:46 2014 +0200

    IB/srp: Introduce srp_finish_mapping()
    
    This patch does not change any functionality.
    
    Signed-off-by: Bart Van Assche <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 76bc1e1ddd1ea8d4bc230fc0aa45c1d14c232531
Author: Bart Van Assche <[email protected]>
Date:   Tue May 20 15:05:21 2014 +0200

    IB/srp: Introduce srp_map_fmr()
    
    This patch does not change any functionality.
    
    Signed-off-by: Bart Van Assche <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 62154b2e892807b8373a107c277f1fa8338f4333
Author: Bart Van Assche <[email protected]>
Date:   Tue May 20 15:04:45 2014 +0200

    IB/srp: Introduce an additional local variable
    
    This patch does not change any functionality.
    
    Signed-off-by: Bart Van Assche <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit af24663bc8204695181cf3b92b7129efadd8d455
Author: Bart Van Assche <[email protected]>
Date:   Tue May 20 15:04:21 2014 +0200

    IB/srp: Fix kernel-doc warnings
    
    Avoid that the kernel-doc tool warns about missing argument
    descriptions for the ib_srp.[ch] source files.
    
    Signed-off-by: Bart Van Assche <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 024ca90151f5e4296d30f72c13ff9a075e23c9ec
Author: Bart Van Assche <[email protected]>
Date:   Tue May 20 15:03:49 2014 +0200

    IB/srp: Fix a sporadic crash triggered by cable pulling
    
    Avoid that the loops that iterate over the request ring can encounter
    a pointer to a SCSI command in req->scmnd that is no longer associated
    with that request. If the function srp_unmap_data() is invoked twice
    for a SCSI command that is not in flight then that would cause
    ib_fmr_pool_unmap() to be invoked with an invalid pointer as argument,
    resulting in a kernel oops.
    
    Reported-by: Sagi Grimberg <[email protected]>
    Reference: http://thread.gmane.org/gmane.linux.drivers.rdma/19068/focus=19069
    Signed-off-by: Bart Van Assche <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Cc: stable <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 1cc6114402f864c3d090738df355d26c1fd374bb
Author: Johan Hedberg <[email protected]>
Date:   Tue May 20 09:45:52 2014 +0300

    Bluetooth: Update smp_confirm to return a response code
    
    Now that smp_confirm() is called "inline" we can have it return a
    response code and have the sending of it be done in the shared place for
    command handlers. One exception is when we're entering smp.c from mgmt.c
    when user space responds to authentication, in which case we still need
    our own code to call smp_failure().
    
    Signed-off-by: Johan Hedberg <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit 861580a970f1abe64193636eab9e5a1a7556a555
Author: Johan Hedberg <[email protected]>
Date:   Tue May 20 09:45:51 2014 +0300

    Bluetooth: Update smp_random to return a response code
    
    Since we're now calling smp_random() "inline" we can have it directly
    return a response code and have the shared command handler send the
    response.
    
    Signed-off-by: Johan Hedberg <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit 4a74d65868f10dafe38765d4fe5bbf1e75f0623d
Author: Johan Hedberg <[email protected]>
Date:   Tue May 20 09:45:50 2014 +0300

    Bluetooth: Rename smp->smp_flags to smp->flags
    
    There's no reason to have "smp" in this variable name since it is
    already part of the SMP struct which provides sufficient context.
    
    Signed-off-by: Johan Hedberg <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit 9dd4dd275f2e6dcef1f798118babcb5947f64497
Author: Johan Hedberg <[email protected]>
Date:   Tue May 20 09:45:49 2014 +0300

    Bluetooth: Remove unnecessary work structs from SMP code
    
    When the SMP code was initially created (mid-2011) parts of the
    Bluetooth subsystem were still not converted to use workqueues. This
    meant that the crypto calls, which could sleep, couldn't be called
    directly. Because of this the "confirm" and "random" work structs were
    introduced.
    
    These days the entire Bluetooth subsystem runs through workqueues which
    makes these structs unnecessary. This patch removes them and converts
    the calls to queue them to use direct function calls instead.
    
    Signed-off-by: Johan Hedberg <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit 1ef35827a999582669b38b71d3167907b4c2afd0
Author: Johan Hedberg <[email protected]>
Date:   Tue May 20 09:45:48 2014 +0300

    Bluetooth: Fix setting initial local auth_req value
    
    There is no reason to have the initial local value conditional to
    whether the remote value has bonding set or not. We can either way start
    off with the value we received.
    
    Signed-off-by: Johan Hedberg <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit 4bc58f51e156227d139668199ffe5df2ccb2f3c2
Author: Johan Hedberg <[email protected]>
Date:   Tue May 20 09:45:47 2014 +0300

    Bluetooth: Make SMP context private to smp.c
    
    There are no users of the smp_chan struct outside of smp.c so move it
    away from smp.h. The addition of the l2cap.h include to hci_core.c,
    hci_conn.c and mgmt.c is something that should have been there already
    previously to avoid warnings of undeclared struct l2cap_conn, but the
    compiler warning was apparently shadowed away by the mention of
    l2cap_conn in the struct smp_chan definition.
    
    Signed-off-by: Johan Hedberg <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit e1618d461ca18d40f9c3ef70598abb72e75d27ae
Author: Vlad Yasevich <[email protected]>
Date:   Tue May 20 10:59:26 2014 -0400

    vlan: Fix build error wth vlan_get_encap_level()
    
    The new function vlan_get_encap_level() uses vlan_dev_priv()
    which is only conditionally avaialble when VLAN support is
    enabled.  Make vlan_get_encap_level() conditionally available
    as well.
    
    Fixes: 44a4085538c8 ("bonding: Fix stacked device detection in arp monitoring")
    Reported-by: Stephen Rothwell <[email protected]>
    CC: Stephen Rothwell <[email protected]>
    Signed-off-by: Vlad Yasevich <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 51697d393922eb643e78ac5db86e8fa5a45b469a
Author: Lai Jiangshan <[email protected]>
Date:   Tue May 20 17:46:36 2014 +0800

    workqueue: use generic attach/detach routine for rescuers
    
    There are several problems with the code that rescuers use to bind
    themselve to the target pool's cpumask.
    
      1) It is very different from how the normal workers bind to cpumask,
         increasing code complexity and maintenance overhead.
    
      2) The code of cpu-binding for rescuers is complicated.
    
      3) If one or more cpu hotplugs happen while a rescuer is processing
         its scheduled work items, the rescuer may not stay bound to the
         cpumask of the pool. This is an allowed behavior, but is still
         hairy. It will be better if the cpumask of the rescuer is always
         kept synchronized with the pool across cpu hotplugs.
    
    Using generic attach/detach routine will solve the above problems and
    results in much simpler code.
    
    tj: Minor description updates.
    
    Signed-off-by: Lai Jiangshan <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 4736cbf7a4b2a6bbb50a809a6933fb7eb29dc38f
Author: Lai Jiangshan <[email protected]>
Date:   Tue May 20 17:46:35 2014 +0800

    workqueue: separate pool-attaching code out from create_worker()
    
    Currently, the code to attach a new worker to its pool is embedded in
    create_worker().  Separating this code out will make the codes clearer
    and will allow rescuers to share the code path later.
    
    tj: Description and comment updates.
    
    Signed-off-by: Lai Jiangshan <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 92f9c5c40cc67ffcc5ac7f55fdbd6ae8afc7e0b4
Author: Lai Jiangshan <[email protected]>
Date:   Tue May 20 17:46:34 2014 +0800

    workqueue: rename manager_mutex to attach_mutex
    
    manager_mutex is only used to protect the attaching for the pool
    and the pool->workers list. It protects the pool->workers and operations
    based on this list, such as:
    
    	cpu-binding for the workers in the pool->workers
    	the operations to set/clear WORKER_UNBOUND
    
    So let's rename manager_mutex to attach_mutex to better reflect its
    role. This patch is a pure rename.
    
    tj: Minor command and description updates.
    
    Signed-off-by: Lai Jiangshan <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 4d757c5c81edba2052aae10d5b36dfcb9902b141
Author: Lai Jiangshan <[email protected]>
Date:   Tue May 20 17:46:33 2014 +0800

    workqueue: narrow the protection range of manager_mutex
    
    In create_worker(), as pool->worker_ida now uses
    ida_simple_get()/ida_simple_put() and doesn't require external
    synchronization, it doesn't need manager_mutex.
    
    struct worker allocation and kthread allocation are not visible by any
    one before attached, so they don't need manager_mutex either.
    
    The above operations are before the attaching operation which attaches
    the worker to the pool. Between attaching and starting the worker, the
    worker is already attached to the pool, so the cpu hotplug will handle
    cpu-binding for the worker correctly and we don't need the
    manager_mutex after attaching.
    
    The conclusion is that only the attaching operation needs manager_mutex,
    so we narrow the protection section of manager_mutex in create_worker().
    
    Some comments about manager_mutex are removed, because we will rename
    it to attach_mutex and add worker_attach_to_pool() later which will be
    self-explanatory.
    
    tj: Minor description updates.
    
    Signed-off-by: Lai Jiangshan <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 7cda9aae0596d871a8d7a6888d7b447c60e5ab30
Author: Lai Jiangshan <[email protected]>
Date:   Tue May 20 17:46:32 2014 +0800

    workqueue: convert worker_idr to worker_ida
    
    We no longer iterate workers via worker_idr and worker_idr is used
    only for allocating/freeing ID, so we can convert it to worker_ida.
    
    By using ida_simple_get/remove(), worker_ida doesn't require external
    synchronization, so we don't need manager_mutex to protect it and the
    ID-removal code is allowed to be moved out from
    worker_detach_from_pool().
    
    In a later patch, worker_detach_from_pool() will be used in rescuers
    which don't have IDs, so we move the ID-removal code out from
    worker_detach_from_pool() into worker_thread().
    
    tj: Minor description updates.
    
    Signed-off-by: Lai Jiangshan <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit da028469ba173e9c634b6ecf80bb0c69c7d1024d
Author: Lai Jiangshan <[email protected]>
Date:   Tue May 20 17:46:31 2014 +0800

    workqueue: separate iteration role from worker_idr
    
    worker_idr has the iteration (iterating for attached workers) and
    worker ID duties. These two duties don't have to be tied together. We
    can separate them and use a list for tracking attached workers and
    iteration.
    
    Before this separation, it wasn't possible to add rescuer workers to
    worker_idr due to rescuer workers couldn't allocate ID dynamically
    because ID-allocation depends on memory-allocation, which rescuer
    can't depend on.
    
    After separation, we can easily add the rescuer workers to the list for
    iteration without any memory-allocation. It is required when we attach
    the rescuer worker to the pool in later patch.
    
    tj: Minor description updates.
    
    Signed-off-by: Lai Jiangshan <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 3347fc9f36e7e5d3ebe504fc4034745b5d8971d3
Author: Lai Jiangshan <[email protected]>
Date:   Tue May 20 17:46:30 2014 +0800

    workqueue: destroy worker directly in the idle timeout handler
    
    Since destroy_worker() doesn't need to sleep nor require manager_mutex,
    destroy_worker() can be directly called in the idle timeout
    handler, it helps us remove POOL_MANAGE_WORKERS and
    maybe_destroy_worker() and simplify the manage_workers()
    
    After POOL_MANAGE_WORKERS is removed, worker_thread() doesn't
    need to test whether it needs to manage after processed works.
    So we can remove the test branch.
    
    Signed-off-by: Lai Jiangshan <[email protected]>

commit 60f5a4bcf852b5dec698b08cd34efc302ea72f2b
Author: Lai Jiangshan <[email protected]>
Date:   Tue May 20 17:46:29 2014 +0800

    workqueue: async worker destruction
    
    worker destruction includes these parts of code:
    	adjust pool's stats
    	remove the worker from idle list
    	detach the worker from the pool
    	kthread_stop() to wait for the worker's task exit
    	free the worker struct
    
    We can find out that there is no essential work to do after
    kthread_stop(), which means destroy_worker() doesn't need to wait for
    the worker's task exit, so we can remove kthread_stop() and free the
    worker struct in the worker exiting path.
    
    However, put_unbound_pool() still needs to sync the all the workers'
    destruction before destroying the pool; otherwise, the workers may
    access to the invalid pool when they are exiting.
    
    So we also move the code of "detach the worker" to the exiting
    path and let put_unbound_pool() to sync with this code via
    detach_completion.
    
    The code of "detach the worker" is wrapped in a new function
    "worker_detach_from_pool()" although worker_detach_from_pool() is only
    called once (in worker_thread()) after this patch, but we need to wrap
    it for these reasons:
    
      1) The code of "detach the worker" is not short enough to unfold them
         in worker_thread().
      2) the name of "worker_detach_from_pool()" is self-comment, and we add
         some comments above the function.
      3) it will be shared by rescuer in later patch which allows rescuer
         and normal thread use the same attach/detach frameworks.
    
    The worker id is freed when detaching which happens before the worker
    is fully dead, but this id of the dying worker may be re-used for a
    new worker, so the dying worker's task name is changed to
    "worker/dying" to avoid two or several workers having the same name.
    
    Since "detach the worker" is moved out from destroy_worker(),
    destroy_worker() doesn't require manager_mutex, so the
    "lockdep_assert_held(&pool->manager_mutex)" in destroy_worker() is
    removed, and destroy_worker() is not protected by manager_mutex in
    put_unbound_pool().
    
    tj: Minor description updates.
    
    Signed-off-by: Lai Jiangshan <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 73eb7fe73ae303996187fff38b1c162f1df0e9d1
Author: Lai Jiangshan <[email protected]>
Date:   Tue May 20 17:46:28 2014 +0800

    workqueue: destroy_worker() should destroy idle workers only
    
    We used to have the CPU online failure path where a worker is created
    and then destroyed without being started. A worker was created for
    the CPU coming online and if the online operation failed the created worker
    was shut down without being started.  But this behavior was changed.
    The first worker is created and started at the same time for the CPU coming
    online.
    
    It means that we had already ensured in the code that destroy_worker()
    destroys only idle workers and we don't want to allow it to destroy
    any non-idle worker in the future. Otherwise, it may be buggy and it
    may be extremely hard to check. We should force destroy_worker() to
    destroy only idle workers explicitly.
    
    Since destroy_worker() destroys only idle workers, this patch does not
    change any functionality. We just need to update the comments and the
    sanity check code.
    
    In the sanity check code, we will refuse to destroy the worker
    if !(worker->flags & WORKER_IDLE).
    
    If the worker entered idle which means it is already started,
    so we remove the check of "worker->flags & WORKER_STARTED",
    after this removal, WORKER_STARTED is totally unneeded,
    so we remove WORKER_STARTED too.
    
    In the comments for create_worker(), "Create a new worker which is bound..."
    is changed to "... which is attached..." due to we change the name of this
    behavior to attaching.
    
    tj: Minor description / comment updates.
    
    Signed-off-by: Lai Jiangshan <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 9625ab1727743f6a164df26b7b1eeeced7380b42
Author: Lai Jiangshan <[email protected]>
Date:   Tue May 20 17:46:27 2014 +0800

    workqueue: use manager lock only to protect worker_idr
    
    worker_idr is highly bound to managers and is always/only accessed in manager
    lock context. So we don't need pool->lock for it.
    
    Signed-off-by: Lai Jiangshan <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit e6c34ff13113c2fe24b7b9e8f1a6db1a626ec26c
Author: Charles Keepax <[email protected]>
Date:   Mon May 19 17:35:29 2014 +0100

    mfd: arizona: Correct error message for addition of main IRQ chip
    
    Signed-off-by: Charles Keepax <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit f59957974e215ad40f087768004700da2395ee6b
Author: Charles Keepax <[email protected]>
Date:   Mon May 19 17:35:28 2014 +0100

    mfd: wm8997: Add registers for high power mode
    
    Some output configurations can require a 50Mhz SYSCLK which requires
    DCVDD to be 1.8V. This patch adds the registers necessary for
    supporting this operational mode.
    
    Signed-off-by: Charles Keepax <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 9d1234aab7949b8437372214d0042e82dea96fa7
Author: Charles Keepax <[email protected]>
Date:   Mon May 19 17:35:27 2014 +0100

    mfd: arizona: Add MICVDD to mapped regulators
    
    Currently, MICVDD only binds because it is both the regulator name and
    the consumer name and we will always match against the regulator name
    regardless of the consumer device. If the regulator was renamed using
    the init_data ASoC will no longer be able to locate the supply, as it
    will be looking on the CODEC device where as the MICVDD consumer is on
    the Arizona device. Add a mapping as we do for the other regulators.
    
    Signed-off-by: Charles Keepax <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit f7d10d7811af6a32070b8e053cf7a11654e7c339
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue May 13 12:58:40 2014 +0200

    mfd: ipaq-micro: Make mfd_cell array const
    
    mfd_add_devices() expects array of struct mfd_cell to be const.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Linus Walleij <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 84615cca3a34f76bd9a917ce402ce27c08e4985c
Author: Jingoo Han <[email protected]>
Date:   Wed May 14 12:17:14 2014 +0900

    mfd: ipaq-micro: Use devm_ioremap_resource()
    
    Use devm_ioremap_resource() because devm_request_and_ioremap() is
    obsoleted by devm_ioremap_resource().
    
    Signed-off-by: Jingoo Han <[email protected]>
    Acked-by: Linus Walleij <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 24acfc632b7ba55bbc2a9305e8df31c8e41178b6
Author: Rafał Miłecki <[email protected]>
Date:   Tue May 20 09:27:18 2014 +0200

    b43: xmit: set 5 GHz bit depending on current band
    
    PHYs other than A may also work in 5 GHz mode.
    
    Signed-off-by: Rafał Miłecki <[email protected]>
    Signed-off-by: John W. Linville <[email protected]>

commit 3cad711dbc79cf9d1bcb9f192ba681e877c18d16
Author: Oleksij Rempel <[email protected]>
Date:   Tue May 20 00:02:03 2014 +0200

    ath9k_htc: fix build with disabled debug
    
      CC [M]  drivers/net/wireless/ath/ath9k/htc_drv_txrx.o
    drivers/net/wireless/ath/ath9k/htc_drv_txrx.c: In function ‘ath9k_rx_prepare’:
    drivers/net/wireless/ath/ath9k/htc_drv_txrx.c:1006:2: warning: passing argument 2 of ‘ath9k_htc_err_stat_rx’ from incompatible pointer type [enabled by default]
      ath9k_htc_err_stat_rx(priv, &rx_stats);
      ^
    In file included from drivers/net/wireless/ath/ath9k/htc_drv_txrx.c:17:0:
    drivers/net/wireless/ath/ath9k/htc.h:380:20: note: expected ‘struct ath_htc_rx_status *’ but argument is of type ‘struct ath_rx_status *’
     static inline void ath9k_htc_err_stat_rx(struct ath9k_htc_priv *priv,
    
    Signed-off-by: Oleksij Rempel <[email protected]>
    Signed-off-by: John W. Linville <[email protected]>

commit 773cfc508f4d64c14547ff8751b5cbd473124364
Author: Rafał Miłecki <[email protected]>
Date:   Mon May 19 23:18:55 2014 +0200

    b43: add more devices to the bands database
    
    Signed-off-by: Rafał Miłecki <[email protected]>
    Signed-off-by: John W. Linville <[email protected]>

commit 075ca604fcc0f761c66b99a406efded7be31aa14
Author: Rafał Miłecki <[email protected]>
Date:   Mon May 19 23:18:54 2014 +0200

    b43: move bands detection to a separated function
    
    This cleans code a bit and allows adding support for more devices.
    
    Signed-off-by: Rafał Miłecki <[email protected]>
    Signed-off-by: John W. Linville <[email protected]>

commit 646b4269e4d0513b4c210cdd47384e8607f539fe
Author: Ville Syrjälä <[email protected]>
Date:   Fri Apr 25 20:14:30 2014 +0300

    drm/i915: Drop /** */ comments from i915_reg.h
    
    The comments in i915_reg.h aren't proper kernel-doc comments, so replace
    the magic /** with just /*
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Damien Lespiau <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 64b14519e5913e8d4de9f2e5d9ef59abba3ed83d
Author: Jens Axboe <[email protected]>
Date:   Tue May 20 08:17:35 2014 -0600

    htmldocs: fix bio.c location
    
    Commit f9c78b2be2ca moved bio.c from fs/ to block/, but didn't
    update the docbook location. Fix that up.
    
    Signed-off-by: Jens Axboe <[email protected]>

commit e4443e459ccf43f2c139358400365fd6a839d40d
Author: Ville Syrjälä <[email protected]>
Date:   Wed Apr 9 13:28:41 2014 +0300

    drm/i915/chv: Add a bunch of pre production workarounds
    
    The following workarounds should be needed for pre-production hardware
    only:
    * WaDisablePwrmtrEvent:chv
    * WaSetMaskForGfxBusyness:chv
    * WaDisableGunitClockGating:chv
    * WaDisableFfDopClockGating:chv
    * WaDisableDopClockGating:chv
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Damien Lespiau <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 1966e59ec1075597eff4d7feb3d11536a242d0eb
Author: Ville Syrjälä <[email protected]>
Date:   Wed Apr 9 13:29:04 2014 +0300

    drm/i915/chv: Use RMW to toggle swing calc init
    
    The spec only tells us to set individual bits here and there. So we use
    RMW for most things. Do the same for the swing calc init.
    
    Eventually we should optimize things to just blast the final value in
    with group access whenever possible. But to do that someone needs to
    take a good look at what's the reset value for each registers, and
    possibly if the BIOS manages to frob with some of them. For now
    use RMW access always.
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit f72df8dbe2211cf2b70e54f8e9408b889fa56974
Author: Ville Syrjälä <[email protected]>
Date:   Wed Apr 9 13:29:03 2014 +0300

    drm/i915/chv: Don't do group access reads from TX lanes either
    
    Like PCS, TX group reads return 0xffffffff. So we need to target each
    lane separately if we want to use RMW cycles to update the registers.
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 97fd4d5c81af7976b4ec9971a93bf3c361066c65
Author: Ville Syrjälä <[email protected]>
Date:   Wed Apr 9 13:29:02 2014 +0300

    drm/i915/chv: Don't use PCS group access reads
    
    All PCS groups access reads return 0xffffffff, so we can't use group
    access for RMW cycles. Instead target each spline separately.
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    [danvet: Fight conflict with misplaced ; .... ARGH!]
    Signed-off-by: Daniel Vetter <[email protected]>

commit d2152b2524a96e6cb71097ea26c2e7c3f9e3ee12
Author: Ville Syrjälä <[email protected]>
Date:   Mon Apr 28 14:15:24 2014 +0300

    drm/i915/chv: Set soft reset override bit for data lane resets
    
    The bits we've been setting so far only progagate the reset singal to
    the data lanes. To actaully force the reset signal we need to set another
    override bit.
    
    v2: Fix mispalced ';' (Mika)
    
    Reviewed-by: Mika Kuoppala <[email protected]>
    Signed-off-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 580d3811f4465feee9d5cacdc88b6aa6b345eff5
Author: Ville Syrjälä <[email protected]>
Date:   Wed Apr 9 13:29:00 2014 +0300

    drm/i915/chv: Reset data lanes in encoder .post_disable() hook
    
    Seems like we shouldn't leave the data lane resert deasserted when
    the port if disabled. So propagate the reset the data lanes in
    the encoder .post_disable() hook.
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit d752048dcd1225b481074318cf92ee751d6d475e
Author: Ville Syrjälä <[email protected]>
Date:   Wed Apr 9 13:28:59 2014 +0300

    drm/i915/chv: Turn off dclkp after the PLL has been disabled
    
    During the enable sequence we first enable the dclkp output to the
    display controller, and then enable the PLL. Do the opposite during
    the disable sequence.
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 949c1d43d681a168216afe35071588e8edec354c
Author: Ville Syrjälä <[email protected]>
Date:   Wed Apr 9 13:28:58 2014 +0300

    drm/i915/chv: Move data lane deassert to encoder pre_enable
    
    We need to pick the correct data lanes based on the port not the
    pipe, so move the data lane deassert into the encoder .pre_enable()
    hook from the chv_enable_pll().
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit a11b07039de9e3866bf479f53f7f9db4923cd1c6
Author: Ville Syrjälä <[email protected]>
Date:   Wed Apr 9 13:28:57 2014 +0300

    drm/i915/chv: Fix CHV PLL state tracking
    
    Setup the pipe config dpll state correctly for CHV. Also add
    a assert_pipe_disabled() to chv_disable_pll(), and program the
    DPLL_MD registers in chv_enable_pll().
    
    Signed-off-by: Ville Syrjälä <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 9418c1f1760c91ae1a8947b0da383f3082799b19
Author: Ville Syrjälä <[email protected]>
Date:   Wed Apr 9 13:28:56 2014 +0300

    drm/i915/chv: Register port D encoders and connectors
    
 …
swarren pushed a commit to swarren/linux-tegra that referenced this pull request Jun 23, 2014
@dzickusrh @sfrothwell
kernel/watchdog.c: remove preemption restrictions when restarting loc…
9080d0e 
…kup detector

Peter Wu noticed the following splat on his machine when updating
/proc/sys/kernel/watchdog_thresh:

[    0.676701] BUG: sleeping function called from invalid context at mm/slub.c:965
[    0.679396] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init
[    0.681204] 3 locks held by init/1:
[    0.682371]  #0:  (sb_writers#3){.+.+.+}, at: [<ffffffff8117b663>] vfs_write+0x143/0x180
[    0.685887]  #1:  (watchdog_proc_mutex){+.+.+.}, at: [<ffffffff810e02d3>] proc_dowatchdog+0x33/0x110
[    0.689631]  #2:  (cpu_hotplug.lock){.+.+.+}, at: [<ffffffff810589c2>] get_online_cpus+0x32/0x80
[    0.693117] Preemption disabled at:[<ffffffff810e0384>] proc_dowatchdog+0xe4/0x110
[    0.695753]
[    0.696588] CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-rc1-testing torvalds#34
[    0.698404] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[    0.704622]  ffff88003f250000 ffff88003f1ffd10 ffffffff81624c59 0000000000000000
[    0.707749]  ffff88003f1ffd30 ffffffff8108df1d 0000000000000010 ffffffff81c56360
[    0.711010]  ffff88003f1ffd78 ffffffff8116a5de ffffffff811159a5 ffffffff810a5f4a
[    0.714053] Call Trace:
[    0.715015]  [<ffffffff81624c59>] dump_stack+0x4e/0x7a
[    0.716619]  [<ffffffff8108df1d>] __might_sleep+0x11d/0x190
[    0.718232]  [<ffffffff8116a5de>] kmem_cache_alloc_trace+0x4e/0x1e0
[    0.720214]  [<ffffffff811159a5>] ? perf_event_alloc+0x55/0x440
[    0.721910]  [<ffffffff810a5f4a>] ? mark_held_locks+0x6a/0x90
[    0.723558]  [<ffffffff811159a5>] perf_event_alloc+0x55/0x440
[    0.725304]  [<ffffffff810e0050>] ? restart_watchdog_hrtimer+0x50/0x50
[    0.727279]  [<ffffffff81116d16>] perf_event_create_kernel_counter+0x26/0xe0
[    0.729269]  [<ffffffff810dfe05>] watchdog_nmi_enable+0x75/0x140
[    0.730965]  [<ffffffff810dffb3>] update_timers_all_cpus+0x53/0xa0
[    0.732953]  [<ffffffff810e0384>] proc_dowatchdog+0xe4/0x110
[    0.738408]  [<ffffffff811d8c93>] proc_sys_call_handler+0xb3/0xc0
[    0.740266]  [<ffffffff811d8cb4>] proc_sys_write+0x14/0x20
[    0.742086]  [<ffffffff8117b5cd>] vfs_write+0xad/0x180
[    0.743669]  [<ffffffff810a606d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[    0.745593]  [<ffffffff8117b799>] SyS_write+0x49/0xb0
[    0.747101]  [<ffffffff8162fe92>] system_call_fastpath+0x16/0x1b
[    0.749069] NMI watchdog: disabled (cpu0): hardware events not enabled

What happened is after updating the watchdog_thresh, the lockup detector
is restarted to utilize the new value.  Part of this process involved
disabling preemption.  Once preemption was disabled, perf tried to
allocate a new event (as part of the restart).  This caused the above
BUG_ON as you can't sleep with preemption disabled.

The preemption restriction seemed agressive as we are not doing anything
on that particular cpu, but with all the online cpus (which are protected
by the get_online_cpus lock).  Remove the restriction and the BUG_ON goes
away.

Signed-off-by: Don Zickus <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Reported-by: Peter Wu <[email protected]>
Tested-by: Peter Wu <[email protected]>
Acked-by: David Rientjes <[email protected]>
Cc: <[email protected]>		[3.13+]
Signed-off-by: Andrew Morton <[email protected]>
torvalds pushed a commit that referenced this pull request Jun 24, 2014
@dzickusrh @torvalds
kernel/watchdog.c: remove preemption restrictions when restarting loc…
bde92cf 
…kup detector

Peter Wu noticed the following splat on his machine when updating
/proc/sys/kernel/watchdog_thresh:

  BUG: sleeping function called from invalid context at mm/slub.c:965
  in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init
  3 locks held by init/1:
   #0:  (sb_writers#3){.+.+.+}, at: [<ffffffff8117b663>] vfs_write+0x143/0x180
   #1:  (watchdog_proc_mutex){+.+.+.}, at: [<ffffffff810e02d3>] proc_dowatchdog+0x33/0x110
   #2:  (cpu_hotplug.lock){.+.+.+}, at: [<ffffffff810589c2>] get_online_cpus+0x32/0x80
  Preemption disabled at:[<ffffffff810e0384>] proc_dowatchdog+0xe4/0x110

  CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-rc1-testing #34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
    dump_stack+0x4e/0x7a
    __might_sleep+0x11d/0x190
    kmem_cache_alloc_trace+0x4e/0x1e0
    perf_event_alloc+0x55/0x440
    perf_event_create_kernel_counter+0x26/0xe0
    watchdog_nmi_enable+0x75/0x140
    update_timers_all_cpus+0x53/0xa0
    proc_dowatchdog+0xe4/0x110
    proc_sys_call_handler+0xb3/0xc0
    proc_sys_write+0x14/0x20
    vfs_write+0xad/0x180
    SyS_write+0x49/0xb0
    system_call_fastpath+0x16/0x1b
  NMI watchdog: disabled (cpu0): hardware events not enabled

What happened is after updating the watchdog_thresh, the lockup detector
is restarted to utilize the new value.  Part of this process involved
disabling preemption.  Once preemption was disabled, perf tried to
allocate a new event (as part of the restart).  This caused the above
BUG_ON as you can't sleep with preemption disabled.

The preemption restriction seemed agressive as we are not doing anything
on that particular cpu, but with all the online cpus (which are
protected by the get_online_cpus lock).  Remove the restriction and the
BUG_ON goes away.

Signed-off-by: Don Zickus <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Reported-by: Peter Wu <[email protected]>
Tested-by: Peter Wu <[email protected]>
Acked-by: David Rientjes <[email protected]>
Cc: <[email protected]>		[3.13+]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
heftig referenced this pull request in zen-kernel/zen-kernel Jul 7, 2014
@dzickusrh @gregkh
kernel/watchdog.c: remove preemption restrictions when restarting loc…
bf63ac6 
…kup detector

commit bde92cf upstream.

Peter Wu noticed the following splat on his machine when updating
/proc/sys/kernel/watchdog_thresh:

  BUG: sleeping function called from invalid context at mm/slub.c:965
  in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init
  3 locks held by init/1:
   #0:  (sb_writers#3){.+.+.+}, at: [<ffffffff8117b663>] vfs_write+0x143/0x180
   #1:  (watchdog_proc_mutex){+.+.+.}, at: [<ffffffff810e02d3>] proc_dowatchdog+0x33/0x110
   #2:  (cpu_hotplug.lock){.+.+.+}, at: [<ffffffff810589c2>] get_online_cpus+0x32/0x80
  Preemption disabled at:[<ffffffff810e0384>] proc_dowatchdog+0xe4/0x110

  CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-rc1-testing #34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
    dump_stack+0x4e/0x7a
    __might_sleep+0x11d/0x190
    kmem_cache_alloc_trace+0x4e/0x1e0
    perf_event_alloc+0x55/0x440
    perf_event_create_kernel_counter+0x26/0xe0
    watchdog_nmi_enable+0x75/0x140
    update_timers_all_cpus+0x53/0xa0
    proc_dowatchdog+0xe4/0x110
    proc_sys_call_handler+0xb3/0xc0
    proc_sys_write+0x14/0x20
    vfs_write+0xad/0x180
    SyS_write+0x49/0xb0
    system_call_fastpath+0x16/0x1b
  NMI watchdog: disabled (cpu0): hardware events not enabled

What happened is after updating the watchdog_thresh, the lockup detector
is restarted to utilize the new value.  Part of this process involved
disabling preemption.  Once preemption was disabled, perf tried to
allocate a new event (as part of the restart).  This caused the above
BUG_ON as you can't sleep with preemption disabled.

The preemption restriction seemed agressive as we are not doing anything
on that particular cpu, but with all the online cpus (which are
protected by the get_online_cpus lock).  Remove the restriction and the
BUG_ON goes away.

Signed-off-by: Don Zickus <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Reported-by: Peter Wu <[email protected]>
Tested-by: Peter Wu <[email protected]>
Acked-by: David Rientjes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
otavio referenced this pull request in Freescale/linux-fslc Jul 7, 2014
@dzickusrh @gregkh
kernel/watchdog.c: remove preemption restrictions when restarting loc…
6cd917a 
…kup detector

commit bde92cf upstream.

Peter Wu noticed the following splat on his machine when updating
/proc/sys/kernel/watchdog_thresh:

  BUG: sleeping function called from invalid context at mm/slub.c:965
  in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init
  3 locks held by init/1:
   #0:  (sb_writers#3){.+.+.+}, at: [<ffffffff8117b663>] vfs_write+0x143/0x180
   #1:  (watchdog_proc_mutex){+.+.+.}, at: [<ffffffff810e02d3>] proc_dowatchdog+0x33/0x110
   #2:  (cpu_hotplug.lock){.+.+.+}, at: [<ffffffff810589c2>] get_online_cpus+0x32/0x80
  Preemption disabled at:[<ffffffff810e0384>] proc_dowatchdog+0xe4/0x110

  CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-rc1-testing #34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
    dump_stack+0x4e/0x7a
    __might_sleep+0x11d/0x190
    kmem_cache_alloc_trace+0x4e/0x1e0
    perf_event_alloc+0x55/0x440
    perf_event_create_kernel_counter+0x26/0xe0
    watchdog_nmi_enable+0x75/0x140
    update_timers_all_cpus+0x53/0xa0
    proc_dowatchdog+0xe4/0x110
    proc_sys_call_handler+0xb3/0xc0
    proc_sys_write+0x14/0x20
    vfs_write+0xad/0x180
    SyS_write+0x49/0xb0
    system_call_fastpath+0x16/0x1b
  NMI watchdog: disabled (cpu0): hardware events not enabled

What happened is after updating the watchdog_thresh, the lockup detector
is restarted to utilize the new value.  Part of this process involved
disabling preemption.  Once preemption was disabled, perf tried to
allocate a new event (as part of the restart).  This caused the above
BUG_ON as you can't sleep with preemption disabled.

The preemption restriction seemed agressive as we are not doing anything
on that particular cpu, but with all the online cpus (which are
protected by the get_online_cpus lock).  Remove the restriction and the
BUG_ON goes away.

Signed-off-by: Don Zickus <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Reported-by: Peter Wu <[email protected]>
Tested-by: Peter Wu <[email protected]>
Acked-by: David Rientjes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
aryabinin pushed a commit to aryabinin/linux that referenced this pull request Sep 3, 2014
@akpm00 @broonie
not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range-checkp…
79b8dbf 
…atch-fixes

ERROR: space prohibited after that open parenthesis '('
torvalds#34: FILE: fs/proc/kcore.c:613:
+	if ( (MODULES_VADDR != VMALLOC_START) &&

ERROR: space prohibited before that close parenthesis ')'
torvalds#35: FILE: fs/proc/kcore.c:614:
+		(MODULES_END != VMALLOC_END) ) {

total: 2 errors, 0 warnings, 12 lines checked

./patches/not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range.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: Baoquan He <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Xishi Qiu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
swarren pushed a commit to swarren/linux-tegra that referenced this pull request Sep 3, 2014
@akpm00 @broonie
not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range-checkp…
514a540 
…atch-fixes

ERROR: space prohibited after that open parenthesis '('
torvalds#34: FILE: fs/proc/kcore.c:613:
+	if ( (MODULES_VADDR != VMALLOC_START) &&

ERROR: space prohibited before that close parenthesis ')'
torvalds#35: FILE: fs/proc/kcore.c:614:
+		(MODULES_END != VMALLOC_END) ) {

total: 2 errors, 0 warnings, 12 lines checked

./patches/not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range.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: Baoquan He <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Xishi Qiu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
andy-shev referenced this pull request in andy-shev/linux Sep 5, 2014
@akpm00 @broonie
not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range-checkp…
b9db59c 
…atch-fixes

ERROR: space prohibited after that open parenthesis '('
#34: FILE: fs/proc/kcore.c:613:
+	if ( (MODULES_VADDR != VMALLOC_START) &&

ERROR: space prohibited before that close parenthesis ')'
#35: FILE: fs/proc/kcore.c:614:
+		(MODULES_END != VMALLOC_END) ) {

total: 2 errors, 0 warnings, 12 lines checked

./patches/not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range.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: Baoquan He <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Xishi Qiu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
torvalds pushed a commit that referenced this pull request Sep 7, 2014
@fweisbec
nohz: Restore NMI safe local irq work for local nohz kick
40bea03 
The local nohz kick is currently used by perf which needs it to be
NMI-safe. Recent commit though (7d1311b)
changed its implementation to fire the local kick using the remote kick
API. It was convenient to make the code more generic but the remote kick
isn't NMI-safe.

As a result:

	WARNING: CPU: 3 PID: 18062 at kernel/irq_work.c:72 irq_work_queue_on+0x11e/0x140()
	CPU: 3 PID: 18062 Comm: trinity-subchil Not tainted 3.16.0+ #34
	0000000000000009 00000000903774d1 ffff880244e06c00 ffffffff9a7f1e37
	0000000000000000 ffff880244e06c38 ffffffff9a0791dd ffff880244fce180
	0000000000000003 ffff880244e06d58 ffff880244e06ef8 0000000000000000
	Call Trace:
	<NMI>  [<ffffffff9a7f1e37>] dump_stack+0x4e/0x7a
	[<ffffffff9a0791dd>] warn_slowpath_common+0x7d/0xa0
	[<ffffffff9a07930a>] warn_slowpath_null+0x1a/0x20
	[<ffffffff9a17ca1e>] irq_work_queue_on+0x11e/0x140
	[<ffffffff9a10a2c7>] tick_nohz_full_kick_cpu+0x57/0x90
	[<ffffffff9a186cd5>] __perf_event_overflow+0x275/0x350
	[<ffffffff9a184f80>] ? perf_event_task_disable+0xa0/0xa0
	[<ffffffff9a01a4cf>] ? x86_perf_event_set_period+0xbf/0x150
	[<ffffffff9a187934>] perf_event_overflow+0x14/0x20
	[<ffffffff9a020386>] intel_pmu_handle_irq+0x206/0x410
	[<ffffffff9a0b54d3>] ? arch_vtime_task_switch+0x63/0x130
	[<ffffffff9a01937b>] perf_event_nmi_handler+0x2b/0x50
	[<ffffffff9a007b72>] nmi_handle+0xd2/0x390
	[<ffffffff9a007aa5>] ? nmi_handle+0x5/0x390
	[<ffffffff9a0d131b>] ? lock_release+0xab/0x330
	[<ffffffff9a008062>] default_do_nmi+0x72/0x1c0
	[<ffffffff9a0c925f>] ? cpuacct_account_field+0xcf/0x200
	[<ffffffff9a008268>] do_nmi+0xb8/0x100

Lets fix this by restoring the use of local irq work for the nohz local
kick.

Reported-by: Catalin Iacob <[email protected]>
Reported-and-tested-by: Dave Jones <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
aryabinin pushed a commit to aryabinin/linux that referenced this pull request Sep 10, 2014
@akpm00 @sfrothwell
not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range-checkp…
4411b45 
…atch-fixes

ERROR: space prohibited after that open parenthesis '('
torvalds#34: FILE: fs/proc/kcore.c:613:
+	if ( (MODULES_VADDR != VMALLOC_START) &&

ERROR: space prohibited before that close parenthesis ')'
torvalds#35: FILE: fs/proc/kcore.c:614:
+		(MODULES_END != VMALLOC_END) ) {

total: 2 errors, 0 warnings, 12 lines checked

./patches/not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range.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: Baoquan He <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Xishi Qiu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
n-aizu pushed a commit to n-aizu/linux that referenced this pull request Sep 10, 2014
@linux4kix
Upstream: imx-drm: imx-drm-core: Fix circular locking dependency
5c72985 
Booting a mx6 with CONFIG_PROVE_LOCKING we get:

======================================================
[ INFO: possible circular locking dependency detected ]
3.12.0-rc4-next-20131009+ torvalds#34 Not tainted
-------------------------------------------------------
swapper/0/1 is trying to acquire lock:
 (&imx_drm_device->mutex){+.+.+.}, at: [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98

but task is already holding lock:
 (&crtc->mutex){+.+...}, at: [<802fe778>] drm_modeset_lock_all+0x40/0x54

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&crtc->mutex){+.+...}:
       [<800777d0>] __lock_acquire+0x18d4/0x1c24
       [<80077fec>] lock_acquire+0x68/0x7c
       [<805ead5c>] _mutex_lock_nest_lock+0x58/0x3a8
       [<802fec50>] drm_crtc_init+0x48/0xa8
       [<80457c88>] imx_drm_add_crtc+0xd4/0x144
       [<8045e2e8>] ipu_drm_probe+0x114/0x1fc
       [<80312278>] platform_drv_probe+0x20/0x50
       [<80310c68>] driver_probe_device+0x110/0x22c
       [<80310e20>] __driver_attach+0x9c/0xa0
       [<8030f218>] bus_for_each_dev+0x5c/0x90
       [<80310750>] driver_attach+0x20/0x28
       [<8031034c>] bus_add_driver+0xdc/0x1dc
       [<803114d8>] driver_register+0x80/0xfc
       [<80312198>] __platform_driver_register+0x50/0x64
       [<808172fc>] ipu_drm_driver_init+0x18/0x20
       [<800088c0>] do_one_initcall+0xfc/0x160
       [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
       [<805e2930>] kernel_init+0x10/0xec
       [<8000ea68>] ret_from_fork+0x14/0x2c

-> #1 (&dev->mode_config.mutex){+.+.+.}:
       [<800777d0>] __lock_acquire+0x18d4/0x1c24
       [<80077fec>] lock_acquire+0x68/0x7c
       [<805eb100>] mutex_lock_nested+0x54/0x3a4
       [<802fe758>] drm_modeset_lock_all+0x20/0x54
       [<802fead4>] drm_encoder_init+0x20/0x7c
       [<80457ae4>] imx_drm_add_encoder+0x88/0xec
       [<80459838>] imx_ldb_probe+0x344/0x4fc
       [<80312278>] platform_drv_probe+0x20/0x50
       [<80310c68>] driver_probe_device+0x110/0x22c
       [<80310e20>] __driver_attach+0x9c/0xa0
       [<8030f218>] bus_for_each_dev+0x5c/0x90
       [<80310750>] driver_attach+0x20/0x28
       [<8031034c>] bus_add_driver+0xdc/0x1dc
       [<803114d8>] driver_register+0x80/0xfc
       [<80312198>] __platform_driver_register+0x50/0x64
       [<8081722c>] imx_ldb_driver_init+0x18/0x20
       [<800088c0>] do_one_initcall+0xfc/0x160
       [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
       [<805e2930>] kernel_init+0x10/0xec
       [<8000ea68>] ret_from_fork+0x14/0x2c

-> #0 (&imx_drm_device->mutex){+.+.+.}:
       [<805e510c>] print_circular_bug+0x74/0x2e0
       [<80077ad0>] __lock_acquire+0x1bd4/0x1c24
       [<80077fec>] lock_acquire+0x68/0x7c
       [<805eb100>] mutex_lock_nested+0x54/0x3a4
       [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98
       [<80459a98>] imx_ldb_encoder_prepare+0x34/0x114
       [<802ef724>] drm_crtc_helper_set_mode+0x1f0/0x4c0
       [<802f0344>] drm_crtc_helper_set_config+0x828/0x99c
       [<802ff270>] drm_mode_set_config_internal+0x5c/0xdc
       [<802eebe0>] drm_fb_helper_set_par+0x50/0xb4
       [<802af580>] fbcon_init+0x490/0x500
       [<802dd104>] visual_init+0xa8/0xf8
       [<802df414>] do_bind_con_driver+0x140/0x37c
       [<802df764>] do_take_over_console+0x114/0x1c4
       [<802af65c>] do_fbcon_takeover+0x6c/0xd4
       [<802b2b30>] fbcon_event_notify+0x7c8/0x818
       [<80049954>] notifier_call_chain+0x4c/0x8c
       [<80049cd8>] __blocking_notifier_call_chain+0x50/0x68
       [<80049d10>] blocking_notifier_call_chain+0x20/0x28
       [<802a75f0>] fb_notifier_call_chain+0x1c/0x24
       [<802a9224>] register_framebuffer+0x188/0x268
       [<802ee994>] drm_fb_helper_initial_config+0x2bc/0x4b8
       [<802f118c>] drm_fbdev_cma_init+0x7c/0xec
       [<80817288>] imx_fb_helper_init+0x54/0x90
       [<800088c0>] do_one_initcall+0xfc/0x160
       [<807e7c5c>] kernel_init_freeable+0x104/0x1d4
       [<805e2930>] kernel_init+0x10/0xec
       [<8000ea68>] ret_from_fork+0x14/0x2c

other info that might help us debug this:

Chain exists of:
  &imx_drm_device->mutex --> &dev->mode_config.mutex --> &crtc->mutex

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&crtc->mutex);
                               lock(&dev->mode_config.mutex);
                               lock(&crtc->mutex);
  lock(&imx_drm_device->mutex);

 *** DEADLOCK ***

6 locks held by swapper/0/1:
 #0:  (registration_lock){+.+.+.}, at: [<802a90bc>] register_framebuffer+0x20/0x268
 #1:  (&fb_info->lock){+.+.+.}, at: [<802a7a90>] lock_fb_info+0x20/0x44
 #2:  (console_lock){+.+.+.}, at: [<802a9218>] register_framebuffer+0x17c/0x268
 #3:  ((fb_notifier_list).rwsem){.+.+.+}, at: [<80049cbc>] __blocking_notifier_call_chain+0x34/0x68
 #4:  (&dev->mode_config.mutex){+.+.+.}, at: [<802fe758>] drm_modeset_lock_all+0x20/0x54
 #5:  (&crtc->mutex){+.+...}, at: [<802fe778>] drm_modeset_lock_all+0x40/0x54

In order to avoid this lockdep warning, remove the locking from
imx_drm_encoder_get_mux_id() and imx_drm_crtc_panel_format_pins().

Tested on a mx6sabrelite and mx53qsb.

Reported-by: Russell King <[email protected]>
Tested-by: Russell King <[email protected]>
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
koct9i pushed a commit to koct9i/linux that referenced this pull request Sep 23, 2014
@akpm00 @hnaz
not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range-checkp…
8b73240 
…atch-fixes

ERROR: space prohibited after that open parenthesis '('
torvalds#34: FILE: fs/proc/kcore.c:613:
+	if ( (MODULES_VADDR != VMALLOC_START) &&

ERROR: space prohibited before that close parenthesis ')'
torvalds#35: FILE: fs/proc/kcore.c:614:
+		(MODULES_END != VMALLOC_END) ) {

total: 2 errors, 0 warnings, 12 lines checked

./patches/not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range.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: Baoquan He <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Xishi Qiu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
aryabinin pushed a commit to aryabinin/linux that referenced this pull request Sep 24, 2014
@akpm00 @hnaz
not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range-checkp…
e4e6a3b 
…atch-fixes

ERROR: space prohibited after that open parenthesis '('
torvalds#34: FILE: fs/proc/kcore.c:613:
+	if ( (MODULES_VADDR != VMALLOC_START) &&

ERROR: space prohibited before that close parenthesis ')'
torvalds#35: FILE: fs/proc/kcore.c:614:
+		(MODULES_END != VMALLOC_END) ) {

total: 2 errors, 0 warnings, 12 lines checked

./patches/not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range.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: Baoquan He <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Xishi Qiu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
ddstreet pushed a commit to ddstreet/linux that referenced this pull request Sep 25, 2014
@akpm00 @sfrothwell
not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range-checkp…
436408f 
…atch-fixes

ERROR: space prohibited after that open parenthesis '('
torvalds#34: FILE: fs/proc/kcore.c:613:
+	if ( (MODULES_VADDR != VMALLOC_START) &&

ERROR: space prohibited before that close parenthesis ')'
torvalds#35: FILE: fs/proc/kcore.c:614:
+		(MODULES_END != VMALLOC_END) ) {

total: 2 errors, 0 warnings, 12 lines checked

./patches/not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range.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: Baoquan He <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Xishi Qiu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
ddstreet pushed a commit to ddstreet/linux that referenced this pull request Sep 25, 2014
@hansendc
x86, sched: Add new topology for multi-NUMA-node CPUs
cebf15e 
I'm getting the spew below when booting with Haswell (Xeon
E5-2699 v3) CPUs and the "Cluster-on-Die" (CoD) feature enabled
in the BIOS.  It seems similar to the issue that some folks from
AMD ran in to on their systems and addressed in this commit:

  161270f ("x86/smp: Fix topology checks on AMD MCM CPUs")

Both these Intel and AMD systems break an assumption which is
being enforced by topology_sane(): a socket may not contain more
than one NUMA node.

AMD special-cased their system by looking for a cpuid flag.  The
Intel mode is dependent on BIOS options and I do not know of a
way which it is enumerated other than the tables being parsed
during the CPU bringup process.  In other words, we have to trust
the ACPI tables <shudder>.

This detects the situation where a NUMA node occurs at a place in
the middle of the "CPU" sched domains.  It replaces the default
topology with one that relies on the NUMA information from the
firmware (SRAT table) for all levels of sched domains above the
hyperthreads.

This also fixes a sysfs bug.  We used to freak out when we saw
the "mc" group cross a node boundary, so we stopped building the
MC group.  MC gets exported as the 'core_siblings_list' in
/sys/devices/system/cpu/cpu*/topology/ and this caused CPUs with
the same 'physical_package_id' to not be listed together in
'core_siblings_list'.  This violates a statement from
Documentation/ABI/testing/sysfs-devices-system-cpu:

	core_siblings: internal kernel map of cpu#'s hardware threads
	within the same physical_package_id.

	core_siblings_list: human-readable list of the logical CPU
	numbers within the same physical_package_id as cpu#.

The sysfs effects here cause an issue with the hwloc tool where
it gets confused and thinks there are more sockets than are
physically present.

Before this patch, there are two packages:

# cd /sys/devices/system/cpu/
# cat cpu*/topology/physical_package_id | sort | uniq -c
     18 0
     18 1

But 4 _sets_ of core siblings:

# cat cpu*/topology/core_siblings_list | sort | uniq -c
      9 0-8
      9 18-26
      9 27-35
      9 9-17

After this set, there are only 2 sets of core siblings, which
is what we expect for a 2-socket system.

# cat cpu*/topology/physical_package_id | sort | uniq -c
     18 0
     18 1
# cat cpu*/topology/core_siblings_list | sort | uniq -c
     18 0-17
     18 18-35

Example spew:
...
	NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
	 #2  #3  #4  #5  torvalds#6  torvalds#7  torvalds#8
	.... node  #1, CPUs:    torvalds#9
	------------[ cut here ]------------
	WARNING: CPU: 9 PID: 0 at /home/ak/hle/linux-hle-2.6/arch/x86/kernel/smpboot.c:306 topology_sane.isra.2+0x74/0x90()
	sched: CPU torvalds#9's mc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
	Modules linked in:
	CPU: 9 PID: 0 Comm: swapper/9 Not tainted 3.17.0-rc1-00293-g8e01c4d-dirty torvalds#631
	Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS GRNDSDP1.86B.0036.R05.1407140519 07/14/2014
	0000000000000009 ffff88046ddabe00 ffffffff8172e485 ffff88046ddabe48
	ffff88046ddabe38 ffffffff8109691d 000000000000b001 0000000000000009
	ffff88086fc12580 000000000000b020 0000000000000009 ffff88046ddabe98
	Call Trace:
	[<ffffffff8172e485>] dump_stack+0x45/0x56
	[<ffffffff8109691d>] warn_slowpath_common+0x7d/0xa0
	[<ffffffff8109698c>] warn_slowpath_fmt+0x4c/0x50
	[<ffffffff81074f94>] topology_sane.isra.2+0x74/0x90
	[<ffffffff8107530e>] set_cpu_sibling_map+0x31e/0x4f0
	[<ffffffff8107568d>] start_secondary+0x1ad/0x240
	---[ end trace 3fe5f587a9fcde61 ]---
	torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17
	.... node  #2, CPUs:   torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 torvalds#24 torvalds#25 torvalds#26
	.... node  #3, CPUs:   torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35

Signed-off-by: Dave Hansen <[email protected]>
[ Added LLC domain and s/match_mc/match_die/ ]
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Igor Mammedov <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Toshi Kani <[email protected]>
Cc: [email protected]
Cc: "H. Peter Anvin" <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
koct9i pushed a commit to koct9i/linux that referenced this pull request Sep 27, 2014
@akpm00 @hnaz
not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range-checkp…
d728013 
…atch-fixes

ERROR: space prohibited after that open parenthesis '('
torvalds#34: FILE: fs/proc/kcore.c:613:
+	if ( (MODULES_VADDR != VMALLOC_START) &&

ERROR: space prohibited before that close parenthesis ')'
torvalds#35: FILE: fs/proc/kcore.c:614:
+		(MODULES_END != VMALLOC_END) ) {

total: 2 errors, 0 warnings, 12 lines checked

./patches/not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range.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: Baoquan He <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Xishi Qiu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
koct9i referenced this pull request in koct9i/linux Sep 27, 2014
@hnaz
linux-next
3ade1b1 
GIT 2cf50762577a191f2f646e4034cc21f4764d90ab

commit 68c7ed167ef564c83a0022f2d0fe15cbdac0c5a4
Author: Peter Foley <[email protected]>
Date:   Thu Sep 25 10:34:04 2014 +1000

    Documentation: disable vdso_test to avoid breakage with old glibc
    
    glibc versions older than 2.16 don't include sys/auxv.h which this
    executable uses.
    Since we don't have a good way to test for specific glibc versions in
    kbuild, just disable it for now.
    
    Signed-off-by: Peter Foley <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>

commit 03979f1100aca61cf16ac7f3e464d7f11747e86b
Author: Peter Foley <[email protected]>
Date:   Thu Sep 25 10:34:04 2014 +1000

    Documentation: update vDSO makefile to build portable examples
    
    Signed-off-by: Peter Foley <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>

commit 13770826a9872de445703ee6c05b44f525f78513
Author: Peter Foley <[email protected]>
Date:   Thu Sep 25 10:34:04 2014 +1000

    Documentation: update .gitignore files
    
    Add some missing files to .gitignore.
    Push Documentation/.gitignore down into subdirectories.
    
    Signed-off-by: Peter Foley <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>

commit ce0f3b2691c066255fcf25c77e929ff8cda73417
Author: Peter Foley <[email protected]>
Date:   Thu Sep 25 10:34:03 2014 +1000

    Documentation: support glibc versions without htole macros
    
    glibc 2.9 introduced the htole<16/32/64> macros, add them to
    tools/include to support older versions of glibc.
    
    Reported-by: Andrew Morton <[email protected]>
    Signed-off-by: Peter Foley <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>

commit 77cb6d96708f5b681969ce144057ae1ebda96057
Author: Mark Brown <[email protected]>
Date:   Thu Sep 25 10:34:03 2014 +1000

    v4l2-pci-skeleton: Only build if PCI is available
    
    Currently arm64 does not support PCI but it does support v4l2. Since the
    PCI skeleton driver is built unconditionally as a module with no dependency
    on PCI this causes build failures for arm64 allmodconfig. Fix this by
    defining a symbol VIDEO_PCI_SKELETON for the skeleton and conditionalising
    the build on that.
    
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]> [added VIDEO dependencies]

commit 112a45ca901ced590ff71c5fd7d717f8771717ce
Author: Peter Foley <[email protected]>
Date:   Thu Sep 25 10:34:03 2014 +1000

    Documentation: fix misc. warnings
    
    Fix a few warnings that gcc emits during a default build.
    
    Signed-off-by: Peter Foley <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>

commit b0fc375fe2c09477b5effc8e030668203d24c897
Author: Peter Foley <[email protected]>
Date:   Thu Sep 25 10:34:03 2014 +1000

    Documentation: make functions static to avoid prototype warnings
    
    Signed-off-by: Peter Foley <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>

commit 593ed472bcea93949c72ddc45e340fee47a05aa3
Author: Peter Foley <[email protected]>
Date:   Thu Sep 25 10:34:03 2014 +1000

    Documentation: add makefiles for more targets
    
    Add a bunch of previously unbuilt source files to the Documentation build
    machinery.
    
    Signed-off-by: Peter Foley <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>

commit cc67d673f252264535cef654c37c8dd621340e8b
Author: Peter Foley <[email protected]>
Date:   Thu Sep 25 10:34:02 2014 +1000

    Documentation: use subdir-y to avoid unnecessary built-in.o files
    
    Change the Documentation makefiles from obj-m to subdir-y
    to avoid generating unnecessary built-in.o files since nothing
    in Documentation/ is ever linked in to vmlinux.
    
    Signed-off-by: Peter Foley <[email protected]>
    Acked-by: Sam Ravnborg <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>

commit bb69afeca345380203c89d2f19e95eca786b5a4c
Author: Peter Foley <[email protected]>
Date:   Thu Sep 25 10:34:02 2014 +1000

    Documentation: remove networking/.gitignore
    
    Remove empty networking/.gitignore
    
    Signed-off-by: Peter Foley <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Randy Dunlap <[email protected]>

commit 4d96fb1ec81118c6406fe6d3670f172b2faaedf3
Author: Heiko Stuebner <[email protected]>
Date:   Tue Sep 23 22:42:16 2014 +0200

    power: gpio-charger: do not use gpio value directly
    
    Some gpio implementations return interesting values for gpio_get_value when
    the value is not 0 - as seen on a imx6sl board. Therefore do not use the
    value returned from gpio_get_value directly but simply check for 0 or not 0.
    
    Signed-off-by: Heiko Stuebner <[email protected]>
    Reviewed-by: Doug Anderson <[email protected]>
    Tested-by: Doug Anderson <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>

commit ddd26dff757d08d4eb309a28bf2a02372387e71f
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Sep 16 18:10:41 2014 +0200

    power: max8925: Use of_get_child_by_name
    
    Use of_get_child_by_name to obtain reference to charger node instead of
    of_find_node_by_name which can walk outside of the parent node.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>

commit 920ac5be91bc447c5ef82f457207a169aa79c5f6
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Sep 16 18:10:40 2014 +0200

    power: max8925: Fix NULL ptr dereference on memory allocation failure
    
    Check the return value of devm_kzalloc() to fix possible NULL pointer
    dereference and properly exit the probe() on memory allocation failure.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>

commit 628ef02c56e515430dd8d8439126dd0ecb8ce8bb
Author: Puthikorn Voravootivat <[email protected]>
Date:   Tue Sep 9 12:20:35 2014 -0700

    bq27x00_battery: Add support to bq27742
    
    Add support to bq27742 in bq27x00 driver. bq27742 register
    addresses are mostly mostly the same as bq27500 addresses
    with minor differences.
    
    Signed-off-by: Puthikorn Voravootivat <[email protected]>
    Reviewed-by: Gwendal Grignou <[email protected]>
    Reviewed-by: Rhyland Klein <[email protected]>
    Reviewed-by: Benson Leung <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>

commit 042e1c79166b9250edd8262bea84e1703f27ad2e
Author: Jin Yao <[email protected]>
Date:   Mon Sep 22 10:31:14 2014 -0700

    Input: soc_button_array - convert to platform bus
    
    ACPI device enumeration mechanism changed a lot since 3.16-rc1.
    ACPI device objects with _HID will be enumerated to platform bus by default.
    For the existing PNP drivers that probe the PNPACPI devices, the device ids
    are listed explicitly in drivers/acpi/acpi_pnp.c.
    But ACPI folks will continue their effort on shrinking this id list by
    converting the PNP drivers to platform drivers, for the devices that don't
    belong to PNP bus in nature.
    
    Signed-off-by: Jin Yao <[email protected]>
    Signed-off-by: Zhang Rui <[email protected]>
    Signed-off-by: Dmitry Torokhov <[email protected]>

commit 3049683eafdbbbd7350b0e5ca02a2d8c026a3362
Author: Marcos Paulo de Souza <[email protected]>
Date:   Wed Sep 24 16:00:33 2014 -0700

    Input: i8042 - fix Asus X450LCP touchpad detection
    
    We need to add this module to the nomux table to be able to detect the
    touchpad.
    
    Cc: stablevger.kernel.org
    Signed-off-by: Marcos Paulo de Souza <[email protected]>
    Signed-off-by: Dmitry Torokhov <[email protected]>

commit 3f3d0463636e38a27c3000d59889b8bdc9072ce1
Author: Javier Martinez Canillas <[email protected]>
Date:   Thu Sep 25 08:23:26 2014 +0900

    ARM: dts: Remove display timings node from exynos5250-snow
    
    Commit a3d72cad63ed ("ARM: dts: Clean up exynos5250-snow")
    improved the Snow DTS but the patch was rebased due conflicting
    changes and the merge resolution added a device node removed by
    commit a98c3c23868f ("ARM: dts: update display related nodes for
    exynos5250-snow").
    
    This patch removes the node again to keep the DTS as before.
    
    Signed-off-by: Javier Martinez Canillas <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit dd12ac7fb3988be113465f499ad91b30b8aa4bdd
Author: Javier Martinez Canillas <[email protected]>
Date:   Thu Sep 25 08:21:25 2014 +0900

    ARM: dts: Fix chip select GPIO on exynos5250-smdk5250
    
    Commit 65bbe3fee0e1 ("ARM: dts: Clean up exynos5250-smdk5250")
    improved the smdk5250 DTS but the patch was rebased due conflicting
    changes and the merge resolution added a regression of the bug fixed
    in commit e138d4333aa0 ("ARM: dts: fix the chip select gpios definition
    in the SPI nodes").
    
    This patch fixes the issue by removing the old cs-gpio and using
    the generic cs-gpios property.
    
    Signed-off-by: Javier Martinez Canillas <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 5c4dd348af35a6f6db97b4f2401f74c71f7f3c7d
Author: Rafael J. Wysocki <[email protected]>
Date:   Thu Sep 25 00:53:44 2014 +0200

    Revert "PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free()"
    
    Revert commit 6efde38f0769 (PM / Hibernate: Iterate over set bits
    instead of PFNs in swsusp_free()) that introduced a NULL pointer
    dereference during system resume from hibernation:
    
    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [<ffffffff810a8cc1>] swsusp_free+0x21/0x190
    PGD b39c2067 PUD b39c1067 PMD 0
    Oops: 0000 [#1] SMP
    Modules linked in: <irrelevant list of modules>
    CPU: 1 PID: 4898 Comm: s2disk Tainted: G         C     3.17-rc5-amd64 #1 Debian 3.17~rc5-1~exp1
    Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
    task: ffff88023155ea40 ti: ffff8800b3b14000 task.ti: ffff8800b3b14000
    RIP: 0010:[<ffffffff810a8cc1>]  [<ffffffff810a8cc1>]
    swsusp_free+0x21/0x190
    RSP: 0018:ffff8800b3b17ea8  EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff8800b39bab00 RCX: 0000000000000001
    RDX: ffff8800b39bab10 RSI: ffff8800b39bab00 RDI: 0000000000000000
    RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000
    R10: ffff8800b39bab10 R11: 0000000000000246 R12: ffffea0000000000
    R13: ffff880232f485a0 R14: ffff88023ac27cd8 R15: ffff880232927590
    FS:  00007f406d83b700(0000) GS:ffff88023bc80000(0000)
    knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000000 CR3: 00000000b3a62000 CR4: 00000000000007e0
    Stack:
     ffff8800b39bab00 0000000000000010 ffff880232927590 ffffffff810acb4a
     ffff8800b39bab00 ffffffff811a955a ffff8800b39bab10 0000000000000000
     ffff88023155f098 ffffffff81a6b8c0 ffff88023155ea40 0000000000000007
    Call Trace:
     [<ffffffff810acb4a>] ? snapshot_release+0x2a/0xb0
     [<ffffffff811a955a>] ? __fput+0xca/0x1d0
     [<ffffffff81080627>] ? task_work_run+0x97/0xd0
     [<ffffffff81012d89>] ? do_notify_resume+0x69/0xa0
     [<ffffffff8151452a>] ? int_signal+0x12/0x17
    Code: 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 41 54 48 8b 05 ba 62 9c 00 49 bc 00 00 00 00 00 ea ff ff 48 8b 3d a1 62 9c 00 55 53 <48> 8b 10 48 89 50 18 48 8b 52 20 48 c7 40 28 00 00 00 00 c7 40
    RIP  [<ffffffff810a8cc1>] swsusp_free+0x21/0x190
     RSP <ffff8800b3b17ea8>
    CR2: 0000000000000000
    ---[ end trace f02be86a1ec0cccb ]---
    
    due to forbidden_pages_map being NULL in swsusp_free().
    
    Fixes: 6efde38f0769 "PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free()"
    Reported-by: Bjørn Mork <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit a928f97152ea39c31f8ea89b60dd30a169d4ed6e
Author: Peter Hüwe <[email protected]>
Date:   Fri Sep 12 21:09:47 2014 +0200

    i2c: acpi: Fix NULL Pointer dereference
    
    If adapter->dev.parent == NULL there is a NULL pointer dereference in
    acpi_i2c_install_space_handler and acpi_i2c_remove_space_handler.
    
    This is present since introduction of this code:
    366047515c6e "i2c: rework kernel config I2C_ACPI" or even
    da3c6647ee08 "I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI"
    
    The adapter->dev.parent == NULL case is valid for the i2c_stub,
    so loading i2c_stub with ACPI_I2C_OPREGION enabled results in an oops.
    This is also valid at least for i2c_tiny_usb and i2c_robotfuzz_osif.
    
    Fix by checking whether it is null before calling ACPI_HANDLE.
    
    Signed-off-by: Peter Huewe <[email protected]>
    Acked-by: Mika Westerberg <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>

commit c15d821ddb9dac9ac6b5beb75bf942f3bc3a4004
Author: Srinivas Pandruvada <[email protected]>
Date:   Tue Sep 23 10:35:54 2014 +0800

    gpio / ACPI: Use pin index and bit length
    
    Fix code when the operation region callback is for an gpio, which
    is not at index 0 and for partial pins in a GPIO definition.
    For example:
    Name (GMOD, ResourceTemplate ()
    {
    	//3 Outputs that define the Power mode of the device
    	GpioIo (Exclusive, PullDown, , , , "\\_SB.GPI2") {10, 11, 12}
    	})
    }
    
    If opregion callback calls is for:
    - Set pin 10, then address = 0 and bit length = 1
    - Set pin 11, then address = 1 and bit length = 1
    - Set for both pin 11 and pin 12, then address = 1, bit length = 2
    
    This change requires updated ACPICA gpio operation handler code to
    send the pin index and bit length.
    
    Fixes: 473ed7be0da0 (gpio / ACPI: Add support for ACPI GPIO operation regions)
    Signed-off-by: Srinivas Pandruvada <[email protected]>
    Acked-by: Mika Westerberg <[email protected]>
    Acked-by: Linus Walleij <[email protected]>
    Cc: 3.15+ <[email protected]> # 3.15+: 75ec6e55f138 ACPICA: Update to GPIO region handler interface.
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 75ec6e55f1384548311a13ce4fcb39c516053314
Author: Bob Moore <[email protected]>
Date:   Tue Sep 23 10:35:47 2014 +0800

    ACPICA: Update to GPIO region handler interface.
    
    Changes to correct several GPIO issues:
    
    1) The update_rule in a GPIO field definition is now ignored;
    a read-modify-write operation is never performed for GPIO fields.
    (Internally, this means that the field assembly/disassembly
    code is completely bypassed for GPIO.)
    
    2) The Address parameter passed to a GPIO region handler is
    now the bit offset of the field from a previous Connection()
    operator. Thus, it becomes a "Pin Number Index" into the
    Connection() resource descriptor.
    
    3) The bit_width parameter passed to a GPIO region handler is
    now the exact bit width of the GPIO field. Thus, it can be
    interpreted as "number of pins".
    
    Overall, we can now say that the region handler interface
    to GPIO handlers is a raw "bit/pin" addressed interface, not
    a byte-addressed interface like the system_memory handler interface.
    
    Signed-off-by: Bob Moore <[email protected]>
    Signed-off-by: Lv Zheng <[email protected]>
    Cc: 3.15+ <[email protected]> # 3.15+
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 457920817e645a7dee42c2a75c81c5ed8e12ee1c
Author: Fu Zhonghui <[email protected]>
Date:   Wed Sep 24 22:42:26 2014 +0200

    ACPI / platform / LPSS: disable async suspend/resume of LPSS devices
    
    On some systems (Asus T100 in particular) there are strict ordering
    dependencies between LPSS devices with respect to power management
    that break if they suspend/resume asynchronously.
    
    In theory it should be possible to follow those dependencies in the
    async suspend/resume case too (the ACPI tables tell as that the
    dependencies are there), but since we're missing infrastructure
    for that at the moment, disable async suspend/resume for all of
    the LPSS devices for the time being.
    
    Link: http://marc.info/?l=linux-acpi&m=141158962321905&w=2
    Fixes: 8ce62f85a81f (ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices)
    Signed-off-by: Li Aubrey <[email protected]>
    Signed-off-by: Fu Zhonghui <[email protected]>
    Cc: 3.16+ <[email protected]> # 3.16+
    [ rjw: Changelog ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit c7da579763f29cf45a861ad4c339aba590d8b80d
Author: Johan Hedberg <[email protected]>
Date:   Wed Sep 24 22:41:46 2014 +0300

    Bluetooth: Add retransmission effort into SCO parameter table
    
    It is expected that new parameter combinations will have the
    retransmission effort value different between some entries (mainly
    because of the new S4 configuration added by HFP 1.7), so it makes sense
    to move it into the table instead of having it hard coded based on the
    selected SCO_AIRMODE_*.
    
    Signed-off-by: Johan Hedberg <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit b2fc3f3c6d397d434174147eca3db1ec778195ce
Author: Olof Johansson <[email protected]>
Date:   Wed Sep 24 11:42:38 2014 -0700

    drivers/soc: ti: fix build break with modules
    
    Fixes below build break by not switching to stubs when the driver is a module:
    
    drivers/soc/ti/knav_dma.c:418:7: error: redefinition of 'knav_dma_open_channel'
     void *knav_dma_open_channel(struct device *dev, const char *name,
           ^
    In file included from drivers/soc/ti/knav_dma.c:26:0:
    include/linux/soc/ti/knav_dma.h:165:21: note: previous definition of 'knav_dma_open_channel' was here
     static inline void *knav_dma_open_channel(struct device *dev, const char *name,
                         ^
    
    Cc: Santosh Shilimkar <[email protected]>
    Signed-off-by: Olof Johansson <[email protected]>

commit 2d9251e3501356ceb44444a8f9a393b57163dc6a
Author: Matthias Brugger <[email protected]>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: multi_v7_defconfig: Enable Mediatek platform
    
    Enable Mediatek platform support for multi_v7_defconfig.
    
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Olof Johansson <[email protected]>

commit d66820853251e8a9b53125a95a773e482cd79136
Author: Matthias Brugger <[email protected]>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: mediatek: Add earlyprintk support for mt6589
    
    Enable low-level debug for Mediatek mt6589 SoC on UART0.
    
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Olof Johansson <[email protected]>

commit 7e9b2828f25ec156623da0c2156604066de5514d
Author: Matthias Brugger <[email protected]>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: dts: mt6589: Change compatible string for GIC
    
    This patch changes the compatible string of the GIC to the
    new "arm,cortex-a7-gic" which does reflect the actual hardware.
    
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Olof Johansson <[email protected]>

commit 6e9cb2633698ddadd2493b3793dbc9723f570538
Author: Matthias Brugger <[email protected]>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: dts: mediatek: Add compatible property for aquaris5
    
    Add the missing 'compatible' property to device tree root node of
    
     - mt6589-aquaris5.dts
    
    and document the new values.
    
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Olof Johansson <[email protected]>

commit d82df11466df3e0934c7e7aa2f5e08c284e1fd9d
Author: Matthias Brugger <[email protected]>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: dts: mt6589-aquaris5: Add boot argument earlyprintk
    
    Add boot argument for earlyprintk to the aquaris5 device tree file.
    
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Olof Johansson <[email protected]>

commit 510f1d72e526e776243397142cbcd459dd2a2efa
Author: Matthias Brugger <[email protected]>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: dts: mt6589: Fix typo in GIC unit address
    
    This changes the unit address of the gic node to it's first register area.
    
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Olof Johansson <[email protected]>

commit 995425883e4087a4bfd61d12e442089d1201fc5c
Author: Matthias Brugger <[email protected]>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: dts: Build dtb for Mediatek board
    
    This allows the "make dtbs" to build the aquaris5 dtb for the Mediatek
    SoC.
    
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Olof Johansson <[email protected]>

commit 00e978180b1fa211c30642139149ea448ff06c55
Author: Pawel Moll <[email protected]>
Date:   Mon Sep 15 15:33:48 2014 +0100

    bus: arm-ccn: Fix spurious warning message
    
    Because CCN's cycle counter always runs, it will generate
    an interrupt on overflow even if the relevant perf event
    was not requested, causing a spurious warning message.
    
    Fixed now by warning on only normal counter unwanted
    overflows. Also cleaning the overflow mask at init now,
    not to warn on event previously requested by firmware.
    
    Signed-off-by: Pawel Moll <[email protected]>
    Signed-off-by: Olof Johansson <[email protected]>

commit 94e57fea62020dbf6e5d0093eabcd28366e86044
Author: Francesco Ruggeri <[email protected]>
Date:   Wed Sep 24 10:12:41 2014 -0700

    PCI: Move PCI_VENDOR_ID_VMWARE to pci_ids.h
    
    Move PCI_VENDOR_ID_VMWARE from device-specific files to pci_ids.h.
    It is useful to always have access to it, especially when accessing
    subsystem_vendor_id on emulated devices.
    
    [bhelgaas: keep pci_ids.h sorted and use lower-case hex]
    Signed-off-by: Francesco Ruggeri <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit 17497acbdce9506fd6a75115dee4ab80c3cc5ee5
Author: Tejun Heo <[email protected]>
Date:   Wed Sep 24 13:31:50 2014 -0400

    blk-mq, percpu_ref: start q->mq_usage_counter in atomic mode
    
    blk-mq uses percpu_ref for its usage counter which tracks the number
    of in-flight commands and used to synchronously drain the queue on
    freeze.  percpu_ref shutdown takes measureable wallclock time as it
    involves a sched RCU grace period.  This means that draining a blk-mq
    takes measureable wallclock time.  One would think that this shouldn't
    matter as queue shutdown should be a rare event which takes place
    asynchronously w.r.t. userland.
    
    Unfortunately, SCSI probing involves synchronously setting up and then
    tearing down a lot of request_queues back-to-back for non-existent
    LUNs.  This means that SCSI probing may take above ten seconds when
    scsi-mq is used.
    
      [    0.949892] scsi host0: Virtio SCSI HBA
      [    1.007864] scsi 0:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    1.1. PQ: 0 ANSI: 5
      [    1.021299] scsi 0:0:1:0: Direct-Access     QEMU     QEMU HARDDISK    1.1. PQ: 0 ANSI: 5
      [    1.520356] tsc: Refined TSC clocksource calibration: 2491.910 MHz
    
      <stall>
    
      [   16.186549] sd 0:0:0:0: Attached scsi generic sg0 type 0
      [   16.190478] sd 0:0:1:0: Attached scsi generic sg1 type 0
      [   16.194099] osd: LOADED open-osd 0.2.1
      [   16.203202] sd 0:0:0:0: [sda] 31457280 512-byte logical blocks: (16.1 GB/15.0 GiB)
      [   16.208478] sd 0:0:0:0: [sda] Write Protect is off
      [   16.211439] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
      [   16.218771] sd 0:0:1:0: [sdb] 31457280 512-byte logical blocks: (16.1 GB/15.0 GiB)
      [   16.223264] sd 0:0:1:0: [sdb] Write Protect is off
      [   16.225682] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    
    This is also the reason why request_queues start in bypass mode which
    is ended on blk_register_queue() as shutting down a fully functional
    queue also involves a RCU grace period and the queues for non-existent
    SCSI devices never reach registration.
    
    blk-mq basically needs to do the same thing - start the mq in a
    degraded mode which is faster to shut down and then make it fully
    functional only after the queue reaches registration.  percpu_ref
    recently grew facilities to force atomic operation until explicitly
    switched to percpu mode, which can be used for this purpose.  This
    patch makes blk-mq initialize q->mq_usage_counter in atomic mode and
    switch it to percpu mode only once blk_register_queue() is reached.
    
    Note that this issue was previously worked around by 0a30288da1ae
    ("blk-mq, percpu_ref: implement a kludge for SCSI blk-mq stall during
    probe") for v3.17.  The temp fix was reverted in preparation of adding
    persistent atomic mode to percpu_ref by 9eca80461a45 ("Revert "blk-mq,
    percpu_ref: implement a kludge for SCSI blk-mq stall during probe"").
    This patch and the prerequisite percpu_ref changes will be merged
    during v3.18 devel cycle.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reported-by: Christoph Hellwig <[email protected]>
    Link: http://lkml.kernel.org/g/[email protected]
    Fixes: add703fda981 ("blk-mq: use percpu_ref for mq usage count")
    Reviewed-by: Kent Overstreet <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Johannes Weiner <[email protected]>

commit e4de4d412fc0d07f820906dcd70ede06dad312e2
Author: Olof Johansson <[email protected]>
Date:   Wed Sep 24 10:34:06 2014 -0700

    ARM: at91: Fix bad conflict resolution in board-dt-sama5.c
    
    Signed-off-by: Olof Johansson <[email protected]>

commit 3c9703a87bdda1fef221ab0957a3ec2a2126f129
Author: Olof Johansson <[email protected]>
Date:   Wed Sep 24 10:32:20 2014 -0700

    Revert "ARM: make arrays containing machine compatible strings const"
    
    I dropped it from next/cleanup, doing a revert on for-next instead of
    rebuilding the branch.
    
    This reverts commit fbce9bc876ab2c905f1f82a78bc25745e98760d9.

commit 1cae13e75b7a7848c03138636d4eb8d8a5054dd5
Author: Tejun Heo <[email protected]>
Date:   Wed Sep 24 13:31:50 2014 -0400

    percpu_ref: make INIT_ATOMIC and switch_to_atomic() sticky
    
    Currently, a percpu_ref which is initialized with
    PERPCU_REF_INIT_ATOMIC or switched to atomic mode via
    switch_to_atomic() automatically reverts to percpu mode on the first
    percpu_ref_reinit().  This makes the atomic mode difficult to use for
    cases where a percpu_ref is used as a persistent on/off switch which
    may be cycled multiple times.
    
    This patch makes such atomic state sticky so that it survives through
    kill/reinit cycles.  After this patch, atomic state is cleared only by
    an explicit percpu_ref_switch_to_percpu() call.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Kent Overstreet <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Johannes Weiner <[email protected]>

commit 2aad2a86f6685c10360ec8a5a55eb9ab7059cb72
Author: Tejun Heo <[email protected]>
Date:   Wed Sep 24 13:31:50 2014 -0400

    percpu_ref: add PERCPU_REF_INIT_* flags
    
    With the recent addition of percpu_ref_reinit(), percpu_ref now can be
    used as a persistent switch which can be turned on and off repeatedly
    where turning off maps to killing the ref and waiting for it to drain;
    however, there currently isn't a way to initialize a percpu_ref in its
    off (killed and drained) state, which can be inconvenient for certain
    persistent switch use cases.
    
    Similarly, percpu_ref_switch_to_atomic/percpu() allow dynamic
    selection of operation mode; however, currently a newly initialized
    percpu_ref is always in percpu mode making it impossible to avoid the
    latency overhead of switching to atomic mode.
    
    This patch adds @flags to percpu_ref_init() and implements the
    following flags.
    
    * PERCPU_REF_INIT_ATOMIC	: start ref in atomic mode
    * PERCPU_REF_INIT_DEAD		: start ref killed and drained
    
    These flags should be able to serve the above two use cases.
    
    v2: target_core_tpg.c conversion was missing.  Fixed.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Kent Overstreet <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Johannes Weiner <[email protected]>

commit f47ad45784611297b699f3dffb6c7222b76afe64
Author: Tejun Heo <[email protected]>
Date:   Wed Sep 24 13:31:49 2014 -0400

    percpu_ref: decouple switching to percpu mode and reinit
    
    percpu_ref has treated the dropping of the base reference and
    switching to atomic mode as an integral operation; however, there's
    nothing inherent tying the two together.
    
    The use cases for percpu_ref have been expanding continuously.  While
    the current init/kill/reinit/exit model can cover a lot, the coupling
    of kill/reinit with atomic/percpu mode switching is turning out to be
    too restrictive for use cases where many percpu_refs are created and
    destroyed back-to-back with only some of them reaching extended
    operation.  The coupling also makes implementing always-atomic debug
    mode difficult.
    
    This patch separates out percpu mode switching into
    percpu_ref_switch_to_percpu() and reimplements percpu_ref_reinit() on
    top of it.
    
    * DEAD still requires ATOMIC.  A dead ref can't be switched to percpu
      mode w/o going through reinit.
    
    v2: __percpu_ref_switch_to_percpu() was missing static.  Fixed.
        Reported by Fengguang aka kbuild test robot.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Kent Overstreet <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Johannes Weiner <[email protected]>
    Cc: kbuild test robot <[email protected]>

commit 490c79a65708873228cf114cf00e32c204e4e907
Author: Tejun Heo <[email protected]>
Date:   Wed Sep 24 13:31:49 2014 -0400

    percpu_ref: decouple switching to atomic mode and killing
    
    percpu_ref has treated the dropping of the base reference and
    switching to atomic mode as an integral operation; however, there's
    nothing inherent tying the two together.
    
    The use cases for percpu_ref have been expanding continuously.  While
    the current init/kill/reinit/exit model can cover a lot, the coupling
    of kill/reinit with atomic/percpu mode switching is turning out to be
    too restrictive for use cases where many percpu_refs are created and
    destroyed back-to-back with only some of them reaching extended
    operation.  The coupling also makes implementing always-atomic debug
    mode difficult.
    
    This patch separates out atomic mode switching into
    percpu_ref_switch_to_atomic() and reimplements
    percpu_ref_kill_and_confirm() on top of it.
    
    * The handling of __PERCPU_REF_ATOMIC and __PERCPU_REF_DEAD is now
      differentiated.  Among get/put operations, percpu_ref_tryget_live()
      is the only one which cares about DEAD.
    
    * percpu_ref_switch_to_atomic() can be called multiple times on the
      same ref.  This means that multiple @confirm_switch may get queued
      up which we can't do reliably without extra memory area.  This is
      handled by making the later invocation synchronously wait for the
      completion of the previous one.  This isn't particularly desirable
      but such synchronous waits shouldn't happen in most cases.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Kent Overstreet <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Johannes Weiner <[email protected]>

commit 27344a9017cdaff82a167827da3001a0918afdc3
Author: Tejun Heo <[email protected]>
Date:   Wed Sep 24 13:31:49 2014 -0400

    percpu_ref: add PCPU_REF_DEAD
    
    percpu_ref will be restructured so that percpu/atomic mode switching
    and reference killing are dedoupled.  In preparation, add
    PCPU_REF_DEAD and PCPU_REF_ATOMIC_DEAD which is OR of ATOMIC and DEAD.
    For now, ATOMIC and DEAD are changed together and all PCPU_REF_ATOMIC
    uses are converted to PCPU_REF_ATOMIC_DEAD without causing any
    behavior changes.
    
    percpu_ref_init() now specifies an explicit alignment when allocating
    the percpu counters so that the pointer has enough unused low bits to
    accomodate the flags.  Note that one flag was fine as min alignment
    for percpu memory is 2 bytes but two flags are already too many for
    the natural alignment of unsigned longs on archs like cris and m68k.
    
    v2: The original patch had BUILD_BUG_ON() which triggers if unsigned
        long's alignment isn't enough to accomodate the flags, which
        triggered on cris and m64k.  percpu_ref_init() updated to specify
        the required alignment explicitly.  Reported by Fengguang.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Kent Overstreet <[email protected]>
    Cc: kbuild test robot <[email protected]>

commit 9e804d1f58da1eca079f796347c1cf1d1df564e2
Author: Tejun Heo <[email protected]>
Date:   Wed Sep 24 13:31:48 2014 -0400

    percpu_ref: rename things to prepare for decoupling percpu/atomic mode switch
    
    percpu_ref will be restructured so that percpu/atomic mode switching
    and reference killing are dedoupled.  In preparation, do the following
    renames.
    
    * percpu_ref->confirm_kill	-> percpu_ref->confirm_switch
    * __PERCPU_REF_DEAD		-> __PERCPU_REF_ATOMIC
    * __percpu_ref_alive()		-> __ref_is_percpu()
    
    This patch is pure rename and doesn't introduce any functional
    changes.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Kent Overstreet <[email protected]>

commit eecc16ba9a49b05dd847a317af166a6728eb56ca
Author: Tejun Heo <[email protected]>
Date:   Wed Sep 24 13:31:48 2014 -0400

    percpu_ref: replace pcpu_ prefix with percpu_
    
    percpu_ref uses pcpu_ prefix for internal stuff and percpu_ for
    externally visible ones.  This is the same convention used in the
    percpu allocator implementation.  It works fine there but percpu_ref
    doesn't have too much internal-only stuff and scattered usages of
    pcpu_ prefix are confusing than helpful.
    
    This patch replaces all pcpu_ prefixes with percpu_.  This is pure
    rename and there's no functional change.  Note that PCPU_REF_DEAD is
    renamed to __PERCPU_REF_DEAD to signify that the flag is internal.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Kent Overstreet <[email protected]>

commit 6251f9976af7656b6970a8820153f356430f5de2
Author: Tejun Heo <[email protected]>
Date:   Wed Sep 24 13:31:48 2014 -0400

    percpu_ref: minor code and comment updates
    
    * Some comments became stale.  Updated.
    * percpu_ref_tryget() unnecessarily initializes @ret.  Removed.
    * A blank line removed from percpu_ref_kill_rcu().
    * Explicit function name in a WARN format string replaced with __func__.
    * WARN_ON() in percpu_ref_reinit() converted to WARN_ON_ONCE().
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Kent Overstreet <[email protected]>

commit a2237370194484ee6aeeff04b617e4b14d178966
Author: Tejun Heo <[email protected]>
Date:   Wed Sep 24 13:31:48 2014 -0400

    percpu_ref: relocate percpu_ref_reinit()
    
    percpu_ref is gonna go through restructuring.  Move
    percpu_ref_reinit() after percpu_ref_kill_and_confirm().  This will
    make later changes easier to follow and result in cleaner
    organization.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Reviewed-by: Kent Overstreet <[email protected]>

commit 1aafa57340c6d906a285d7823e0fe68696c1ae07
Author: Wei Xu <[email protected]>
Date:   Wed Sep 24 17:07:48 2014 +0800

    ARM: hisi: Fix platmcpm compilation when ARMv6 is selected
    
    When compiling with "ARCH=arm" and "allmodconfig",
    with commit: 9cdc99919a95e8b54c1998b65bb1bfdabd47d27b [2/7] ARM: hisi: enable MCPM implementation
    we will get:
    
       /tmp/cc6DjYjT.s: Assembler messages:
       /tmp/cc6DjYjT.s:63: Error: selected processor does not support ARM mode `ubfx r1,r0,#8,#8'
       /tmp/cc6DjYjT.s:761: Error: selected processor does not support ARM mode `isb '
       /tmp/cc6DjYjT.s:762: Error: selected processor does not support ARM mode `dsb '
       /tmp/cc6DjYjT.s:769: Error: selected processor does not support ARM mode `isb '
       /tmp/cc6DjYjT.s:775: Error: selected processor does not support ARM mode `isb '
       /tmp/cc6DjYjT.s:776: Error: selected processor does not support ARM mode `dsb '
       /tmp/cc6DjYjT.s:795: Error: selected processor does not support ARM mode `isb '
       /tmp/cc6DjYjT.s:801: Error: selected processor does not support ARM mode `isb '
       /tmp/cc6DjYjT.s:802: Error: selected processor does not support ARM mode `dsb '
    
    Fix platmcpm compilation when ARMv6 is selected.
    
    Signed-off-by: Wei Xu <[email protected]>
    Signed-off-by: Olof Johansson <[email protected]>

commit 495aa2e1facebf770224c33aae2a01541889e54e
Author: Liviu Dudau <[email protected]>
Date:   Tue Sep 23 20:01:14 2014 +0100

    arm64: Add architectural support for PCI
    
    Use the generic PCI domain and OF functions to provide support for PCI
    on arm64.
    
    [bhelgaas: Change comments to use generic PCI, not just PCIe.  Nothing at
    this level is PCIe-specific.]
    Signed-off-by: Liviu Dudau <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Acked-by: Catalin Marinas <[email protected]>

commit b766eafe68281a12169f9eb8c06fd80d2e7897d7
Author: Liviu Dudau <[email protected]>
Date:   Tue Sep 23 20:01:13 2014 +0100

    PCI: Add pci_remap_iospace() to map bus I/O resources
    
    Add pci_remap_iospace() to map bus I/O resources into the CPU virtual
    address space.  Architectures with special needs may provide their own
    version, but most should be able to use this one.
    
    This function is useful for PCI host bridge drivers that need to map the
    PCI I/O resources into virtual memory space.
    
    [bhelgaas: phys_addr description, drop temporary "err" variable]
    Signed-off-by: Liviu Dudau <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Rob Herring <[email protected]>
    Reviewed-by: Catalin Marinas <[email protected]>
    CC: Arnd Bergmann <[email protected]>

commit 5a4f662d44116022e3378b32a1a79b718e110096
Author: Liviu Dudau <[email protected]>
Date:   Tue Sep 23 20:01:12 2014 +0100

    PCI: Assign unassigned bus resources in pci_scan_root_bus()
    
    If the firmware has not assigned all the bus resources and we are not just
    probing the PCI buses, it makes sense to assign the unassigned resources
    in pci_scan_root_bus().
    
    Signed-off-by: Liviu Dudau <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    CC: Arnd Bergmann <[email protected]>
    CC: Jason Gunthorpe <[email protected]>
    CC: Rob Herring <[email protected]>

commit 07428b62addb624a3b51b6e8a213fec9b97dbfd0
Author: Liviu Dudau <[email protected]>
Date:   Wed Sep 24 11:27:33 2014 -0600

    of/pci: Add support for parsing PCI host bridge resources from DT
    
    Provide a function to parse the PCI DT ranges that can be used to create a
    pci_host_bridge structure together with its associated bus.
    
    Signed-off-by: Liviu Dudau <[email protected]>
    [make io_base parameter optional]
    Signed-off-by: Robert Richter <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    CC: Arnd Bergmann <[email protected]>
    CC: Grant Likely <[email protected]>
    CC: Rob Herring <[email protected]>
    CC: Catalin Marinas <[email protected]>

commit 9eca80461a45177e456219a9cd944c27675d6512
Author: Tejun Heo <[email protected]>
Date:   Wed Sep 24 13:07:33 2014 -0400

    Revert "blk-mq, percpu_ref: implement a kludge for SCSI blk-mq stall during probe"
    
    This reverts commit 0a30288da1aec914e158c2d7a3482a85f632750f, which
    was a temporary fix for SCSI blk-mq stall issue.  The following
    patches will fix the issue properly by introducing atomic mode to
    percpu_ref.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Cc: Kent Overstreet <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Christoph Hellwig <[email protected]>

commit 83417b202bf5aa2cd82637aa81aa9f065cfe5f21
Author: Wolfram Sang <[email protected]>
Date:   Mon Sep 22 19:41:00 2014 +0200

    i2c: move acpi code back into the core
    
    Commit 5d98e61d337c ("I2C/ACPI: Add i2c ACPI operation region support")
    renamed the i2c-core module. This may cause regressions for
    distributions, so put the ACPI code back into the core.
    
    Reported-by: Jean Delvare <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Cc: Mika Westerberg <[email protected]>
    Cc: Lan Tianyu <[email protected]>

commit 964356938fcd3c0001a786f55b9f0a0fbe47656a
Author: Andreas Werner <[email protected]>
Date:   Wed Aug 27 19:53:06 2014 +0200

    hwmon: (menf21bmc) Introduce MEN14F021P00 BMC HWMON driver
    
    Added driver to support the 14F021P00 BMC Hardware Monitoring.
    The BMC is a Board Management Controller including monitoring of the
    board voltages.
    
    Signed-off-by: Andreas Werner <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 38433639af915deeb0b0e28462dd740ce57b72fd
Author: Andreas Werner <[email protected]>
Date:   Wed Aug 27 19:52:36 2014 +0200

    leds: leds-menf21bmc: Introduce MEN 14F021P00 BMC LED driver
    
    Added driver to support the 14F021P00 BMC LEDs.
    The BMC is a Board Management Controller including four LEDs which
    can be switched on and off.
    
    Signed-off-by: Andreas Werner <[email protected]>
    Acked-by: Bryan Wu <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 5033263992eece84e19946d2cab940c86ec862ba
Author: Andreas Werner <[email protected]>
Date:   Wed Aug 27 19:52:06 2014 +0200

    watchdog: menf21bmc_wdt: Introduce MEN 14F021P00 BMC Watchdog driver
    
    Added driver to support the 14F021P00 BMC Watchdog.
    The BMC is a Board Management Controller including watchdog functionality.
    
    Signed-off-by: Andreas Werner <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit d6cc1f5824cbca392d099f3bb0c441efd9e54de9
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Sep 12 08:54:00 2014 +0200

    Documentation: charger: max14577: Document exported sysfs entry
    
    Document the 'fast charge timer' setting exported by max14577 driver
    through sysfs entry.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Andrew Morton <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 8d70d68d7a1b3082ca5a3808be18103a83ae348d
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Sep 12 08:53:59 2014 +0200

    devicetree: mfd: max14577: Add device tree bindings document
    
    Add document describing device tree bindings for MAX14577 MFD
    drivers: MFD core, extcon, regulator and charger.
    
    Both MAX14577 and MAX77836 chipsets are documented.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Tomasz Figa <[email protected]>
    Acked-by: Andrew Morton <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 2c33e9296202cd11bf2e2f801b69ffba0953748a
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Sep 12 08:53:58 2014 +0200

    power: max17040: Add ID for MAX77836 Fuel Gauge block
    
    MAX77836 has the same Fuel Gauge as MAX17040/17048. The max17040 driver
    can be safely re-used. The patch adds MAX77836 device to the array of
    i2c_device_id. Additionally it removes the id associated with MAX17040
    device as the value is not used.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Andrew Morton <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit e30110e9c96f48aea01abc3e6dfadb369cbafec3
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Sep 12 08:53:57 2014 +0200

    charger: max14577: Configure battery-dependent settings from DTS and sysfs
    
    Remove hard-coded values for:
     - Fast Charge current,
     - End Of Charge current,
     - Fast Charge timer,
     - Overvoltage Protection Threshold,
     - Battery Constant Voltage,
    and use DTS or sysfs to configure them. This allows using the max14577 charger
    driver with different batteries.
    
    Now the charger driver requires valid configuration data from DTS. In
    case of wrong configuration data it fails during probe.
    
    The fast charge timer is configured through sysfs entry.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Andrew Morton <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit b8f139f68f2099b7f8b4ef470a1e53210e3aa025
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Sep 12 08:53:56 2014 +0200

    regulator/mfd: max14577: Export symbols for calculating charger current
    
    This patch prepares for changing the max14577 charger driver to allow
    configuring battery-dependent settings from DTS.
    
    The patch moves from regulator driver to MFD core driver and exports:
     - function for calculating register value for charger's current;
     - table of limits for chargers (MAX14577, MAX77836).
    
    Previously they were used only by the max14577 regulator driver. In next
    patch the charger driver will use them as well. Exporting them will
    reduce unnecessary code duplication.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Mark Brown <[email protected]>
    Acked-by: Andrew Morton <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 3682a8ee87f9107253e51733f42da10160ce41e3
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Sep 12 08:53:55 2014 +0200

    charger: max14577: Add support for MAX77836 charger
    
    Add support for MAX77836 charger to the max14577 driver. The MAX77836
    charger is almost the same as 14577 model except:
     - No dead-battery detection;
     - Support for special charger (like in MAX77693);
     - Support for DX over-voltage protection (like in MAX77693);
     - Lower values of charging current (two times lower current for
       slow/fast charge, much lower EOC current);
     - Slightly different values in ChgTyp field of STATUS2 register. On
       MAX14577 0x6 is reserved and 0x7 dead battery. On the MAX77836 the
       0x6 means special charger and 0x7 is reserved. Regardless of these
       differences the driver maps them to one enum max14577_muic_charger_type.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Andrew Morton <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 2f4096e311ef0922c42cbf7bc5df44efb3aff716
Author: Quentin Lambert <[email protected]>
Date:   Sun Sep 7 20:04:28 2014 +0200

    PCI: Remove assignment from complicated "if" conditions
    
    The modifications effectively change the value of len_tmp
    in the case where the first condition is not met.
    
    Signed-off-by: Quentin Lambert <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit 79e50e72986c9fcb06d707ce587cfd24fefa33e3
Author: Quentin Lambert <[email protected]>
Date:   Sun Sep 7 20:03:32 2014 +0200

    PCI: Remove assignment from "if" conditions
    
    The following Coccinelle semantic patch was used to find and correct cases
    of assignments in "if" conditions:
    
    @@
    expression var, expr;
    statement S;
    @@
    
    + var = expr;
      if(
    - (var = expr)
    + var
      ) S
    
    Signed-off-by: Quentin Lambert <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit 656f978f9af9d8d77436e8159f51f7aa1e673309
Author: Quentin Lambert <[email protected]>
Date:   Sun Sep 7 20:02:47 2014 +0200

    PCI: Remove unnecessary curly braces
    
    Remove curly braces in simple "if" cases.
    
    No functional change.
    
    Signed-off-by: Quentin Lambert <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit e0c524049f8279d00d2fbd4748b03234a2726fdd
Author: Santosh Shilimkar <[email protected]>
Date:   Thu Jul 10 11:30:08 2014 -0400

    MAINTAINERS: Add Keystone Multicore Navigator drivers entry
    
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 88139ed030583557751e279968e13e892ae10825
Author: Santosh Shilimkar <[email protected]>
Date:   Sun Mar 30 17:29:04 2014 -0400

    soc: ti: add Keystone Navigator DMA support
    
    The Keystone Navigator DMA driver sets up the dma channels and flows for
    the QMSS(Queue Manager SubSystem) who triggers the actual data movements
    across clients using destination queues. Every client modules like
    NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO
    Engines has its own instance of packet dma hardware. QMSS has also
    an internal packet DMA module which is used as an infrastructure
    DMA with zero copy.
    
    Initially this driver was proposed as DMA engine driver but since the
    hardware is not typical DMA engine and hence doesn't comply with typical
    DMA engine driver needs, that approach was naked. Link to that
    discussion -
    	https://lkml.org/lkml/2014/3/18/340
    
    As aligned, now we pair the Navigator DMA with its companion Navigator
    QMSS subsystem driver.
    
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Kumar Gala <[email protected]>
    Cc: Olof Johansson <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Grant Likely <[email protected]>
    Cc: Rob Herring <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Signed-off-by: Sandeep Nair <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 8172296d8717be1951da4bb4feb2700a60e8cdde
Author: Santosh Shilimkar <[email protected]>
Date:   Sun Mar 30 17:29:04 2014 -0400

    Documentation: dt: soc: add Keystone Navigator DMA bindings
    
    The Keystone Navigator DMA driver sets up the dma channels and flows for
    the QMSS(Queue Manager SubSystem) who triggers the actual data movements
    across clients using destination queues. Every client modules like
    NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO
    Engines has its own instance of packet dma hardware. QMSS has also
    an internal packet DMA module which is used as an infrastructure
    DMA with zero copy.
    
    Initially this driver was proposed as DMA engine driver but since the
    hardware is not typical DMA engine and hence doesn't comply with typical
    DMA engine driver needs, that approach was naked. Link to that
    discussion -
    	https://lkml.org/lkml/2014/3/18/340
    
    As aligned, now we pair the Navigator DMA with its companion Navigator
    QMSS subsystem driver.
    
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Kumar Gala <[email protected]>
    Cc: Olof Johansson <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Grant Likely <[email protected]>
    Cc: Rob Herring <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Signed-off-by: Sandeep Nair <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 41f93af900a20d1a0a358b522b5129c89677e9dc
Author: Sandeep Nair <[email protected]>
Date:   Fri Feb 28 10:47:50 2014 -0500

    soc: ti: add Keystone Navigator QMSS driver
    
    The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
    the main hardware sub system which forms the backbone of the Keystone
    Multi-core Navigator. QMSS consist of queue managers, packed-data structure
    processors(PDSP), linking RAM, descriptor pools and infrastructure
    Packet DMA.
    
    The Queue Manager is a hardware module that is responsible for accelerating
    management of the packet queues. Packets are queued/de-queued by writing or
    reading descriptor address to a particular memory mapped location. The PDSPs
    perform QMSS related functions like accumulation, QoS, or event management.
    Linking RAM registers are used to link the descriptors which are stored in
    descriptor RAM. Descriptor RAM is configurable as internal or external memory.
    
    The QMSS driver manages the PDSP setups, linking RAM regions,
    queue pool management (allocation, push, pop and notify) and descriptor
    pool management. The specifics on the device tree bindings for
    QMSS can be found in:
    	Documentation/devicetree/bindings/soc/keystone-navigator-qmss.txt
    
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Kumar Gala <[email protected]>
    Cc: Olof Johansson <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Grant Likely <[email protected]>
    Cc: Rob Herring <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Signed-off-by: Sandeep Nair <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit a4dfb8c41043dd6c2b9defbe846c44389c4b6f02
Author: Sandeep Nair <[email protected]>
Date:   Fri Feb 28 10:47:50 2014 -0500

    Documentation: dt: soc: add Keystone Navigator QMSS bindings
    
    The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
    the main hardware sub system which forms the backbone of the Keystone
    Multi-core Navigator. QMSS consist of queue managers, packed-data structure
    processors(PDSP), linking RAM, descriptor pools and infrastructure
    Packet DMA.
    
    The Queue Manager is a hardware module that is responsible for accelerating
    management of the packet queues. Packets are queued/de-queued by writing or
    reading descriptor address to a particular memory mapped location. The PDSPs
    perform QMSS related functions like accumulation, QoS, or event management.
    Linking RAM registers are used to link the descriptors which are stored in
    descriptor RAM. Descriptor RAM is configurable as internal or external memory.
    
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Kumar Gala <[email protected]>
    Cc: Olof Johansson <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Grant Likely <[email protected]>
    Cc: Rob Herring <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Signed-off-by: Sandeep Nair <[email protected]>
    Signed-off-by: Santosh Shilimkar <[email protected]>

commit 382a9c9adc1cd540f5b714b65db315fc1c0b553d
Author: Quentin Lambert <[email protected]>
Date:   Sun Sep 7 20:02:04 2014 +0200

    PCI: Add space before open parenthesis
    
    Add space before open parenthesis as is conventional.
    
    No functional change.
    
    [bhelgaas: fix a few more in ibmphp, shpchp]
    Signed-off-by: Quentin Lambert <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit fe6ce32189136370b3d236d1c32ab812b93cd0d8
Author: Yijing Wang <[email protected]>
Date:   Wed Sep 24 11:09:59 2014 +0800

    PCI/MSI: Rename __read_msi_msg() to read_msi_msg()
    
    Rename __read_msi_msg() to read_msi_msg().
    
    No functional change.
    
    Signed-off-by: Yijing Wang <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit c2eb2dc3461e522d6452e1f74e36194633d4db0d
Author: Yijing Wang <[email protected]>
Date:   Wed Sep 24 11:09:53 2014 +0800

    PCI/MSI: Remove unused read_msi_msg()
    
    Now no one uses read_msi_msg(), so remove it.
    
    No functional change.
    
    Signed-off-by: Yijing Wang <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit 11c013fd8afbc7c6b2e15608ed5fc2c249552998
Author: Yijing Wang <[email protected]>
Date:   Wed Sep 24 11:09:45 2014 +0800

    MSI/powerpc: Use __read_msi_msg() instead of read_msi_msg()
    
    rtas_setup_msi_irqs() already has the struct msi_desc pointer required by
    __read_msi_msg(), so call it directly instead of having read_msi_msg() look
    it up from the IRQ.
    
    No functional change.
    
    [bhelgaas: changelog]
    Signed-off-by: Yijing Wang <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Acked-by: Michael Ellerman <[email protected]>
    CC: Benjamin Herrenschmidt <[email protected]>
    CC: [email protected]

commit eeeda4cd06e828b331b15741a204ff9f5874d28d
Author: Ben Hutchings <[email protected]>
Date:   Wed Sep 24 13:30:12 2014 +0100

    x86/relocs: Make per_cpu_load_addr static
    
    per_cpu_load_addr is only used for 64-bit relocations, but is
    declared in both configurations of relocs.c - with different
    types.  This has undefined behaviour in general.  GNU ld is
    documented to use the larger size in this case, but other tools
    may differ and some warn about this.
    
    References: https://bugs.debian.org/748577
    Reported-by: Michael Tautschnig <[email protected]>
    Signed-off-by: Ben Hutchings <[email protected]>
    Cc: [email protected]
    Cc: Linus Torvalds <[email protected]>
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ingo Molnar <[email protected]>

commit 212be3b2320bcf33eff648bc4e1f0edbf4d90acf
Author: Oleg Nesterov <[email protected]>
Date:   Sun Sep 21 20:42:32 2014 +0200

    x86/lib/Makefile: Remove the unnecessary "+= thunk_64.o"
    
    Trivial. We have "lib-y += thunk_$(BITS).o" at the start, no
    need to add thunk_64.o if !CONFIG_X86_32.
    
    Signed-off-by: Oleg Nesterov <[email protected]>
    Acked-by: Andy Lutomirski <[email protected]>
    Cc: Denys Vlasenko <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ingo Molnar <[email protected]>

commit 0ad6e3c5199be12c9745da8f8b9e3c9f8066c235
Author: Oleg Nesterov <[email protected]>
Date:   Sun Sep 21 20:41:53 2014 +0200

    x86: Speed up ___preempt_schedule*() by using THUNK helpers
    
    ___preempt_schedule() does SAVE_ALL/RESTORE_ALL but this is
    suboptimal, we do not need to save/restore the callee-saved
    register. And we already have arch/x86/lib/thunk_*.S which
    implements the similar asm wrappers, so it makes sense to
    redefine ___preempt_schedule() as "THUNK ..." and remove
    preempt.S altogether.
    
    Signed-off-by: Oleg Nesterov <[email protected]>
    Reviewed-by: Andy Lutomirski <[email protected]>
    Cc: Denys Vlasenko <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ingo Molnar <[email protected]>

commit 03bd4e1f7265548832a76e7919a81f3137c44fd1
Author: Wanpeng Li <[email protected]>
Date:   Wed Sep 24 16:38:05 2014 +0800

    sched: Fix unreleased llc_shared_mask bit during CPU hotplug
    
    The following bug can be triggered by hot adding and removing a large number of
    xen domain0's vcpus repeatedly:
    
    	BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [..] find_busiest_group
    	PGD 5a9d5067 PUD 13067 PMD 0
    	Oops: 0000 [#3] SMP
    	[...]
    	Call Trace:
    	load_balance
    	? _raw_spin_unlock_irqrestore
    	idle_balance
    	__schedule
    	schedule
    	schedule_timeout
    	? lock_timer_base
    	schedule_timeout_uninterruptible
    	msleep
    	lock_device_hotplug_sysfs
    	online_store
    	dev_attr_store
    	sysfs_write_file
    	vfs_write
    	SyS_write
    	system_call_fastpath
    
    Last level cache shared mask is built during CPU up and the
    build_sched_domain() routine takes advantage of it to setup
    the sched domain CPU topology.
    
    However, llc_shared_mask is not released during CPU disable,
    which leads to an invalid sched domainCPU topology.
    
    This patch fix it by releasing the llc_shared_mask correctly
    during CPU disable.
    
    Yasuaki also reported that this can happen on real hardware:
    
      https://lkml.org/lkml/2014/7/22/1018
    
    His case is here:
    
    	==
    	Here is an example on my system.
    	My system has 4 sockets and each socket has 15 cores and HT is
    	enabled. In this case, each core of sockes is numbered as
    	follows:
    
    		 | CPU#
    	Socket#0 | 0-14 , 60-74
    	Socket#1 | 15-29, 75-89
    	Socket#2 | 30-44, 90-104
    	Socket#3 | 45-59, 105-119
    
    	Then llc_shared_mask of CPU#30 has 0x3fff80000001fffc0000000.
    
    	It means that last level cache of Socket#2 is shared with
    	CPU#30-44 and 90-104.
    
    	When hot-removing socket#2 and #3, each core of sockets is
    	numbered as follows:
    
    		 | CPU#
    	Socket#0 | 0-14 , 60-74
    	Socket#1 | 15-29, 75-89
    
    	But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30
    	remains having 0x3fff80000001fffc0000000.
    
    	After that, when hot-adding socket#2 and #3, each core of
    	sockets is numbered as follows:
    
    		 | CPU#
    	Socket#0 | 0-14 , 60-74
    	Socket#1 | 15-29, 75-89
    	Socket#2 | 30-59
    	Socket#3 | 90-119
    
    	Then llc_shared_mask of CPU#30 becomes
    	0x3fff8000fffffffc0000000. It means that last level cache of
    	Socket#2 is shared with CPU#30-59 and 90-104. So the mask has
    	the wrong value.
    
    Signed-off-by: Wanpeng Li <[email protected]>
    Tested-by: Linn Crosetto <[email protected]>
    Reviewed-by: Borislav Petkov <[email protected]>
    Reviewed-by: Toshi Kani <[email protected]>
    Reviewed-by: Yasuaki Ishimatsu <[email protected]>
    Cc: <[email protected]>
    Cc: David Rientjes <[email protected]>
    Cc: Prarit Bhargava <[email protected]>
    Cc: Steven Rostedt <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ingo Molnar <[email protected]>

commit 24832b4de315ad00e5430a53772750dfcf18514d
Author: Minghuan Lian <[email protected]>
Date:   Tue Sep 23 22:28:59 2014 +0800

    PCI: designware: Add get_msi_data() to pcie_host_ops
    
    Add a struct pcie_host_ops .get_msi_data() method for platforms to return
    their special MSI message data.
    
    Signed-off-by: Minghuan Lian <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Acked-by: Mohit KUMAR <[email protected]>

commit ee1b5b165c0a2f04d2107e634e51f05d0eb107de
Author: Bryan O'Donoghue <[email protected]>
Date:   Wed Sep 24 00:26:24 2014 +0100

    x86/intel/quark: Switch off CR4.PGE so TLB flush uses CR3 instead
    
    Quark x1000 advertises PGE via the standard CPUID method
    PGE bits exist in Quark X1000's PTEs. In order to flush
    an individual PTE it is necessary to reload CR3 irrespective
    of the PTE.PGE bit.
    
    See Quark Core_DevMan_001.pdf section 6.4.11
    
    This bug was fixed in Galileo kernels, unfixed vanilla kernels are expected to
    crash and burn on this platform.
    
    Signed-off-by: Bryan O'Donoghue <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: <[email protected]>
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ingo Molnar <[email protected]>

commit 450e344e421b9f555261a2d97952d9e71d4cb082
Author: Minghuan Lian <[email protected]>
Date:   Tue Sep 23 22:28:58 2014 +0800

    PCI: designware: Rename get_msi_data() to get_msi_addr()
    
    The struct pcie_host_ops .get_msi_data() method returns the MSI message
    address.  To accurately express its purpose, rename it to .get_msi_addr().
    
    Signed-off-by: Minghuan Lian <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Acked-by: Mohit KUMAR <[email protected]>

commit 0c61ea77cceafd1134225099961c2df0866b500f
Author: Minghuan Lian <Minghuan.Lian@fre…
tom3q pushed a commit to tom3q/linux that referenced this pull request Oct 2, 2014
@akpm00 @sfrothwell
not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range-checkp…
8d76d66 
…atch-fixes

ERROR: space prohibited after that open parenthesis '('
torvalds#34: FILE: fs/proc/kcore.c:613:
+	if ( (MODULES_VADDR != VMALLOC_START) &&

ERROR: space prohibited before that close parenthesis ')'
torvalds#35: FILE: fs/proc/kcore.c:614:
+		(MODULES_END != VMALLOC_END) ) {

total: 2 errors, 0 warnings, 12 lines checked

./patches/not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range.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: Baoquan He <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Xishi Qiu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
aryabinin pushed a commit to aryabinin/linux that referenced this pull request Oct 3, 2014
@akpm00 @hnaz
not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range-checkp…
7f8b7cc 
…atch-fixes

ERROR: space prohibited after that open parenthesis '('
torvalds#34: FILE: fs/proc/kcore.c:613:
+	if ( (MODULES_VADDR != VMALLOC_START) &&

ERROR: space prohibited before that close parenthesis ')'
torvalds#35: FILE: fs/proc/kcore.c:614:
+		(MODULES_END != VMALLOC_END) ) {

total: 2 errors, 0 warnings, 12 lines checked

./patches/not-adding-modules-range-to-kcore-if-its-equal-to-vmcore-range.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: Baoquan He <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Xishi Qiu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 6, 2024
@j-c-h
l2tp: fix lockdep splat
297d325 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Aug 6, 2024
@j-c-h @intel-lab-lkp
l2tp: fix lockdep splat
6aaed6e 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 6, 2024
@j-c-h
l2tp: fix lockdep splat
760af04 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 7, 2024
@j-c-h
l2tp: fix lockdep splat
91f33b3 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 7, 2024
@j-c-h
l2tp: fix lockdep splat
e30d816 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 7, 2024
@j-c-h
l2tp: fix lockdep splat
6271b0c 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 7, 2024
@j-c-h
l2tp: fix lockdep splat
c2f0a06 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 7, 2024
@j-c-h
l2tp: fix lockdep splat
4261e0e 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 7, 2024
@j-c-h
l2tp: fix lockdep splat
656338e 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 7, 2024
@j-c-h
l2tp: fix lockdep splat
1bb0119 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 7, 2024
@j-c-h
l2tp: fix lockdep splat
a11cb78 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 8, 2024
@j-c-h
l2tp: fix lockdep splat
a4d2a29 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 8, 2024
@j-c-h
l2tp: fix lockdep splat
ee26ea1 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 8, 2024
@j-c-h
l2tp: fix lockdep splat
a8b9c7f 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 8, 2024
@j-c-h
l2tp: fix lockdep splat
261393e 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 8, 2024
@j-c-h
l2tp: fix lockdep splat
5b478d1 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 8, 2024
@j-c-h
l2tp: fix lockdep splat
15daa4e 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
kuba-moo pushed a commit to linux-netdev/testing that referenced this pull request Aug 8, 2024
@j-c-h @kuba-moo
l2tp: fix lockdep splat
86a41ea 
When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Aug 12, 2024
@j-c-h @gregkh
l2tp: fix lockdep splat
6e10aa0 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Aug 12, 2024
@j-c-h @gregkh
l2tp: fix lockdep splat
3684d44 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Aug 12, 2024
@j-c-h @gregkh
l2tp: fix lockdep splat
584ccec 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Aug 12, 2024
@j-c-h @gregkh
l2tp: fix lockdep splat
13fa54d 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Aug 13, 2024
@j-c-h @gregkh
l2tp: fix lockdep splat
6fb3200 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Kaz205 pushed a commit to Kaz205/linux that referenced this pull request Aug 14, 2024
@j-c-h @gregkh
l2tp: fix lockdep splat
405573c 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Kaz205 pushed a commit to Kaz205/linux that referenced this pull request Aug 14, 2024
@j-c-h
l2tp: fix lockdep splat
53c0fe1 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
intersectRaven pushed a commit to intersectRaven/linux that referenced this pull request Aug 14, 2024
@j-c-h @gregkh
l2tp: fix lockdep splat
977de64 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this pull request Aug 14, 2024
@j-c-h @gregkh
l2tp: fix lockdep splat
3d35a09 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Aug 15, 2024
@j-c-h @gregkh
l2tp: fix lockdep splat
207e881 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[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 Sep 4, 2024
@j-c-h @gregkh
l2tp: fix lockdep splat
8659486 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
1054009064 pushed a commit to 1054009064/linux that referenced this pull request Sep 9, 2024
@j-c-h @gregkh
l2tp: fix lockdep splat
cb85266 
[ Upstream commit 86a41ea ]

When l2tp tunnels use a socket provided by userspace, we can hit
lockdep splats like the below when data is transmitted through another
(unrelated) userspace socket which then gets routed over l2tp.

This issue was previously discussed here:
https://lore.kernel.org/netdev/[email protected]/

The solution is to have lockdep treat socket locks of l2tp tunnel
sockets separately than those of standard INET sockets. To do so, use
a different lockdep subclass where lock nesting is possible.

  ============================================
  WARNING: possible recursive locking detected
  6.10.0+ torvalds#34 Not tainted
  --------------------------------------------
  iperf3/771 is trying to acquire lock:
  ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0

  but task is already holding lock:
  ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10

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

         CPU0
         ----
    lock(slock-AF_INET/1);
    lock(slock-AF_INET/1);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  10 locks held by iperf3/771:
   #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40
   #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0
   #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260
   #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10
   torvalds#6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0
   torvalds#7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130
   torvalds#8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450
   torvalds#9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450

  stack backtrace:
  CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ torvalds#34
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <IRQ>
   dump_stack_lvl+0x69/0xa0
   dump_stack+0xc/0x20
   __lock_acquire+0x135d/0x2600
   ? srso_alias_return_thunk+0x5/0xfbef5
   lock_acquire+0xc4/0x2a0
   ? l2tp_xmit_skb+0x243/0x9d0
   ? __skb_checksum+0xa3/0x540
   _raw_spin_lock_nested+0x35/0x50
   ? l2tp_xmit_skb+0x243/0x9d0
   l2tp_xmit_skb+0x243/0x9d0
   l2tp_eth_dev_xmit+0x3c/0xc0
   dev_hard_start_xmit+0x11e/0x420
   sch_direct_xmit+0xc3/0x640
   __dev_queue_xmit+0x61c/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   __tcp_send_ack+0x1b8/0x340
   tcp_send_ack+0x23/0x30
   __tcp_ack_snd_check+0xa8/0x530
   ? srso_alias_return_thunk+0x5/0xfbef5
   tcp_rcv_established+0x412/0xd70
   tcp_v4_do_rcv+0x299/0x420
   tcp_v4_rcv+0x1991/0x1e10
   ip_protocol_deliver_rcu+0x50/0x220
   ip_local_deliver_finish+0x158/0x260
   ip_local_deliver+0xc8/0xe0
   ip_rcv+0xe5/0x1d0
   ? __pfx_ip_rcv+0x10/0x10
   __netif_receive_skb_one_core+0xce/0xe0
   ? process_backlog+0x28b/0x9f0
   __netif_receive_skb+0x34/0xd0
   ? process_backlog+0x28b/0x9f0
   process_backlog+0x2cb/0x9f0
   __napi_poll.constprop.0+0x61/0x280
   net_rx_action+0x332/0x670
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? find_held_lock+0x2b/0x80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   handle_softirqs+0xda/0x480
   ? __dev_queue_xmit+0xa2c/0x1450
   do_softirq+0xa1/0xd0
   </IRQ>
   <TASK>
   __local_bh_enable_ip+0xc8/0xe0
   ? __dev_queue_xmit+0xa2c/0x1450
   __dev_queue_xmit+0xa48/0x1450
   ? ip_finish_output2+0xf4c/0x1130
   ip_finish_output2+0x6b6/0x1130
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __ip_finish_output+0x217/0x380
   ? srso_alias_return_thunk+0x5/0xfbef5
   __ip_finish_output+0x217/0x380
   ip_output+0x99/0x120
   __ip_queue_xmit+0xae4/0xbc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? tcp_options_write.constprop.0+0xcb/0x3e0
   ip_queue_xmit+0x34/0x40
   __tcp_transmit_skb+0x1625/0x1890
   tcp_write_xmit+0x766/0x2fb0
   ? __entry_text_end+0x102ba9/0x102bad
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __might_fault+0x74/0xc0
   ? srso_alias_return_thunk+0x5/0xfbef5
   __tcp_push_pending_frames+0x56/0x190
   tcp_push+0x117/0x310
   tcp_sendmsg_locked+0x14c1/0x1740
   tcp_sendmsg+0x28/0x40
   inet_sendmsg+0x5d/0x90
   sock_write_iter+0x242/0x2b0
   vfs_write+0x68d/0x800
   ? __pfx_sock_write_iter+0x10/0x10
   ksys_write+0xc8/0xf0
   __x64_sys_write+0x3d/0x50
   x64_sys_call+0xfaf/0x1f50
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4d143af992
  Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> e9 01 cc ff ff 41 54 b8 02 00 00 0
  RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992
  RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005
  RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc
  R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0
   </TASK>

Fixes: 0b2c597 ("l2tp: close all race conditions in l2tp_tunnel_register()")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
CC: [email protected]
CC: [email protected]
Signed-off-by: James Chapman <[email protected]>
Signed-off-by: Tom Parkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@smeaime