If the system had a few memory groups and all of them were destroyed,
memcg_limited_groups_array_size has non-zero value, but all new caches
are created without memcg_params, because memcg_kmem_enabled() returns
false.

We try to enumirate child caches in a few places and all of them are
potentially dangerous.

For example my kernel is compiled with CONFIG_SLAB and it crashed when I
tryed to mount a NFS share after a few experiments with kmemcg.

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: [<ffffffff8118166a>] do_tune_cpucache 0x8a/0xd0
  PGD b942a067 PUD b999f067 PMD 0
  Oops: 0000 [#1] SMP
  Modules linked in: fscache( ) ip6table_filter ip6_tables iptable_filter ip_tables i2c_piix4 pcspkr virtio_net virtio_balloon i2c_core floppy
  CPU: 0 PID: 357 Comm: modprobe Not tainted 3.11.0-rc7  torvalds#59
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  task: ffff8800b9f98240 ti: ffff8800ba32e000 task.ti: ffff8800ba32e000
  RIP: 0010:[<ffffffff8118166a>]  [<ffffffff8118166a>] do_tune_cpucache 0x8a/0xd0
  RSP: 0018:ffff8800ba32fb70  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
  RDX: 0000000000000000 RSI: ffff8800b9f98910 RDI: 0000000000000246
  RBP: ffff8800ba32fba0 R08: 0000000000000002 R09: 0000000000000004
  R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000010
  R13: 0000000000000008 R14: 00000000000000d0 R15: ffff8800375d0200
  FS:  00007f55f1378740(0000) GS:ffff8800bfa00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 00007f24feba57a0 CR3: 0000000037b51000 CR4: 00000000000006f0
  Call Trace:
    enable_cpucache 0x49/0x100
    setup_cpu_cache 0x215/0x280
    __kmem_cache_create 0x2fa/0x450
    kmem_cache_create_memcg 0x214/0x350
    kmem_cache_create 0x2b/0x30
    fscache_init 0x19b/0x230 [fscache]
    do_one_initcall 0xfa/0x1b0
    load_module 0x1c41/0x26d0
    SyS_finit_module 0x86/0xb0
    system_call_fastpath 0x16/0x1b

Signed-off-by: Andrey Vagin <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Christoph Lameter <[email protected]>
Cc: Glauber Costa <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

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]>

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]>

commit 6f6b895 upstream.

If the system had a few memory groups and all of them were destroyed,
memcg_limited_groups_array_size has non-zero value, but all new caches
are created without memcg_params, because memcg_kmem_enabled() returns
false.

We try to enumirate child caches in a few places and all of them are
potentially dangerous.

For example my kernel is compiled with CONFIG_SLAB and it crashed when I
tryed to mount a NFS share after a few experiments with kmemcg.

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: [<ffffffff8118166a>] do_tune_cpucache 0x8a/0xd0
  PGD b942a067 PUD b999f067 PMD 0
  Oops: 0000 [#1] SMP
  Modules linked in: fscache( ) ip6table_filter ip6_tables iptable_filter ip_tables i2c_piix4 pcspkr virtio_net virtio_balloon i2c_core floppy
  CPU: 0 PID: 357 Comm: modprobe Not tainted 3.11.0-rc7  torvalds#59
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  task: ffff8800b9f98240 ti: ffff8800ba32e000 task.ti: ffff8800ba32e000
  RIP: 0010:[<ffffffff8118166a>]  [<ffffffff8118166a>] do_tune_cpucache 0x8a/0xd0
  RSP: 0018:ffff8800ba32fb70  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
  RDX: 0000000000000000 RSI: ffff8800b9f98910 RDI: 0000000000000246
  RBP: ffff8800ba32fba0 R08: 0000000000000002 R09: 0000000000000004
  R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000010
  R13: 0000000000000008 R14: 00000000000000d0 R15: ffff8800375d0200
  FS:  00007f55f1378740(0000) GS:ffff8800bfa00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 00007f24feba57a0 CR3: 0000000037b51000 CR4: 00000000000006f0
  Call Trace:
    enable_cpucache 0x49/0x100
    setup_cpu_cache 0x215/0x280
    __kmem_cache_create 0x2fa/0x450
    kmem_cache_create_memcg 0x214/0x350
    kmem_cache_create 0x2b/0x30
    fscache_init 0x19b/0x230 [fscache]
    do_one_initcall 0xfa/0x1b0
    load_module 0x1c41/0x26d0
    SyS_finit_module 0x86/0xb0
    system_call_fastpath 0x16/0x1b

Signed-off-by: Andrey Vagin <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Christoph Lameter <[email protected]>
Cc: Glauber Costa <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Johannes Weiner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

The iommu_count field in si_domain(static identity domain) is
initialized to zero and never increases. It will underflow
when tearing down iommu unit in function free_dmar_iommu()
and leak memory. So refine code to correctly manage
si_domain->iommu_count.

Warning message caused by si_domain memory leak:
[   14.609681] IOMMU: Setting RMRR:
[   14.613496] Ignoring identity map for HW passthrough device 0000:00:1a.0 [0xbdcfd000 - 0xbdd1dfff]
[   14.623809] Ignoring identity map for HW passthrough device 0000:00:1d.0 [0xbdcfd000 - 0xbdd1dfff]
[   14.634162] IOMMU: Prepare 0-16MiB unity mapping for LPC
[   14.640329] Ignoring identity map for HW passthrough device 0000:00:1f.0 [0x0 - 0xffffff]
[   14.673360] IOMMU: dmar init failed
[   14.678157] kmem_cache_destroy iommu_devinfo: Slab cache still has objects
[   14.686076] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry  torvalds#59
[   14.694176] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
[   14.707412]  0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff880c2cc37c00
[   14.716407]  ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00
[   14.725468]  ffffffff81dc7a6a ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711
[   14.734464] Call Trace:
[   14.737453]  [<ffffffff8156223d>] dump_stack 0x4d/0x66
[   14.743430]  [<ffffffff811790b1>] kmem_cache_destroy 0xf1/0x100
[   14.750279]  [<ffffffff81dc7a6a>] intel_iommu_init 0x122/0x56a
[   14.757035]  [<ffffffff81d8a711>] ? iommu_setup 0x27d/0x27d
[   14.763491]  [<ffffffff81d8a739>] pci_iommu_init 0x28/0x52
[   14.769846]  [<ffffffff81000342>] do_one_initcall 0x122/0x180
[   14.776506]  [<ffffffff81077738>] ? parse_args 0x1e8/0x320
[   14.782866]  [<ffffffff81d850e8>] kernel_init_freeable 0x1e1/0x26c
[   14.789994]  [<ffffffff81d84833>] ? do_early_param 0x88/0x88
[   14.796556]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   14.802626]  [<ffffffff8154ffce>] kernel_init 0xe/0x130
[   14.808698]  [<ffffffff815756ac>] ret_from_fork 0x7c/0xb0
[   14.814963]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   14.821640] kmem_cache_destroy iommu_domain: Slab cache still has objects
[   14.829456] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry  torvalds#59
[   14.837562] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
[   14.850803]  0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff88102c1ee3c0
[   14.861222]  ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00
[   14.870284]  ffffffff81dc7a76 ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711
[   14.879271] Call Trace:
[   14.882227]  [<ffffffff8156223d>] dump_stack 0x4d/0x66
[   14.888197]  [<ffffffff811790b1>] kmem_cache_destroy 0xf1/0x100
[   14.895034]  [<ffffffff81dc7a76>] intel_iommu_init 0x12e/0x56a
[   14.901781]  [<ffffffff81d8a711>] ? iommu_setup 0x27d/0x27d
[   14.908238]  [<ffffffff81d8a739>] pci_iommu_init 0x28/0x52
[   14.914863]  [<ffffffff81000342>] do_one_initcall 0x122/0x180
[   14.921244]  [<ffffffff81077738>] ? parse_args 0x1e8/0x320
[   14.927598]  [<ffffffff81d850e8>] kernel_init_freeable 0x1e1/0x26c
[   14.934738]  [<ffffffff81d84833>] ? do_early_param 0x88/0x88
[   14.941309]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   14.947380]  [<ffffffff8154ffce>] kernel_init 0xe/0x130
[   14.953430]  [<ffffffff815756ac>] ret_from_fork 0x7c/0xb0
[   14.959689]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   14.966299] kmem_cache_destroy iommu_iova: Slab cache still has objects
[   14.973923] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry  torvalds#59
[   14.982020] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
[   14.995263]  0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff88042cb5c980
[   15.004265]  ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00
[   15.013322]  ffffffff81dc7a82 ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711
[   15.022318] Call Trace:
[   15.025238]  [<ffffffff8156223d>] dump_stack 0x4d/0x66
[   15.031202]  [<ffffffff811790b1>] kmem_cache_destroy 0xf1/0x100
[   15.038038]  [<ffffffff81dc7a82>] intel_iommu_init 0x13a/0x56a
[   15.044786]  [<ffffffff81d8a711>] ? iommu_setup 0x27d/0x27d
[   15.051242]  [<ffffffff81d8a739>] pci_iommu_init 0x28/0x52
[   15.057601]  [<ffffffff81000342>] do_one_initcall 0x122/0x180
[   15.064254]  [<ffffffff81077738>] ? parse_args 0x1e8/0x320
[   15.070608]  [<ffffffff81d850e8>] kernel_init_freeable 0x1e1/0x26c
[   15.077747]  [<ffffffff81d84833>] ? do_early_param 0x88/0x88
[   15.084300]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   15.090362]  [<ffffffff8154ffce>] kernel_init 0xe/0x130
[   15.096431]  [<ffffffff815756ac>] ret_from_fork 0x7c/0xb0
[   15.102693]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   15.189273] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)

Signed-off-by: Jiang Liu <[email protected]>
Cc: Alex Williamson <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>

…loop-during-umount-checkpatch-fixes

ERROR: code indent should use tabs where possible
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
                        if (tmp->type == DLM_MLE_MASTER) {$

WARNING: please, no spaces at the start of a line
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
                        if (tmp->type == DLM_MLE_MASTER) {$

WARNING: suspect code indent for conditional statements (23, 31)
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
                        if (tmp->type == DLM_MLE_MASTER) {
                                ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;

ERROR: code indent should use tabs where possible
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
                                ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

WARNING: please, no spaces at the start of a line
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
                                ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

ERROR: code indent should use tabs where possible
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
                                mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: please, no spaces at the start of a line
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
                                mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: quoted string split across lines
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
                                mlog(0, "%s:%.*s: master=%u, newmaster=%u, "
                                                "telling master to get ref "

ERROR: code indent should use tabs where possible
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
                                                "telling master to get ref "$

WARNING: please, no spaces at the start of a line
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
                                                "telling master to get ref "$

WARNING: quoted string split across lines
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
                                                "telling master to get ref "
                                                "for cleared out mle during "

ERROR: code indent should use tabs where possible
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
                                                "for cleared out mle during "$

WARNING: please, no spaces at the start of a line
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
                                                "for cleared out mle during "$

WARNING: quoted string split across lines
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
                                                "for cleared out mle during "
                                                "migration\n", dlm->name,

ERROR: code indent should use tabs where possible
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
                                                "migration\n", dlm->name,$

WARNING: please, no spaces at the start of a line
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
                                                "migration\n", dlm->name,$

ERROR: code indent should use tabs where possible
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
                                                namelen, name, master,$

WARNING: please, no spaces at the start of a line
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
                                                namelen, name, master,$

ERROR: code indent should use tabs where possible
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
                                                new_master);$

WARNING: please, no spaces at the start of a line
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
                                                new_master);$

ERROR: code indent should use tabs where possible
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
                        }$

WARNING: please, no spaces at the start of a line
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
                        }$

total: 9 errors, 13 warnings, 20 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endlessloop-during-umount.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: Joel Becker <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Xue jiufei <[email protected]>
Cc: jiangyiwen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…loop-during-umount-checkpatch-fixes

ERROR: code indent should use tabs where possible
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
                        if (tmp->type == DLM_MLE_MASTER) {$

WARNING: please, no spaces at the start of a line
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
                        if (tmp->type == DLM_MLE_MASTER) {$

WARNING: suspect code indent for conditional statements (23, 31)
torvalds#56: FILE: fs/ocfs2/dlm/dlmmaster.c:3087:
                        if (tmp->type == DLM_MLE_MASTER) {
                                ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;

ERROR: code indent should use tabs where possible
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
                                ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

WARNING: please, no spaces at the start of a line
torvalds#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
                                ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

ERROR: code indent should use tabs where possible
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
                                mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: please, no spaces at the start of a line
#58: FILE: fs/ocfs2/dlm/dlmmaster.c:3089:
                                mlog(0, "%s:%.*s: master=%u, newmaster=%u, "$

WARNING: quoted string split across lines
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
                                mlog(0, "%s:%.*s: master=%u, newmaster=%u, "
                                                "telling master to get ref "

ERROR: code indent should use tabs where possible
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
                                                "telling master to get ref "$

WARNING: please, no spaces at the start of a line
torvalds#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
                                                "telling master to get ref "$

WARNING: quoted string split across lines
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
                                                "telling master to get ref "
                                                "for cleared out mle during "

ERROR: code indent should use tabs where possible
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
                                                "for cleared out mle during "$

WARNING: please, no spaces at the start of a line
torvalds#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
                                                "for cleared out mle during "$

WARNING: quoted string split across lines
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
                                                "for cleared out mle during "
                                                "migration\n", dlm->name,

ERROR: code indent should use tabs where possible
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
                                                "migration\n", dlm->name,$

WARNING: please, no spaces at the start of a line
torvalds#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
                                                "migration\n", dlm->name,$

ERROR: code indent should use tabs where possible
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
                                                namelen, name, master,$

WARNING: please, no spaces at the start of a line
torvalds#62: FILE: fs/ocfs2/dlm/dlmmaster.c:3093:
                                                namelen, name, master,$

ERROR: code indent should use tabs where possible
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
                                                new_master);$

WARNING: please, no spaces at the start of a line
torvalds#63: FILE: fs/ocfs2/dlm/dlmmaster.c:3094:
                                                new_master);$

ERROR: code indent should use tabs where possible
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
                        }$

WARNING: please, no spaces at the start of a line
torvalds#64: FILE: fs/ocfs2/dlm/dlmmaster.c:3095:
                        }$

total: 9 errors, 13 warnings, 20 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endlessloop-during-umount.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: Joel Becker <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Xue jiufei <[email protected]>
Cc: jiangyiwen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

GIT 3b55c3c0ec2eb3f163f15559f3962df717f53ccb

commit 8dec067dc9c59f9fdcaf4357c22994cde3647eb8
Author: Tomasz Figa <[email protected]>
Date:   Fri Mar 21 02:59:30 2014  0900

    ARM: EXYNOS: Fix compilation error in cpuidle.c
    
    The big series refactoring Exynos suspend to RAM handling missed the
    cpuidle driver that is disabled in exynos_defconfig, leaving it
    including old mach/pm_core.h header and using old s3c_cpu_resume symbol
    instead of new exynos_cpu_resume, resulting in compilation failures with
    CONFIG_ARCH_EXYNOS and CONFIG_CPU_IDLE enabled.
    
    This patch fixes that silly mistake and performs necessary modification
    to arhc/arm/exynos/cpuidle.c to make it compile again.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 58f37b0d47e9839fc8ef90d712863ed55cfcb2c7
Author: Tomasz Figa <[email protected]>
Date:   Fri Mar 21 03:22:33 2014  0900

    ARM: S5P64X0: Explicitly include linux/serial_s3c.h in mach/pm-core.h
    
    This patch fixes compilation failure due to missing explicit inclusion
    of linux/serial_s3c.h in mach/pm-core.h, which contains definitions
    required for further code in this header.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit b2cde2cc71f2382e4a4bfaaacd5263bd93f1e0d2
Author: Florian Fainelli <[email protected]>
Date:   Thu Mar 20 10:53:23 2014 -0700

    net: bcmgenet: manipulate netdev_queue directly
    
    Instead of always invoking netdev_get_tx_queue() in bcmgenet_xmit() and
    bcmgenet_tx_reclaim(), just get the corresponding netdev_queue pointer
    once and for all and manipulate it throughout bcmgenet_xmit() and
    bcmgenet_tx_reclaim().
    
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit d5c76f628d399f06785b0ee910c431770a01b807
Author: Florian Fainelli <[email protected]>
Date:   Thu Mar 20 10:53:22 2014 -0700

    net: bcmgenet: remove bogus tx queue checks
    
    netdev_pick_tx already takes care of making sure that a given
    skb->queue_mapping value will remain within the number of advertised
    hardware queue number, there is no need to re-do this again in the
    driver.
    
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit d03825fba459d0d58e4fe162439babfc5f5eabc4
Author: Florian Fainelli <[email protected]>
Date:   Thu Mar 20 10:53:21 2014 -0700

    net: bcmgenet: add skb_tx_timestamp call
    
    The BCMGENET driver was not TX timestamping the SKBs it queued for
    transmission, do this in bcmgenet_xmit() right before kicking the
    Transmit DMA engine.
    
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 9460c936794fbcf82623e263926b17334ca5887a
Author: Florian Fainelli <[email protected]>
Date:   Thu Mar 20 10:53:20 2014 -0700

    net: bcmgenet: remove unused spinlock member
    
    The spinlock cookie in bcmgenet_priv is never used, get rid of it.
    
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit f738a13d8365b0f824f3f20450b413f55374f175
Author: Laurent Pinchart <laurent.pinchart [email protected]>
Date:   Thu Mar 20 15:00:35 2014  0100

    sh_eth: Remove goto statements that jump straight to a return
    
    "goto" is well accepted for error paths in the kernel but should not be
    used unnecessarily. Return the correct value directly instead of using a
    goto when possible.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart [email protected]>
    Acked-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit daacf03f0bbfefee3df107c3f7659d22e22538a7
Author: Laurent Pinchart <laurent.pinchart [email protected]>
Date:   Thu Mar 20 15:00:34 2014  0100

    sh_eth: Register MDIO bus before registering the network device
    
    Network API functions that rely on the MDIO bus can be called as soon as
    the driver calls register_netdev(). Register the MDIO bus before the
    network device to avoid race conditions.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart [email protected]>
    Acked-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit bd920ff553ba17f19372501a14e432d9d92b102b
Author: Laurent Pinchart <laurent.pinchart [email protected]>
Date:   Thu Mar 20 15:00:33 2014  0100

    sh_eth: Simplify MDIO bus initialization and release
    
    The network device passed to the sh_mdio_init and sh_mdio_release
    functions is only used to access the sh_eth_private instance. Pass it
    directly to those functions.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart [email protected]>
    Acked-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit a5bd60608936fbb84471a80592401ce29a68de71
Author: Laurent Pinchart <laurent.pinchart [email protected]>
Date:   Thu Mar 20 15:00:32 2014  0100

    sh_eth: Use the platform device as the MDIO bus parent
    
    The MDIO bus parent is set to the network device. Beside not reflecting
    the hardware topology, this prevents registering the MDIO bus before
    initializing the network device. Fix it by setting the MDIO bus parent
    to the platform device.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart [email protected]>
    Acked-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit aa8d422510969b705656e49fc0166d862aca9246
Author: Laurent Pinchart <laurent.pinchart [email protected]>
Date:   Thu Mar 20 15:00:31 2014  0100

    sh_eth: Use the platform device for memory allocation
    
    Memory allocated for the MDIO bus with the devm_kzalloc() API is
    associated with the network device. While this will cause memory to be
    freed at the right time, it doesn't allow allocating memory before the
    network device is initialized.
    
    Replace the network device with the parent platform device for memory
    allocation to remove that dependency. This also improves consistency
    with the other devm_* calls in the driver that all use the platform
    device.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart [email protected]>
    Acked-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 54af36e7136b5e111734ca5b06c6b4390d663cac
Author: Alexander Aring <[email protected]>
Date:   Thu Mar 20 14:57:03 2014  0100

    ieee802154: dgram: cleanup set of broadcast panid
    
    This patch is only a cleanup to use the right define for a panid field.
    The broadcast address and panid broadcast is still the same value.
    
    Signed-off-by: Alexander Aring <[email protected]>
    Cc: Phoebe Buckheister <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 06324f2f7c21e3ba3529546063a3ebf7da806ed0
Author: Alexander Aring <[email protected]>
Date:   Thu Mar 20 14:57:02 2014  0100

    af_ieee802154: fix check on broadcast address
    
    This patch fixes an issue which was introduced by commit
    b70ab2e87f17176d18f67ef331064441a032b5f3 ("ieee802154: enforce
    consistent endianness in the 802.15.4 stack").
    
    The correct behaviour should be a check on the broadcast address field
    which is 0xffff.
    
    Signed-off-by: Alexander Aring <[email protected]>
    Reported-by: Jan Luebbe <[email protected]>
    Cc: Phoebe Buckheister <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 3c6f5592203e8126b70717f040c6c59f953068b3
Author: Jason Gunthorpe <[email protected]>
Date:   Wed Mar 19 16:15:24 2014 -0600

    of_mdio: Allow the DT to specify the phy ID and avoid autoprobing
    
    This makes the generic of_mdiobus_register parse the DT compatible string for
    the pattern ethernet-phy-idAAAA.BBBB. If present it should be a value that
    matches the phy-id register normally readable through MDIO.
    
    When the ID is given the phy autoprobing is defeated and the phy is
    created directly.
    
    This is necessary to support phy's that cannot be autoprobed when
    of_mdiobus_register is called. Specifically, my case has the phy in reset at
    of_mdiobus_register, the reset is only released once the ethernet driver
    starts, before it attaches to the phy.
    
    Tested on ARM Kirkwood with phy id 0x01410e90 (Marvell 88E1318)
    
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Acked-by: Rob Herring <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit f00e756ed12d3204583764c93e41b89e1ae7ee44
Author: Jason Gunthorpe <[email protected]>
Date:   Wed Mar 19 16:15:23 2014 -0600

    dt: Document a compatible entry for MDIO ethernet Phys
    
    This describes a compatible entry of the form:
      ethernet-phy-idAAAA,BBBB
    Which is modelled after the PCI structured compatible entry
    (pciVVVV,DDDD.SSSS.ssss.RR)
    
    If present the OF core will be able to use this information to
    directly create the correct phy without auto probing the bus.
    
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Acked-by: Rob Herring <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 259fef033ffe4e70bf7f358c53400a09f1b5384e
Author: Ben Chan <[email protected]>
Date:   Wed Mar 19 14:00:06 2014 -0700

    net: cdc_ncm: respect operator preferred MTU reported by MBIM
    
    According to "Universal Serial Bus Communications Class Subclass
    Specification for Mobile Broadband Interface Model, Revision 1.0,
    Errata-1" published by USB-IF, the wMTU field of the MBIM extended
    functional descriptor indicates the operator preferred MTU for IP data
    streams.
    
    This patch modifies cdc_ncm_setup to ensure that the MTU value set on
    the usbnet device does not exceed the operator preferred MTU indicated
    by wMTU if the MBIM device exposes a MBIM extended functional
    descriptor.
    
    Signed-off-by: Ben Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit bfe9b3f8c5229e5de4fd18e941866bc410d16334
Author: Ben Chan <[email protected]>
Date:   Wed Mar 19 14:00:05 2014 -0700

    USB: cdc: add MBIM extended functional descriptor structure
    
    This patch adds the MBIM extended functional descriptor structure
    defined in "Universal Serial Bus Communications Class Subclass
    Specification for Mobile Broadband Interface Model, Revision 1.0,
    Errata-1" published by USB-IF.
    
    Signed-off-by: Ben Chan <[email protected]>
    Acked-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit f518338b16038beeb73e155e60d0f70beb9379f4
Author: Nicolas Dichtel <[email protected]>
Date:   Wed Mar 19 17:47:51 2014  0100

    ip6mr: fix mfc notification flags
    
    Commit 812e44dd1829 ("ip6mr: advertise new mfc entries via rtnl") reuses the
    function ip6mr_fill_mroute() to notify mfc events.
    But this function was used only for dump and thus was always setting the
    flag NLM_F_MULTI, which is wrong in case of a single notification.
    
    Libraries like libnl will wait forever for NLMSG_DONE.
    
    CC: Thomas Graf <[email protected]>
    Signed-off-by: Nicolas Dichtel <[email protected]>
    Acked-by: Thomas Graf <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 65886f439ab0fdc2dff20d1fa87afb98c6717472
Author: Nicolas Dichtel <[email protected]>
Date:   Wed Mar 19 17:47:50 2014  0100

    ipmr: fix mfc notification flags
    
    Commit 8cd3ac9f9b7b ("ipmr: advertise new mfc entries via rtnl") reuses the
    function ipmr_fill_mroute() to notify mfc events.
    But this function was used only for dump and thus was always setting the
    flag NLM_F_MULTI, which is wrong in case of a single notification.
    
    Libraries like libnl will wait forever for NLMSG_DONE.
    
    CC: Thomas Graf <[email protected]>
    Signed-off-by: Nicolas Dichtel <[email protected]>
    Acked-by: Thomas Graf <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 1c104a6bebf3c16b6248408b84f91d09ac8a26b6
Author: Nicolas Dichtel <[email protected]>
Date:   Wed Mar 19 17:47:49 2014  0100

    rtnetlink: fix fdb notification flags
    
    Commit 3ff661c38c84 ("net: rtnetlink notify events for FDB NTF_SELF adds and
    deletes") reuses the function nlmsg_populate_fdb_fill() to notify fdb events.
    But this function was used only for dump and thus was always setting the
    flag NLM_F_MULTI, which is wrong in case of a single notification.
    
    Libraries like libnl will wait forever for NLMSG_DONE.
    
    CC: Thomas Graf <[email protected]>
    Signed-off-by: Nicolas Dichtel <[email protected]>
    Acked-by: Thomas Graf <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 632623153196bf183a69686ed9c07eee98ff1bf8
Author: Eric Dumazet <[email protected]>
Date:   Wed Mar 19 21:02:21 2014 -0700

    tcp: syncookies: do not use getnstimeofday()
    
    While it is true that getnstimeofday() uses about 40 cycles if TSC
    is available, it can use 1600 cycles if hpet is the clocksource.
    
    Switch to get_jiffies_64(), as this is more than enough, and
    go back to 60 seconds periods.
    
    Fixes: 8c27bd75f04f ("tcp: syncookies: reduce cookie lifetime to 128 seconds")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Florian Westphal <[email protected]>
    Acked-by: Florian Westphal <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit dd41cc3bb90efd455df514899a5d3cf245182eb1
Author: Matan Barak <[email protected]>
Date:   Wed Mar 19 18:11:53 2014  0200

    net/mlx4: Adapt num_vfs/probed_vf params for single port VF
    
    A new syntax is added for the module parameters num_vfs and probe_vf.
    
      num_vfs=p1,p2,p1 p2
      probe_bf=p1,p2,p1 p2
    
    Where p1(2) is the number of VFs on / probed VFs for physical
    port1(2) and p1 p2 is the number of dual port VFs.
    
    Single port VFs are currently supported only when the link type
    for both ports of the device is Ethernet.
    
    Signed-off-by: Matan Barak <[email protected]>
    Signed-off-by: Or Gerlitz <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 449fc48866f7d84b0d9a19201de18a4dd4d3488c
Author: Matan Barak <[email protected]>
Date:   Wed Mar 19 18:11:52 2014  0200

    net/mlx4: Adapt code for N-Port VF
    
    Adds support for N-Port VFs, this includes:
    1. Adding support in the wrapped FW command
    	In wrapped commands, we need to verify and convert
    	the slave's port into the real physical port.
    	Furthermore, when sending the response back to the slave,
    	a reverse conversion should be made.
    2. Adjusting sqpn for QP1 para-virtualization
    	The slave assumes that sqpn is used for QP1 communication.
    	If the slave is assigned to a port != (first port), we need
    	to adjust the sqpn that will direct its QP1 packets into the
    	correct endpoint.
    3. Adjusting gid[5] to modify the port for raw ethernet
    	In B0 steering, gid[5] contains the port. It needs
    	to be adjusted into the physical port.
    4. Adjusting number of ports in the query / ports caps in the FW commands
    	When a slave queries the hardware, it needs to view only
    	the physical ports it's assigned to.
    5. Adjusting the sched_qp according to the port number
    	The QP port is encoded in the sched_qp, thus in modify_qp we need
    	to encode the correct port in sched_qp.
    
    Signed-off-by: Matan Barak <[email protected]>
    Signed-off-by: Or Gerlitz <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit f74462acf8f390528c8b7937f227c6c90d017f3b
Author: Matan Barak <[email protected]>
Date:   Wed Mar 19 18:11:51 2014  0200

    net/mlx4: Add utils for N-Port VFs
    
    This patch adds the following utils:
    1. Convert slave_id -> VF
    2. Get the active ports by slave_id
    3. Convert slave's port to real port
    4. Get the slave's port from real port
    5. Get all slaves that uses the i'th real port
    6. Get all slaves that uses the i'th real port exclusively
    
    Signed-off-by: Matan Barak <[email protected]>
    Signed-off-by: Or Gerlitz <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 1ab95d37bcc3ff2d69e3871e4f056bab7aed0b85
Author: Matan Barak <[email protected]>
Date:   Wed Mar 19 18:11:50 2014  0200

    net/mlx4: Add data structures to support N-Ports per VF
    
    Adds the required data structures to support VFs with N (1 or 2)
    ports instead of always using the number of physical ports.
    
    Signed-off-by: Matan Barak <[email protected]>
    Signed-off-by: Or Gerlitz <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 82373701be26b893eaf7372db0af84235a51998a
Author: Matan Barak <[email protected]>
Date:   Wed Mar 19 18:11:49 2014  0200

    IB/mlx4_ib: Adapt code to use caps.num_ports instead of a constant
    
    Some code in the mlx4 IB driver stack assumed MLX4_MAX_PORTS ports.
    
    Instead, we should only loop until the number of actual ports in i
    the device, which is stored in dev->caps.num_ports.
    
    Signed-off-by: Matan Barak <[email protected]>
    Signed-off-by: Or Gerlitz <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 8798998c2cdbc0df3c64e8845c1502ed93ef1ebd
Author: Fabio Estevam <[email protected]>
Date:   Wed Mar 19 11:22:06 2014 -0300

    smsc911x: Change clock warning message to debug level
    
    Since passing the clock is not mandatory, change the warning message to debug,
    so that we avoid getting the following clock failure message on every boot:
    
    smsc911x: Driver version 2008-10-21
    smsc911x smsc911x (unregistered net_device): couldn't get clock -2
    libphy: smsc911x-mdio: probed
    
    Signed-off-by: Fabio Estevam <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit e35bad5d876dc7b0bfd794a3ba328a442bd970e0
Author: Daniel Baluta <[email protected]>
Date:   Wed Mar 19 15:58:25 2014  0200

    net: remove empty lines from tcp_syn_flood_action
    
    Signed-off-by: Daniel Baluta <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 1aa9c483d1be13831bc4e516ce4848d32ac3e944
Author: Sachin Kamat <[email protected]>
Date:   Fri Mar 21 04:49:03 2014  0900

    ARM: EXYNOS: Remove hardware.h file
    
    This is a dummy placeholder file. Delete it.
    
    Signed-off-by: Sachin Kamat <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 2bb1ad17d66da3549eb4d23e264786a98f9ab17b
Author: Sachin Kamat <[email protected]>
Date:   Fri Mar 21 04:48:59 2014  0900

    ARM: SAMSUNG: Remove hardware.h inclusion
    
    The contents of this header file are not referenced anywhere in the
    included .c files except in devs.c. Remove its inclusion. For devs.c,
    explicitly include sizes.h header for SZ_* macros.
    
    Signed-off-by: Sachin Kamat <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 144bf7b0a96e28266c6b2f47a6e04c7a4e4b3aa4
Author: Sachin Kamat <[email protected]>
Date:   Fri Mar 21 04:48:07 2014  0900

    ARM: S3C24XX: Remove invalid code from hardware.h
    
    Remove the code that is not referenced anywhere. While at it also
    remove incorrect file path.
    
    Signed-off-by: Sachin Kamat <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 676141e48af7463717896352e69c10f945ac22dd
Author: Jens Axboe <[email protected]>
Date:   Thu Mar 20 13:29:18 2014 -0600

    blk-mq: don't dump CPU -> hw queue map on driver load
    
    Now that we are out of initial debug/bringup mode, remove
    the verbose dump of the mapping table.
    
    Provide the mapping table in sysfs, under the hardware queue
    directory, in the cpu_list file.
    
    Signed-off-by: Jens Axboe <[email protected]>

commit 602408e3de70d132c115670a366f4c5ae657080c
Author: Tushar Behera <[email protected]>
Date:   Fri Mar 21 04:31:30 2014  0900

    dt-bindings: clock: Move exynos-audss-clk.h to dt-bindings/clock
    
    Most of the clock related dt-binding header files are located in
    dt-bindings/clock folder. It would be good to keep all the similar
    header files at a single location.
    
    Signed-off-by: Tushar Behera <[email protected]>
    Reviewed-by: Sachin Kamat <[email protected]>
    Acked-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 55ace6b285d7350d5b562ba065656c8242629a32
Author: Tushar Behera <[email protected]>
Date:   Fri Mar 21 04:26:40 2014  0900

    ARM: dts: Keep some essential LDOs enabled for arndale-octa board
    
    LDO3 and LDO23 need to be enabled in order for soft-reset to work.
    Additionally LDO9 needs to be enabled for USB operations.
    
    Signed-off-by: Tushar Behera <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 3da355c03a44bc45f3688bb68b51eefa738d1857
Author: Tushar Behera <[email protected]>
Date:   Fri Mar 21 04:26:40 2014  0900

    ARM: dts: Disable MDMA1 node for arndale-octa board
    
    MDMA1 can support both secure and non-secure AXI transactions. When this
    is enabled in the kernel for boards that run in secure mode, we get
    imprecise external aborts causing the kernel to oops.
    
    Unhandled fault: imprecise external abort (0x1406) at 0x00000000
    Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
    
    Suggested-by: Javi Merino <[email protected]>
    Signed-off-by: Tushar Behera <[email protected]>
    Tested-by: Javi Merino <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit e1a9d00c689a5da2d1baf273891507c5fb063f4c
Author: Mark Brown <[email protected]>
Date:   Fri Mar 21 02:57:18 2014  0900

    ARM: S3C64XX: Fix build for implicit serial_s3c.h inclusion
    
    Some very recent change appears to have removed an implicit inclusion of
    serial_s3c.h causing build failures due to references to UART registers
    in the serial port restore code in next-20140318.  Include it explicitly
    to fix the build.
    
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit cf559ab94e058df65c841b4afc8d5346fdda19b3
Author: Mark Brown <[email protected]>
Date:   Fri Mar 21 02:55:11 2014  0900

    serial: s3c: Fix build of header without serial_core.h preinclusion
    
    serial_s3c.h uses upf_t which is defined in serial_core.h but does not
    include that itself meaning that users which include serial_s3c.h by
    itself don't build.
    
    Signed-off-by: Mark Brown <[email protected]>
    [t.figa: Moved inclusion under #ifndef __ASSEMBLY__ to fix mach-exynos]
    Signed-off-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit dd8ac696b20c1be5ca4728045df10e882e01e91d
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:30 2014  0900

    ARM: EXYNOS: Allow wake-up using GIC interrupts
    
    This patch restores the ability to receive wake-up events from internal
    GIC interrupts, e.g. RTC tick or alarm interrupts.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit d710aa31874e2ff6e656dbd4807f4bd8d659eb93
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:27 2014  0900

    ARM: EXYNOS: Stop using legacy Samsung PM code
    
    Since Exynos SoCs does not follow most of the semantics of older SoCs
    when configuring the system to enter sleep, there is no reason to rely
    on the legacy Samsung PM core anymore.
    
    This patch adds local Exynos suspend ops and removes all the code left
    unnecessary. As a side effect, suspend support on Exynos becomes
    multiplatform-friendly.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 559ba237999d723ccba5b4a75cf6b280bac1ab21
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:22 2014  0900

    ARM: EXYNOS: Remove PM initcalls and useless indirection
    
    This patch simplifies Exynos PM initialization and makes it
    multiplatform friendly by replacing initcalls used originally to invoke
    all the initialization code with explicit function calls.
    
    In addition, an useless subsys_interface is removed, as all its .add_dev
    callback did was setting two function pointers.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit dbc5ca163dc46153a8e5249da627af571ae47c10
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:10 2014  0900

    ARM: EXYNOS: Fix abuse of CONFIG_PM
    
    CONFIG_PM means that at least one of CONFIG_PM_SLEEP and
    CONFIG_PM_RUNTIME is enabled, while multiple entries in
    mach-exynos/Kconfig abused it to enable sleep- and runtime-specific
    functionality.
    
    This patch fixes this abuse by replacing dependencies on CONFIG_PM with
    appropriate dependencies on either CONFIG_PM_SLEEP or CONFIG_PM_RUNTIME,
    whichever is appropriate.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit f682426630c620a2b8ae488a4f0d85ec6c272d66
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:10 2014  0900

    ARM: SAMSUNG: Move s3c_pm_check_* prototypes to plat/pm-common.h
    
    To allow using Samsung PM memory check helpers on platforms that do not
    use the legacy Samsung PM core, this patch moves prototypes of relevant
    functions to plat/pm-common.h header.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit b27899178c53226a5ff780a17657c84eb5e32338
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:10 2014  0900

    ARM: SAMSUNG: Move common save/restore helpers to separate file
    
    To separate legacy PM code from generic helpers, this patch moves the
    generic register save/restore helpers to a new file called pm-common.c
    that is compiled always when CONFIG_PM_SLEEP is enabled, to allow
    platforms that do not want to use the legacy PM code use the generic
    helpers.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 72551f6cf13e2f3a1d273b7007b5d7d7fd69c554
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:09 2014  0900

    ARM: SAMSUNG: Move Samsung PM debug code into separate file
    
    Not all Samsung SoC platforms are going to use the legacy Samsung PM
    code enabled by CONFIG_SAMSUNG_PM_DEBUG. To allow using Samsung PM debug
    helpers on such platforms, related code is moved to separate file and
    a plat/pm-common.h header is added to separate legacy and generic code.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit d38688a69fd88269eae3c7c66ec34fb02fb04fd1
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:09 2014  0900

    ARM: SAMSUNG: Consolidate PM debug functions
    
    This patch removes one-line functions that was used just to pass
    constant arguments to lower level functions. After previous patches the
    need for those constants has been eliminated, so the main functions can
    be called directly.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 99b2fc2b8b40256538332769f11f2fe6ee942f6c
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:09 2014  0900

    ARM: SAMSUNG: Use debug_ll_addr() to get UART base address
    
    This patch modifies Samsung PM debug helpers to use a multiplatform
    friendly way of getting base address of debug UART port, so instead
    of using a per-mach static macro, a generic debug_ll_addr() helper
    is used.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit de7fe0807c08553b88028d039861a4b8ad04fc62
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:09 2014  0900

    ARM: SAMSUNG: Save UART DIVSLOT register based on SoC type
    
    The only SoC that does not have DIVSLOT register is S3C2410, so instead
    of exporting a variable for platforms to set if DIVSLOT register should
    be preserved, it's enough to simply check whether we are running on
    a S3C2410 instead.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 04241069617d4f0bfd9f4a3aeefae13e1e5b55e1
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:09 2014  0900

    ARM: SAMSUNG: Add soc_is_s3c2410() helper
    
    Due to the S3C2410 SoC being quite different from other S3C24xx SoCs
    in some aspects, such as availability of DIVSLOT register in its UART
    blocks, there is a need sometimes to check whether we are running on
    this SoC, not just the S3C24xx series. This patch adds soc_is_s3c2410()
    helper function for this purpose.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 61557b8bac9c80a5c14d237d420c246703e5c2e2
Author: Tomasz Figa <[email protected]>
Date:   Tue Mar 18 07:28:09 2014  0900

    ARM: EXYNOS: Do not resume l2x0 if not enabled before suspend
    
    Trying to resume l2x0 if it was not enabled before suspend leads to
    system crash. This patch prevents this by checking if l2x0_regs_phys is
    a valid pointer to l2x0 context data saved on initialization.
    
    Signed-off-by: Tomasz Figa <[email protected]>
    Acked-by: Kyungmin Park <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 56981fbc1b044cb140f70279deb736b6ae8664fb
Author: Mike Snitzer <[email protected]>
Date:   Thu Mar 20 10:11:15 2014 -0400

    dm cache: prevent corruption caused by discard_block_size > cache_block_size
    
    If the discard block size is larger than the cache block size we will
    not properly quiesce IO to a region that is about to be discarded.  This
    results in a race between a cache migration where no copy is needed, and
    a write to an adjacent cache block that's within the same large discard
    block.
    
    Workaround this by limiting the discard_block_size to cache_block_size.
    Also limit the max_discard_sectors to cache_block_size.
    
    A more comprehensive fix that introduces range locking support in the
    bio_prison and proper quiescing of a discard range that spans multiple
    cache blocks is already in development.
    
    Reported-by: Morgan Mears <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Acked-by: Joe Thornber <[email protected]>
    Acked-by: Heinz Mauelshagen <[email protected]>
    Cc: [email protected]

commit 88050049e7111f074e8887ba5a4cefc9f8fa8d41
Author: stephen hemminger <[email protected]>
Date:   Wed Mar 19 21:54:20 2014 -0700

    netlink: fix setsockopt in mmap examples in documentation
    
    The documentation for how to use netlink mmap interface is incorrect.
    The calls to setsockopt() require an additional argument.
    
    Signed-off-by: Stephen Hemminger <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit f9b8c4c8baded129535d82d74df8e87a7a369f54
Author: Ben Pfaff <[email protected]>
Date:   Thu Mar 20 10:45:21 2014 -0700

    openvswitch: Correctly report flow used times for first 5 minutes after boot.
    
    The kernel starts out its "jiffies" timer as 5 minutes below zero, as
    shown in include/linux/jiffies.h:
    
      /*
       * Have the 32 bit jiffies value wrap 5 minutes after boot
       * so jiffies wrap bugs show up earlier.
       */
      #define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))
    
    The loop in ovs_flow_stats_get() starts out with 'used' set to 0, then
    takes any "later" time.  This means that for the first five minutes after
    boot, flows will always be reported as never used, since 0 is greater than
    any time already seen.
    
    Signed-off-by: Ben Pfaff <[email protected]>
    Acked-by: Pravin B Shelar <[email protected]>
    Signed-off-by: Jesse Gross <[email protected]>

commit 494314c415e2d3b308f57c9245ae6525166c70b8
Author: Trond Myklebust <[email protected]>
Date:   Thu Mar 20 12:59:09 2014 -0400

    SUNRPC: rpc_restart_call/rpc_restart_call_prepare should clear task->tk_status
    
    When restarting an rpc call, we should not be carrying over data from the
    previous call.
    
    Signed-off-by: Trond Myklebust <[email protected]>

commit 6bd144160a5554e4af052c153a094c4851a4c6aa
Author: Trond Myklebust <[email protected]>
Date:   Thu Mar 20 12:53:54 2014 -0400

    SUNRPC: Don't let rpc_delay() clobber non-timeout errors
    
    Signed-off-by: Trond Myklebust <[email protected]>

commit d614f6d0bed7fa5a795708a6dc334370e1ca7951
Author: Yan Burman <[email protected]>
Date:   Tue Mar 11 14:41:47 2014  0200

    IB/mad: Check and handle potential DMA mapping errors
    
    Running with DMA_API_DEBUG enabled and not checking for DMA mapping
    errors triggers a kernel stack trace with "DMA-API: device driver
    failed to check map error" message.  Add these checks to the MAD
    module, both to be be more robust and also eliminate these
    false-positive stack traces.
    
    Signed-off-by: Yan Burman <[email protected]>
    Signed-off-by: Or Gerlitz <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 76cf9cbb68f3234f54c0a12bde6372911157c650
Author: Selvin Xavier <[email protected]>
Date:   Tue Mar 18 14:54:56 2014  0530

    RDMA/ocrdma: Unregister inet notifier when unloading ocrdma
    
    Unregister the inet notifier during ocrdma unload to avoid a panic after
    driver unload.
    
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 186f8ba062f796221d51077342f3ba5202838e9f
Author: Dan Carpenter <[email protected]>
Date:   Thu Jan 30 15:12:31 2014  0300

    IB/qib: Cleanup qib_register_observer()
    
    Returning directly is easier to read than do-nothing gotos.  Remove the
    duplicative check on "olp" and pull the code in one indent level.
    
    Signed-off-by: Dan Carpenter <[email protected]>
    Acked-by: Mike Marciniszyn <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 49c0e2414b20d868cf006addf14152570aef2605
Author: CQ Tang <[email protected]>
Date:   Thu Jan 30 17:36:00 2014 -0500

    IB/qib: Change SDMA progression mode depending on single- or multi-rail
    
    Improve performance by changing the behavour of the driver when all
    SDMA descriptors are in use, and the processes adding new descriptors
    are single- or multi-rail.
    
    For single-rail processes, the driver will block the call and finish
    posting all SDMA descriptors onto the hardware queue before returning
    back to PSM.  Repeated kernel calls are slower than blocking.
    
    For multi-rail processes, the driver will return to PSM as quick as
    possible so PSM can feed packets to other rail.  If all hardware
    queues are full, PSM will buffer the remaining SDMA descriptors until
    notified by interrupt that space is available.
    
    This patch builds a red-black tree to track the number rails opened by
    a particular PID. If the number is more than one, it is a multi-rail
    PSM process, otherwise, it is a single-rail process.
    
    Reviewed-by: Dean Luick <[email protected]>
    Reviewed-by: John A Gregor <[email protected]>
    Reviewed-by: Mitko Haralanov <[email protected]>
    Signed-off-by: CQ Tang <[email protected]>
    Signed-off-by: Mike Marciniszyn <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 8307281a5bceaaaa1566897dc0b57cdb62413ae8
Author: Roland Dreier <[email protected]>
Date:   Mon Mar 17 23:14:17 2014 -0700

    RDMA/ocrdma: Fix warnings about pointer <-> integer casts
    
    We should cast pointers to and from unsigned long to turn them into ints.
    
    Signed-off-by: Roland Dreier <[email protected]>

commit 0d3a1e7e317b06d87b92011c62a5061f299820b9
Author: Devesh Sharma <[email protected]>
Date:   Tue Feb 4 11:57:10 2014  0530

    RDMA/ocrdma: Code clean-up
    
    Clean up code.  Also modifying GSI QP to error during ocrdma_close is fixed.
    
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 9a31758308df672713ea0db9a9eff7c3cb348bc2
Author: Selvin Xavier <[email protected]>
Date:   Tue Feb 4 11:57:09 2014  0530

    RDMA/ocrdma: Display FW version
    
    Adding a sysfs file for getting the FW version.
    
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit babe6b9ce0bdf964624435382a67c09f668bcab0
Author: Selvin Xavier <[email protected]>
Date:   Tue Feb 4 11:57:07 2014  0530

    RDMA/ocrdma: Query controller information
    
    Issue mailbox commands to query ocrdma controller information and phy
    information and print them while adding ocrdma device.
    
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 8bdb31b4d1931a32264fbe4651e607eb72941ff0
Author: Sachin Kamat <[email protected]>
Date:   Fri Mar 21 02:17:22 2014  0900

    ARM: dts: Update Exynos DT files with generic compatible strings
    
    Add generic compatible strings to the respective board DT files.
    
    Signed-off-by: Sachin Kamat <[email protected]>
    Acked-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 4868123ceb6ef0d4fa04e3211a0f4cd948f418f9
Author: Sachin Kamat <[email protected]>
Date:   Fri Mar 21 02:14:59 2014  0900

    ARM: EXYNOS: Add generic compatible strings
    
    Add generic compatible strings for Exynos4 and 5 platforms so that
    future SoCs can use them if there is nothing extra/specific to be
    differentiated.
    
    Signed-off-by: Sachin Kamat <[email protected]>
    Acked-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit cbf08b9ebdfc75bb13ef80ad3b8e3bea46d8c43a
Author: Sachin Kamat <[email protected]>
Date:   Fri Mar 21 02:14:30 2014  0900

    ARM: EXYNOS: Consolidate exynos4 and exynos5 machine files
    
    Since there is very little difference between these two files,
    they can be easily combined into one with necessary SoC checks.
    While at it also merge the common.c file into this as it does
    not have any other users.
    
    Signed-off-by: Sachin Kamat <[email protected]>
    Acked-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 6eb84669cf7e94214593f162d4c1cf20424dd906
Author: Sachin Kamat <[email protected]>
Date:   Fri Mar 21 02:09:39 2014  0900

    ARM: EXYNOS: Consolidate CPU init code
    
    cpu_table was used to distinguish between different Exynos4 and 5
    SoCs and based on the type do the initialization and io mapping.
    exynos_init is dummy and no longer needed as we do a DT based booting.
    By having a common io mapping function we can get rid of the whole
    table and avoid populating it for every SoC.
    
    Tested on Exynos4210, 5250 and 5420 based boards.
    
    Signed-off-by: Sachin Kamat <[email protected]>
    Tested-by: Tomasz Figa <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 7bd03c0ebe54db94f20cd7577b875d9d27e539a9
Author: Selvin Xavier <[email protected]>
Date:   Tue Feb 4 11:57:06 2014  0530

    RDMA/ocrdma: Support non-embedded mailbox commands
    
    Added a routine to issue non-embedded mailbox commands for handling
    large mailbox request/response data.
    
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit a1b8aff87d5f27022e6c14c43bf43226e75d2745
Author: Selvin Xavier <[email protected]>
Date:   Tue Feb 4 11:57:05 2014  0530

    RDMA/ocrdma: Handle CQ overrun error
    
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 23631e15a7f3c01a1ebb34f2c176f658c27eb949
Author: Selvin Xavier <[email protected]>
Date:   Tue Feb 4 11:57:04 2014  0530

    RDMA/ocrdma: Display proper value for max_mw
    
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit c0e19755d56142b026b07b8020273301c8ed42bb
Author: Selvin Xavier <[email protected]>
Date:   Tue Feb 4 11:57:03 2014  0530

    RDMA/ocrdma: Use non-zero tag in SRQ posting
    
    As part of SRQ receive buffers posting we populate a non-zero tag
    which will be returned in SRQ receive completions.
    
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit def4eb8e5eacdfbc4788a6cb1bc0a3f118b5b349
Author: Selvin Xavier <[email protected]>
Date:   Tue Feb 4 11:57:02 2014  0530

    RDMA/ocrdma: Memory leak fix in ocrdma_dereg_mr()
    
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 0f4d45e0845e63e54aeaf5a7444b8ef4b77e4895
Author: [email protected] <[email protected]>
Date:   Tue Feb 4 11:57:01 2014  0530

    RDMA/ocrdma: Increment abi version count
    
    Increment the ABI version count for driver/library interface.
    
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 5b5eb9421408080b46ce14210ca717714859dee4
Author: [email protected] <[email protected]>
Date:   Tue Feb 4 11:57:00 2014  0530

    RDMA/ocrdma: Update version string
    
    Update the driver vrsion string and node description string
    
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 91b3140a692e87733367521efdd24f9a3532889a
Author: [email protected] <[email protected]>
Date:   Tue Feb 4 11:56:59 2014  0530

    be2net: Add abi version between be2net and ocrdma
    
    This patch adds abi versioning between be2net and ocrdma driver modules
    to catch functional incompatibilities in the two drivers.
    
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 973ce6ce272d2c79f7eb1094ec26c25d1d8b4b32
Author: [email protected] <[email protected]>
Date:   Tue Feb 4 11:56:58 2014  0530

    RDMA/ocrdma: ABI versioning between ocrdma and be2net
    
    While loading RoCE driver be2net driver should check for ABI version
    to catch functional incompatibilities.
    
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit db84035babf25f81be2a548f9332553b3a62865f
Author: [email protected] <[email protected]>
Date:   Tue Feb 4 11:56:57 2014  0530

    RDMA/ocrdma: Allow DPP QP creation
    
    Allow creating DPP QP even if inline-data is not requested.  This is an
    optimization to lower latency.
    
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit d64c9414a4cc7c768d117ae035bf45cce760aeb5
Author: [email protected] <[email protected]>
Date:   Tue Feb 4 11:56:56 2014  0530

    RDMA/ocrdma: Read ASIC_ID register to select asic_gen
    
    ocrdma driver selects execution path based on sli_family and asic
    generation number.  This introduces code to read the asic gen number
    from pci register instead of obtaining it from the Emulex NIC driver.
    
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit da7d0e7699e6c5e3b076ba68680afe679e7379f0
Author: Devesh Sharma <[email protected]>
Date:   Tue Feb 4 11:56:55 2014  0530

    RDMA/ocrdma: SQ and RQ doorbell offset clean up
    
    Introducing new macros to define SQ and RQ doorbell offset.
    
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 1dbf741320af98620593c9a1d7481dd8b37f53fe
Author: [email protected] <[email protected]>
Date:   Tue Feb 4 11:56:54 2014  0530

    RDMA/ocrdma: EQ full catastrophe avoidance
    
    Stale entries in the CQ being destroyed causes hardware to generate
    EQEs indefinitely for a given CQ.  Thus causing uncontrolled execution
    of irq_handler.  This patch fixes this using following sementics:
    
        * irq_handler will ring EQ doorbell atleast once and implement budgeting scheme.
        * cq_destroy will count number of valid entires during destroy and ring
          cq-db so that hardware does not generate uncontrolled EQE.
        * cq_destroy will synchronize with last running irq_handler instance.
        * arm_cq will always defer arming CQ till poll_cq, except for the first arm_cq call.
        * poll_cq will always ring cq-db with arm=SET if arm_cq was called prior to enter poll_cq.
        * poll_cq will always ring cq-db with arm=UNSET if arm_cq was not called prior to enter poll_cq.
    
    Signed-off-by: Devesh Sharma <[email protected]>
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit eda6d1d1b7932f90d55583f8f3835dd7d6b32543
Author: Steve Wise <[email protected]>
Date:   Wed Mar 19 17:44:45 2014  0530

    RDMA/cxgb4: Save the correct map length for fast_reg_page_lists
    
    We cannot save the mapped length using the rdma max_page_list_len field
    of the ib_fast_reg_page_list struct because the core code uses it.  This
    results in an incorrect unmap of the page list in c4iw_free_fastreg_pbl().
    
    I found this with dma mapping debugging enabled in the kernel.  The
    fix is to save the length in the c4iw_fr_page_list struct.
    
    Signed-off-by: Steve Wise <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit df2d5130ece9118591c2f3fbf0ee4a79183b4ccc
Author: Steve Wise <[email protected]>
Date:   Wed Mar 19 17:44:44 2014  0530

    RDMA/cxgb4: Default peer2peer mode to 1
    
    Signed-off-by: Steve Wise <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit ba32de9d8d8173a1d6dd1ed608c519d5d0a623bb
Author: Steve Wise <[email protected]>
Date:   Wed Mar 19 17:44:43 2014  0530

    RDMA/cxgb4: Mind the sq_sig_all/sq_sig_type QP attributes
    
    Signed-off-by: Steve Wise <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 8a9c399eeee8c2d99e22b975f6023001a1fde88f
Author: Steve Wise <[email protected]>
Date:   Wed Mar 19 17:44:42 2014  0530

    RDMA/cxgb4: Fix incorrect BUG_ON conditions
    
    Based on original work from Jay Hernandez <[email protected]>
    
    Signed-off-by: Steve Wise <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 58553078c1feb40e0a02d7c72ae41dd6b923f231
Author: Sachin Kamat <[email protected]>
Date:   Fri Mar 21 02:00:21 2014  0900

    ARM: SAMSUNG: Introduce generic Exynos4 and 5 helpers
    
    Add helpers to check for Exynos4 and 5 family of SoCs.
    This will eliminate comparing long list of SoCs and make
    code simpler.
    
    Signed-off-by: Sachin Kamat <[email protected]>
    Acked-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 7ed30015007c32c006783526dc54a2a88bd5e13b
Author: Sachin Kamat <[email protected]>
Date:   Fri Mar 21 01:52:56 2014  0900

    ARM: EXYNOS: Add support to reserve memory for MFC-v7
    
    Reserve memory for MFC-v7 IP.
    
    Signed-off-by: Sachin Kamat <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit 8b3e8bbd132279be544a6f4dc22c22d244c98c23
Author: Tushar Behera <[email protected]>
Date:   Fri Mar 21 01:49:24 2014  0900

    ARM: SAMSUNG: Reorganize calls to reserve memory for MFC
    
    Reorganize code so that "plat/mfc.h" is no more referred
    from mach-exynos directory.
    
    Signed-off-by: Tushar Behera <[email protected]>
    Signed-off-by: Kukjin Kim <[email protected]>

commit ebf00060c33b9d0946384fa6f440df7ea35a569e
Author: Steve Wise <[email protected]>
Date:   Wed Mar 19 17:44:40 2014  0530

    RDMA/cxgb4: Always release neigh entry
    
    Always release the neigh entry in rx_pkt().
    
    Based on original work by Santosh Rastapur <[email protected]>.
    
    Signed-off-by: Steve Wise <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit f8e819081f797df355cffbdedb9301ea50ae76b2
Author: Steve Wise <[email protected]>
Date:   Wed Mar 19 17:44:39 2014  0530

    RDMA/cxgb4: Allow loopback connections
    
    find_route() must treat loopback as a valid egress interface.
    
    Signed-off-by: Steve Wise <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit ffd435924c86de055d33fe59941841819eef9f6a
Author: Steve Wise <[email protected]>
Date:   Wed Mar 19 17:44:38 2014  0530

    RDMA/cxgb4: Cap CQ size at T4_MAX_IQ_SIZE
    
    Signed-off-by: Steve Wise <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit e24a72a3302a638d4c6e77f0b40c45cc61c3f089
Author: Dan Carpenter <[email protected]>
Date:   Sat Oct 19 12:14:35 2013  0300

    RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq()
    
    There is a four byte hole at the end of the "uresp" struct after the
    ->qid_mask member.
    
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit ff1706f4feb8e0e1a2e56a8dd57e17a4b45649b5
Author: Dan Carpenter <[email protected]>
Date:   Sat Oct 19 12:14:12 2013  0300

    RDMA/cxgb4: Fix underflows in c4iw_create_qp()
    
    These sizes should be unsigned so we don't allow negative values and
    have underflow bugs.  These can come from the user so there may be
    security implications, but I have not tested this.
    
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Roland Dreier <[email protected]>

commit 4726e0b045b80c514377da35ca01467ef6a4de53
Author: Sagar Kamble <[email protected]>
Date:   Mon Mar 10 17:06:23 2014  0530

    drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
    
    With this patch we allow larger cursor planes of sizes 128x128
    and 256x256.
    
    v2: Added more precise check on size while setting cursor plane.
    
    v3: Changes related to restructuring cursor size restrictions
    and DRM_DEBUG usage.
    
    v4: Indentation related changes for setting cursor control and
    implementing DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT
    
    Testcase: igt/kms_cursor_crc
    Cc: Daniel Vetter <[email protected]>
    Cc: Jani Nikula <[email protected]>
    Cc: David Airlie <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: G, Pallavi <[email protected]>
    Signed-off-by: Sagar Kamble <[email protected]>
    Reviewed-by: Imre Deak <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>

commit 61b1a7fbda6f761ebe16a62124578ca0779d9365
Author: Johan Hedberg <[email protected]>
Date:   Thu Mar 20 12:54:16 2014  0200

    Bluetooth: Fix address value for early disconnection events
    
    We need to ensure that we do not send events to user space with the
    identity address if we have not yet notified user space of the IRK. The
    code was previously trying to handle this for the mgmt_pair_device
    response (which worked well enough) but this is not the only connection
    related event that might be sent to user space before pairing is
    successful: another important event is Device Disconnected.
    
    The issue can actually be solved more simply than the solution
    previously used for mgmt_pair_device. Since we do have the identity
    address tracked as part of the remote IRK struct we can just copy it
    over from there to the hci_conn struct once we've for real sent the mgmt
    event for the new IRK.
    
    Signed-off-by: Johan Hedberg <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit 204747c970c0d568721c76ab8a57dde0e5dcf0d5
Author: Guenter Roeck <[email protected]>
Date:   Thu Mar 20 08:12:28 2014 -0700

    mfd: kempld-core: Fix potential hang-up during boot
    
    On PXT and COMe-cPC2 boards it is observed that the hardware
    mutex is acquired but not being released during initialization.
    This can result in a hang-up during boot if the driver is built
    into the kernel.
    
    Releasing the mutex twice if it was acquired fixes the problem.
    Subsequent request/release cycles work as expected, so the fix is
    only needed during initialization.
    
    Cc: <[email protected]>
    Reviewed-by: Michael Brunner <[email protected]>
    Tested-by: Michael Brunner <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 5a78401623740c892868d5929b33f5cda8fe819e
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Mar 18 14:11:26 2014  0100

    mfd: sec-core: Fix uninitialized 'regmap_rtc' on S2MPA01
    
    Initialize the 'regmap_rtc' on S2MPA01 to some sane value. Sane at least
    for S5M87X chipsets, not S2MPS/S2MPA but it won't be used because
    rtc-s5m driver does not support S2MPA01.
    
    This fixes following error:
    drivers/mfd/sec-core.c:342:45: warning: ‘regmap_rtc’ may be used uninitialized in this function [-Wuninitialized]
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Sachin Kamat <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>

commit 67b3bd4e65f0854aca70e0134d59b1daede49504
Author: Arend van Spriel <[email protected]>
Date:   Thu Mar 20 10:18:03 2014  0100

    brcmfmac: fallback to mimo_bw_cap for older firmwares
    
    In order to support the driver behaviour introduced by:
    
       commit d0575a5a703978c43e25128421158c78534ba100
       Author: Daniel Kim <[email protected]>
       Date:   Wed Mar 12 18:12:14 2014 -0700
    
           brcmfmac: Enable 40MHz bandwidth in 2GHz band and OBSS scanning
    
    in devices that do not support bwcap firmware command a fallback
    is added.
    
    Reviewed-by: Daniel (Deognyoun) Kim <[email protected]>
    Reviewed-by: Pieter-Paul Giesberts <[email protected]>
    Signed-off-by: Arend van Spriel <[email protected]>
    Signed-off-by: John W. Linville <[email protected]>

commit 4d1a4f16c96d3f4cf6afd92ca3ffb4d2c24875e1
Author: Arend van Spriel <[email protected]>
Date:   Thu Mar 20 10:18:02 2014  0100

    brcmfmac: only show error message when brcmf_sdiod_regrw_helper() fails
    
    In the function brcmf_sdiod_request_data() an error message is logged,
    but the calling function retries it. This patch will only log an error
    message when retry limit is reached. The low-level error is still
    logged by a SDIO debug message.
    
    Reviewed-by: Daniel (Deognyoun) Kim <[email protected]>
    Reviewed-by: Pieter-Paul Giesberts <[email protected]>
    Signed-off-by: Arend van Spriel <[email protected]>
    Signed-off-by: John W. Linville <[email protected]>

commit 58e9df462fd70a1862378beb46b312f1f6bca94f
Author: Arend van Spriel <[email protected]>
Date:   Thu Mar 20 10:18:01 2014  0100

    brcmfmac: reinit watchdog completion after handling watchdog
    
    The watchdog thread waits on completion that is set from a timer. As
    the completion is count based this could mean that on a busy system
    the watchdog is handled multiple times with a very short interval.
    This is not the intended behaviour. After handling the watchdog it
    should wait for the next timer expiry. This is accomplished by
    reinitializing the completion.
    
    Reviewed-by: Hante Meuleman <[email protected]>
    Reviewed-by: Pieter-Paul Giesberts <[email protected]>
    Signed-off-by: Arend van Spriel <[email protected]>
    Signed-off-by: John W. Linville <[email protected]>

commit d23536796011cbeeb93fc866446800c52deb5603
Author: Daniel Kim <[email protected]>
Date:   Thu Mar 20 10:18:00 2014  0100

    brcmfmac: Enable 40MHz bandwidth in 2GHz band and OBSS scanning operations
    
    This patch enables 40MHz bandwidth in 2GHz band after checking whether
    cfg80211 allows it or not, and enables OBSS scanning operations to
    to support 20/40 BSS coexistence.
    
    Reviewed-by: Arend Van Spriel <[email protected]>
    Reviewed-by: Hante Meuleman <[email protected]>
    Reviewed-by: Pieter-Paul Giesberts <[email protected]>
    Signed-off-by: Daniel Kim <[email protected]>
    Signed-off-by: Arend van Spriel <[email protected]>
    Signed-off-by: John W. Linville <[email protected]>

commit 1fa3e2eb9db07f30a605c66d1a2fdde4b24e74d5
Author: Steve Dickson <[email protected]>
Date:   Thu Mar 20 11:23:03 2014 -0400

    SUNRPC: Ensure call_connect_status() deals correctly with SOFTCONN tasks
    
    Don't schedule an rpc_delay before checking to see if the task
    is a SOFTCONN because the tk_callback from the delay (__rpc_atrun)
    clears the task status before the rpc_exit_task can be run.
    
    Signed-off-by: Steve Dickson <[email protected]>
    Fixes: 561ec1603171c (SUNRPC: call_connect_status should recheck...)
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Trond Myklebust <[email protected]>

commit f5b972e9fbd2e99a2abc3221783d089799b69394
Author: Heiko Carstens <[email protected]>
Date:   Thu Mar 20 15:30:14 2014  0100

    compat: include linux/unistd.h within linux/compat.h
    
    linux/compat.h does not include linux/unistd.h but the compat.h header
    file contains various conditional
    
     #ifdef __ARCH_WANT_COMPAT_...
     asmlinkage long compat...()
     #endif
    
    compat system call function declarations.
    If linux/unistd.h isn't included it depends on previous includes if those
    __ARCH_WANT_COMPAT_... defines are defined or not. So add an additional
    linux/unistd.h include.
    
    Should fix this compile error on tile:
    
    include/uapi/asm-generic/unistd.h:195:1: error: 'compat_sys_getdents64' undeclared
    make[3]: *** [arch/tile/kernel/compat.o] Error 1
    
    Reported-by: Geert Uytterhoeven <[email protected]>
    Acked-by: Geert Uytterhoeven <[email protected]>
    Acked-by: Chris Metcalf <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>

commit e1b2dc176f2d5be7952c47a4e4e8f3b06a90db1c
Author: Tejun Heo <[email protected]>
Date:   Thu Mar 20 11:10:15 2014 -0400

    cgroup: break kernfs active_ref protection in cgroup directory operations
    
    cgroup_tree_mutex should nest above the kernfs active_ref protection;
    however, cgroup_create() and cgroup_rename() were grabbing
    cgroup_tree_mutex while under kernfs active_ref protection.  This has
    actualy possibility to lead to deadlocks in case these operations race
    against cgroup_rmdir() which invokes kernfs_remove() on directory
    kernfs_node while holding cgroup_tree_mutex.
    
    Neither cgroup_create() or cgroup_rename() requires active_ref
    protection.  The former already has enough synchronization through
    cgroup_lock_live_group() and the latter doesn't care, so this can be
    fixed by updating both functions to break all active_ref protections
    before grabbing cgroup_tree_mutex.
    
    While this patch fixes the immediate issue, it probably needs further
    work in the long term - kernfs directories should enable lockdep
    annotations and maybe the better way to handle this is marking
    directory nodes as not needing active_ref protection rather than
    breaking it in each operation.
    
    Signed-off-by: Tejun Heo <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>

commit 80e0b6e8a001361316a2d62b748fe677ec46b860
Author: Richard Guy Briggs <[email protected]>
Date:   Sun Mar 16 14:00:19 2014 -0400

    sched: declare pid_alive as inline
    
    We accidentally declared pid_alive without any extern/inline connotation.
    Some platforms were fine with this, some like ia64 and mips were very angry.
    If the function is inline, the prototype should be inline!
    
    on ia64:
    include/linux/sched.h:1718: warning: 'pid_alive' declared inline after
    being called
    
    Signed-off-by: Richard Guy Briggs <[email protected]>
    Signed-off-by: Eric Paris <[email protected]>

commit 579ec9e1ab0bdca2dbc3c942aa1a530a6ec8c349
Author: Eric Paris <[email protected]>
Date:   Tue Mar 11 12:55:42 2014 -0400

    audit: use uapi/linux/audit.h for AUDIT_ARCH declarations
    
    The syscall.h headers were including linux/audit.h but really only
    needed the uapi/linux/audit.h to get the requisite defines.  Switch to
    the uapi headers.
    
    Signed-off-by: Eric Paris <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]

commit 5e937a9ae9137899c6641d718bd3820861099a09
Author: Eric Paris <[email protected]>
Date:   Tue Mar 11 12:48:43 2014 -0400

    syscall_get_arch: remove useless function arguments
    
    Every caller of syscall_get_arch() uses current for the task and no
    implementors of the function need args.  So just get rid of both of
    those things.  Admittedly, since these are inline functions we aren't
    wasting stack space, but it just makes the prototypes better.
    
    Signed-off-by: Eric Paris <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]

commit b7550787fe8b5beffb5f56fa11a87712d699d085
Author: Joe Perches <jo…

The iommu_count field in si_domain(static identity domain) is
initialized to zero and never increases. It will underflow
when tearing down iommu unit in function free_dmar_iommu()
and leak memory. So refine code to correctly manage
si_domain->iommu_count.

Warning message caused by si_domain memory leak:
[   14.609681] IOMMU: Setting RMRR:
[   14.613496] Ignoring identity map for HW passthrough device 0000:00:1a.0 [0xbdcfd000 - 0xbdd1dfff]
[   14.623809] Ignoring identity map for HW passthrough device 0000:00:1d.0 [0xbdcfd000 - 0xbdd1dfff]
[   14.634162] IOMMU: Prepare 0-16MiB unity mapping for LPC
[   14.640329] Ignoring identity map for HW passthrough device 0000:00:1f.0 [0x0 - 0xffffff]
[   14.673360] IOMMU: dmar init failed
[   14.678157] kmem_cache_destroy iommu_devinfo: Slab cache still has objects
[   14.686076] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry  torvalds#59
[   14.694176] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
[   14.707412]  0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff880c2cc37c00
[   14.716407]  ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00
[   14.725468]  ffffffff81dc7a6a ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711
[   14.734464] Call Trace:
[   14.737453]  [<ffffffff8156223d>] dump_stack 0x4d/0x66
[   14.743430]  [<ffffffff811790b1>] kmem_cache_destroy 0xf1/0x100
[   14.750279]  [<ffffffff81dc7a6a>] intel_iommu_init 0x122/0x56a
[   14.757035]  [<ffffffff81d8a711>] ? iommu_setup 0x27d/0x27d
[   14.763491]  [<ffffffff81d8a739>] pci_iommu_init 0x28/0x52
[   14.769846]  [<ffffffff81000342>] do_one_initcall 0x122/0x180
[   14.776506]  [<ffffffff81077738>] ? parse_args 0x1e8/0x320
[   14.782866]  [<ffffffff81d850e8>] kernel_init_freeable 0x1e1/0x26c
[   14.789994]  [<ffffffff81d84833>] ? do_early_param 0x88/0x88
[   14.796556]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   14.802626]  [<ffffffff8154ffce>] kernel_init 0xe/0x130
[   14.808698]  [<ffffffff815756ac>] ret_from_fork 0x7c/0xb0
[   14.814963]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   14.821640] kmem_cache_destroy iommu_domain: Slab cache still has objects
[   14.829456] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry  torvalds#59
[   14.837562] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
[   14.850803]  0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff88102c1ee3c0
[   14.861222]  ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00
[   14.870284]  ffffffff81dc7a76 ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711
[   14.879271] Call Trace:
[   14.882227]  [<ffffffff8156223d>] dump_stack 0x4d/0x66
[   14.888197]  [<ffffffff811790b1>] kmem_cache_destroy 0xf1/0x100
[   14.895034]  [<ffffffff81dc7a76>] intel_iommu_init 0x12e/0x56a
[   14.901781]  [<ffffffff81d8a711>] ? iommu_setup 0x27d/0x27d
[   14.908238]  [<ffffffff81d8a739>] pci_iommu_init 0x28/0x52
[   14.914863]  [<ffffffff81000342>] do_one_initcall 0x122/0x180
[   14.921244]  [<ffffffff81077738>] ? parse_args 0x1e8/0x320
[   14.927598]  [<ffffffff81d850e8>] kernel_init_freeable 0x1e1/0x26c
[   14.934738]  [<ffffffff81d84833>] ? do_early_param 0x88/0x88
[   14.941309]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   14.947380]  [<ffffffff8154ffce>] kernel_init 0xe/0x130
[   14.953430]  [<ffffffff815756ac>] ret_from_fork 0x7c/0xb0
[   14.959689]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   14.966299] kmem_cache_destroy iommu_iova: Slab cache still has objects
[   14.973923] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry  torvalds#59
[   14.982020] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
[   14.995263]  0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff88042cb5c980
[   15.004265]  ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00
[   15.013322]  ffffffff81dc7a82 ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711
[   15.022318] Call Trace:
[   15.025238]  [<ffffffff8156223d>] dump_stack 0x4d/0x66
[   15.031202]  [<ffffffff811790b1>] kmem_cache_destroy 0xf1/0x100
[   15.038038]  [<ffffffff81dc7a82>] intel_iommu_init 0x13a/0x56a
[   15.044786]  [<ffffffff81d8a711>] ? iommu_setup 0x27d/0x27d
[   15.051242]  [<ffffffff81d8a739>] pci_iommu_init 0x28/0x52
[   15.057601]  [<ffffffff81000342>] do_one_initcall 0x122/0x180
[   15.064254]  [<ffffffff81077738>] ? parse_args 0x1e8/0x320
[   15.070608]  [<ffffffff81d850e8>] kernel_init_freeable 0x1e1/0x26c
[   15.077747]  [<ffffffff81d84833>] ? do_early_param 0x88/0x88
[   15.084300]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   15.090362]  [<ffffffff8154ffce>] kernel_init 0xe/0x130
[   15.096431]  [<ffffffff815756ac>] ret_from_fork 0x7c/0xb0
[   15.102693]  [<ffffffff8154ffc0>] ? rest_init 0xd0/0xd0
[   15.189273] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)

Signed-off-by: Jiang Liu <[email protected]>
Cc: Alex Williamson <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>

If the system had a few memory groups and all of them were destroyed,
memcg_limited_groups_array_size has non-zero value, but all new caches
are created without memcg_params, because memcg_kmem_enabled() returns
false.

We try to enumirate child caches in a few places and all of them are
potentially dangerous.

For example my kernel is compiled with CONFIG_SLAB and it crashed when I
tryed to mount a NFS share after a few experiments with kmemcg.

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: [<ffffffff8118166a>] do_tune_cpucache 0x8a/0xd0
  PGD b942a067 PUD b999f067 PMD 0
  Oops: 0000 [#1] SMP
  Modules linked in: fscache( ) ip6table_filter ip6_tables iptable_filter ip_tables i2c_piix4 pcspkr virtio_net virtio_balloon i2c_core floppy
  CPU: 0 PID: 357 Comm: modprobe Not tainted 3.11.0-rc7  torvalds#59
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  task: ffff8800b9f98240 ti: ffff8800ba32e000 task.ti: ffff8800ba32e000
  RIP: 0010:[<ffffffff8118166a>]  [<ffffffff8118166a>] do_tune_cpucache 0x8a/0xd0
  RSP: 0018:ffff8800ba32fb70  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
  RDX: 0000000000000000 RSI: ffff8800b9f98910 RDI: 0000000000000246
  RBP: ffff8800ba32fba0 R08: 0000000000000002 R09: 0000000000000004
  R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000010
  R13: 0000000000000008 R14: 00000000000000d0 R15: ffff8800375d0200
  FS:  00007f55f1378740(0000) GS:ffff8800bfa00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 00007f24feba57a0 CR3: 0000000037b51000 CR4: 00000000000006f0
  Call Trace:
    enable_cpucache 0x49/0x100
    setup_cpu_cache 0x215/0x280
    __kmem_cache_create 0x2fa/0x450
    kmem_cache_create_memcg 0x214/0x350
    kmem_cache_create 0x2b/0x30
    fscache_init 0x19b/0x230 [fscache]
    do_one_initcall 0xfa/0x1b0
    load_module 0x1c41/0x26d0
    SyS_finit_module 0x86/0xb0
    system_call_fastpath 0x16/0x1b

Signed-off-by: Andrey Vagin <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Christoph Lameter <[email protected]>
Cc: Glauber Costa <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

Fix power off code

dev_opp_list_lock is used everywhere to protect device and OPP lists,
but dev_pm_opp_set_sharing_cpus() is missed somehow. And instead we used
rcu-lock, which wouldn't help here as we are adding a new list_dev.

This also fixes a problem where we have called kzalloc(..., GFP_KERNEL)
from within rcu-lock, which isn't allowed as kzalloc can sleep when
called with GFP_KERNEL.

With CONFIG_DEBUG_ATOMIC_SLEEP set, we get following lockdep-splat:

include/linux/rcupdate.h:578 Illegal context switch in RCU read-side critical section!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
5 locks held by swapper/0/1:
 #0:  (&dev->mutex){......}, at: [<c02f68f4>] __driver_attach 0x48/0x98
 #1:  (&dev->mutex){......}, at: [<c02f6904>] __driver_attach 0x58/0x98
 #2:  (cpu_hotplug.lock){      }, at: [<c00249d0>] get_online_cpus 0x40/0xb0
 #3:  (subsys mutex#5){ . . .}, at: [<c02f4f8c>] subsys_interface_register 0x44/0xdc
 #4:  (rcu_read_lock){......}, at: [<c0305c80>] dev_pm_opp_set_sharing_cpus 0x0/0x1e4

stack backtrace:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W       4.3.0-rc7-00047-g81f5932958a8 torvalds#59
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c0016874>] (unwind_backtrace) from [<c001355c>] (show_stack 0x10/0x14)
[<c001355c>] (show_stack) from [<c022553c>] (dump_stack 0x94/0xbc)
[<c022553c>] (dump_stack) from [<c004904c>] (___might_sleep 0x24c/0x298)
[<c004904c>] (___might_sleep) from [<c00f07e4>] (kmem_cache_alloc 0xe8/0x164)
[<c00f07e4>] (kmem_cache_alloc) from [<c0305354>] (_add_list_dev 0x30/0x58)
[<c0305354>] (_add_list_dev) from [<c0305d50>] (dev_pm_opp_set_sharing_cpus 0xd0/0x1e4)
[<c0305d50>] (dev_pm_opp_set_sharing_cpus) from [<c040eda4>] (cpufreq_init 0x4cc/0x62c)
[<c040eda4>] (cpufreq_init) from [<c040a964>] (cpufreq_online 0xbc/0x73c)
[<c040a964>] (cpufreq_online) from [<c02f4fe0>] (subsys_interface_register 0x98/0xdc)
[<c02f4fe0>] (subsys_interface_register) from [<c040a640>] (cpufreq_register_driver 0x110/0x17c)
[<c040a640>] (cpufreq_register_driver) from [<c040ef64>] (dt_cpufreq_probe 0x60/0x8c)
[<c040ef64>] (dt_cpufreq_probe) from [<c02f8084>] (platform_drv_probe 0x44/0xa4)
[<c02f8084>] (platform_drv_probe) from [<c02f67c0>] (driver_probe_device 0x208/0x2f4)
[<c02f67c0>] (driver_probe_device) from [<c02f6940>] (__driver_attach 0x94/0x98)
[<c02f6940>] (__driver_attach) from [<c02f4c1c>] (bus_for_each_dev 0x68/0x9c)

Cc: 4.3 <[email protected]> # 4.3
Reported-by: Michael Turquette <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

dev_opp_list_lock is used everywhere to protect device and OPP lists,
but dev_pm_opp_set_sharing_cpus() is missed somehow. And instead we used
rcu-lock, which wouldn't help here as we are adding a new list_dev.

This also fixes a problem where we have called kzalloc(..., GFP_KERNEL)
from within rcu-lock, which isn't allowed as kzalloc can sleep when
called with GFP_KERNEL.

With CONFIG_DEBUG_ATOMIC_SLEEP set, we get following lockdep-splat:

include/linux/rcupdate.h:578 Illegal context switch in RCU read-side critical section!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
5 locks held by swapper/0/1:
 #0:  (&dev->mutex){......}, at: [<c02f68f4>] __driver_attach 0x48/0x98
 #1:  (&dev->mutex){......}, at: [<c02f6904>] __driver_attach 0x58/0x98
 #2:  (cpu_hotplug.lock){      }, at: [<c00249d0>] get_online_cpus 0x40/0xb0
 #3:  (subsys mutex#5){ . . .}, at: [<c02f4f8c>] subsys_interface_register 0x44/0xdc
 #4:  (rcu_read_lock){......}, at: [<c0305c80>] dev_pm_opp_set_sharing_cpus 0x0/0x1e4

stack backtrace:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W       4.3.0-rc7-00047-g81f5932958a8 torvalds#59
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c0016874>] (unwind_backtrace) from [<c001355c>] (show_stack 0x10/0x14)
[<c001355c>] (show_stack) from [<c022553c>] (dump_stack 0x94/0xbc)
[<c022553c>] (dump_stack) from [<c004904c>] (___might_sleep 0x24c/0x298)
[<c004904c>] (___might_sleep) from [<c00f07e4>] (kmem_cache_alloc 0xe8/0x164)
[<c00f07e4>] (kmem_cache_alloc) from [<c0305354>] (_add_list_dev 0x30/0x58)
[<c0305354>] (_add_list_dev) from [<c0305d50>] (dev_pm_opp_set_sharing_cpus 0xd0/0x1e4)
[<c0305d50>] (dev_pm_opp_set_sharing_cpus) from [<c040eda4>] (cpufreq_init 0x4cc/0x62c)
[<c040eda4>] (cpufreq_init) from [<c040a964>] (cpufreq_online 0xbc/0x73c)
[<c040a964>] (cpufreq_online) from [<c02f4fe0>] (subsys_interface_register 0x98/0xdc)
[<c02f4fe0>] (subsys_interface_register) from [<c040a640>] (cpufreq_register_driver 0x110/0x17c)
[<c040a640>] (cpufreq_register_driver) from [<c040ef64>] (dt_cpufreq_probe 0x60/0x8c)
[<c040ef64>] (dt_cpufreq_probe) from [<c02f8084>] (platform_drv_probe 0x44/0xa4)
[<c02f8084>] (platform_drv_probe) from [<c02f67c0>] (driver_probe_device 0x208/0x2f4)
[<c02f67c0>] (driver_probe_device) from [<c02f6940>] (__driver_attach 0x94/0x98)
[<c02f6940>] (__driver_attach) from [<c02f4c1c>] (bus_for_each_dev 0x68/0x9c)

Reported-by: Michael Turquette <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Cc: 4.3 <[email protected]> # 4.3
Signed-off-by: Rafael J. Wysocki <[email protected]>

exfat_upcase.c: mark uni_upcase table as "const".

commit 6f6b895 upstream.

If the system had a few memory groups and all of them were destroyed,
memcg_limited_groups_array_size has non-zero value, but all new caches
are created without memcg_params, because memcg_kmem_enabled() returns
false.

We try to enumirate child caches in a few places and all of them are
potentially dangerous.

For example my kernel is compiled with CONFIG_SLAB and it crashed when I
tryed to mount a NFS share after a few experiments with kmemcg.

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: [<ffffffff8118166a>] do_tune_cpucache 0x8a/0xd0
  PGD b942a067 PUD b999f067 PMD 0
  Oops: 0000 [#1] SMP
  Modules linked in: fscache( ) ip6table_filter ip6_tables iptable_filter ip_tables i2c_piix4 pcspkr virtio_net virtio_balloon i2c_core floppy
  CPU: 0 PID: 357 Comm: modprobe Not tainted 3.11.0-rc7  torvalds#59
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  task: ffff8800b9f98240 ti: ffff8800ba32e000 task.ti: ffff8800ba32e000
  RIP: 0010:[<ffffffff8118166a>]  [<ffffffff8118166a>] do_tune_cpucache 0x8a/0xd0
  RSP: 0018:ffff8800ba32fb70  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
  RDX: 0000000000000000 RSI: ffff8800b9f98910 RDI: 0000000000000246
  RBP: ffff8800ba32fba0 R08: 0000000000000002 R09: 0000000000000004
  R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000010
  R13: 0000000000000008 R14: 00000000000000d0 R15: ffff8800375d0200
  FS:  00007f55f1378740(0000) GS:ffff8800bfa00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 00007f24feba57a0 CR3: 0000000037b51000 CR4: 00000000000006f0
  Call Trace:
    enable_cpucache 0x49/0x100
    setup_cpu_cache 0x215/0x280
    __kmem_cache_create 0x2fa/0x450
    kmem_cache_create_memcg 0x214/0x350
    kmem_cache_create 0x2b/0x30
    fscache_init 0x19b/0x230 [fscache]
    do_one_initcall 0xfa/0x1b0
    load_module 0x1c41/0x26d0
    SyS_finit_module 0x86/0xb0
    system_call_fastpath 0x16/0x1b

Signed-off-by: Andrey Vagin <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Christoph Lameter <[email protected]>
Cc: Glauber Costa <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Johannes Weiner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Signed-off-by: Sasha Levin <[email protected]>

Move dma channel allocations to pcmops open and close functions. Reason
to do this is that, lpass_platform_pcm_free() accesses snd_soc_pcm_runtime
via substream->private data, However By this time runtimes are already
freed as part of soc_cleanup_card_resources() sequence.

This patch moves the channel allocations/deallocations to pcmops open()
and close() respectively, where the code has valid snd_soc_pcm_runtime.

Without this patch unloading lpass sound card module would result in below
crash:

Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd = ffff800038f0d000
[00000000] *pgd=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in: snd_soc_apq8016_sbc(-) snd_soc_lpass_apq8016
snd_soc_lpass_cpu snd_soc_lpass_platform
CPU: 0 PID: 1573 Comm: rmmod Not tainted 4.7.0-rc2-next-20160609  torvalds#59
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
task: ffff800038cd0000 ti: ffff80003929c000 task.ti: ffff80003929c000
PC is at lpass_platform_pcm_free 0xc4/0x1c0 [snd_soc_lpass_platform]
LR is at lpass_platform_pcm_free 0xb8/0x1c0 [snd_soc_lpass_platform]
pc : [<ffff000000b20b64>] lr : [<ffff000000b20b58>] pstate: 60000145
sp : ffff80003929fa90
x29: ffff80003929fa90 x28: ffff000000b22438
x27: ffff000000b22450 x26: ffff000000b22468
x25: ffff000000b22488 x24: ffff000000b223f0
x23: ffff000000b22418 x22: ffff800038f428c0
x21: ffff8000392ae280 x20: 0000000000000001
x19: ffff000000b22118 x18: 0000ffffdc331600
x17: 0000ffffb78036c0 x16: ffff0000081c16e8
x15: 0000ffffb77f0588 x14: 3d4d554e51455300
x13: ffffffffffff0000 x12: 0000000000000028
x11: 0000000000000044 x10: ffff80003929f822
x9 : ffff80003929f823 x8 : 0000000000000000
x7 : 0000000000000004 x6 : ffff000008864890
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 0000000000000000 x2 : ffff80003efac228
x1 : ffff000000b22118 x0 : ffff000000b22450

Process rmmod (pid: 1573, stack limit = 0xffff80003929c020)
Stack: (0xffff80003929fa90 to 0xffff8000392a0000)
fa80:                                  ffff80003929fb40 ffff0000086d1f8c
faa0: ffff000008ca5408 ffff800038f42200 ffff000008ca5420 000000000000000b
fac0: ffff80003929fd70 0000000000000015 0000000000000120 000000000000006a
fae0: ffff0000087f2000 ffff80003929c000 ffff80003929fb40 ffff8000392ae358
fb00: ffff8000392af900 0000000000000000 ffff8000392afa48 000000000000000b
fb20: ffff80003929fd70 0000000000000015 ffff80003929fb80 ffff0000086cc070
fb40: ffff80003929fb70 ffff0000086d21d4 ffff800038f7fa00 ffff8000392801a0
fb60: ffff800038cf2000 0000000000000015 ffff80003929fb80 ffff0000086cc064
fb80: ffff80003929fba0 ffff0000086cc1f4 ffff800038f70600 000000000000000b
fba0: ffff80003929fbc0 ffff0000086c68a8 ffff800039280000 ffff800039280540
fbc0: ffff80003929fbe0 ffff0000084a7438 ffff800039280540 ffff800039280550
fbe0: ffff80003929fc10 ffff000008355ddc ffff800039280550 ffff000008c64718
fc00: ffff800038f61d00 ffff000008ca5190 ffff80003929fc40 ffff000008355e5c
fc20: ffff800039280550 ffff800039280000 ffff80003847b618 ffff800039280000
fc40: ffff80003929fc60 ffff0000084a77d8 0000000000000000 0000000000000015
fc60: ffff80003929fc70 ffff0000086c6e58 ffff80003929fc90 ffff0000086c6fbc
fc80: ffff80003929fcb0 ffff800039280000 ffff80003929fcd0 ffff0000086e3e50
fca0: ffff80003847b050 ffff80003847b728 ffff800000000000 ffff000000000000
fcc0: ffff80003929fcc0 ffff80003929fcc0 ffff80003929fd00 ffff0000086e4c8c
fce0: ffff80003847b618 ffff800038f61100 ffff8000399ddf90 000000000000000b
fd00: ffff80003929fd20 ffff0000086f0684 ffff800038f61000 ffff0000080d51c0
fd20: ffff80003929fd30 ffff0000084af904 ffff80003929fd80 ffff0000084afcf8
fd40: ffff8000399ddf90 ffff000000b3c028 ffff8000399ddff0 ffff000008cc8000
fd60: 0000000080000000 ffff0000084ac090 ffff800038f94600 ffff800038f61000
fd80: ffff80003929fda0 ffff0000084ac0b0 ffff8000399ddf90 ffff000000b3c028
fda0: ffff80003929fdc0 ffff0000084ac234 ffff8000399ddf90 ffff000000b3c028
fdc0: ffff80003929fdf0 ffff0000084ab3d4 ffff000000b3c028 ffff000008c64000
fde0: ffff000008c64818 ffff000000000001 ffff80003929fe20 ffff0000084ac8ac
fe00: ffff000000b3c028 ffff000000b3c100 fffffffffffffff5 0000000000000000
fe20: ffff80003929fe40 ffff0000084ad998 ffff000008c2d000 0000000000000015
fe40: ffff80003929fe50 ffff000000b3a460 ffff80003929fe60 ffff000008120fe4
fe60: 0000000000000000 ffff000008084e70 0000000000000000 0000000000000000
fe80: ffffffffffffffff 0000ffff954cca48 0000000000000004 5f636f735f646e73
fea0: 5f36313038717061 0000000000636273 0000000000000000 ffff000008084d64
fec0: 0000000000000000 0000000000000000 0000aaaabc814340 0000000000000800
fee0: 4fdc43dac03e2300 0000000000002002 0000ffff95548e58 0000ffffd9f89fb9
ff00: 0000000000000000 0000000000000000 000000000000006a 1999999999999999
ff20: 00000000ffffffff 0000000000000000 0000000000000005 ffffffffffffffff
ff40: 0000ffff95402a94 0000ffff9554a588 0000ffff954cca40 0000aaaaaf8d22d0
ff60: 0000ffffd9f8ad70 0000aaaabc8142e0 0000000000000000 0000000000000000
ff80: 0000ffffd9f8be7c 0000000000000000 0000ffffd9f8b0e0 0000ffffd9f8b2b8
ffa0: 0000aaaabc8142e0 0000aaaabc813010 0000000000000000 0000ffffd9f8b010
ffc0: 0000aaaaaf8b5ad4 0000ffffd9f8b010 0000ffff954cca48 0000000080000000
ffe0: 0000aaaabc814340 000000000000006a 0000060000000000 00000000fffefcaf
Call trace:
Exception stack(0xffff80003929f8d0 to 0xffff80003929f9f0)
f8c0:                                   ffff000000b22118 00000000000001
f8e0: ffff80003929fa90 ffff000000b20b64 ffff80003929f910 ffff000008a12f40
f900: ffff000008c15b78 0000000100000001 ffff80003929f9b0 ffff0000080f66e0
f920: ffff000000b22118 0000000000000001 ffff8000392ae280 ffff800038f428c0
f940: ffff000000b22418 ffff000000b223f0 ffff000000b22488 ffff000000b22468
f960: ffff000000b22450 ffff000000b22438 ffff000000b22450 ffff000000b22118
f980: ffff80003efac228 0000000000000000 0000000000000000 0000000000000000
f9a0: ffff000008864890 0000000000000004 0000000000000000 ffff80003929f823
f9c0: ffff80003929f822 0000000000000044 0000000000000028 ffffffffffff0000
f9e0: 3d4d554e51455300 0000ffffb77f0588
[<ffff000000b20b64>] lpass_platform_pcm_free 0xc4/0x1c0 [snd_soc_lpass_platform]
[<ffff0000086d1f8c>] snd_pcm_free 0x30/0xa0
[<ffff0000086d21d4>] snd_pcm_dev_free 0x10/0x18
[<ffff0000086cc064>] __snd_device_free 0x58/0xa0
[<ffff0000086cc1f4>] snd_device_free_all 0x2c/0x48
[<ffff0000086c68a8>] release_card_device 0x1c/0x74
[<ffff0000084a7438>] device_release 0x34/0x90
[<ffff000008355ddc>] kobject_release 0x44/0x84
[<ffff000008355e5c>] kobject_put 0x40/0x68
[<ffff0000084a77d8>] put_device 0x14/0x1c
[<ffff0000086c6e58>] snd_card_free_when_closed 0x24/0x34
[<ffff0000086c6fbc>] snd_card_free 0x40/0x60
[<ffff0000086e3e50>] soc_cleanup_card_resources 0x80/0x94
[<ffff0000086e4c8c>] snd_soc_unregister_card 0x28/0x38
[<ffff0000086f0684>] devm_card_release 0x10/0x18
[<ffff0000084af904>] release_nodes 0x124/0x208
[<ffff0000084afcf8>] devres_release_all 0x34/0x54
[<ffff0000084ac0b0>] __device_release_driver 0x84/0xfc
[<ffff0000084ac234>] driver_detach 0xbc/0xc0
[<ffff0000084ab3d4>] bus_remove_driver 0x58/0xac
[<ffff0000084ac8ac>] driver_unregister 0x2c/0x4c
[<ffff0000084ad998>] platform_driver_unregister 0x10/0x18
[<ffff000000b3a460>] apq8016_sbc_platform_driver_exit 0x10/0xbb0 [snd_soc_apq8016_sbc]
[<ffff000008120fe4>] SyS_delete_module 0x1b8/0x1fc
[<ffff000008084e70>] el0_svc_naked 0x24/0x28
Signed-off-by: Srinivas Kandagatla <[email protected]>

Move dma channel allocations to pcmops open and close functions. Reason
to do this is that, lpass_platform_pcm_free() accesses snd_soc_pcm_runtime
via substream->private data, However By this time runtimes are already
freed as part of soc_cleanup_card_resources() sequence.

This patch moves the channel allocations/deallocations to pcmops open()
and close() respectively, where the code has valid snd_soc_pcm_runtime.

Without this patch unloading lpass sound card module would result in below
crash:

Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd = ffff800038f0d000
[00000000] *pgd=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in: snd_soc_apq8016_sbc(-) snd_soc_lpass_apq8016
snd_soc_lpass_cpu snd_soc_lpass_platform
CPU: 0 PID: 1573 Comm: rmmod Not tainted 4.7.0-rc2-next-20160609  torvalds#59
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
task: ffff800038cd0000 ti: ffff80003929c000 task.ti: ffff80003929c000
PC is at lpass_platform_pcm_free 0xc4/0x1c0 [snd_soc_lpass_platform]
LR is at lpass_platform_pcm_free 0xb8/0x1c0 [snd_soc_lpass_platform]
pc : [<ffff000000b20b64>] lr : [<ffff000000b20b58>] pstate: 60000145
sp : ffff80003929fa90
x29: ffff80003929fa90 x28: ffff000000b22438
x27: ffff000000b22450 x26: ffff000000b22468
x25: ffff000000b22488 x24: ffff000000b223f0
x23: ffff000000b22418 x22: ffff800038f428c0
x21: ffff8000392ae280 x20: 0000000000000001
x19: ffff000000b22118 x18: 0000ffffdc331600
x17: 0000ffffb78036c0 x16: ffff0000081c16e8
x15: 0000ffffb77f0588 x14: 3d4d554e51455300
x13: ffffffffffff0000 x12: 0000000000000028
x11: 0000000000000044 x10: ffff80003929f822
x9 : ffff80003929f823 x8 : 0000000000000000
x7 : 0000000000000004 x6 : ffff000008864890
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 0000000000000000 x2 : ffff80003efac228
x1 : ffff000000b22118 x0 : ffff000000b22450

Process rmmod (pid: 1573, stack limit = 0xffff80003929c020)
Stack: (0xffff80003929fa90 to 0xffff8000392a0000)
fa80:                                  ffff80003929fb40 ffff0000086d1f8c
faa0: ffff000008ca5408 ffff800038f42200 ffff000008ca5420 000000000000000b
fac0: ffff80003929fd70 0000000000000015 0000000000000120 000000000000006a
fae0: ffff0000087f2000 ffff80003929c000 ffff80003929fb40 ffff8000392ae358
fb00: ffff8000392af900 0000000000000000 ffff8000392afa48 000000000000000b
fb20: ffff80003929fd70 0000000000000015 ffff80003929fb80 ffff0000086cc070
fb40: ffff80003929fb70 ffff0000086d21d4 ffff800038f7fa00 ffff8000392801a0
fb60: ffff800038cf2000 0000000000000015 ffff80003929fb80 ffff0000086cc064
fb80: ffff80003929fba0 ffff0000086cc1f4 ffff800038f70600 000000000000000b
fba0: ffff80003929fbc0 ffff0000086c68a8 ffff800039280000 ffff800039280540
fbc0: ffff80003929fbe0 ffff0000084a7438 ffff800039280540 ffff800039280550
fbe0: ffff80003929fc10 ffff000008355ddc ffff800039280550 ffff000008c64718
fc00: ffff800038f61d00 ffff000008ca5190 ffff80003929fc40 ffff000008355e5c
fc20: ffff800039280550 ffff800039280000 ffff80003847b618 ffff800039280000
fc40: ffff80003929fc60 ffff0000084a77d8 0000000000000000 0000000000000015
fc60: ffff80003929fc70 ffff0000086c6e58 ffff80003929fc90 ffff0000086c6fbc
fc80: ffff80003929fcb0 ffff800039280000 ffff80003929fcd0 ffff0000086e3e50
fca0: ffff80003847b050 ffff80003847b728 ffff800000000000 ffff000000000000
fcc0: ffff80003929fcc0 ffff80003929fcc0 ffff80003929fd00 ffff0000086e4c8c
fce0: ffff80003847b618 ffff800038f61100 ffff8000399ddf90 000000000000000b
fd00: ffff80003929fd20 ffff0000086f0684 ffff800038f61000 ffff0000080d51c0
fd20: ffff80003929fd30 ffff0000084af904 ffff80003929fd80 ffff0000084afcf8
fd40: ffff8000399ddf90 ffff000000b3c028 ffff8000399ddff0 ffff000008cc8000
fd60: 0000000080000000 ffff0000084ac090 ffff800038f94600 ffff800038f61000
fd80: ffff80003929fda0 ffff0000084ac0b0 ffff8000399ddf90 ffff000000b3c028
fda0: ffff80003929fdc0 ffff0000084ac234 ffff8000399ddf90 ffff000000b3c028
fdc0: ffff80003929fdf0 ffff0000084ab3d4 ffff000000b3c028 ffff000008c64000
fde0: ffff000008c64818 ffff000000000001 ffff80003929fe20 ffff0000084ac8ac
fe00: ffff000000b3c028 ffff000000b3c100 fffffffffffffff5 0000000000000000
fe20: ffff80003929fe40 ffff0000084ad998 ffff000008c2d000 0000000000000015
fe40: ffff80003929fe50 ffff000000b3a460 ffff80003929fe60 ffff000008120fe4
fe60: 0000000000000000 ffff000008084e70 0000000000000000 0000000000000000
fe80: ffffffffffffffff 0000ffff954cca48 0000000000000004 5f636f735f646e73
fea0: 5f36313038717061 0000000000636273 0000000000000000 ffff000008084d64
fec0: 0000000000000000 0000000000000000 0000aaaabc814340 0000000000000800
fee0: 4fdc43dac03e2300 0000000000002002 0000ffff95548e58 0000ffffd9f89fb9
ff00: 0000000000000000 0000000000000000 000000000000006a 1999999999999999
ff20: 00000000ffffffff 0000000000000000 0000000000000005 ffffffffffffffff
ff40: 0000ffff95402a94 0000ffff9554a588 0000ffff954cca40 0000aaaaaf8d22d0
ff60: 0000ffffd9f8ad70 0000aaaabc8142e0 0000000000000000 0000000000000000
ff80: 0000ffffd9f8be7c 0000000000000000 0000ffffd9f8b0e0 0000ffffd9f8b2b8
ffa0: 0000aaaabc8142e0 0000aaaabc813010 0000000000000000 0000ffffd9f8b010
ffc0: 0000aaaaaf8b5ad4 0000ffffd9f8b010 0000ffff954cca48 0000000080000000
ffe0: 0000aaaabc814340 000000000000006a 0000060000000000 00000000fffefcaf
Call trace:
Exception stack(0xffff80003929f8d0 to 0xffff80003929f9f0)
f8c0:                                   ffff000000b22118 00000000000001
f8e0: ffff80003929fa90 ffff000000b20b64 ffff80003929f910 ffff000008a12f40
f900: ffff000008c15b78 0000000100000001 ffff80003929f9b0 ffff0000080f66e0
f920: ffff000000b22118 0000000000000001 ffff8000392ae280 ffff800038f428c0
f940: ffff000000b22418 ffff000000b223f0 ffff000000b22488 ffff000000b22468
f960: ffff000000b22450 ffff000000b22438 ffff000000b22450 ffff000000b22118
f980: ffff80003efac228 0000000000000000 0000000000000000 0000000000000000
f9a0: ffff000008864890 0000000000000004 0000000000000000 ffff80003929f823
f9c0: ffff80003929f822 0000000000000044 0000000000000028 ffffffffffff0000
f9e0: 3d4d554e51455300 0000ffffb77f0588
[<ffff000000b20b64>] lpass_platform_pcm_free 0xc4/0x1c0 [snd_soc_lpass_platform]
[<ffff0000086d1f8c>] snd_pcm_free 0x30/0xa0
[<ffff0000086d21d4>] snd_pcm_dev_free 0x10/0x18
[<ffff0000086cc064>] __snd_device_free 0x58/0xa0
[<ffff0000086cc1f4>] snd_device_free_all 0x2c/0x48
[<ffff0000086c68a8>] release_card_device 0x1c/0x74
[<ffff0000084a7438>] device_release 0x34/0x90
[<ffff000008355ddc>] kobject_release 0x44/0x84
[<ffff000008355e5c>] kobject_put 0x40/0x68
[<ffff0000084a77d8>] put_device 0x14/0x1c
[<ffff0000086c6e58>] snd_card_free_when_closed 0x24/0x34
[<ffff0000086c6fbc>] snd_card_free 0x40/0x60
[<ffff0000086e3e50>] soc_cleanup_card_resources 0x80/0x94
[<ffff0000086e4c8c>] snd_soc_unregister_card 0x28/0x38
[<ffff0000086f0684>] devm_card_release 0x10/0x18
[<ffff0000084af904>] release_nodes 0x124/0x208
[<ffff0000084afcf8>] devres_release_all 0x34/0x54
[<ffff0000084ac0b0>] __device_release_driver 0x84/0xfc
[<ffff0000084ac234>] driver_detach 0xbc/0xc0
[<ffff0000084ab3d4>] bus_remove_driver 0x58/0xac
[<ffff0000084ac8ac>] driver_unregister 0x2c/0x4c
[<ffff0000084ad998>] platform_driver_unregister 0x10/0x18
[<ffff000000b3a460>] apq8016_sbc_platform_driver_exit 0x10/0xbb0 [snd_soc_apq8016_sbc]
[<ffff000008120fe4>] SyS_delete_module 0x1b8/0x1fc
[<ffff000008084e70>] el0_svc_naked 0x24/0x28

Signed-off-by: Srinivas Kandagatla <[email protected]>

Move dma channel allocations to pcmops open and close functions. Reason
to do this is that, lpass_platform_pcm_free() accesses snd_soc_pcm_runtime
via substream->private data, However By this time runtimes are already
freed as part of soc_cleanup_card_resources() sequence.

This patch moves the channel allocations/deallocations to pcmops open()
and close() respectively, where the code has valid snd_soc_pcm_runtime.

Without this patch unloading lpass sound card module would result in below
crash:

Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd = ffff800038f0d000
[00000000] *pgd=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in: snd_soc_apq8016_sbc(-) snd_soc_lpass_apq8016
snd_soc_lpass_cpu snd_soc_lpass_platform
CPU: 0 PID: 1573 Comm: rmmod Not tainted 4.7.0-rc2-next-20160609  torvalds#59
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
task: ffff800038cd0000 ti: ffff80003929c000 task.ti: ffff80003929c000
PC is at lpass_platform_pcm_free 0xc4/0x1c0 [snd_soc_lpass_platform]
LR is at lpass_platform_pcm_free 0xb8/0x1c0 [snd_soc_lpass_platform]
pc : [<ffff000000b20b64>] lr : [<ffff000000b20b58>] pstate: 60000145
sp : ffff80003929fa90
x29: ffff80003929fa90 x28: ffff000000b22438
x27: ffff000000b22450 x26: ffff000000b22468
x25: ffff000000b22488 x24: ffff000000b223f0
x23: ffff000000b22418 x22: ffff800038f428c0
x21: ffff8000392ae280 x20: 0000000000000001
x19: ffff000000b22118 x18: 0000ffffdc331600
x17: 0000ffffb78036c0 x16: ffff0000081c16e8
x15: 0000ffffb77f0588 x14: 3d4d554e51455300
x13: ffffffffffff0000 x12: 0000000000000028
x11: 0000000000000044 x10: ffff80003929f822
x9 : ffff80003929f823 x8 : 0000000000000000
x7 : 0000000000000004 x6 : ffff000008864890
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 0000000000000000 x2 : ffff80003efac228
x1 : ffff000000b22118 x0 : ffff000000b22450

Process rmmod (pid: 1573, stack limit = 0xffff80003929c020)
Stack: (0xffff80003929fa90 to 0xffff8000392a0000)
fa80:                                  ffff80003929fb40 ffff0000086d1f8c
faa0: ffff000008ca5408 ffff800038f42200 ffff000008ca5420 000000000000000b
fac0: ffff80003929fd70 0000000000000015 0000000000000120 000000000000006a
fae0: ffff0000087f2000 ffff80003929c000 ffff80003929fb40 ffff8000392ae358
fb00: ffff8000392af900 0000000000000000 ffff8000392afa48 000000000000000b
fb20: ffff80003929fd70 0000000000000015 ffff80003929fb80 ffff0000086cc070
fb40: ffff80003929fb70 ffff0000086d21d4 ffff800038f7fa00 ffff8000392801a0
fb60: ffff800038cf2000 0000000000000015 ffff80003929fb80 ffff0000086cc064
fb80: ffff80003929fba0 ffff0000086cc1f4 ffff800038f70600 000000000000000b
fba0: ffff80003929fbc0 ffff0000086c68a8 ffff800039280000 ffff800039280540
fbc0: ffff80003929fbe0 ffff0000084a7438 ffff800039280540 ffff800039280550
fbe0: ffff80003929fc10 ffff000008355ddc ffff800039280550 ffff000008c64718
fc00: ffff800038f61d00 ffff000008ca5190 ffff80003929fc40 ffff000008355e5c
fc20: ffff800039280550 ffff800039280000 ffff80003847b618 ffff800039280000
fc40: ffff80003929fc60 ffff0000084a77d8 0000000000000000 0000000000000015
fc60: ffff80003929fc70 ffff0000086c6e58 ffff80003929fc90 ffff0000086c6fbc
fc80: ffff80003929fcb0 ffff800039280000 ffff80003929fcd0 ffff0000086e3e50
fca0: ffff80003847b050 ffff80003847b728 ffff800000000000 ffff000000000000
fcc0: ffff80003929fcc0 ffff80003929fcc0 ffff80003929fd00 ffff0000086e4c8c
fce0: ffff80003847b618 ffff800038f61100 ffff8000399ddf90 000000000000000b
fd00: ffff80003929fd20 ffff0000086f0684 ffff800038f61000 ffff0000080d51c0
fd20: ffff80003929fd30 ffff0000084af904 ffff80003929fd80 ffff0000084afcf8
fd40: ffff8000399ddf90 ffff000000b3c028 ffff8000399ddff0 ffff000008cc8000
fd60: 0000000080000000 ffff0000084ac090 ffff800038f94600 ffff800038f61000
fd80: ffff80003929fda0 ffff0000084ac0b0 ffff8000399ddf90 ffff000000b3c028
fda0: ffff80003929fdc0 ffff0000084ac234 ffff8000399ddf90 ffff000000b3c028
fdc0: ffff80003929fdf0 ffff0000084ab3d4 ffff000000b3c028 ffff000008c64000
fde0: ffff000008c64818 ffff000000000001 ffff80003929fe20 ffff0000084ac8ac
fe00: ffff000000b3c028 ffff000000b3c100 fffffffffffffff5 0000000000000000
fe20: ffff80003929fe40 ffff0000084ad998 ffff000008c2d000 0000000000000015
fe40: ffff80003929fe50 ffff000000b3a460 ffff80003929fe60 ffff000008120fe4
fe60: 0000000000000000 ffff000008084e70 0000000000000000 0000000000000000
fe80: ffffffffffffffff 0000ffff954cca48 0000000000000004 5f636f735f646e73
fea0: 5f36313038717061 0000000000636273 0000000000000000 ffff000008084d64
fec0: 0000000000000000 0000000000000000 0000aaaabc814340 0000000000000800
fee0: 4fdc43dac03e2300 0000000000002002 0000ffff95548e58 0000ffffd9f89fb9
ff00: 0000000000000000 0000000000000000 000000000000006a 1999999999999999
ff20: 00000000ffffffff 0000000000000000 0000000000000005 ffffffffffffffff
ff40: 0000ffff95402a94 0000ffff9554a588 0000ffff954cca40 0000aaaaaf8d22d0
ff60: 0000ffffd9f8ad70 0000aaaabc8142e0 0000000000000000 0000000000000000
ff80: 0000ffffd9f8be7c 0000000000000000 0000ffffd9f8b0e0 0000ffffd9f8b2b8
ffa0: 0000aaaabc8142e0 0000aaaabc813010 0000000000000000 0000ffffd9f8b010
ffc0: 0000aaaaaf8b5ad4 0000ffffd9f8b010 0000ffff954cca48 0000000080000000
ffe0: 0000aaaabc814340 000000000000006a 0000060000000000 00000000fffefcaf
Call trace:
Exception stack(0xffff80003929f8d0 to 0xffff80003929f9f0)
f8c0:                                   ffff000000b22118 00000000000001
f8e0: ffff80003929fa90 ffff000000b20b64 ffff80003929f910 ffff000008a12f40
f900: ffff000008c15b78 0000000100000001 ffff80003929f9b0 ffff0000080f66e0
f920: ffff000000b22118 0000000000000001 ffff8000392ae280 ffff800038f428c0
f940: ffff000000b22418 ffff000000b223f0 ffff000000b22488 ffff000000b22468
f960: ffff000000b22450 ffff000000b22438 ffff000000b22450 ffff000000b22118
f980: ffff80003efac228 0000000000000000 0000000000000000 0000000000000000
f9a0: ffff000008864890 0000000000000004 0000000000000000 ffff80003929f823
f9c0: ffff80003929f822 0000000000000044 0000000000000028 ffffffffffff0000
f9e0: 3d4d554e51455300 0000ffffb77f0588
[<ffff000000b20b64>] lpass_platform_pcm_free 0xc4/0x1c0 [snd_soc_lpass_platform]
[<ffff0000086d1f8c>] snd_pcm_free 0x30/0xa0
[<ffff0000086d21d4>] snd_pcm_dev_free 0x10/0x18
[<ffff0000086cc064>] __snd_device_free 0x58/0xa0
[<ffff0000086cc1f4>] snd_device_free_all 0x2c/0x48
[<ffff0000086c68a8>] release_card_device 0x1c/0x74
[<ffff0000084a7438>] device_release 0x34/0x90
[<ffff000008355ddc>] kobject_release 0x44/0x84
[<ffff000008355e5c>] kobject_put 0x40/0x68
[<ffff0000084a77d8>] put_device 0x14/0x1c
[<ffff0000086c6e58>] snd_card_free_when_closed 0x24/0x34
[<ffff0000086c6fbc>] snd_card_free 0x40/0x60
[<ffff0000086e3e50>] soc_cleanup_card_resources 0x80/0x94
[<ffff0000086e4c8c>] snd_soc_unregister_card 0x28/0x38
[<ffff0000086f0684>] devm_card_release 0x10/0x18
[<ffff0000084af904>] release_nodes 0x124/0x208
[<ffff0000084afcf8>] devres_release_all 0x34/0x54
[<ffff0000084ac0b0>] __device_release_driver 0x84/0xfc
[<ffff0000084ac234>] driver_detach 0xbc/0xc0
[<ffff0000084ab3d4>] bus_remove_driver 0x58/0xac
[<ffff0000084ac8ac>] driver_unregister 0x2c/0x4c
[<ffff0000084ad998>] platform_driver_unregister 0x10/0x18
[<ffff000000b3a460>] apq8016_sbc_platform_driver_exit 0x10/0xbb0 [snd_soc_apq8016_sbc]
[<ffff000008120fe4>] SyS_delete_module 0x1b8/0x1fc
[<ffff000008084e70>] el0_svc_naked 0x24/0x28

Signed-off-by: Srinivas Kandagatla <[email protected]>

…ckpatch-fixes

WARNING: line over 80 characters
torvalds#59: FILE: mm/mempolicy.c:1686:
 		 * __GFP_THISNODE shouldn't even be used with the bind policy because

WARNING: line over 80 characters
torvalds#60: FILE: mm/mempolicy.c:1687:
 		 * we might easily break the expectation to stay on the requested node

WARNING: line over 80 characters
torvalds#69: FILE: mm/mempolicy.c:1690:
 		WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));

total: 0 errors, 3 warnings, 33 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ckpatch-fixes

WARNING: line over 80 characters
torvalds#59: FILE: mm/mempolicy.c:1686:
 		 * __GFP_THISNODE shouldn't even be used with the bind policy because

WARNING: line over 80 characters
torvalds#60: FILE: mm/mempolicy.c:1687:
 		 * we might easily break the expectation to stay on the requested node

WARNING: line over 80 characters
torvalds#69: FILE: mm/mempolicy.c:1690:
 		WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));

total: 0 errors, 3 warnings, 33 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ckpatch-fixes

WARNING: line over 80 characters
torvalds#59: FILE: mm/mempolicy.c:1686:
 		 * __GFP_THISNODE shouldn't even be used with the bind policy because

WARNING: line over 80 characters
torvalds#60: FILE: mm/mempolicy.c:1687:
 		 * we might easily break the expectation to stay on the requested node

WARNING: line over 80 characters
torvalds#69: FILE: mm/mempolicy.c:1690:
 		WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));

total: 0 errors, 3 warnings, 33 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ckpatch-fixes

WARNING: line over 80 characters
torvalds#59: FILE: mm/mempolicy.c:1686:
 		 * __GFP_THISNODE shouldn't even be used with the bind policy because

WARNING: line over 80 characters
torvalds#60: FILE: mm/mempolicy.c:1687:
 		 * we might easily break the expectation to stay on the requested node

WARNING: line over 80 characters
torvalds#69: FILE: mm/mempolicy.c:1690:
 		WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));

total: 0 errors, 3 warnings, 33 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ckpatch-fixes

WARNING: line over 80 characters
torvalds#59: FILE: mm/mempolicy.c:1686:
 		 * __GFP_THISNODE shouldn't even be used with the bind policy because

WARNING: line over 80 characters
torvalds#60: FILE: mm/mempolicy.c:1687:
 		 * we might easily break the expectation to stay on the requested node

WARNING: line over 80 characters
torvalds#69: FILE: mm/mempolicy.c:1690:
 		WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));

total: 0 errors, 3 warnings, 33 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

When removing and adding cpu 0 on a system with GHES NMI the following stack
trace is seen when re-adding the cpu:

WARNING: CPU: 0 PID: 0 at arch/x86/kernel/apic/apic.c:1349 setup_local_APIC 
Modules linked in: nfsv3 rpcsec_gss_krb5 nfsv4 nfs fscache coretemp intel_ra
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc5  torvalds#59
Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.01.00.0
ffffffff81c03e78 ffffffff81337905 0000000000000000 0000000000000000
ffffffff81c03eb8 ffffffff8107d9c1 00000545810aac4a 0000000000000000
00000000000000f0 0000000000000000 000081cb6440f1d0 0000000000000001
Call Trace:
[<ffffffff81337905>] dump_stack 0x63/0x8e
[<ffffffff8107d9c1>] __warn 0xd1/0xf0
[<ffffffff8107daad>] warn_slowpath_null 0x1d/0x20
[<ffffffff810522b5>] setup_local_APIC 0x275/0x370
[<ffffffff810523be>] apic_ap_setup 0xe/0x20
[<ffffffff8104f5a8>] start_secondary 0x48/0x180
[<ffffffff81d89aa0>] ? set_init_arg 0x55/0x55
[<ffffffff81d89120>] ? early_idt_handler_array 0x120/0x120
[<ffffffff81d895d6>] ? x86_64_start_reservations 0x2a/0x2c
[<ffffffff81d89715>] ? x86_64_start_kernel 0x13d/0x14c
---[ end trace 7b6555b6343ef9ee ]---

During the cpu bringup, wakeup_cpu_via_init_nmi() is called and issues an
NMI on CPU 0.  The GHES NMI handler, ghes_notify_nmi() runs the
ghes_proc_irq_work work queue which ends up setting IRQ_WORK_VECTOR
(0xf6).  The "faulty" IR line set at arch/x86/kernel/apic/apic.c:1349 is  also
0xf6 (specifically APIC IRR for irqs 255 to 224 is 0x400000) which confirms
that something has set the IRQ_WORK_VECTOR line prior to the APIC being
initialized.

Commit 2383844 ("GHES: Elliminate double-loop in the NMI handler")
incorrectly modified the behavior such that the handler returns
NMI_HANDLED only if an error was processed, and incorrectly runs the ghes
work queue for every NMI.

This patch modifies the ghes_proc_irq_work() to run as it did prior to
2383844 ("GHES: Elliminate double-loop in the NMI handler") by
properly returning NMI_HANDLED and only calling the work queue if
NMI_HANDLED has been set.

Fixes: 2383844 ("GHES: Elliminate double-loop in the NMI handler")
Signed-off-by: Prarit Bhargava <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Tyler Baicar <[email protected]>
Cc: Punit Agrawal <[email protected]>
Cc: Don Zickus <[email protected]>
Cc: [email protected]

…ckpatch-fixes

WARNING: line over 80 characters
torvalds#59: FILE: mm/mempolicy.c:1686:
 		 * __GFP_THISNODE shouldn't even be used with the bind policy because

WARNING: line over 80 characters
torvalds#60: FILE: mm/mempolicy.c:1687:
 		 * we might easily break the expectation to stay on the requested node

WARNING: line over 80 characters
torvalds#69: FILE: mm/mempolicy.c:1690:
 		WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));

total: 0 errors, 3 warnings, 33 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ckpatch-fixes

WARNING: line over 80 characters
torvalds#59: FILE: mm/mempolicy.c:1686:
 		 * __GFP_THISNODE shouldn't even be used with the bind policy because

WARNING: line over 80 characters
torvalds#60: FILE: mm/mempolicy.c:1687:
 		 * we might easily break the expectation to stay on the requested node

WARNING: line over 80 characters
torvalds#69: FILE: mm/mempolicy.c:1690:
 		WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));

total: 0 errors, 3 warnings, 33 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

…ckpatch-fixes

WARNING: line over 80 characters
torvalds#59: FILE: mm/mempolicy.c:1686:
 		 * __GFP_THISNODE shouldn't even be used with the bind policy because

WARNING: line over 80 characters
torvalds#60: FILE: mm/mempolicy.c:1687:
 		 * we might easily break the expectation to stay on the requested node

WARNING: line over 80 characters
torvalds#69: FILE: mm/mempolicy.c:1690:
 		WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));

total: 0 errors, 3 warnings, 33 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist.patch has style problems, please review.

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

Please run checkpatch prior to sending patches

Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: NipaLocal <nipa@local>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: NipaLocal <nipa@local>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: NipaLocal <nipa@local>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: NipaLocal <nipa@local>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: NipaLocal <nipa@local>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: NipaLocal <nipa@local>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: NipaLocal <nipa@local>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: NipaLocal <nipa@local>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: NipaLocal <nipa@local>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: NipaLocal <nipa@local>

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org
Signed-off-by: Jakub Kicinski <[email protected]>

commit fb7a0d3 upstream.

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fb7a0d3 upstream.

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fb7a0d3 upstream.

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fb7a0d3 upstream.

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fb7a0d3 upstream.

Christoph reported a splat hinting at a corrupted snd_una:

  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 torvalds#59
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una 0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9500013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   <TASK>
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans 0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker 0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work 0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread 0x3c7/0x640 kernel/workqueue.c:3416
   kthread 0x121/0x170 kernel/kthread.c:388
   ret_from_fork 0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm 0x1a/0x30 arch/x86/entry/entry_64.S:243
   </TASK>

When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.

Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.

Fixes: 8fd7380 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: multipath-tcp/mptcp_net-next#485
Tested-by: Christoph Paasch <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org
Signed-off-by: Jakub Kicinski <[email protected]>
[ snd_nxt field is not available in v5.10.y: before, only write_seq was
  used, see commit eaa2ffa ("mptcp: introduce MPTCP snd_nxt") for
  more details about that. ]
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Originally there was a race where removing a psock from the sock map while
it was also receiving an skb and calling sk_psock_data_ready(). It was
possible the removal code would NULL/set the data_ready callback while
concurrently calling the hook from receive path. The fix was to wrap the
access in sk_callback_lock to ensure the saved_data_ready pointer didn't
change under us. There was some discussion around doing a larger change
to ensure we could use READ_ONCE/WRITE_ONCE over the callback, but that
was for *next kernels not stable fixes.

But, we unfortunately introduced a regression with the fix because there
is another path into this code (that didn't have a test case) through
the stream parser. The stream parser runs with the lower lock which means
we get the following splat and lock up.

 ============================================
 WARNING: possible recursive locking detected
 6.10.0-rc2 torvalds#59 Not tainted
 --------------------------------------------
 test_sockmap/342 is trying to acquire lock:
 ffff888007a87228 (clock-AF_INET){  --}-{2:2}, at:
 sk_psock_skb_ingress_enqueue (./include/linux/skmsg.h:467
 net/core/skmsg.c:555)

 but task is already holding lock:
 ffff888007a87228 (clock-AF_INET){  --}-{2:2}, at:
 sk_psock_strp_data_ready (net/core/skmsg.c:1120)

To fix ensure we do not grap lock when we reach this code through the
strparser.

Fixes: 6648e61 ("bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue")
Reported-by: Vincent Whitchurch <[email protected]>
Signed-off-by: John Fastabend <[email protected]>

Fix WARN_ON:
[   22.869352][ T1885] clk_spi0 already unprepared
[   22.869379][ T1885] WARNING: CPU: 3 PID: 1885 at drivers/clk/clk.c:813 clk_core_unprepare 0xbc4
[   22.869380][ T1885] Modules linked in: bcmdhd dhd_static_buf
[   22.869391][ T1885] CPU: 3 PID: 1885 Comm: Binder:355_2 Tainted: G        W         5.10.66 torvalds#59
[   22.869393][ T1885] Hardware name: Rockchip RK3588 EVB1 LP4 V10 Board (DT)
[   22.869397][ T1885] pstate: 60400009 (nZCv daif  PAN -UAO -TCO BTYPE=--)
[   22.869401][ T1885] pc : clk_core_unprepare 0xbc/0x214
[   22.869404][ T1885] lr : clk_core_unprepare 0xbc/0x214

Fixes:  ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops")
Signed-off-by: Jon Lin <[email protected]>

Fix WARN_ON:
[   22.869352][ T1885] clk_spi0 already unprepared
[   22.869379][ T1885] WARNING: CPU: 3 PID: 1885 at drivers/clk/clk.c:813 clk_core_unprepare 0xbc4
[   22.869380][ T1885] Modules linked in: bcmdhd dhd_static_buf
[   22.869391][ T1885] CPU: 3 PID: 1885 Comm: Binder:355_2 Tainted: G        W         5.10.66 torvalds#59
[   22.869393][ T1885] Hardware name: Rockchip RK3588 EVB1 LP4 V10 Board (DT)
[   22.869397][ T1885] pstate: 60400009 (nZCv daif  PAN -UAO -TCO BTYPE=--)
[   22.869401][ T1885] pc : clk_core_unprepare 0xbc/0x214
[   22.869404][ T1885] lr : clk_core_unprepare 0xbc/0x214

Fixes:  ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops")
Signed-off-by: Jon Lin <[email protected]>

Fix WARN_ON:
[   22.869352][ T1885] clk_spi0 already unprepared
[   22.869379][ T1885] WARNING: CPU: 3 PID: 1885 at drivers/clk/clk.c:813 clk_core_unprepare 0xbc4
[   22.869380][ T1885] Modules linked in: bcmdhd dhd_static_buf
[   22.869391][ T1885] CPU: 3 PID: 1885 Comm: Binder:355_2 Tainted: G        W         5.10.66 torvalds#59
[   22.869393][ T1885] Hardware name: Rockchip RK3588 EVB1 LP4 V10 Board (DT)
[   22.869397][ T1885] pstate: 60400009 (nZCv daif  PAN -UAO -TCO BTYPE=--)
[   22.869401][ T1885] pc : clk_core_unprepare 0xbc/0x214
[   22.869404][ T1885] lr : clk_core_unprepare 0xbc/0x214

Fixes:  ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops")
Signed-off-by: Jon Lin <[email protected]>

commit 25216af ("PCI: Add managed pcim_intx()") moved the
allocation step for pci_intx()'s device resource from
pcim_enable_device() to pcim_intx(). As before, pcim_enable_device()
sets pci_dev.is_managed to true; and it is never set to false again.

Due to the lifecycle of a struct pci_dev, it can happen that a second
driver obtains the same pci_dev after a first driver ran.
If one driver uses pcim_enable_device() and the other doesn't,
this causes the other driver to run into managed pcim_intx(), which will
try to allocate when called for the first time.

Allocations might sleep, so calling pci_intx() while holding spinlocks
becomes then invalid, which causes lockdep warnings and could cause
deadlocks:

========================================================
WARNING: possible irq lock inversion dependency detected
6.11.0-rc6  torvalds#59 Tainted: G        W
--------------------------------------------------------
CPU 0/KVM/1537 just changed the state of lock:
ffffa0f0cff965f0 (&vdev->irqlock){-...}-{2:2}, at:
vfio_intx_handler 0x21/0xd0 [vfio_pci_core] but this lock took another,
HARDIRQ-unsafe lock in the past: (fs_reclaim){ . .}-{0:0}

and interrupts could create inverse lock ordering between them.

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

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
                               local_irq_disable();
                               lock(&vdev->irqlock);
                               lock(fs_reclaim);
  <Interrupt>
    lock(&vdev->irqlock);

 *** DEADLOCK ***

Have pcim_enable_device()'s release function, pcim_disable_device(), set
pci_dev.is_managed to false so that subsequent drivers using the same
struct pci_dev do implicitly run into managed code.

Fixes: 25216af ("PCI: Add managed pcim_intx()")
Reported-by: Alex Williamson <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Suggested-by: Alex Williamson <[email protected]>
Signed-off-by: Philipp Stanner <[email protected]>
Tested-by: Alex Williamson <[email protected]>

25216af ("PCI: Add managed pcim_intx()") moved the allocation step for
pci_intx()'s device resource from pcim_enable_device() to pcim_intx(). As
before, pcim_enable_device() sets pci_dev.is_managed to true; and it is
never set to false again.

Due to the lifecycle of a struct pci_dev, it can happen that a second
driver obtains the same pci_dev after a first driver ran.  If one driver
uses pcim_enable_device() and the other doesn't, this causes the other
driver to run into managed pcim_intx(), which will try to allocate when
called for the first time.

Allocations might sleep, so calling pci_intx() while holding spinlocks
becomes then invalid, which causes lockdep warnings and could cause
deadlocks:

  ========================================================
  WARNING: possible irq lock inversion dependency detected
  6.11.0-rc6  torvalds#59 Tainted: G        W
  --------------------------------------------------------
  CPU 0/KVM/1537 just changed the state of lock:
  ffffa0f0cff965f0 (&vdev->irqlock){-...}-{2:2}, at:
  vfio_intx_handler 0x21/0xd0 [vfio_pci_core] but this lock took another,
  HARDIRQ-unsafe lock in the past: (fs_reclaim){ . .}-{0:0}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:

  Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
			       local_irq_disable();
			       lock(&vdev->irqlock);
			       lock(fs_reclaim);
  <Interrupt>
    lock(&vdev->irqlock);

  *** DEADLOCK ***

Have pcim_enable_device()'s release function, pcim_disable_device(), set
pci_dev.is_managed to false so that subsequent drivers using the same
struct pci_dev do implicitly run into managed code.

Link: https://lore.kernel.org/r/[email protected]
Fixes: 25216af ("PCI: Add managed pcim_intx()")
Reported-by: Alex Williamson <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Suggested-by: Alex Williamson <[email protected]>
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Tested-by: Alex Williamson <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>

25216af ("PCI: Add managed pcim_intx()") moved the allocation step for
pci_intx()'s device resource from pcim_enable_device() to pcim_intx(). As
before, pcim_enable_device() sets pci_dev.is_managed to true; and it is
never set to false again.

Due to the lifecycle of a struct pci_dev, it can happen that a second
driver obtains the same pci_dev after a first driver ran.  If one driver
uses pcim_enable_device() and the other doesn't, this causes the other
driver to run into managed pcim_intx(), which will try to allocate when
called for the first time.

Allocations might sleep, so calling pci_intx() while holding spinlocks
becomes then invalid, which causes lockdep warnings and could cause
deadlocks:

  ========================================================
  WARNING: possible irq lock inversion dependency detected
  6.11.0-rc6  torvalds#59 Tainted: G        W
  --------------------------------------------------------
  CPU 0/KVM/1537 just changed the state of lock:
  ffffa0f0cff965f0 (&vdev->irqlock){-...}-{2:2}, at:
  vfio_intx_handler 0x21/0xd0 [vfio_pci_core] but this lock took another,
  HARDIRQ-unsafe lock in the past: (fs_reclaim){ . .}-{0:0}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:

  Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
			       local_irq_disable();
			       lock(&vdev->irqlock);
			       lock(fs_reclaim);
  <Interrupt>
    lock(&vdev->irqlock);

  *** DEADLOCK ***

Have pcim_enable_device()'s release function, pcim_disable_device(), set
pci_dev.is_managed to false so that subsequent drivers using the same
struct pci_dev do not implicitly run into managed code.

Link: https://lore.kernel.org/r/[email protected]
Fixes: 25216af ("PCI: Add managed pcim_intx()")
Reported-by: Alex Williamson <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Suggested-by: Alex Williamson <[email protected]>
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Tested-by: Alex Williamson <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>

25216af ("PCI: Add managed pcim_intx()") moved the allocation step for
pci_intx()'s device resource from pcim_enable_device() to pcim_intx(). As
before, pcim_enable_device() sets pci_dev.is_managed to true; and it is
never set to false again.

Due to the lifecycle of a struct pci_dev, it can happen that a second
driver obtains the same pci_dev after a first driver ran.  If one driver
uses pcim_enable_device() and the other doesn't, this causes the other
driver to run into managed pcim_intx(), which will try to allocate when
called for the first time.

Allocations might sleep, so calling pci_intx() while holding spinlocks
becomes then invalid, which causes lockdep warnings and could cause
deadlocks:

  ========================================================
  WARNING: possible irq lock inversion dependency detected
  6.11.0-rc6  torvalds#59 Tainted: G        W
  --------------------------------------------------------
  CPU 0/KVM/1537 just changed the state of lock:
  ffffa0f0cff965f0 (&vdev->irqlock){-...}-{2:2}, at:
  vfio_intx_handler 0x21/0xd0 [vfio_pci_core] but this lock took another,
  HARDIRQ-unsafe lock in the past: (fs_reclaim){ . .}-{0:0}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:

  Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
			       local_irq_disable();
			       lock(&vdev->irqlock);
			       lock(fs_reclaim);
  <Interrupt>
    lock(&vdev->irqlock);

  *** DEADLOCK ***

Have pcim_enable_device()'s release function, pcim_disable_device(), set
pci_dev.is_managed to false so that subsequent drivers using the same
struct pci_dev do not implicitly run into managed code.

Link: https://lore.kernel.org/r/[email protected]
Fixes: 25216af ("PCI: Add managed pcim_intx()")
Reported-by: Alex Williamson <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Suggested-by: Alex Williamson <[email protected]>
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Tested-by: Alex Williamson <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>

WARNING: please, no spaces at the start of a line
\torvalds#28: FILE: drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c:608:
     int err, pd;$

WARNING: please, no spaces at the start of a line
\torvalds#59: FILE: drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c:789:
     }$

total: 0 errors, 2 warnings, 90 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

0001-pinctrl-mediatek-add-support-for-MTK_PULL_PD_TYPE.patch has style problems, please review.

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

WARNING: please, no spaces at the start of a line
\torvalds#28: FILE: drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c:608:
     int err, pd;$

WARNING: please, no spaces at the start of a line
\torvalds#59: FILE: drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c:789:
     }$

total: 0 errors, 2 warnings, 90 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

0001-pinctrl-mediatek-add-support-for-MTK_PULL_PD_TYPE.patch has style problems, please review.

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

WARNING: please, no spaces at the start of a line
\torvalds#28: FILE: drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c:608:
     int err, pd;$

WARNING: please, no spaces at the start of a line
\torvalds#59: FILE: drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c:789:
     }$

total: 0 errors, 2 warnings, 90 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

0001-pinctrl-mediatek-add-support-for-MTK_PULL_PD_TYPE.patch has style problems, please review.

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