Odroidxu 3.4.y #63

Open
wants to merge 5,007 commits into
from
@hany0622

No description provided.

@DestroyFX DestroyFX pushed a commit to DestroyFX/reiser4 that referenced this pull request Dec 25, 2013
Borislav Petkov x86: Improve the printout of the SMP bootup CPU table
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  #6  #7 OK
 [    0.644008] smpboot: Booting Node   1, Processors:  #8  #9 #10 #11 #12 #13 #14 #15 OK
 [    1.245006] smpboot: Booting Node   2, Processors: #16 #17 #18 #19 #20 #21 #22 #23 OK
 [    1.864005] smpboot: Booting Node   3, Processors: #24 #25 #26 #27 #28 #29 #30 #31 OK
 [    2.489005] smpboot: Booting Node   4, Processors: #32 #33 #34 #35 #36 #37 #38 #39 OK
 [    3.093005] smpboot: Booting Node   5, Processors: #40 #41 #42 #43 #44 #45 #46 #47 OK
 [    3.698005] smpboot: Booting Node   6, Processors: #48 #49 #50 #51 #52 #53 #54 #55 OK
 [    4.304005] smpboot: Booting Node   7, Processors: #56 #57 #58 #59 #60 #61 #62 #63 OK
 [    4.961413] Brought up 64 CPUs

and this:

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

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Libin <huawei.libin@huawei.com>
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Link: http://lkml.kernel.org/r/20130927143554.GF4422@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
646e29a
@DestroyFX DestroyFX pushed a commit to DestroyFX/reiser4 that referenced this pull request Dec 25, 2013
Borislav Petkov x86/boot: Further compress CPUs bootup message
Turn it into (for example):

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

and drop useless elements.

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

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: huawei.libin@huawei.com
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
a17bce4
@mitake mitake pushed a commit to mitake/linux that referenced this pull request Jan 12, 2014
@ebiederm ebiederm userns: Stop oopsing in key_change_session_keyring
Dave Jones <davej@redhat.com> writes:
> Just hit this on Linus' current tree.
>
> [   89.621770] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8
> [   89.623111] IP: [<ffffffff810784b0>] commit_creds+0x250/0x2f0
> [   89.624062] PGD 122bfd067 PUD 122bfe067 PMD 0
> [   89.624901] Oops: 0000 [#1] PREEMPT SMP
> [   89.625678] Modules linked in: caif_socket caif netrom bridge hidp 8021q garp stp mrp rose llc2 af_rxrpc phonet af_key binfmt_misc bnep l2tp_ppp can_bcm l2tp_core pppoe pppox can_raw scsi_transport_iscsi ppp_generic slhc nfnetlink can ipt_ULOG ax25 decnet irda nfc rds x25 crc_ccitt appletalk atm ipx p8023 psnap p8022 llc lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables btusb bluetooth snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm vhost_net snd_page_alloc snd_timer tun macvtap usb_debug snd rfkill microcode macvlan edac_core pcspkr serio_raw kvm_amd soundcore kvm r8169 mii
> [   89.637846] CPU 2
> [   89.638175] Pid: 782, comm: trinity-main Not tainted 3.8.0+ #63 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
> [   89.639850] RIP: 0010:[<ffffffff810784b0>]  [<ffffffff810784b0>] commit_creds+0x250/0x2f0
> [   89.641161] RSP: 0018:ffff880115657eb8  EFLAGS: 00010207
> [   89.641984] RAX: 00000000000003e8 RBX: ffff88012688b000 RCX: 0000000000000000
> [   89.643069] RDX: 0000000000000000 RSI: ffffffff81c32960 RDI: ffff880105839600
> [   89.644167] RBP: ffff880115657ed8 R08: 0000000000000000 R09: 0000000000000000
> [   89.645254] R10: 0000000000000001 R11: 0000000000000246 R12: ffff880105839600
> [   89.646340] R13: ffff88011beea490 R14: ffff88011beea490 R15: 0000000000000000
> [   89.647431] FS:  00007f3ac063b740(0000) GS:ffff88012b200000(0000) knlGS:0000000000000000
> [   89.648660] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [   89.649548] CR2: 00000000000000c8 CR3: 0000000122bfc000 CR4: 00000000000007e0
> [   89.650635] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   89.651723] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [   89.652812] Process trinity-main (pid: 782, threadinfo ffff880115656000, task ffff88011beea490)
> [   89.654128] Stack:
> [   89.654433]  0000000000000000 ffff8801058396a0 ffff880105839600 ffff88011beeaa78
> [   89.655769]  ffff880115657ef8 ffffffff812c7d9b ffffffff82079be0 0000000000000000
> [   89.657073]  ffff880115657f28 ffffffff8106c665 0000000000000002 ffff880115657f58
> [   89.658399] Call Trace:
> [   89.658822]  [<ffffffff812c7d9b>] key_change_session_keyring+0xfb/0x140
> [   89.659845]  [<ffffffff8106c665>] task_work_run+0xa5/0xd0
> [   89.660698]  [<ffffffff81002911>] do_notify_resume+0x71/0xb0
> [   89.661581]  [<ffffffff816c9a4a>] int_signal+0x12/0x17
> [   89.662385] Code: 24 90 00 00 00 48 8b b3 90 00 00 00 49 8b 4c 24 40 48 39 f2 75 08 e9 83 00 00 00 48 89 ca 48 81 fa 60 29 c3 81 0f 84 41 fe ff ff <48> 8b 8a c8 00 00 00 48 39 ce 75 e4 3b 82 d0 00 00 00 0f 84 4b
> [   89.667778] RIP  [<ffffffff810784b0>] commit_creds+0x250/0x2f0
> [   89.668733]  RSP <ffff880115657eb8>
> [   89.669301] CR2: 00000000000000c8
>
> My fastest trinity induced oops yet!
>
>
> Appears to be..
>
>                 if ((set_ns == subset_ns->parent)  &&
>      850:       48 8b 8a c8 00 00 00    mov    0xc8(%rdx),%rcx
>
> from the inlined cred_cap_issubset

By historical accident we have been reading trying to set new->user_ns
from new->user_ns.  Which is totally silly as new->user_ns is NULL (as
is every other field in new except session_keyring at that point).

The intent is clearly to copy all of the fields from old to new so copy
old->user_ns into  into new->user_ns.

Cc: stable@vger.kernel.org
Reported-by: Dave Jones <davej@redhat.com>
Tested-by: Dave Jones <davej@redhat.com>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
ba0e342
@tobiasjakobi tobiasjakobi pushed a commit that referenced this pull request Jan 27, 2014
@ebiederm ebiederm userns: Stop oopsing in key_change_session_keyring
commit ba0e342 upstream.

Dave Jones <davej@redhat.com> writes:
> Just hit this on Linus' current tree.
>
> [   89.621770] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8
> [   89.623111] IP: [<ffffffff810784b0>] commit_creds+0x250/0x2f0
> [   89.624062] PGD 122bfd067 PUD 122bfe067 PMD 0
> [   89.624901] Oops: 0000 [#1] PREEMPT SMP
> [   89.625678] Modules linked in: caif_socket caif netrom bridge hidp 8021q garp stp mrp rose llc2 af_rxrpc phonet af_key binfmt_misc bnep l2tp_ppp can_bcm l2tp_core pppoe pppox can_raw scsi_transport_iscsi ppp_generic slhc nfnetlink can ipt_ULOG ax25 decnet irda nfc rds x25 crc_ccitt appletalk atm ipx p8023 psnap p8022 llc lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables btusb bluetooth snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm vhost_net snd_page_alloc snd_timer tun macvtap usb_debug snd rfkill microcode macvlan edac_core pcspkr serio_raw kvm_amd soundcore kvm r8169 mii
> [   89.637846] CPU 2
> [   89.638175] Pid: 782, comm: trinity-main Not tainted 3.8.0+ #63 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
> [   89.639850] RIP: 0010:[<ffffffff810784b0>]  [<ffffffff810784b0>] commit_creds+0x250/0x2f0
> [   89.641161] RSP: 0018:ffff880115657eb8  EFLAGS: 00010207
> [   89.641984] RAX: 00000000000003e8 RBX: ffff88012688b000 RCX: 0000000000000000
> [   89.643069] RDX: 0000000000000000 RSI: ffffffff81c32960 RDI: ffff880105839600
> [   89.644167] RBP: ffff880115657ed8 R08: 0000000000000000 R09: 0000000000000000
> [   89.645254] R10: 0000000000000001 R11: 0000000000000246 R12: ffff880105839600
> [   89.646340] R13: ffff88011beea490 R14: ffff88011beea490 R15: 0000000000000000
> [   89.647431] FS:  00007f3ac063b740(0000) GS:ffff88012b200000(0000) knlGS:0000000000000000
> [   89.648660] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [   89.649548] CR2: 00000000000000c8 CR3: 0000000122bfc000 CR4: 00000000000007e0
> [   89.650635] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   89.651723] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [   89.652812] Process trinity-main (pid: 782, threadinfo ffff880115656000, task ffff88011beea490)
> [   89.654128] Stack:
> [   89.654433]  0000000000000000 ffff8801058396a0 ffff880105839600 ffff88011beeaa78
> [   89.655769]  ffff880115657ef8 ffffffff812c7d9b ffffffff82079be0 0000000000000000
> [   89.657073]  ffff880115657f28 ffffffff8106c665 0000000000000002 ffff880115657f58
> [   89.658399] Call Trace:
> [   89.658822]  [<ffffffff812c7d9b>] key_change_session_keyring+0xfb/0x140
> [   89.659845]  [<ffffffff8106c665>] task_work_run+0xa5/0xd0
> [   89.660698]  [<ffffffff81002911>] do_notify_resume+0x71/0xb0
> [   89.661581]  [<ffffffff816c9a4a>] int_signal+0x12/0x17
> [   89.662385] Code: 24 90 00 00 00 48 8b b3 90 00 00 00 49 8b 4c 24 40 48 39 f2 75 08 e9 83 00 00 00 48 89 ca 48 81 fa 60 29 c3 81 0f 84 41 fe ff ff <48> 8b 8a c8 00 00 00 48 39 ce 75 e4 3b 82 d0 00 00 00 0f 84 4b
> [   89.667778] RIP  [<ffffffff810784b0>] commit_creds+0x250/0x2f0
> [   89.668733]  RSP <ffff880115657eb8>
> [   89.669301] CR2: 00000000000000c8
>
> My fastest trinity induced oops yet!
>
>
> Appears to be..
>
>                 if ((set_ns == subset_ns->parent)  &&
>      850:       48 8b 8a c8 00 00 00    mov    0xc8(%rdx),%rcx
>
> from the inlined cred_cap_issubset

By historical accident we have been reading trying to set new->user_ns
from new->user_ns.  Which is totally silly as new->user_ns is NULL (as
is every other field in new except session_keyring at that point).

The intent is clearly to copy all of the fields from old to new so copy
old->user_ns into  into new->user_ns.

Reported-by: Dave Jones <davej@redhat.com>
Tested-by: Dave Jones <davej@redhat.com>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
f6eff27
@torvalds torvalds pushed a commit that referenced this pull request Mar 14, 2014
@sorenb-xlnx sorenb-xlnx net: macb: Check DMA mappings for error
With CONFIG_DMA_API_DEBUG enabled the following warning is printed:
 WARNING: CPU: 0 PID: 619 at lib/dma-debug.c:1101 check_unmap+0x758/0x894()
 macb e000b000.ethernet: DMA-API: device driver failed to check map error[device address=0x000000002d171c02] [size=322 bytes] [mapped as single]
 Modules linked in:
 CPU: 0 PID: 619 Comm: udhcpc Not tainted 3.14.0-rc3-xilinx-00219-gd158fc7f36a2 #63
 [<c001516c>] (unwind_backtrace) from [<c0011df8>] (show_stack+0x10/0x14)
 [<c0011df8>] (show_stack) from [<c03c7714>] (dump_stack+0x7c/0xc8)
 [<c03c7714>] (dump_stack) from [<c00245cc>] (warn_slowpath_common+0x60/0x84)
 [<c00245cc>] (warn_slowpath_common) from [<c0024670>] (warn_slowpath_fmt+0x2c/0x3c)
 [<c0024670>] (warn_slowpath_fmt) from [<c0228244>] (check_unmap+0x758/0x894)
 [<c0228244>] (check_unmap) from [<c0228588>] (debug_dma_unmap_page+0x64/0x70)
 [<c0228588>] (debug_dma_unmap_page) from [<c02aba64>] (macb_interrupt+0x1f8/0x2dc)
 [<c02aba64>] (macb_interrupt) from [<c006c6e4>] (handle_irq_event_percpu+0x2c/0x178)
 [<c006c6e4>] (handle_irq_event_percpu) from [<c006c86c>] (handle_irq_event+0x3c/0x5c)
 [<c006c86c>] (handle_irq_event) from [<c006f548>] (handle_fasteoi_irq+0xb8/0x100)
 [<c006f548>] (handle_fasteoi_irq) from [<c006c148>] (generic_handle_irq+0x20/0x30)
 [<c006c148>] (generic_handle_irq) from [<c000f35c>] (handle_IRQ+0x64/0x8c)
 [<c000f35c>] (handle_IRQ) from [<c0008528>] (gic_handle_irq+0x3c/0x60)
 [<c0008528>] (gic_handle_irq) from [<c0012904>] (__irq_svc+0x44/0x78)
 Exception stack(0xed197f60 to 0xed197fa8)
 7f60: 00000134 60000013 bd94362e bd94362e be96b37c 00000014 fffffd72 00000122
 7f80: c000ebe4 ed196000 00000000 00000011 c032c0d8 ed197fa8 c0064008 c000ea20
 7fa0: 60000013 ffffffff
 [<c0012904>] (__irq_svc) from [<c000ea20>] (ret_fast_syscall+0x0/0x48)
 ---[ end trace 478f921d0d542d1e ]---
 Mapped at:
  [<c0227184>] debug_dma_map_page+0x48/0x11c
  [<c02aaca0>] macb_start_xmit+0x184/0x2a8
  [<c03143c0>] dev_hard_start_xmit+0x334/0x470
  [<c032c09c>] sch_direct_xmit+0x78/0x2f8
  [<c0314814>] __dev_queue_xmit+0x318/0x708

due to missing checks of the dma mapping. Add the appropriate checks to fix
this.

Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
9203090
@zeitgeist87 zeitgeist87 pushed a commit to zeitgeist87/linux that referenced this pull request Mar 14, 2014
Andrew Morton ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endless…
…loop-during-umount-checkpatch-fixes

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

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

WARNING: suspect code indent for conditional statements (23, 31)
#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
#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

WARNING: please, no spaces at the start of a line
#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
#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
#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                                               "telling master to get ref "$

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

WARNING: quoted string split across lines
#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
#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "for cleared out mle during "$

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

WARNING: quoted string split across lines
#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
#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "migration\n", dlm->name,$

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

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

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

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

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

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

WARNING: please, no spaces at the start of a line
#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 <jlbec@evilplan.org>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Xue jiufei <xuejiufei@huawei.com>
Cc: jiangyiwen <jiangyiwen@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
b29f935
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request Mar 19, 2014
Andrew Morton ocfs2-do-not-return-dlm_migrate_response_mastery_ref-to-avoid-endless…
…loop-during-umount-checkpatch-fixes

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

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

WARNING: suspect code indent for conditional statements (23, 31)
#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
#57: FILE: fs/ocfs2/dlm/dlmmaster.c:3088:
+                               ret = DLM_MIGRATE_RESPONSE_MASTERY_REF;$

WARNING: please, no spaces at the start of a line
#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
#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
#59: FILE: fs/ocfs2/dlm/dlmmaster.c:3090:
+                                               "telling master to get ref "$

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

WARNING: quoted string split across lines
#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
#60: FILE: fs/ocfs2/dlm/dlmmaster.c:3091:
+                                               "for cleared out mle during "$

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

WARNING: quoted string split across lines
#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
#61: FILE: fs/ocfs2/dlm/dlmmaster.c:3092:
+                                               "migration\n", dlm->name,$

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

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

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

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

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

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

WARNING: please, no spaces at the start of a line
#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 <jlbec@evilplan.org>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Xue jiufei <xuejiufei@huawei.com>
Cc: jiangyiwen <jiangyiwen@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
216ace2
@Gnurou Gnurou pushed a commit to Gnurou/linux that referenced this pull request Jun 27, 2014
@paulmck paulmck rcu: Use __this_cpu_read() instead of per_cpu_ptr()
The __this_cpu_read() function produces better code than does
per_cpu_ptr() on both ARM and x86.  For example, gcc (Ubuntu/Linaro
4.7.3-12ubuntu1) 4.7.3 produces the following:

ARMv7 per_cpu_ptr():

force_quiescent_state:
    mov    r3, sp    @,
    bic    r1, r3, #8128    @ tmp171,,
    ldr    r2, .L98    @ tmp169,
    bic    r1, r1, #63    @ tmp170, tmp171,
    ldr    r3, [r0, #220]    @ __ptr, rsp_6(D)->rda
    ldr    r1, [r1, #20]    @ D.35903_68->cpu, D.35903_68->cpu
    mov    r6, r0    @ rsp, rsp
    ldr    r2, [r2, r1, asl #2]    @ tmp173, __per_cpu_offset
    add    r3, r3, r2    @ tmp175, __ptr, tmp173
    ldr    r5, [r3, #12]    @ rnp_old, D.29162_13->mynode

ARMv7 __this_cpu_read():

force_quiescent_state:
    ldr    r3, [r0, #220]    @ rsp_7(D)->rda, rsp_7(D)->rda
    mov    r6, r0    @ rsp, rsp
    add    r3, r3, #12    @ __ptr, rsp_7(D)->rda,
    ldr    r5, [r2, r3]    @ rnp_old, *D.29176_13

Using gcc 4.8.2:

x86_64 per_cpu_ptr():

    movl %gs:cpu_number,%edx    # cpu_number, pscr_ret__
    movslq    %edx, %rdx    # pscr_ret__, pscr_ret__
    movq    __per_cpu_offset(,%rdx,8), %rdx    # __per_cpu_offset, tmp93
    movq    %rdi, %r13    # rsp, rsp
    movq    1000(%rdi), %rax    # rsp_9(D)->rda, __ptr
    movq    24(%rdx,%rax), %r12    # _15->mynode, rnp_old

x86_64 __this_cpu_read():

    movq    %rdi, %r13    # rsp, rsp
    movq    1000(%rdi), %rax    # rsp_9(D)->rda, rsp_9(D)->rda
    movq %gs:24(%rax),%r12    # _10->mynode, rnp_old

Because this change produces significant benefits for these two very
diverse architectures, this commit makes this change.

Signed-off-by: Shan Wei <davidshan@tencent.com>
Acked-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
0f7bbb9
mstsirkin and others added some commits Jul 20, 2012
@mstsirkin mstsirkin skbuff: add an api to orphan frags
commit a353e0c upstream.

Many places do
       if ((skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY))
		skb_copy_ubufs(skb, gfp_mask);
to copy and invoke frag destructors if necessary.
Add an inline helper for this.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1f29351
@mstsirkin mstsirkin skbuff: export skb_copy_ubufs
commit dcc0fb7 upstream.

Export skb_copy_ubufs so that modules can orphan frags.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2f3ca8e
Thomas Gleixner genirq: Sanitize spurious interrupt detection of threaded irqs
commit 1e77d0a upstream.

Till reported that the spurious interrupt detection of threaded
interrupts is broken in two ways:

- note_interrupt() is called for each action thread of a shared
  interrupt line. That's wrong as we are only interested whether none
  of the device drivers felt responsible for the interrupt, but by
  calling multiple times for a single interrupt line we account
  IRQ_NONE even if one of the drivers felt responsible.

- note_interrupt() when called from the thread handler is not
  serialized. That leaves the members of irq_desc which are used for
  the spurious detection unprotected.

To solve this we need to defer the spurious detection of a threaded
interrupt to the next hardware interrupt context where we have
implicit serialization.

If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we
check whether the previous interrupt requested a deferred check. If
not, we request a deferred check for the next hardware interrupt and
return.

If set, we check whether one of the interrupt threads signaled
success. Depending on this information we feed the result into the
spurious detector.

If one primary handler of a shared interrupt returns IRQ_HANDLED we
disable the deferred check of irq threads on the same line, as we have
found at least one device driver who cared.

Reported-by: Till Straumann <strauman@slac.stanford.edu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Austin Schuh <austin@peloton-tech.com>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionos
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
a97df3f
@rogerq rogerq usb: usbtest: Add timetout to simple_io()
commit e5e4746 upstream.

Without a timetout some tests e.g. test_halt() can remain stuck forever.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3b0d089
@mstsirkin mstsirkin skbuff: skb_segment: orphan frags before copying
commit 1fd819e upstream.

skb_segment copies frags around, so we need
to copy them carefully to avoid accessing
user memory after reporting completion to userspace
through a callback.

skb_segment doesn't normally happen on datapath:
TSO needs to be disabled - so disabling zero copy
in this case does not look like a big deal.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2.  As skb_segment() only supports page-frags *or* a
 frag list, there is no need for the additional frag_skb pointer or the
 preparatory renaming.]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2edae61
@masoncl masoncl Btrfs: fix double free in find_lock_delalloc_range
commit 7d78874 upstream.

We need to NULL the cached_state after freeing it, otherwise
we might free it again if find_delalloc_range doesn't find anything.

Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
a25ebe2
Rickard Strandqvist fs: btrfs: volumes.c: Fix for possible null pointer dereference
commit 8321cf2 upstream.

There is otherwise a risk of a possible null pointer dereference.

Was largely found by using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8f1dd63
Liu Bo Btrfs: use right type to get real comparison
commit cd857dd upstream.

We want to make sure the point is still within the extent item, not to verify
the memory it's pointing to.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
64b84ef
Eric Sandeen btrfs: fix use of uninit "ret" in end_extent_writepage()
commit 3e2426b upstream.

If this condition in end_extent_writepage() is false:

	if (tree->ops && tree->ops->writepage_end_io_hook)

we will then test an uninitialized "ret" at:

	ret = ret < 0 ? ret : -EIO;

The test for ret is for the case where ->writepage_end_io_hook
failed, and we'd choose that ret as the error; but if
there is no ->writepage_end_io_hook, nothing sets ret.

Initializing ret to 0 should be sufficient; if
writepage_end_io_hook wasn't set, (!uptodate) means
non-zero err was passed in, so we choose -EIO in that case.

Signed-of-by: Eric Sandeen <sandeen@redhat.com>

Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
e18bac2
@amluto amluto x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508)
commit 554086d upstream.

The bad syscall nr paths are their own incomprehensible route
through the entry control flow.  Rearrange them to work just like
syscalls that return -ENOSYS.

This fixes an OOPS in the audit code when fast-path auditing is
enabled and sysenter gets a bad syscall nr (CVE-2014-4508).

This has probably been broken since Linux 2.6.27:
af0575b i386 syscall audit fast-path

Cc: Roland McGrath <roland@redhat.com>
Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Link: http://lkml.kernel.org/r/e09c499eade6fc321266dd6b54da7beb28d6991c.1403558229.git.luto@amacapital.net
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d300733
@gregkh gregkh Linux 3.4.96 3e3d5f6
@Gnurou Gnurou pushed a commit to Gnurou/linux that referenced this pull request Jul 1, 2014
@paulmck paulmck rcu: Use __this_cpu_read() instead of per_cpu_ptr()
The __this_cpu_read() function produces better code than does
per_cpu_ptr() on both ARM and x86.  For example, gcc (Ubuntu/Linaro
4.7.3-12ubuntu1) 4.7.3 produces the following:

ARMv7 per_cpu_ptr():

force_quiescent_state:
    mov    r3, sp    @,
    bic    r1, r3, #8128    @ tmp171,,
    ldr    r2, .L98    @ tmp169,
    bic    r1, r1, #63    @ tmp170, tmp171,
    ldr    r3, [r0, #220]    @ __ptr, rsp_6(D)->rda
    ldr    r1, [r1, #20]    @ D.35903_68->cpu, D.35903_68->cpu
    mov    r6, r0    @ rsp, rsp
    ldr    r2, [r2, r1, asl #2]    @ tmp173, __per_cpu_offset
    add    r3, r3, r2    @ tmp175, __ptr, tmp173
    ldr    r5, [r3, #12]    @ rnp_old, D.29162_13->mynode

ARMv7 __this_cpu_read():

force_quiescent_state:
    ldr    r3, [r0, #220]    @ rsp_7(D)->rda, rsp_7(D)->rda
    mov    r6, r0    @ rsp, rsp
    add    r3, r3, #12    @ __ptr, rsp_7(D)->rda,
    ldr    r5, [r2, r3]    @ rnp_old, *D.29176_13

Using gcc 4.8.2:

x86_64 per_cpu_ptr():

    movl %gs:cpu_number,%edx    # cpu_number, pscr_ret__
    movslq    %edx, %rdx    # pscr_ret__, pscr_ret__
    movq    __per_cpu_offset(,%rdx,8), %rdx    # __per_cpu_offset, tmp93
    movq    %rdi, %r13    # rsp, rsp
    movq    1000(%rdi), %rax    # rsp_9(D)->rda, __ptr
    movq    24(%rdx,%rax), %r12    # _15->mynode, rnp_old

x86_64 __this_cpu_read():

    movq    %rdi, %r13    # rsp, rsp
    movq    1000(%rdi), %rax    # rsp_9(D)->rda, rsp_9(D)->rda
    movq %gs:24(%rax),%r12    # _10->mynode, rnp_old

Because this change produces significant benefits for these two very
diverse architectures, this commit makes this change.

Signed-off-by: Shan Wei <davidshan@tencent.com>
Acked-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
40791b4
bjorn-helgaas and others added some commits Apr 5, 2014
@bjorn-helgaas bjorn-helgaas PCI: Fix incorrect vgaarb conditional in WARN_ON()
commit 67ebd81 upstream.

3448a19 "vgaarb: use bridges to control VGA routing where possible"
added the "flags & PCI_VGA_STATE_CHANGE_DECODES" condition to an existing
WARN_ON(), but used bitwise AND (&) instead of logical AND (&&), so the
condition is never true.  Replace with logical AND.

Found by Coverity (CID 142811).

Fixes: 3448a19 "vgaarb: use bridges to control VGA routing where possible"
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: David Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5564b79
@thomasjfox thomasjfox PCI: Add new ID for Intel GPU "spurious interrupt" quirk
commit 7c82126 upstream.

After a CPU upgrade while keeping the same mainboard, we faced "spurious
interrupt" problems again.

It turned out that the new CPU also featured a new GPU with a different PCI
ID.

Add this PCI ID to the quirk table.  Probably all other Intel GPU PCI IDs
are affected, too, but I don't want to add them without a test system.

See f67fd55 ("PCI: Add quirk for still enabled interrupts on Intel
Sandy Bridge GPUs") for some history.

[bhelgaas: add f67fd55 reference, stable tag]
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ade1407
@mmarcini mmarcini IB/qib: Fix port in pkey change event
commit 911eccd upstream.

The code used a literal 1 in dispatching an IB_EVENT_PKEY_CHANGE.

As of the dual port qib QDR card, this is not necessarily correct.

Change to use the port as specified in the call.

Reported-by: Alex Estrin <alex.estrin@intel.com>
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dd823fd
@ddalessa ddalessa IB/ipath: Translate legacy diagpkt into newer extended diagpkt
commit 7e6d3e5 upstream.

This patch addresses an issue where the legacy diagpacket is sent in
from the user, but the driver operates on only the extended
diagpkt. This patch specifically initializes the extended diagpkt
based on the legacy packet.

Reported-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
7517010
@vireshk vireshk watchdog: sp805: Set watchdog_device->timeout from ->set_timeout()
commit 938626d upstream.

Implementation of ->set_timeout() is supposed to set 'timeout' field of 'struct
watchdog_device' passed to it. sp805 was rather setting this in a local
variable. Fix it.

Reported-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
e8b6433
@bvanassche bvanassche IB/umad: Fix error handling
commit 8ec0a0e upstream.

Avoid leaking a kref count in ib_umad_open() if port->ib_dev == NULL
or if nonseekable_open() fails.

Avoid leaking a kref count, that sm_sem is kept down and also that the
IB_PORT_SM capability mask is not cleared in ib_umad_sm_open() if
nonseekable_open() fails.

Since container_of() never returns NULL, remove the code that tests
whether container_of() returns NULL.

Moving the kref_get() call from the start of ib_umad_*open() to the
end is safe since it is the responsibility of the caller of these
functions to ensure that the cdev pointer remains valid until at least
when these functions return.

Signed-off-by: Bart Van Assche <bvanassche@acm.org>

[ydroneaud@opteya.com: rework a bit to reduce the amount of code changed]

Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>

[ nonseekable_open() can't actually fail, but....  - Roland ]

Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
b6b405b
@bvanassche bvanassche IB/srp: Fix a sporadic crash triggered by cable pulling
commit 024ca90 upstream.

Avoid that the loops that iterate over the request ring can encounter
a pointer to a SCSI command in req->scmnd that is no longer associated
with that request. If the function srp_unmap_data() is invoked twice
for a SCSI command that is not in flight then that would cause
ib_fmr_pool_unmap() to be invoked with an invalid pointer as argument,
resulting in a kernel oops.

Reported-by: Sagi Grimberg <sagig@mellanox.com>
Reference: http://thread.gmane.org/gmane.linux.drivers.rdma/19068/focus=19069
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
c52be4c
J. Bruce Fields nfsd4: fix FREE_STATEID lockowner leak
commit 4838540 upstream.

27b1142 ("nfsd4: remove lockowner when removing lock stateid")
introduced a memory leak.

Reported-by: Jeff Layton <jeff.layton@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
eb55ed0
Christoph Hellwig nfsd: getattr for FATTR4_WORD0_FILES_AVAIL needs the statfs buffer
commit 1233790 upstream.

Note nobody's ever noticed because the typical client probably never
requests FILES_AVAIL without also requesting something else on the list.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bdef830
hujianyang UBIFS: Remove incorrect assertion in shrink_tnc()
commit 72abc8f upstream.

I hit the same assert failed as Dolev Raviv reported in Kernel v3.10
shows like this:

[ 9641.164028] UBIFS assert failed in shrink_tnc at 131 (pid 13297)
[ 9641.234078] CPU: 1 PID: 13297 Comm: mmap.test Tainted: G           O 3.10.40 #1
[ 9641.234116] [<c0011a6c>] (unwind_backtrace+0x0/0x12c) from [<c000d0b0>] (show_stack+0x20/0x24)
[ 9641.234137] [<c000d0b0>] (show_stack+0x20/0x24) from [<c0311134>] (dump_stack+0x20/0x28)
[ 9641.234188] [<c0311134>] (dump_stack+0x20/0x28) from [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs])
[ 9641.234265] [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs]) from [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs])
[ 9641.234307] [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs]) from [<c00cdad8>] (shrink_slab+0x1d4/0x2f8)
[ 9641.234327] [<c00cdad8>] (shrink_slab+0x1d4/0x2f8) from [<c00d03d0>] (do_try_to_free_pages+0x300/0x544)
[ 9641.234344] [<c00d03d0>] (do_try_to_free_pages+0x300/0x544) from [<c00d0a44>] (try_to_free_pages+0x2d0/0x398)
[ 9641.234363] [<c00d0a44>] (try_to_free_pages+0x2d0/0x398) from [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8)
[ 9641.234382] [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8) from [<c00f62d8>] (new_slab+0x78/0x238)
[ 9641.234400] [<c00f62d8>] (new_slab+0x78/0x238) from [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c)
[ 9641.234419] [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c) from [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188)
[ 9641.234459] [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188) from [<bf227908>] (do_readpage+0x168/0x468 [ubifs])
[ 9641.234553] [<bf227908>] (do_readpage+0x168/0x468 [ubifs]) from [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs])
[ 9641.234606] [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs]) from [<c00c17c0>] (filemap_fault+0x304/0x418)
[ 9641.234638] [<c00c17c0>] (filemap_fault+0x304/0x418) from [<c00de694>] (__do_fault+0xd4/0x530)
[ 9641.234665] [<c00de694>] (__do_fault+0xd4/0x530) from [<c00e10c0>] (handle_pte_fault+0x480/0xf54)
[ 9641.234690] [<c00e10c0>] (handle_pte_fault+0x480/0xf54) from [<c00e2bf8>] (handle_mm_fault+0x140/0x184)
[ 9641.234716] [<c00e2bf8>] (handle_mm_fault+0x140/0x184) from [<c0316688>] (do_page_fault+0x150/0x3ac)
[ 9641.234737] [<c0316688>] (do_page_fault+0x150/0x3ac) from [<c000842c>] (do_DataAbort+0x3c/0xa0)
[ 9641.234759] [<c000842c>] (do_DataAbort+0x3c/0xa0) from [<c0314e38>] (__dabt_usr+0x38/0x40)

After analyzing the code, I found a condition that may cause this failed
in correct operations. Thus, I think this assertion is wrong and should be
removed.

Suppose there are two clean znodes and one dirty znode in TNC. So the
per-filesystem atomic_t @clean_zn_cnt is (2). If commit start, dirty_znode
is set to COW_ZNODE in get_znodes_to_commit() in case of potentially ops
on this znode. We clear COW bit and DIRTY bit in write_index() without
@tnc_mutex locked. We don't increase @clean_zn_cnt in this place. As the
comments in write_index() shows, if another process hold @tnc_mutex and
dirty this znode after we clean it, @clean_zn_cnt would be decreased to (1).
We will increase @clean_zn_cnt to (2) with @tnc_mutex locked in
free_obsolete_znodes() to keep it right.

If shrink_tnc() performs between decrease and increase, it will release
other 2 clean znodes it holds and found @clean_zn_cnt is less than zero
(1 - 2 = -1), then hit the assertion. Because free_obsolete_znodes() will
soon correct @clean_zn_cnt and no harm to fs in this case, I think this
assertion could be removed.

2 clean zondes and 1 dirty znode, @clean_zn_cnt == 2

Thread A (commit)         Thread B (write or others)       Thread C (shrinker)
->write_index
   ->clear_bit(DIRTY_NODE)
   ->clear_bit(COW_ZNODE)

            @clean_zn_cnt == 2
                          ->mutex_locked(&tnc_mutex)
                          ->dirty_cow_znode
                              ->!ubifs_zn_cow(znode)
                              ->!test_and_set_bit(DIRTY_NODE)
                              ->atomic_dec(&clean_zn_cnt)
                          ->mutex_unlocked(&tnc_mutex)

            @clean_zn_cnt == 1
                                                           ->mutex_locked(&tnc_mutex)
                                                           ->shrink_tnc
                                                             ->destroy_tnc_subtree
                                                             ->atomic_sub(&clean_zn_cnt, 2)
                                                             ->ubifs_assert  <- hit
                                                           ->mutex_unlocked(&tnc_mutex)

            @clean_zn_cnt == -1
->mutex_lock(&tnc_mutex)
->free_obsolete_znodes
   ->atomic_inc(&clean_zn_cnt)
->mutux_unlock(&tnc_mutex)

            @clean_zn_cnt == 0 (correct after shrink)

Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
0834497
@bvanassche bvanassche IB/umad: Fix use-after-free on close
commit 60e1751 upstream.

Avoid that closing /dev/infiniband/umad<n> or /dev/infiniband/issm<n>
triggers a use-after-free.  __fput() invokes f_op->release() before it
invokes cdev_put().  Make sure that the ib_umad_device structure is
freed by the cdev_put() call instead of f_op->release().  This avoids
that changing the port mode from IB into Ethernet and back to IB
followed by restarting opensmd triggers the following kernel oops:

    general protection fault: 0000 [#1] PREEMPT SMP
    RIP: 0010:[<ffffffff810cc65c>]  [<ffffffff810cc65c>] module_put+0x2c/0x170
    Call Trace:
     [<ffffffff81190f20>] cdev_put+0x20/0x30
     [<ffffffff8118e2ce>] __fput+0x1ae/0x1f0
     [<ffffffff8118e35e>] ____fput+0xe/0x10
     [<ffffffff810723bc>] task_work_run+0xac/0xe0
     [<ffffffff81002a9f>] do_notify_resume+0x9f/0xc0
     [<ffffffff814b8398>] int_signal+0x12/0x17

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=75051
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d0d9888
@jwrdegoede jwrdegoede Input: elantech - deal with clickpads reporting right button events
commit cd9e83e upstream.

At least the Dell Vostro 5470 elantech *clickpad* reports right button
clicks when clicked in the right bottom area:

https://bugzilla.redhat.com/show_bug.cgi?id=1103528

This is different from how (elantech) clickpads normally operate, normally
no matter where the user clicks on the pad the pad always reports a left
button event, since there is only 1 hardware button beneath the path.

It looks like Dell has put 2 buttons under the pad, one under each bottom
corner, causing this.

Since this however still clearly is a real clickpad hardware-wise, we still
want to report it as such to userspace, so that things like finger movement
in the bottom area can be properly ignored as it should be on clickpads.

So deal with this weirdness by simply mapping a right click to a left click
on elantech clickpads. As an added advantage this is something which we can
simply do on all elantech clickpads, so no need to add special quirks for
this weird model.

Reported-and-tested-by: Elder Marco <eldermarco@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
c80dcb8
@aejsmith aejsmith recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in…
… modules

commit 91ad11d upstream.

On MIPS calls to _mcount in modules generate 2 instructions to load
the _mcount address (and therefore 2 relocations). The mcount_loc
table should only reference the first of these, so the second is
filtered out by checking the relocation offset and ignoring ones that
immediately follow the previous one seen.

However if a module has an _mcount call at offset 0, the second
relocation would not be filtered out due to old_r_offset == 0
being taken to mean that the current relocation is the first one
seen, and both would end up in the mcount_loc table.

This results in ftrace_make_nop() patching both (adjacent)
instructions to branches over the _mcount call sequence like so:

  0xffffffffc08a8000:  04 00 00 10     b       0xffffffffc08a8014
  0xffffffffc08a8004:  04 00 00 10     b       0xffffffffc08a8018
  0xffffffffc08a8008:  2d 08 e0 03     move    at,ra
  ...

The second branch is in the delay slot of the first, which is
defined to be unpredictable - on the platform on which this bug was
encountered, it triggers a reserved instruction exception.

Fix by initializing old_r_offset to ~0 and using that instead of 0
to determine whether the current relocation is the first seen.

Signed-off-by: Alex Smith <alex.smith@imgtec.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7098/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
0e4c57c
Markos Chandras MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremap'd region
commit ab6c15b upstream.

Previously, the lower limit for the MIPS SC initialization loop was
set incorrectly allowing one extra loop leading to writes
beyond the MSC ioremap'd space. More precisely, the value of the 'imp'
in the last loop increased beyond the msc_irqmap_t boundaries and
as a result of which, the 'n' variable was loaded with an incorrect
value. This value was used later on to calculate the offset in the
MSC01_IC_SUP which led to random crashes like the following one:

CPU 0 Unable to handle kernel paging request at virtual address e75c0200,
epc == 8058dba4, ra == 8058db90
[...]
Call Trace:
[<8058dba4>] init_msc_irqs+0x104/0x154
[<8058b5bc>] arch_init_irq+0xd8/0x154
[<805897b0>] start_kernel+0x220/0x36c

Kernel panic - not syncing: Attempted to kill the idle task!

This patch fixes the problem

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7118/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
df5c07b
@utrace utrace tracing: Fix syscall_*regfunc() vs copy_process() race
commit 4af4206 upstream.

syscall_regfunc() and syscall_unregfunc() should set/clear
TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race
with copy_process() and miss the new child which was not added to
the process/thread lists yet.

Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT
under tasklist.

Link: http://lkml.kernel.org/p/20140413185854.GB20668@redhat.com

Fixes: a871bd3 "tracing: Add syscall tracepoints"
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
0c3351a
Gavin Shan powerpc/pseries: Fix overwritten PE state
commit 54f112a upstream.

In pseries_eeh_get_state(), EEH_STATE_UNAVAILABLE is always
overwritten by EEH_STATE_NOT_SUPPORT because of the missed
"break" there. The patch fixes the issue.

Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d5110f6
@pebolle pebolle powerpc: fix typo 'CONFIG_PPC_CPU'
commit b69a1da upstream.

Commit cd64d16 ("powerpc: mtmsrd not defined") added a check for
CONFIG_PPC_CPU were a check for CONFIG_PPC_FPU was clearly intended.

Fixes: cd64d16 ("powerpc: mtmsrd not defined")
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
60db341
@pebolle pebolle powerpc: fix typo 'CONFIG_PMAC'
commit 6e0fdf9 upstream.

Commit b0d278b ("powerpc/perf_event: Reduce latency of calling
perf_event_do_pending") added a check for CONFIG_PMAC were a check for
CONFIG_PPC_PMAC was clearly intended.

Fixes: b0d278b ("powerpc/perf_event: Reduce latency of calling perf_event_do_pending")
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
52cbee9
@htejun htejun ptrace,x86: force IRET path after a ptrace_stop()
commit b9cd18d upstream.

The 'sysret' fastpath does not correctly restore even all regular
registers, much less any segment registers or reflags values.  That is
very much part of why it's faster than 'iret'.

Normally that isn't a problem, because the normal ptrace() interface
catches the process using the signal handler infrastructure, which
always returns with an iret.

However, some paths can get caught using ptrace_event() instead of the
signal path, and for those we need to make sure that we aren't going to
return to user space using 'sysret'.  Otherwise the modifications that
may have been done to the register set by the tracer wouldn't
necessarily take effect.

Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
arch_ptrace_stop_needed() which is invoked from ptrace_stop().

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
e3293b8
@gregkh gregkh Linux 3.4.97 7913639
@bmork bmork USB: add USB_DEVICE_INTERFACE_CLASS macro
commit 17b72fe upstream.

Matching on device and interface class with with unspecified
subclass and protocol is sometimes useful.  This is slightly
different from USB_DEVICE_AND_INTERFACE_INFO which requires
the full interface class/subclass/protocol triplet.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3943a08
Oliver Neukum USB: option: add device ID for SpeedUp SU9800 usb 3g modem
commit 1cab4c6 upstream.

Reported by Alif Mubarak Ahmad:

This device vendor and product id is 1c9e:9800
It is working as serial interface with generic usbserial driver.
I thought it is more suitable to use usbserial option driver, which has
better capability distinguishing between modem serial interface and
micro sd storage interface.

[ johan: style changes ]

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Tested-by: Alif Mubarak Ahmad <alive4ever@live.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1bd617e
@bjking1 bjking1 ibmvscsi: Abort init sequence during error recovery
commit 9ee7559 upstream.

If a CRQ reset is triggered for some reason while in the middle
of performing VSCSI adapter initialization, we don't want to
call the done function for the initialization MAD commands as
this will only result in two threads attempting initialization
at the same time, resulting in failures.

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
7c4b5eb
@jhovold jhovold USB: ftdi_sio: fix null deref at port probe
commit aea1ae8 upstream.

Fix NULL-pointer dereference when probing an interface with no
endpoints.

These devices have two bulk endpoints per interface, but this avoids
crashing the kernel if a user forces a non-FTDI device to be probed.

Note that the iterator variable was made unsigned in order to avoid
a maybe-uninitialized compiler warning for ep_desc after the loop.

Fixes: 895f28b ("USB: ftdi_sio: fix hi-speed device packet size
calculation")

Reported-by: Mike Remski <mremski@mutualink.net>
Tested-by: Mike Remski <mremski@mutualink.net>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d539a05
@bmork bmork usb: option: add/modify Olivetti Olicard modems
commit b0ebef3 upstream.

Adding a couple of Olivetti modems and blacklisting the net
function on a couple which are already supported.

Reported-by: Lars Melin <larsm17@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1d4cd89
@mina86 mina86 usb: gadget: f_fs: fix NULL pointer dereference when there are no str…
…ings

commit f0688c8 upstream.

If the descriptors do not need any strings and user space sends empty
set of strings, the ffs->stringtabs field remains NULL.  Thus
*ffs->stringtabs in functionfs_bind leads to a NULL pointer
dereferenece.

The bug was introduced by commit [fd7c9a0: “use usb_string_ids_n()”].

While at it, remove double initialisation of lang local variable in
that function.

ffs->strings_count does not need to be checked in any way since in
the above scenario it will remain zero and usb_string_ids_n() is
a no-operation when colled with 0 argument.

Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
005564f
@matnyman matnyman xhci: correct burst count field for isoc transfers on 1.0 xhci hosts
commit 3213b15 upstream.

The transfer burst count (TBC) field in xhci 1.0 hosts should be set
to the number of bursts needed to transfer all packets in a isoc TD.
Supported values are 0-2 (1 to 3 bursts per service interval).

Formula for TBC calculation is given in xhci spec section 4.11.2.3:
TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1

This patch should be applied to stable kernels since 3.0 that contain
the commit 5cd43e3
"xhci 1.0: Set transfer burst count field."

Suggested-by: ShiChun Ma <masc2008@qq.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
4d73119
Wang, Yu xhci: Fix runtime suspended xhci from blocking system suspend.
commit d6236f6 upstream.

The system suspend flow as following:
1, Freeze all user processes and kenrel threads.

2, Try to suspend all devices.

2.1, If pci device is in RPM suspended state, then pci driver will try
to resume it to RPM active state in the prepare stage.

2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
workqueue items to resume usb2&usb3 roothub devices.

2.3, Call suspend callbacks of devices.

2.3.1, All suspend callbacks of all hcd's children, including
roothub devices are called.

2.3.2, Finally, hcd_pci_suspend callback is called.

Due to workqueue threads were already frozen in step 1, the workqueue
items can't be scheduled, and the roothub devices can't be resumed in
this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
usb_hcd_resume_root_hub won't be cleared. Finally,
hcd_pci_suspend will return -EBUSY, and system suspend fails.

The reason why this issue doesn't show up very often is due to that
choose_wakeup will be called in step 2.3.1. In step 2.3.1, if
udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then
udev will resume to RPM active for changing the wakeup settings. This
has been a lucky hit which hides this issue.

For some special xHCI controllers which have no USB2 port, then roothub
will not match hub driver due to probe failed. Then its
do_remote_wakeup will be set to zero, and we won't be as lucky.

xhci driver doesn't need to resume roothub devices everytime like in
the above case. It's only needed when there are pending event TRBs.

This patch should be back-ported to kernels as old as 3.2, that
contains the commit f69e312
"USB: XHCI: resume root hubs when the controller resumes"

Signed-off-by: Wang, Yu <yu.y.wang@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
[use readl() instead of removed xhci_readl(), reword commit message -Mathias]
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
939a3a4
Syam Sidhardhan Bluetooth: Remove unused hci_le_ltk_reply()
commit e10b996 upstream.

In this API, we were using sizeof operator for an array
given as function argument, which is invalid.
However this API is not used anywhere.

Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
eb688f6
Alex Deucher drm/radeon: only apply hdmi bpc pll flags when encoder mode is hdmi
commit 7d5ab30 upstream.

May fix display issues with non-HDMI displays.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
b048370
@tpetazzoni tpetazzoni mtd: pxa3xx_nand: make the driver work on big-endian systems
commit b7e4606 upstream.

The pxa3xx_nand driver currently uses __raw_writel() and __raw_readl()
to access I/O registers. However, those functions do not do any
endianness swapping, which means that they won't work when the CPU
runs in big-endian but the I/O registers are little endian, which is
the common situation for ARM systems running big endian.

Since __raw_writel() and __raw_readl() do not include any memory
barriers and the pxa3xx_nand driver can only be compiled for ARM
platforms, the closest I/o accessors functions that do endianess
swapping are writel_relaxed() and readl_relaxed().

This patch has been verified to work on Armada XP GP: without the
patch, the NAND is not detected when the kernel runs big endian while
it is properly detected when the kernel runs little endian. With the
patch applied, the NAND is properly detected in both situations
(little and big endian).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
c27517d
@ariknem ariknem mac80211: don't check netdev state for debugfs read/write
commit 923eaf3 upstream.

Doing so will lead to an oops for a p2p-dev interface, since it has
no netdev.

Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dc0bfd6
Alex Deucher drm/radeon: fix typo in radeon_connector_is_dp12_capable()
commit af5d365 upstream.

We were checking the ext clock rather than the display clock.

Noticed by ArtForz on IRC.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
91b75cb
Alex Deucher drm/radeon/atom: fix dithering on certain panels
commit 6425283 upstream.

We need to specify the encoder mode as LVDS for eDP
when using the Crtc_Source atom table in order to properly
set up the FMT hardware.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73911

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
822780c
@jhedberg jhedberg Bluetooth: Fix SSP acceptor just-works confirmation without MITM
commit ba15a58 upstream.

From the Bluetooth Core Specification 4.1 page 1958:

"if both devices have set the Authentication_Requirements parameter to
one of the MITM Protection Not Required options, authentication stage 1
shall function as if both devices set their IO capabilities to
DisplayOnly (e.g., Numeric comparison with automatic confirmation on
both devices)"

So far our implementation has done user confirmation for all just-works
cases regardless of the MITM requirements, however following the
specification to the word means that we should not be doing confirmation
when neither side has the MITM flag set.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Tested-by: Szymon Janc <szymon.janc@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bc96ff5
@sgruszka sgruszka rt2x00: disable TKIP on USB
commit 8edcb0b upstream.

On USB we can not get atomically TKIP key. We have to disable support
for TKIP acceleration on USB hardware to avoid bug as showed bellow.

[  860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002
<snip>
[  860.827280] Call Trace:
[  860.827282]  [<ffffffff81682ea6>] dump_stack+0x4d/0x66
[  860.827284]  [<ffffffff8167eb9b>] __schedule_bug+0x47/0x55
[  860.827285]  [<ffffffff81685bb3>] __schedule+0x733/0x7b0
[  860.827287]  [<ffffffff81685c59>] schedule+0x29/0x70
[  860.827289]  [<ffffffff81684f8a>] schedule_timeout+0x15a/0x2b0
[  860.827291]  [<ffffffff8105ac50>] ? ftrace_raw_event_tick_stop+0xc0/0xc0
[  860.827294]  [<ffffffff810c13c2>] ? __module_text_address+0x12/0x70
[  860.827296]  [<ffffffff81686823>] wait_for_completion_timeout+0xb3/0x140
[  860.827298]  [<ffffffff81080fc0>] ? wake_up_state+0x20/0x20
[  860.827301]  [<ffffffff814d5b3d>] usb_start_wait_urb+0x7d/0x150
[  860.827303]  [<ffffffff814d5cd5>] usb_control_msg+0xc5/0x110
[  860.827305]  [<ffffffffa02fb0c6>] rt2x00usb_vendor_request+0xc6/0x160  [rt2x00usb]
[  860.827307]  [<ffffffffa02fb215>] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb]
[  860.827309]  [<ffffffffa02fb393>] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb]
[  860.827311]  [<ffffffffa023d1a3>] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb]
[  860.827314]  [<ffffffffa05805f9>] rt2800_get_tkip_seq+0x39/0x50  [rt2800lib]
[  860.827321]  [<ffffffffa0480f88>] ieee80211_get_key+0x218/0x2a0  [mac80211]
[  860.827322]  [<ffffffff815cc68c>] ? __nlmsg_put+0x6c/0x80
[  860.827329]  [<ffffffffa051b02e>] nl80211_get_key+0x22e/0x360 [cfg80211]

Reported-and-tested-by: Peter Wu <lekensteyn@gmail.com>
Reported-and-tested-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2160cad
@rmilecki rmilecki b43: fix frequency reported on G-PHY with /new/ firmware
commit 2fc68eb upstream.

Support for firmware rev 508+ was added years ago, but we never noticed
it reports channel in a different way for G-PHY devices. Instead of
offset from 2400 MHz it simply passes channel id (AKA hw_value).

So far it was (most probably) affecting monitor mode users only, but
the following recent commit made it noticeable for quite everybody:

commit 3afc216
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Tue Mar 4 16:50:13 2014 +0200

    cfg80211/mac80211: ignore signal if the frame was heard on wrong channel

Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
74be85d
Stanislaw Gruszka rt2x00: fix rfkill regression on rt2500pci
commit 616a839 upstream.

As reported by Niels, starting rfkill polling during device probe
(commit e2bc7c5, generally sane change) broke rfkill on rt2500pci
device. I considered that bug as some initalization issue, which
should be fixed on rt2500pci specific code. But after several
attempts (see bug report for details) we fail to find working solution.
Hence I decided to revert to old behaviour on rt2500pci to fix
regression.

Additionally patch also unregister rfkill on device remove instead
of ifconfig down, what was another issue introduced by bad commit.

Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=73821

Fixes: e2bc7c5 ("rt2x00: Fix rfkill_polling register function.")
Bisected-by: Niels <nille0386@googlemail.com>
Reported-and-tested-by: Niels <nille0386@googlemail.com>
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
53a7d50
David R. Piegdon ARM: OMAP2+: Fix parser-bug in platform muxing code
commit c021f24 upstream.

Fix a parser-bug in the omap2 muxing code where muxtable-entries will be
wrongly selected if the requested muxname is a *prefix* of their
m0-entry and they have a matching mN-entry. Fix by additionally checking
that the length of the m0_entry is equal.

For example muxing of "dss_data2.dss_data2" on omap32xx will fail
because the prefix "dss_data2" will match the mux-entries "dss_data2" as
well as "dss_data20", with the suffix "dss_data2" matching m0 (for
dss_data2) and m4 (for dss_data20). Thus both are recognized as signal
path candidates:

Relevant muxentries from mux34xx.c:
        _OMAP3_MUXENTRY(DSS_DATA20, 90,
                "dss_data20", NULL, "mcspi3_somi", "dss_data2",
                "gpio_90", NULL, NULL, "safe_mode"),
        _OMAP3_MUXENTRY(DSS_DATA2, 72,
                "dss_data2", NULL, NULL, NULL,
                "gpio_72", NULL, NULL, "safe_mode"),

This will result in a failure to mux the pin at all:

 _omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2

Patch should apply to linus' latest master down to rather old linux-2.6
trees.

Signed-off-by: David R. Piegdon <lkml@p23q.org>
Cc: stable@vger.kernel.org
[tony@atomide.com: updated description to include full description]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ba8f03a
Nadav Amit KVM: x86: Increase the number of fixed MTRR regs to 10
commit 682367c upstream.

Recent Intel CPUs have 10 variable range MTRRs. Since operating systems
sometime make assumptions on CPUs while they ignore capability MSRs, it is
better for KVM to be consistent with recent CPUs. Reporting more MTRRs than
actually supported has no functional implications.

Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
80bbfba
@bonzini bonzini KVM: x86: preserve the high 32-bits of the PAT register
commit 7cb060a upstream.

KVM does not really do much with the PAT, so this went unnoticed for a
long time.  It is exposed however if you try to do rdmsr on the PAT
register.

Reported-by: Valentine Sinitsyn <valentine.sinitsyn@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
a96a557
J. Bruce Fields nfsd: fix rare symlink decoding bug
commit 76f4712 upstream.

An NFS operation that creates a new symlink includes the symlink data,
which is xdr-encoded as a length followed by the data plus 0 to 3 bytes
of zero-padding as required to reach a 4-byte boundary.

The vfs, on the other hand, wants null-terminated data.

The simple way to handle this would be by copying the data into a newly
allocated buffer with space for the final null.

The current nfsd_symlink code tries to be more clever by skipping that
step in the (likely) case where the byte following the string is already
0.

But that assumes that the byte following the string is ours to look at.
In fact, it might be the first byte of a page that we can't read, or of
some object that another task might modify.

Worse, the NFSv4 code tries to fix the problem by actually writing to
that byte.

In the NFSv2/v3 cases this actually appears to be safe:

	- nfs3svc_decode_symlinkargs explicitly null-terminates the data
	  (after first checking its length and copying it to a new
	  page).
	- NFSv2 limits symlinks to 1k.  The buffer holding the rpc
	  request is always at least a page, and the link data (and
	  previous fields) have maximum lengths that prevent the request
	  from reaching the end of a page.

In the NFSv4 case the CREATE op is potentially just one part of a long
compound so can end up on the end of a page if you're unlucky.

The minimal fix here is to copy and null-terminate in the NFSv4 case.
The nfsd_symlink() interface here seems too fragile, though.  It should
really either do the copy itself every time or just require a
null-terminated string.

Reported-by: Jeff Layton <jlayton@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
a22a7e7
@smfrench smfrench CIFS: fix mount failure with broken pathnames when smb3 mount with ma…
…pchars option

commit ce36d9a upstream.

When we SMB3 mounted with mapchars (to allow reserved characters : \ / > < * ?
via the Unicode Windows to POSIX remap range) empty paths
(eg when we open "" to query the root of the SMB3 directory on mount) were not
null terminated so we sent garbarge as a path name on empty paths which caused
SMB2/SMB2.1/SMB3 mounts to fail when mapchars was specified.  mapchars is
particularly important since Unix Extensions for SMB3 are not supported (yet)

Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6e44d31
@thomashvmw thomashvmw drm/vmwgfx: Fix incorrect write to read-only register v2:
commit 4e57808 upstream.

Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
SVGA_REG_PITCHLOCK.

This patch is Cc'd stable because of the unknown effects writing to this
register might have, particularly on older device versions.

v2: Updated log message.

Cc: Christopher Friedt <chrisfriedt@gmail.com>
Tested-by: Christopher Friedt <chrisfriedt@gmail.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1dbae5d
@iksaif iksaif acpi/video_detect: blacklist samsung x360
commit 084940d upstream.

On Samsung X360, the BIOS will set a flag (VDRV) if the generic
ACPI backlight device is used. This flag will definitively break
the backlight interface (even the vendor interface) untill next
reboot. It's why we should prevent video.ko from being used here
and we can't rely on a later call to acpi_video_unregister().

Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
89c9afd
@ian-abbott ian-abbott staging: comedi: das08: Correct AI encoding for das08jr-16-ao
commit e6391a1 upstream.

The element of `das08_boards[]` for the 'das08jr-16-ao' board has the
`ai_encoding` member set to `das08_encode12`.  It should be set to
`das08_encode16` same as the 'das08jr/16' board.  After all, this board
has 16-bit AI resolution.

The description of the A/D LSB register at offset 0 seems incorrect in
the user manual "cio-das08jr-16-ao.pdf" as it implies that the AI
resolution is only 12 bits.  The diagrams of the A/D LSB and MSB
registers show 15 data bits and a sign bit, which matches what the
software expects for the `das08_encode16` AI encoding method.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust indentation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2a6ae02
Kevin McKinney Staging: bcm: Create and initialize new device id in InterfaceInit
commit e66fc1f upstream.

This patch create and initalizes a new device
id of 0x172 as reported by Rinat Camalov
<richman1000000d@gmail.com>. In addition, a
comment is added to the potential invalid
existing device id.

Reported-by: Rinat Camalov <richman1000000d@gmail.com>
Signed-off-by: Kevin McKinney <klmckinney1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
f3e786c
Kevin McKinney Staging: bcm: Add two products and remove an existing product.
commit 4f29ef0 upstream.

This patch adds two new products and modifies
the device id table to include them. In addition,
product of 0xbccd - BCM_USB_PRODUCT_ID_SM250 is
removed because Beceem, ZTE, Sprint use this id
for block devices.

Reported-by: Muhammad Minhazul Haque <mdminhazulhaque@gmail.com>
Signed-off-by: Kevin McKinney <klmckinney1@gmail.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
edc9d9a
Lan Tianyu ACPI / video: Add "Asus UL30VT" to ACPI video detect blacklist
commit d0c2ce1 upstream.

The ACPI video driver can't control backlight correctly on
Asus UL30VT.  Vendor driver (asus-laptop) can work.  This patch is to
add "Asus UL30VT" to ACPI video detect blacklist in order to use
asus-laptop for video control on the "Asus UL30VT" rather than ACPI
video driver.

References: https://bugzilla.kernel.org/show_bug.cgi?id=32592
Reported-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
622c5c1
Chen Gang powerpc/smp: Section mismatch from smp_release_cpus to __initdata spi…
…nning_secondaries

commit 8246aca upstream.

the smp_release_cpus is a normal funciton and called in normal environments,
  but it calls the __initdata spinning_secondaries.
  need modify spinning_secondaries to match smp_release_cpus.

the related warning:
  (the linker report boot_paca.33377, but it should be spinning_secondaries)

-----------------------------------------------------------------------------

WARNING: arch/powerpc/kernel/built-in.o(.text+0x23176): Section mismatch in reference from the function .smp_release_cpus() to the variable .init.data:boot_paca.33377
The function .smp_release_cpus() references
the variable __initdata boot_paca.33377.
This is often because .smp_release_cpus lacks a __initdata
annotation or the annotation of boot_paca.33377 is wrong.

WARNING: arch/powerpc/kernel/built-in.o(.text+0x231fe): Section mismatch in reference from the function .smp_release_cpus() to the variable .init.data:boot_paca.33377
The function .smp_release_cpus() references
the variable __initdata boot_paca.33377.
This is often because .smp_release_cpus lacks a __initdata
annotation or the annotation of boot_paca.33377 is wrong.

-----------------------------------------------------------------------------

Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1902a25
Chen Gang powerpc/pseries/lparcfg: Fix possible overflow are more than 1026
commit 5676005 upstream.

need set '\0' for 'local_buffer'.

SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096. so the contents of
rtas_data_buf may truncated in memcpy.

if contents are really truncated.
  the splpar_strlen is more than 1026. the next while loop checking will
  not find the end of buffer. that will cause memory access violation.

Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
a1ca0f8
Alex Hung ACPI video: ignore BIOS initial backlight value for HP 1000
commit 4ef366c upstream.

On HP 1000 lapops, BIOS reports minimum backlight on boot and
causes backlight to dim completely. This ignores the initial backlight
values and set to max brightness.

References:: https://bugs.launchpad.net/bugs/1167760
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
0e4337b
@btriller btriller ACPI / video: Add "Asus UL30A" to ACPI video detect blacklist
commit c8f6d83 upstream.

Like on UL30VT, the ACPI video driver can't control backlight correctly on
Asus UL30A.  Vendor driver (asus-laptop) can work.  This patch is to
add "Asus UL30A" to ACPI video detect blacklist in order to use
asus-laptop for video control on the "Asus UL30A" rather than ACPI
video driver.

Signed-off-by: Bastian Triller <bastian.triller@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
047cce4
@paulusmack paulusmack powerpc: Fix emulation of illegal instructions on PowerNV platform
commit bf59390 upstream.

Normally, the kernel emulates a few instructions that are unimplemented
on some processors (e.g. the old dcba instruction), or privileged (e.g.
mfpvr).  The emulation of unimplemented instructions is currently not
working on the PowerNV platform.  The reason is that on these machines,
unimplemented and illegal instructions cause a hypervisor emulation
assist interrupt, rather than a program interrupt as on older CPUs.
Our vector for the emulation assist interrupt just calls
program_check_exception() directly, without setting the bit in SRR1
that indicates an illegal instruction interrupt.  This fixes it by
making the emulation assist interrupt set that bit before calling
program_check_interrupt().  With this, old programs that use no-longer
implemented instructions such as dcba now work again.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1ee6596
@ian-abbott ian-abbott staging: comedi: fix a race between do_cmd_ioctl() and read/write
commit 4b18f08 upstream.

`do_cmd_ioctl()` is called with the comedi device's mutex locked to
process the `COMEDI_CMD` ioctl to set up comedi's asynchronous command
handling on a comedi subdevice.  `comedi_read()` and `comedi_write()`
are the `read` and `write` handlers for the comedi device, but do not
lock the mutex (for performance reasons, as some things can hold the
mutex for quite a long time).

There is a race condition if `comedi_read()` or `comedi_write()` is
running at the same time and for the same file object and comedi
subdevice as `do_cmd_ioctl()`.  `do_cmd_ioctl()` sets the subdevice's
`busy` pointer to the file object way before it sets the `SRF_RUNNING` flag
in the subdevice's `runflags` member.  `comedi_read() and
`comedi_write()` check the subdevice's `busy` pointer is pointing to the
current file object, then if the `SRF_RUNNING` flag is not set, will call
`do_become_nonbusy()` to shut down the asyncronous command.  Bad things
can happen if the asynchronous command is being shutdown and set up at
the same time.

To prevent the race, don't set the `busy` pointer until
after the `SRF_RUNNING` flag has been set.  Also, make sure the mutex is
held in `comedi_read()` and `comedi_write()` while calling
`do_become_nonbusy()` in order to avoid moving the race condition to a
point within that function.

Change some error handling `goto cleanup` statements in `do_cmd_ioctl()`
to simple `return -ERRFOO` statements as a result of changing when the
`busy` pointer is set.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d4a64a9
@ozbenh ozbenh powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without hype…
…rvisor

commit f5f6cbb upstream.

/proc/powerpc/lparcfg is an ancient facility (though still actively used)
which allows access to some informations relative to the partition when
running underneath a PAPR compliant hypervisor.

It makes no sense on non-pseries machines. However, currently, not only
can it be created on these if the kernel has pseries support, but accessing
it on such a machine will crash due to trying to do hypervisor calls.

In fact, it should also not do HV calls on older pseries that didn't have
an hypervisor either.

Finally, it has the plumbing to be a module but is a "bool" Kconfig option.

This fixes the whole lot by turning it into a machine_device_initcall
that is only created on pseries, and adding the necessary hypervisor
check before calling the H_GET_EM_PARMS hypercall

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[bwh: Backported to 3.2: lparcfg_cleanup() was a bit different]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
58b9385
@paulmck paulmck powerpc: Restore registers on error exit from csum_partial_copy_gener…
…ic()

commit 8f21bd0 upstream.

The csum_partial_copy_generic() function saves the PowerPC non-volatile
r14, r15, and r16 registers for the main checksum-and-copy loop.
Unfortunately, it fails to restore them upon error exit from this loop,
which results in silent corruption of these registers in the presumably
rare event of an access exception within that loop.

This commit therefore restores these register on error exit from the loop.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[bwh: Backported to 3.2: register name macros use lower-case 'r']
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
0b36b7f
Dan Carpenter staging: wlags49_h2: buffer overflow setting station name
commit b5e2f33 upstream.

We need to check the length parameter before doing the memcpy().  I've
actually changed it to strlcpy() as well so that it's NUL terminated.

You need CAP_NET_ADMIN to trigger these so it's not the end of the
world.

Reported-by: Nico Golde <nico@ngolde.de>
Reported-by: Fabian Yamaguchi <fabs@goesec.de>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8f668a0
Mikulas Patocka sym53c8xx_2: Set DID_REQUEUE return code when aborting squeue
commit fd1232b upstream.

This patch fixes I/O errors with the sym53c8xx_2 driver when the disk
returns QUEUE FULL status.

When the controller encounters an error (including QUEUE FULL or BUSY
status), it aborts all not yet submitted requests in the function
sym_dequeue_from_squeue.

This function aborts them with DID_SOFT_ERROR.

If the disk has full tag queue, the request that caused the overflow is
aborted with QUEUE FULL status (and the scsi midlayer properly retries
it until it is accepted by the disk), but the sym53c8xx_2 driver aborts
the following requests with DID_SOFT_ERROR --- for them, the midlayer
does just a few retries and then signals the error up to sd.

The result is that disk returning QUEUE FULL causes request failures.

The error was reproduced on 53c895 with COMPAQ BD03685A24 disk
(rebranded ST336607LC) with command queue 48 or 64 tags.  The disk has
64 tags, but under some access patterns it return QUEUE FULL when there
are less than 64 pending tags.  The SCSI specification allows returning
QUEUE FULL anytime and it is up to the host to retry.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8e51d5a
@mina86 mina86 tools: ffs-test: fix header values endianess
commit f35f712 upstream.

It appears that no one ever run ffs-test on a big-endian machine,
since it used cpu-endianess for fs_count and hs_count fields which
should be in little-endian format.  Fix by wrapping the numbers in
cpu_to_le32.

Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
21057e4
@neilbrown neilbrown md: flush writes before starting a recovery.
commit 133d452 upstream.

When we write to a degraded array which has a bitmap, we
make sure the relevant bit in the bitmap remains set when
the write completes (so a 're-add' can quickly rebuilt a
temporarily-missing device).

If, immediately after such a write starts, we incorporate a spare,
commence recovery, and skip over the region where the write is
happening (because the 'needs recovery' flag isn't set yet),
then that write will not get to the new device.

Once the recovery finishes the new device will be trusted, but will
have incorrect data, leading to possible corruption.

We cannot set the 'needs recovery' flag when we start the write as we
do not know easily if the write will be "degraded" or not.  That
depends on details of the particular raid level and particular write
request.

This patch fixes a corruption issue of long standing and so it
suitable for any -stable kernel.  It applied correctly to 3.0 at
least and will minor editing to earlier kernels.

Reported-by: Bill <billstuff2001@sbcglobal.net>
Tested-by: Bill <billstuff2001@sbcglobal.net>
Link: http://lkml.kernel.org/r/53A518BB.60709@sbcglobal.net
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d3ef655
Gustavo Maciel Dias Vieira ACPI video: ignore BIOS backlight value for HP dm4
commit 771d09b upstream.

On a HP Pavilion dm4 laptop the BIOS sets minimum backlight on boot,
completely dimming the screen. Ignore this initial value for this
machine.

Signed-off-by: Gustavo Maciel Dias Vieira <gustavo@sagui.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[wyj: Backported to 3.4: adjust context]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
badd9b7
Madhavan Srinivasan powerpc/sysfs: Disable writing to PURR in guest mode
commit d1211af upstream.

arch/powerpc/kernel/sysfs.c exports PURR with write permission.
This may be valid for kernel in phyp mode. But writing to
the file in guest mode causes crash due to a priviledge violation

Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[Backported to 3.4: adjust context]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
08ccce4
@antonblanchard antonblanchard powerpc/pseries: Duplicate dtl entries sometimes sent to userspace
commit 84b0738 upstream.

When reading from the dispatch trace log (dtl) userspace interface, I
sometimes see duplicate entries. One example:

# hexdump -C dtl.out

00000000  07 04 00 0c 00 00 48 44  00 00 00 00 00 00 00 00
00000010  00 0c a0 b4 16 83 6d 68  00 00 00 00 00 00 00 00
00000020  00 00 00 00 10 00 13 50  80 00 00 00 00 00 d0 32

00000030  07 04 00 0c 00 00 48 44  00 00 00 00 00 00 00 00
00000040  00 0c a0 b4 16 83 6d 68  00 00 00 00 00 00 00 00
00000050  00 00 00 00 10 00 13 50  80 00 00 00 00 00 d0 32

The problem is in scan_dispatch_log() where we call dtl_consumer()
but bail out before incrementing the index.

To fix this I moved dtl_consumer() after the timebase comparison.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9e1ba6f
@Naoya-Horiguchi Naoya-Horiguchi hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned…
… entry

commit 4a705fe upstream.

There's a race between fork() and hugepage migration, as a result we try
to "dereference" a swap entry as a normal pte, causing kernel panic.
The cause of the problem is that copy_hugetlb_page_range() can't handle
"swap entry" family (migration entry and hwpoisoned entry) so let's fix
it.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: <stable@vger.kernel.org>	[2.6.37+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2bcdd49
Hugh Dickins mm: fix crashes from mbind() merging vmas
commit d05f0cd upstream.

In v2.6.34 commit 9d8cebd ("mm: fix mbind vma merge problem")
introduced vma merging to mbind(), but it should have also changed the
convention of passing start vma from queue_pages_range() (formerly
check_range()) to new_vma_page(): vma merging may have already freed
that structure, resulting in BUG at mm/mempolicy.c:1738 and probably
worse crashes.

Fixes: 9d8cebd ("mm: fix mbind vma merge problem")
Reported-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Tested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
50a28ba
@gregkh gregkh Linux 3.4.98 0bbbf93
@krieger-od krieger-od pushed a commit to krieger-od/linux that referenced this pull request Jul 10, 2014
Shan Wei rcu: Use __this_cpu_read() instead of per_cpu_ptr()
The __this_cpu_read() function produces better code than does
per_cpu_ptr() on both ARM and x86.  For example, gcc (Ubuntu/Linaro
4.7.3-12ubuntu1) 4.7.3 produces the following:

ARMv7 per_cpu_ptr():

force_quiescent_state:
    mov    r3, sp    @,
    bic    r1, r3, #8128    @ tmp171,,
    ldr    r2, .L98    @ tmp169,
    bic    r1, r1, #63    @ tmp170, tmp171,
    ldr    r3, [r0, #220]    @ __ptr, rsp_6(D)->rda
    ldr    r1, [r1, #20]    @ D.35903_68->cpu, D.35903_68->cpu
    mov    r6, r0    @ rsp, rsp
    ldr    r2, [r2, r1, asl #2]    @ tmp173, __per_cpu_offset
    add    r3, r3, r2    @ tmp175, __ptr, tmp173
    ldr    r5, [r3, #12]    @ rnp_old, D.29162_13->mynode

ARMv7 __this_cpu_read():

force_quiescent_state:
    ldr    r3, [r0, #220]    @ rsp_7(D)->rda, rsp_7(D)->rda
    mov    r6, r0    @ rsp, rsp
    add    r3, r3, #12    @ __ptr, rsp_7(D)->rda,
    ldr    r5, [r2, r3]    @ rnp_old, *D.29176_13

Using gcc 4.8.2:

x86_64 per_cpu_ptr():

    movl %gs:cpu_number,%edx    # cpu_number, pscr_ret__
    movslq    %edx, %rdx    # pscr_ret__, pscr_ret__
    movq    __per_cpu_offset(,%rdx,8), %rdx    # __per_cpu_offset, tmp93
    movq    %rdi, %r13    # rsp, rsp
    movq    1000(%rdi), %rax    # rsp_9(D)->rda, __ptr
    movq    24(%rdx,%rax), %r12    # _15->mynode, rnp_old

x86_64 __this_cpu_read():

    movq    %rdi, %r13    # rsp, rsp
    movq    1000(%rdi), %rax    # rsp_9(D)->rda, rsp_9(D)->rda
    movq %gs:24(%rax),%r12    # _10->mynode, rnp_old

Because this change produces significant benefits for these two very
diverse architectures, this commit makes this change.

Signed-off-by: Shan Wei <davidshan@tencent.com>
Acked-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Lai Jiangshan <laijs@cn.fujitsu.com>
d860d40
ckkim and others added some commits Jul 8, 2014
ckkim exynos5410 not support HS200-DDR 2293439
@mdrjr mdrjr Merge tag 'v3.4.92' of git://git.kernel.org/pub/scm/linux/kernel/git/…
…stable/linux-stable into odroidxu-3.4.y

This is the 3.4.92 stable release
07d1e46
@mdrjr mdrjr Merge tag 'v3.4.93' of git://git.kernel.org/pub/scm/linux/kernel/git/…
…stable/linux-stable into odroidxu-3.4.y

This is the 3.4.93 stable release

Conflicts:
	drivers/usb/core/hub.c
bdd10fc
@mdrjr mdrjr Revert "lib: Update RWSEM to Linux 3.10"
This reverts commit 4f3c3c9.
fd7a472
@mdrjr mdrjr Revert "Optimized ARM RWSEM algorithm"
This reverts commit 378d07f.
afcc02f
@mdrjr mdrjr Merge tag 'v3.4.94' of git://git.kernel.org/pub/scm/linux/kernel/git/…
…stable/linux-stable into odroidxu-3.4.y

This is the 3.4.94 stable release
582f7f5
@mdrjr mdrjr Merge tag 'v3.4.95' of git://git.kernel.org/pub/scm/linux/kernel/git/…
…stable/linux-stable into odroidxu-3.4.y

This is the 3.4.95 stable release
13991f8
@mdrjr mdrjr Merge tag 'v3.4.96' of git://git.kernel.org/pub/scm/linux/kernel/git/…
…stable/linux-stable into odroidxu-3.4.y

This is the 3.4.96 stable release
2760c39
@mdrjr mdrjr Merge tag 'v3.4.97' of git://git.kernel.org/pub/scm/linux/kernel/git/…
…stable/linux-stable into odroidxu-3.4.y

This is the 3.4.97 stable release
b48f142
@mdrjr mdrjr Merge tag 'v3.4.98' of git://git.kernel.org/pub/scm/linux/kernel/git/…
…stable/linux-stable into odroidxu-3.4.y

This is the 3.4.98 stable release

Conflicts:
	net/bluetooth/hci_conn.c
31c5b91
@hsnaves hsnaves clk: exynos5410: Removed duplicate entry in the clock tree.
This repeated entry was preventing the logic in arch/arm/plat-samsung/clock.c
from creating a DebugFS representation of the clock tree under the
directory /sys/kernel/debug/clock.
8d92ab4
@mdrjr mdrjr Merge pull request #57 from hsnaves/odroidxu-3.4.y
clk: exynos5410: Removed duplicate entry in the clock tree.
b34f657
davem330 and others added some commits Apr 29, 2014
@davem330 davem330 sparc64: Fix top-level fault handling bugs.
[ Upstream commit 70ffc6e ]

Make get_user_insn() able to cope with huge PMDs.

Next, make do_fault_siginfo() more robust when get_user_insn() can't
actually fetch the instruction.  In particular, use the MMU announced
fault address when that happens, instead of calling
compute_effective_address() and computing garbage.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
86982cf
@davem330 davem330 sparc64: Fix argument sign extension for compat_sys_futex().
[ Upstream commit aa3449e ]

Only the second argument, 'op', is signed.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
0da9685
@davem330 davem330 sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fa…
…ult addresses.

[ Upstream commit e5c460f ]

This was found using Dave Jone's trinity tool.

When a user process which is 32-bit performs a load or a store, the
cpu chops off the top 32-bits of the effective address before
translating it.

This is because we run 32-bit tasks with the PSTATE_AM (address
masking) bit set.

We can't run the kernel with that bit set, so when the kernel accesses
userspace no address masking occurs.

Since a 32-bit process will have no mappings in that region we will
properly fault, so we don't try to handle this using access_ok(),
which can safely just be a NOP on sparc64.

Real faults from 32-bit processes should never generate such addresses
so a bug check was added long ago, and it barks in the logs if this
happens.

But it also barks when a kernel user access causes this condition, and
that _can_ happen.  For example, if a pointer passed into a system call
is "0xfffffffc" and the kernel access 4 bytes offset from that pointer.

Just handle such faults normally via the exception entries.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
0de4921
@borkmann borkmann net: sctp: inherit auth_capable on INIT collisions
[ Upstream commit 1be9a95 ]

Jason reported an oops caused by SCTP on his ARM machine with
SCTP authentication enabled:

Internal error: Oops: 17 [#1] ARM
CPU: 0 PID: 104 Comm: sctp-test Not tainted 3.13.0-68744-g3632f30c9b20-dirty #1
task: c6eefa40 ti: c6f52000 task.ti: c6f52000
PC is at sctp_auth_calculate_hmac+0xc4/0x10c
LR is at sg_init_table+0x20/0x38
pc : [<c024bb80>]    lr : [<c00f32dc>]    psr: 40000013
sp : c6f538e8  ip : 00000000  fp : c6f53924
r10: c6f50d80  r9 : 00000000  r8 : 00010000
r7 : 00000000  r6 : c7be4000  r5 : 00000000  r4 : c6f56254
r3 : c00c8170  r2 : 00000001  r1 : 00000008  r0 : c6f1e660
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005397f  Table: 06f28000  DAC: 00000015
Process sctp-test (pid: 104, stack limit = 0xc6f521c0)
Stack: (0xc6f538e8 to 0xc6f54000)
[...]
Backtrace:
[<c024babc>] (sctp_auth_calculate_hmac+0x0/0x10c) from [<c0249af8>] (sctp_packet_transmit+0x33c/0x5c8)
[<c02497bc>] (sctp_packet_transmit+0x0/0x5c8) from [<c023e96c>] (sctp_outq_flush+0x7fc/0x844)
[<c023e170>] (sctp_outq_flush+0x0/0x844) from [<c023ef78>] (sctp_outq_uncork+0x24/0x28)
[<c023ef54>] (sctp_outq_uncork+0x0/0x28) from [<c0234364>] (sctp_side_effects+0x1134/0x1220)
[<c0233230>] (sctp_side_effects+0x0/0x1220) from [<c02330b0>] (sctp_do_sm+0xac/0xd4)
[<c0233004>] (sctp_do_sm+0x0/0xd4) from [<c023675c>] (sctp_assoc_bh_rcv+0x118/0x160)
[<c0236644>] (sctp_assoc_bh_rcv+0x0/0x160) from [<c023d5bc>] (sctp_inq_push+0x6c/0x74)
[<c023d550>] (sctp_inq_push+0x0/0x74) from [<c024a6b0>] (sctp_rcv+0x7d8/0x888)

While we already had various kind of bugs in that area
ec0223e ("net: sctp: fix sctp_sf_do_5_1D_ce to verify if
we/peer is AUTH capable") and b14878c ("net: sctp: cache
auth_enable per endpoint"), this one is a bit of a different
kind.

Giving a bit more background on why SCTP authentication is
needed can be found in RFC4895:

  SCTP uses 32-bit verification tags to protect itself against
  blind attackers. These values are not changed during the
  lifetime of an SCTP association.

  Looking at new SCTP extensions, there is the need to have a
  method of proving that an SCTP chunk(s) was really sent by
  the original peer that started the association and not by a
  malicious attacker.

To cause this bug, we're triggering an INIT collision between
peers; normal SCTP handshake where both sides intent to
authenticate packets contains RANDOM; CHUNKS; HMAC-ALGO
parameters that are being negotiated among peers:

  ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
  <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
  -------------------- COOKIE-ECHO -------------------->
  <-------------------- COOKIE-ACK ---------------------

RFC4895 says that each endpoint therefore knows its own random
number and the peer's random number *after* the association
has been established. The local and peer's random number along
with the shared key are then part of the secret used for
calculating the HMAC in the AUTH chunk.

Now, in our scenario, we have 2 threads with 1 non-blocking
SEQ_PACKET socket each, setting up common shared SCTP_AUTH_KEY
and SCTP_AUTH_ACTIVE_KEY properly, and each of them calling
sctp_bindx(3), listen(2) and connect(2) against each other,
thus the handshake looks similar to this, e.g.:

  ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
  <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
  <--------- INIT[RANDOM; CHUNKS; HMAC-ALGO] -----------
  -------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] -------->
  ...

Since such collisions can also happen with verification tags,
the RFC4895 for AUTH rather vaguely says under section 6.1:

  In case of INIT collision, the rules governing the handling
  of this Random Number follow the same pattern as those for
  the Verification Tag, as explained in Section 5.2.4 of
  RFC 2960 [5]. Therefore, each endpoint knows its own Random
  Number and the peer's Random Number after the association
  has been established.

In RFC2960, section 5.2.4, we're eventually hitting Action B:

  B) In this case, both sides may be attempting to start an
     association at about the same time but the peer endpoint
     started its INIT after responding to the local endpoint's
     INIT. Thus it may have picked a new Verification Tag not
     being aware of the previous Tag it had sent this endpoint.
     The endpoint should stay in or enter the ESTABLISHED
     state but it MUST update its peer's Verification Tag from
     the State Cookie, stop any init or cookie timers that may
     running and send a COOKIE ACK.

In other words, the handling of the Random parameter is the
same as behavior for the Verification Tag as described in
Action B of section 5.2.4.

Looking at the code, we exactly hit the sctp_sf_do_dupcook_b()
case which triggers an SCTP_CMD_UPDATE_ASSOC command to the
side effect interpreter, and in fact it properly copies over
peer_{random, hmacs, chunks} parameters from the newly created
association to update the existing one.

Also, the old asoc_shared_key is being released and based on
the new params, sctp_auth_asoc_init_active_key() updated.
However, the issue observed in this case is that the previous
asoc->peer.auth_capable was 0, and has *not* been updated, so
that instead of creating a new secret, we're doing an early
return from the function sctp_auth_asoc_init_active_key()
leaving asoc->asoc_shared_key as NULL. However, we now have to
authenticate chunks from the updated chunk list (e.g. COOKIE-ACK).

That in fact causes the server side when responding with ...

  <------------------ AUTH; COOKIE-ACK -----------------

... to trigger a NULL pointer dereference, since in
sctp_packet_transmit(), it discovers that an AUTH chunk is
being queued for xmit, and thus it calls sctp_auth_calculate_hmac().

Since the asoc->active_key_id is still inherited from the
endpoint, and the same as encoded into the chunk, it uses
asoc->asoc_shared_key, which is still NULL, as an asoc_key
and dereferences it in ...

  crypto_hash_setkey(desc.tfm, &asoc_key->data[0], asoc_key->len)

... causing an oops. All this happens because sctp_make_cookie_ack()
called with the *new* association has the peer.auth_capable=1
and therefore marks the chunk with auth=1 after checking
sctp_auth_send_cid(), but it is *actually* sent later on over
the then *updated* association's transport that didn't initialize
its shared key due to peer.auth_capable=0. Since control chunks
in that case are not sent by the temporary association which
are scheduled for deletion, they are issued for xmit via
SCTP_CMD_REPLY in the interpreter with the context of the
*updated* association. peer.auth_capable was 0 in the updated
association (which went from COOKIE_WAIT into ESTABLISHED state),
since all previous processing that performed sctp_process_init()
was being done on temporary associations, that we eventually
throw away each time.

The correct fix is to update to the new peer.auth_capable
value as well in the collision case via sctp_assoc_update(),
so that in case the collision migrated from 0 -> 1,
sctp_auth_asoc_init_active_key() can properly recalculate
the secret. This therefore fixes the observed server panic.

Fixes: 730fc3d ("[SCTP]: Implete SCTP-AUTH parameter processing")
Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
0fd6471
Christoph Paasch tcp: Fix integer-overflows in TCP veno
[ Upstream commit 45a0769 ]

In veno we do a multiplication of the cwnd and the rtt. This
may overflow and thus their result is stored in a u64. However, we first
need to cast the cwnd so that actually 64-bit arithmetic is done.

A first attempt at fixing 76f1017 ([TCP]: TCP Veno congestion
control) was made by 1591311 (tcp: Overflow bug in Vegas), but it
failed to add the required cast in tcp_veno_cong_avoid().

Fixes: 76f1017 ([TCP]: TCP Veno congestion control)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1f9480d
Christoph Paasch tcp: Fix integer-overflow in TCP vegas
[ Upstream commit 1f74e61 ]

In vegas we do a multiplication of the cwnd and the rtt. This
may overflow and thus their result is stored in a u64. However, we first
need to cast the cwnd so that actually 64-bit arithmetic is done.

Then, we need to do do_div to allow this to be used on 32-bit arches.

Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Laight <David.Laight@ACULAB.COM>
Cc: Doug Leith <doug.leith@nuim.ie>
Fixes: 8d3a564 (tcp: tcp_vegas cong avoid fix)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1d06a70
Vlad Yasevich macvlan: Initialize vlan_features to turn on offload support.
[ Upstream commit 081e83a ]

Macvlan devices do not initialize vlan_features.  As a result,
any vlan devices configured on top of macvlans perform very poorly.
Initialize vlan_features based on the vlan features of the lower-level
device.

Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
e2a2802
Vlad Yasevich net: Correctly set segment mac_len in skb_segment().
[ Upstream commit fcdfe3a ]

When performing segmentation, the mac_len value is copied right
out of the original skb.  However, this value is not always set correctly
(like when the packet is VLAN-tagged) and we'll end up copying a bad
value.

One way to demonstrate this is to configure a VM which tags
packets internally and turn off VLAN acceleration on the forwarding
bridge port.  The packets show up corrupt like this:
16:18:24.985548 52:54:00🆎be:25 > 52:54:00:26:ce:a3, ethertype 802.1Q
(0x8100), length 1518: vlan 100, p 0, ethertype 0x05e0,
        0x0000:  8cdb 1c7c 8cdb 0064 4006 b59d 0a00 6402 ...|...d@.....d.
        0x0010:  0a00 6401 9e0d b441 0a5e 64ec 0330 14fa ..d....A.^d..0..
        0x0020:  29e3 01c9 f871 0000 0101 080a 000a e833)....q.........3
        0x0030:  000f 8c75 6e65 7470 6572 6600 6e65 7470 ...unetperf.netp
        0x0040:  6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp
        0x0050:  6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp
        0x0060:  6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp
        ...

This also leads to awful throughput as GSO packets are dropped and
cause retransmissions.

The solution is to set the mac_len using the values already available
in then new skb.  We've already adjusted all of the header offset, so we
might as well correctly figure out the mac_len using skb_reset_mac_len().
After this change, packets are segmented correctly and performance
is restored.

CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
80db167
@sashalevin sashalevin iovec: make sure the caller actually wants anything in memcpy_fromiov…
…ecend

[ Upstream commit 06ebb06 ]

Check for cases when the caller requests 0 bytes instead of running off
and dereferencing potentially invalid iovecs.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8fbbef0
Eric Dumazet sctp: fix possible seqlock seadlock in sctp_packet_transmit()
[ Upstream commit 757efd3 ]

Dave reported following splat, caused by improper use of
IP_INC_STATS_BH() in process context.

BUG: using __this_cpu_add() in preemptible [00000000] code: trinity-c117/14551
caller is __this_cpu_preempt_check+0x13/0x20
CPU: 3 PID: 14551 Comm: trinity-c117 Not tainted 3.16.0+ #33
 ffffffff9ec898f0 0000000047ea7e23 ffff88022d32f7f0 ffffffff9e7ee207
 0000000000000003 ffff88022d32f818 ffffffff9e397eaa ffff88023ee70b40
 ffff88022d32f970 ffff8801c026d580 ffff88022d32f828 ffffffff9e397ee3
Call Trace:
 [<ffffffff9e7ee207>] dump_stack+0x4e/0x7a
 [<ffffffff9e397eaa>] check_preemption_disabled+0xfa/0x100
 [<ffffffff9e397ee3>] __this_cpu_preempt_check+0x13/0x20
 [<ffffffffc0839872>] sctp_packet_transmit+0x692/0x710 [sctp]
 [<ffffffffc082a7f2>] sctp_outq_flush+0x2a2/0xc30 [sctp]
 [<ffffffff9e0d985c>] ? mark_held_locks+0x7c/0xb0
 [<ffffffff9e7f8c6d>] ? _raw_spin_unlock_irqrestore+0x5d/0x80
 [<ffffffffc082b99a>] sctp_outq_uncork+0x1a/0x20 [sctp]
 [<ffffffffc081e112>] sctp_cmd_interpreter.isra.23+0x1142/0x13f0 [sctp]
 [<ffffffffc081c86b>] sctp_do_sm+0xdb/0x330 [sctp]
 [<ffffffff9e0b8f1b>] ? preempt_count_sub+0xab/0x100
 [<ffffffffc083b350>] ? sctp_cname+0x70/0x70 [sctp]
 [<ffffffffc08389ca>] sctp_primitive_ASSOCIATE+0x3a/0x50 [sctp]
 [<ffffffffc083358f>] sctp_sendmsg+0x88f/0xe30 [sctp]
 [<ffffffff9e0d673a>] ? lock_release_holdtime.part.28+0x9a/0x160
 [<ffffffff9e0d62ce>] ? put_lock_stats.isra.27+0xe/0x30
 [<ffffffff9e73b624>] inet_sendmsg+0x104/0x220
 [<ffffffff9e73b525>] ? inet_sendmsg+0x5/0x220
 [<ffffffff9e68ac4e>] sock_sendmsg+0x9e/0xe0
 [<ffffffff9e1c0c09>] ? might_fault+0xb9/0xc0
 [<ffffffff9e1c0bae>] ? might_fault+0x5e/0xc0
 [<ffffffff9e68b234>] SYSC_sendto+0x124/0x1c0
 [<ffffffff9e0136b0>] ? syscall_trace_enter+0x250/0x330
 [<ffffffff9e68c3ce>] SyS_sendto+0xe/0x10
 [<ffffffff9e7f9be4>] tracesys+0xdd/0xe2

This is a followup of commits f1d8cba ("inet: fix possible
seqlock deadlocks") and 7f88c6b ("ipv6: fix possible seqlock
deadlock in ip6_finish_output2")

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Reported-by: Dave Jones <davej@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5c19acc
@davem330 davem330 sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus.
[ Upstream commit b18eb2d ]

Access to the TSB hash tables during TLB misses requires that there be
an atomic 128-bit quad load available so that we fetch a matching TAG
and DATA field at the same time.

On cpus prior to UltraSPARC-III only virtual address based quad loads
are available.  UltraSPARC-III and later provide physical address
based variants which are easier to use.

When we only have virtual address based quad loads available this
means that we have to lock the TSB into the TLB at a fixed virtual
address on each cpu when it runs that process.  We can't just access
the PAGE_OFFSET based aliased mapping of these TSBs because we cannot
take a recursive TLB miss inside of the TLB miss handler without
risking running out of hardware trap levels (some trap combinations
can be deep, such as those generated by register window spill and fill
traps).

Without huge pages it's working perfectly fine, but when the huge TSB
got added another chunk of fixed virtual address space was not
allocated for this second TSB mapping.

So we were mapping both the 8K and 4MB TSBs to the same exact virtual
address, causing multiple TLB matches which gives undefined behavior.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fdd8801
@davem330 davem330 sparc64: Add membar to Niagara2 memcpy code.
[ Upstream commit 5aa4ecf ]

This is the prevent previous stores from overlapping the block stores
done by the memcpy loop.

Based upon a glibc patch by Jose E. Marchesi

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8e8955a
@sowminiv sowminiv sparc64: ldc_connect() should not return EINVAL when handshake is in …
…progress.

[ Upstream commit 4ec1b01 ]

The LDC handshake could have been asynchronously triggered
after ldc_bind() enables the ldc_rx() receive interrupt-handler
(and thus intercepts incoming control packets)
and before vio_port_up() calls ldc_connect(). If that is the case,
ldc_connect() should return 0 and let the state-machine
progress.

Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Acked-by: Karl Volz <karl.volz@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
29fa649
@catschulze catschulze bbc-i2c: Fix BBC I2C envctrl on SunBlade 2000
[ Upstream commit 5cdceab ]

Fix regression in bbc i2c temperature and fan control on some Sun systems
that causes the driver to refuse to load due to the bbc_i2c_bussel resource not
being present on the (second) i2c bus where the temperature sensors and fan
control are located. (The check for the number of resources was removed when
the driver was ported to a pure OF driver in mid 2008.)

Signed-off-by: Christopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
7554c49
@catschulze catschulze sunsab: Fix detection of BREAK on sunsab serial console
[ Upstream commit fe41823 ]

Fix detection of BREAK on sunsab serial console: BREAK detection was only
performed when there were also serial characters received simultaneously.
To handle all BREAKs correctly, the check for BREAK and the corresponding
call to uart_handle_break() must also be done if count == 0, therefore
duplicate this code fragment and pull it out of the loop over the received
characters.

Patch applies to 3.16-rc6.

Signed-off-by: Christopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
a46e945
@davem330 davem330 sparc64: Do not insert non-valid PTEs into the TSB hash table.
[ Upstream commit 18f3813 ]

The assumption was that update_mmu_cache() (and the equivalent for PMDs) would
only be called when the PTE being installed will be accessible by the user.

This is not true for code paths originating from remove_migration_pte().

There are dire consequences for placing a non-valid PTE into the TSB.  The TLB
miss frramework assumes thatwhen a TSB entry matches we can just load it into
the TLB and return from the TLB miss trap.

So if a non-valid PTE is in there, we will deadlock taking the TLB miss over
and over, never satisfying the miss.

Just exit early from update_mmu_cache() and friends in this situation.

Based upon a report and patch from Christopher Alexander Tobias Schulze.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
afa9b04
@davem330 davem330 sparc64: Guard against flushing openfirmware mappings.
[ Upstream commit 4ca9a23 ]

Based almost entirely upon a patch by Christopher Alexander Tobias
Schulze.

In commit db64fe0 ("mm: rewrite vmap
layer") lazy VMAP tlb flushing was added to the vmalloc layer.  This
causes problems on sparc64.

Sparc64 has two VMAP mapped regions and they are not contiguous with
eachother.  First we have the malloc mapping area, then another
unrelated region, then the vmalloc region.

This "another unrelated region" is where the firmware is mapped.

If the lazy TLB flushing logic in the vmalloc code triggers after
we've had both a module unload and a vfree or similar, it will pass an
address range that goes from somewhere inside the malloc region to
somewhere inside the vmalloc region, and thus covering the
openfirmware area entirely.

The sparc64 kernel learns about openfirmware's dynamic mappings in
this region early in the boot, and then services TLB misses in this
area.  But openfirmware has some locked TLB entries which are not
mentioned in those dynamic mappings and we should thus not disturb
them.

These huge lazy TLB flush ranges causes those openfirmware locked TLB
entries to be removed, resulting in all kinds of problems including
hard hangs and crashes during reboot/reset.

Besides causing problems like this, such huge TLB flush ranges are
also incredibly inefficient.  A plea has been made with the author of
the VMAP lazy TLB flushing code, but for now we'll put a safety guard
into our flush_tlb_kernel_range() implementation.

Since the implementation has become non-trivial, stop defining it as a
macro and instead make it a function in a C source file.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d7bcdfe
@krieger-od krieger-od arch/sparc/math-emu/math_32.c: drop stray break operator
[ Upstream commit 093758e ]

This commit is a guesswork, but it seems to make sense to drop this
break, as otherwise the following line is never executed and becomes
dead code. And that following line actually saves the result of
local calculation by the pointer given in function argument. So the
proposed change makes sense if this code in the whole makes sense (but I
am unable to analyze it in the whole).

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81641
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Andrey Utkin <andrey.krieger.utkin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
0ace429
@gregkh gregkh Linux 3.4.103 9f089cf
@mdrjr mdrjr Merge tag 'v3.4.99' of git://git.kernel.org/pub/scm/linux/kernel/git/…
…stable/linux-stable into odroidxu-3.4.y

This is the 3.4.99 stable release
7111646
@mdrjr mdrjr Merge tag 'v3.4.100' of git://git.kernel.org/pub/scm/linux/kernel/git…
…/stable/linux-stable into odroidxu-3.4.y

This is the 3.4.100 stable release
87077f4
@mdrjr mdrjr Merge tag 'v3.4.101' of git://git.kernel.org/pub/scm/linux/kernel/git…
…/stable/linux-stable into odroidxu-3.4.y

This is the 3.4.101 stable release
7ebcf75
@mdrjr mdrjr Merge tag 'v3.4.102' of git://git.kernel.org/pub/scm/linux/kernel/git…
…/stable/linux-stable into odroidxu-3.4.y

This is the 3.4.102 stable release
fe00ea6
@mdrjr mdrjr Merge tag 'v3.4.103' of git://git.kernel.org/pub/scm/linux/kernel/git…
…/stable/linux-stable into odroidxu-3.4.y

This is the 3.4.103 stable release
7699466
@mdrjr mdrjr Merge branch 'odroidxu-3.4.y' of github.com:hardkernel/linux into odr…
…oidxu-3.4.y
4a4236f
@mdrjr mdrjr drivers/hardkernel: fan: increase start speed 5e87789
@mdrjr mdrjr defconfig: odroidxu: enable fhandle and xts
Change-Id: I485924e3f667b28b3db2d2a37160d855f2ff1573
488ed00
@ffainelli ffainelli pushed a commit to ffainelli/linux that referenced this pull request Sep 25, 2014
@borkmann borkmann net: bpf: arm: make hole-faulting more robust
Will Deacon pointed out, that the currently used opcode for filling holes,
that is 0xe7ffffff, seems not robust enough ...

  $ echo 0xffffffe7 | xxd -r > test.bin
  $ arm-linux-gnueabihf-objdump -m arm -D -b binary test.bin
  ...
  0: e7ffffff     udf    #65535  ; 0xffff

... while for Thumb, it ends up as ...

  0: ffff e7ff    vqshl.u64  q15, <illegal reg q15.5>, #63

... which is a bit fragile. The ARM specification defines some *permanently*
guaranteed undefined instruction (UDF) space, for example for ARM in ARMv7-AR,
section A5.4 and for Thumb in ARMv7-M, section A5.2.6.

Similarly, ptrace, kprobes, kgdb, bug and uprobes make use of such instruction
as well to trap. Given mentioned section from the specification, we can find
such a universe as (where 'x' denotes 'don't care'):

  ARM:    xxxx 0111 1111 xxxx xxxx xxxx 1111 xxxx
  Thumb:  1101 1110 xxxx xxxx

We therefore should use a more robust opcode that fits both. Russell King
suggested that we can even reuse a single 32-bit word, that is, 0xe7fddef1
which will fault if executed in ARM *or* Thumb mode as done in f928d4f
("ARM: poison the vectors page"). That will still hold our requirements:

  $ echo 0xf1defde7 | xxd -r > test.bin
  $ arm-unknown-linux-gnueabi-objdump -m arm -D -b binary test.bin
  ...
  0: e7fddef1     udf    #56801 ; 0xdde1
  $ echo 0xf1defde7f1defde7f1defde7 | xxd -r > test.bin
  $ arm-unknown-linux-gnueabi-objdump -marm -Mforce-thumb -D -b binary test.bin
  ...
  0: def1         udf    #241 ; 0xf1
  2: e7fd         b.n    0x0
  4: def1         udf    #241 ; 0xf1
  6: e7fd         b.n    0x4
  8: def1         udf    #241 ; 0xf1
  a: e7fd         b.n    0x8

So on ARM 0xe7fddef1 conforms to the above UDF pattern, and the low 16 bit
likewise correspond to UDF in Thumb case. The 0xe7fd part is an unconditional
branch back to the UDF instruction.

Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mircea Gherzan <mgherzan@gmail.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
e8b56d5
Dave Chiluk and others added some commits Jun 24, 2014
Dave Chiluk stable_kernel_rules: Add pointer to netdev-FAQ for network patches
commit b76fc28 upstream.

Stable_kernel_rules should point submitters of network stable patches to the
netdev_FAQ.txt as requests for stable network patches should go to netdev
first.

Signed-off-by: Dave Chiluk <chiluk@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
b402b72
@zonque zonque ASoC: pxa-ssp: drop SNDRV_PCM_FMTBIT_S24_LE
commit 9301503 upstream.

This mode is unsupported, as the DMA controller can't do zero-padding
of samples.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
c27d3b5
Jiri Kosina HID: fix a couple of off-by-ones
commit 4ab2578 upstream.

There are a few very theoretical off-by-one bugs in report descriptor size
checking when performing a pre-parsing fixup. Fix those.

Reported-by: Ben Hawkes <hawkes@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
dab2f9b
@antonblanchard antonblanchard ibmveth: Fix endian issues with rx_no_buffer statistic
commit cbd5228 upstream.

Hidden away in the last 8 bytes of the buffer_list page is a solitary
statistic. It needs to be byte swapped or else ethtool -S will
produce numbers that terrify the user.

Since we do this in multiple places, create a helper function with a
comment explaining what is going on.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Zefan Li <lizefan@huawei.com>
9220628
@aakoskin aakoskin MIPS: OCTEON: make get_system_type() thread-safe
commit 6083086 upstream.

get_system_type() is not thread-safe on OCTEON. It uses static data,
also more dangerous issue is that it's calling cvmx_fuse_read_byte()
every time without any synchronization. Currently it's possible to get
processes stuck looping forever in kernel simply by launching multiple
readers of /proc/cpuinfo:

	(while true; do cat /proc/cpuinfo > /dev/null; done) &
	(while true; do cat /proc/cpuinfo > /dev/null; done) &
	...

Fix by initializing the system type string only once during the early
boot.

Signed-off-by: Aaro Koskinen <aaro.koskinen@nsn.com>
Reviewed-by: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7437/
Signed-off-by: James Hogan <james.hogan@imgtec.com>
[lizf: Backport to 3.x: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
33df36f
@jankara jankara isofs: Fix unbounded recursion when processing relocated directories
commit 410dd3c upstream.

We did not check relocated directory in any way when processing Rock
Ridge 'CL' tag. Thus a corrupted isofs image can possibly have a CL
entry pointing to another CL entry leading to possibly unbounded
recursion in kernel code and thus stack overflow or deadlocks (if there
is a loop created from CL entries).

Fix the problem by not allowing CL entry to point to a directory entry
with CL entry (such use makes no good sense anyway) and by checking
whether CL entry doesn't point to itself.

Reported-by: Chris Evans <cevans@google.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Zefan Li <lizefan@huawei.com>
5ccd3e2
@mstsirkin mstsirkin kvm: iommu: fix the third parameter of kvm_iommu_put_pages (CVE-2014-…
…3601)

commit 350b8bd upstream.

The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn - slot->base_gfn'.

By making gfn very large, malicious guest or userspace can cause kvm to
go to this error path, and subsequently to pass a huge value as size.
Alternatively if gfn is small, then pages would be pinned but never
unpinned, causing host memory leak and local DOS.

Passing a reasonable but large value could be the most dangerous case,
because it would unpin a page that should have stayed pinned, and thus
allow the device to DMA into arbitrary memory.  However, this cannot
happen because of the condition that can trigger the error:

- out of memory (where you can't allocate even a single page)
  should not be possible for the attacker to trigger

- when exceeding the iommu's address space, guest pages after gfn
  will also exceed the iommu's address space, and inside
  kvm_iommu_put_pages() the iommu_iova_to_phys() will fail.  The
  page thus would not be unpinned at all.

Reported-by: Jack Morgenstein <jackm@mellanox.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
f0634a3
Jiri Kosina HID: logitech: perform bounds checking on device_id early enough
commit ad3e14d upstream.

device_index is a char type and the size of paired_dj_deivces is 7
elements, therefore proper bounds checking has to be applied to
device_index before it is used.

We are currently performing the bounds checking in
logi_dj_recv_add_djhid_device(), which is too late, as malicious device
could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the
problem in one of the report forwarding functions called from
logi_dj_raw_event().

Fix this by performing the check at the earliest possible ocasion in
logi_dj_raw_event().

Reported-by: Ben Hawkes <hawkes@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Zefan Li <lizefan@huawei.com>
c945ed6
@joergroedel joergroedel iommu/amd: Fix cleanup_domain for mass device removal
commit 9b29d3c upstream.

When multiple devices are detached in __detach_device, they
are also removed from the domains dev_list. This makes it
unsafe to use list_for_each_entry_safe, as the next pointer
might also not be in the list anymore after __detach_device
returns. So just repeatedly remove the first element of the
list until it is empty.

Tested-by: Marti Raudsepp <marti@juffo.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Zefan Li <lizefan@huawei.com>
77e5657
@neilbrown neilbrown md/raid6: avoid data corruption during recovery of double-degraded RAID6
commit 9c4bdf6 upstream.

During recovery of a double-degraded RAID6 it is possible for
some blocks not to be recovered properly, leading to corruption.

If a write happens to one block in a stripe that would be written to a
missing device, and at the same time that stripe is recovering data
to the other missing device, then that recovered data may not be written.

This patch skips, in the double-degraded case, an optimisation that is
only safe for single-degraded arrays.

Bug was introduced in 2.6.32 and fix is suitable for any kernel since
then.  In an older kernel with separate handle_stripe5() and
handle_stripe6() functions the patch must change handle_stripe6().

Fixes: 6c0069c
Cc: Yuri Tikhonov <yur@emcraft.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reported-by: "Manibalan P" <pmanibalan@amiindia.co.in>
Tested-by: "Manibalan P" <pmanibalan@amiindia.co.in>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1090423
Signed-off-by: NeilBrown <neilb@suse.de>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
a0e5b9d
@tiwai tiwai ALSA: hda/realtek - Avoid setting wrong COEF on ALC269 & co
commit f3ee07d upstream.

ALC269 & co have many vendor-specific setups with COEF verbs.
However, some verbs seem specific to some codec versions and they
result in the codec stalling.  Typically, such a case can be avoided
by checking the return value from reading a COEF.  If the return value
is -1, it implies that the COEF is invalid, thus it shouldn't be
written.

This patch adds the invalid COEF checks in appropriate places
accessing ALC269 and its variants.  The patch actually fixes the
resume problem on Acer AO725 laptop.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52181
Tested-by: Francesco Muzio <muziofg@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Zefan Li <lizefan@huawei.com>
483320c
@arjun024 arjun024 pata_scc: propagate return value of scc_wait_after_reset
commit 4dc7c76 upstream.

scc_bus_softreset not necessarily should return zero.
Propagate the error code.

Signed-off-by: Arjun Sreedharan <arjun024@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
db83744
Pavel Shilovsky CIFS: Fix wrong directory attributes after rename
commit b46799a upstream.

When we requests rename we also need to update attributes
of both source and target parent directories. Not doing it
causes generic/309 xfstest to fail on SMB2 mounts. Fix this
by marking these directories for force revalidating.

Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
d06e4b0
@jcmvbkbc jcmvbkbc xtensa: replace IOCTL code definitions with constants
commit f61bf8e upstream.

This fixes userspace code that builds on other architectures but fails
on xtensa due to references to structures that other architectures don't
refer to. E.g. this fixes the following issue with python-2.7.8:

  python-2.7.8/Modules/termios.c:861:25: error: invalid application
     of 'sizeof' to incomplete type 'struct serial_multiport_struct'
     {"TIOCSERGETMULTI", TIOCSERGETMULTI},
  python-2.7.8/Modules/termios.c:870:25: error: invalid application
     of 'sizeof' to incomplete type 'struct serial_multiport_struct'
     {"TIOCSERSETMULTI", TIOCSERSETMULTI},
  python-2.7.8/Modules/termios.c:900:24: error: invalid application
     of 'sizeof' to incomplete type 'struct tty_struct'
     {"TIOCTTYGSTRUCT", TIOCTTYGSTRUCT},

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
[lizf: Backported to 3.4: adjust filename]
Signed-off-by: Zefan Li <lizefan@huawei.com>
2297927
@jcmvbkbc jcmvbkbc xtensa: fix TLBTEMP_BASE_2 region handling in fast_second_level_miss
commit 7128039 upstream.

Current definition of TLBTEMP_BASE_2 is always 32K above the
TLBTEMP_BASE_1, whereas fast_second_level_miss handler for the TLBTEMP
region analyzes virtual address bit (PAGE_SHIFT + DCACHE_ALIAS_ORDER)
to determine TLBTEMP region where the fault happened. The size of the
TLBTEMP region is also checked incorrectly: not 64K, but twice data
cache way size (whicht may as well be less than the instruction cache
way size).

Fix TLBTEMP_BASE_2 to be TLBTEMP_BASE_1 + data cache way size.
Provide TLBTEMP_SIZE that is a greater of doubled data cache way size or
the instruction cache way size, and use it to determine if the second
level TLB miss occured in the TLBTEMP region.

Practical occurence of page faults in the TLBTEMP area is extremely
rare, this code can be tested by deletion of all w[di]tlb instructions
in the tlbtemp_mapping region.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
bcf20fd
Alan Douglas xtensa: fix address checks in dma_{alloc,free}_coherent
commit 1ca4946 upstream.

Virtual address is translated to the XCHAL_KSEG_CACHED region in the
dma_free_coherent, but is checked to be in the 0...XCHAL_KSEG_SIZE
range.

Change check for end of the range from 'addr >= X' to 'addr > X - 1' to
handle the case of X == 0.

Replace 'if (C) BUG();' construct with 'BUG_ON(C);'.

Signed-off-by: Alan Douglas <adouglas@cadence.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
fb2ae73
@jcmvbkbc jcmvbkbc xtensa: fix a6 and a7 handling in fast_syscall_xtensa
commit d1b6ba8 upstream.

Remove restoring a6 on some return paths and instead modify and restore
it in a single place, using symbolic name.
Correctly restore a7 from PT_AREG7 in case of illegal a6 value.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
f40751b
@einon einon staging: et131x: Fix errors caused by phydev->addr accesses before in…
…itialisation

commit ec0a38b upstream.

Fix two reported bugs, caused by et131x_adapter->phydev->addr being accessed
before it is initialised, by:

- letting et131x_mii_write() take a phydev address, instead of using the one
  stored in adapter by default. This is so et131x_mdio_write() can use it's own
  addr value.
- removing implementation of et131x_mdio_reset(), as it's not needed.
- moving a call to et131x_disable_phy_coma() in et131x_pci_setup(), which uses
  phydev->addr, until after the mdiobus has been registered.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=80751
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77121
Signed-off-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4:
- adjust context
- update more update more et131x_mii_write() calls in 
  et1310_phy_access_mii_bit() and et131x_xcvr_init()]
Signed-off-by: Zefan Li <lizefan@huawei.com>
c2aa9b7
@btashton btashton USB: option: add VIA Telecom CDS7 chipset device id
commit d773027 upstream.

This VIA Telecom baseband processor is used is used by by u-blox in both the
FW2770 and FW2760 products and may be used in others as well.

This patch has been tested on both of these modem versions.

Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
78aea3a
@jhovold jhovold USB: ftdi_sio: add Basic Micro ATOM Nano USB2Serial PID
commit 6552cc7 upstream.

Add device id for Basic Micro ATOM Nano USB2Serial adapters.

Reported-by: Nicolas Alt <n.alt@mytum.de>
Tested-by: Nicolas Alt <n.alt@mytum.de>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
262548e
@gregkh gregkh USB: serial: pl2303: add device id for ztek device
commit 91fcb1c upstream.

This adds a new device id to the pl2303 driver for the ZTEK device.

Reported-by: Mike Chu <Mike-Chu@prolific.com.tw>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
68e9929
@bartmanus bartmanus USB: ftdi_sio: Added PID for new ekey device
commit 646907f upstream.

Added support to the ftdi_sio driver for ekey Converter USB which
uses an FT232BM chip.

Signed-off-by: Jaša Bartelj <jasa.bartelj@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
d232e2c
@jwrdegoede jwrdegoede xhci: Treat not finding the event_seg on COMP_STOP the same as COMP_S…
…TOP_INVAL

commit 9a54886 upstream.

When using a Renesas uPD720231 chipset usb-3 uas to sata bridge with a 120G
Crucial M500 ssd, model string: Crucial_ CT120M500SSD1, together with a
the integrated Intel xhci controller on a Haswell laptop:

00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04)

The following error gets logged to dmesg:

xhci error: Transfer event TRB DMA ptr not part of current TD

Treating COMP_STOP the same as COMP_STOP_INVAL when no event_seg gets found
fixes this.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
42494f0
@huangrui huangrui usb: xhci: amd chipset also needs short TX quirk
commit 2597fe9 upstream.

AMD xHC also needs short tx quirk after tested on most of chipset
generations. That's because there is the same incorrect behavior like
Fresco Logic host. Please see below message with on USB webcam
attached on xHC host:

[  139.262944] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.266934] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.270913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.274937] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.278914] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.282936] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.286915] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.290938] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.294913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.298917] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?

Reported-by: Arindam Nath <arindam.nath@amd.com>
Tested-by: Shriraj-Rai P <shriraj-rai.p@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
1d37c3e
Benjamin Tissoires HID: logitech-dj: prevent false errors to be shown
commit 5abfe85 upstream.

Commit "HID: logitech: perform bounds checking on device_id early
enough" unfortunately leaks some errors to dmesg which are not real
ones:
- if the report is not a DJ one, then there is not point in checking
  the device_id
- the receiver (index 0) can also receive some notifications which
  can be safely ignored given the current implementation

Move out the test regarding the report_id and also discards
printing errors when the receiver got notified.

Fixes: ad3e14d

Reported-and-tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Zefan Li <lizefan@huawei.com>
86d165e
James Forshaw USB: whiteheat: Added bounds checking for bulk command response
commit 6817ae2 upstream.

This patch fixes a potential security issue in the whiteheat USB driver
which might allow a local attacker to cause kernel memory corrpution. This
is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On
EHCI and XHCI busses it's possible to craft responses greater than 64
bytes leading a buffer overflow.

Signed-off-by: James Forshaw <forshaw@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
2f2c704
@shemminger shemminger USB: sisusb: add device id for Magic Control USB video
commit 5b6b80a upstream.

I have a j5 create (JUA210) USB 2 video device and adding it device id
to SIS USB video gets it to work.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
818ee41
@trondmypd trondmypd NFSv4: Fix problems with close in the presence of a delegation
commit aee7af3 upstream.

In the presence of delegations, we can no longer assume that the
state->n_rdwr, state->n_rdonly, state->n_wronly reflect the open
stateid share mode, and so we need to calculate the initial value
for calldata->arg.fmode using the state->flags.

Reported-by: James Drews <drews@engr.wisc.edu>
Fixes: 88069f7 (NFSv41: Fix a potential state leakage when...)
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
[lizf: Backport to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
0bfb000
Jiri Kosina HID: magicmouse: sanity check report size in raw_event() callback
commit c54def7 upstream.

The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that
magicmouse_emit_touch() gets only valid values of raw_id.

Reported-by: Steven Vittitoe <scvitti@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Zefan Li <lizefan@huawei.com>
e115f02
Jiri Kosina HID: picolcd: sanity check report size in raw_event() callback
commit 844817e upstream.

The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that raw_data
that we hold in picolcd_pending structure are always kept within proper
bounds.

Reported-by: Steven Vittitoe <scvitti@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
[lizf: Backported to 3.4: adjust filename]
Signed-off-by: Zefan Li <lizefan@huawei.com>
e78c127
Mark Rutland ARM: 8128/1: abort: don't clear the exclusive monitors
commit 8586831 upstream.

The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors
upon entry to the kernel, but this is redundant:

  - We clear the monitors on every exception return since commit
    200b812 ("Clear the exclusive monitor when returning from an
    exception"), so this is not necessary to ensure the monitors are
    cleared before returning from a fault handler.

  - Any dummy STREX will target a temporary scratch area in memory, and
    may succeed or fail without corrupting useful data. Its status value
    will not be used.

  - Any other STREX in the kernel must be preceded by an LDREX, which
    will initialise the monitors consistently and will not depend on the
    earlier state of the monitors.

Therefore we have no reason to care about the initial state of the
exclusive monitors when a data abort is taken, and clearing the monitors
prior to exception return (as we already do) is sufficient.

This patch removes the redundant clearing of the exclusive monitors from
the early abort handlers.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Zefan Li <lizefan@huawei.com>
5624bb3
Mark Rutland ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using dumm…
…y strex

commit 2c32c65 upstream.

On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may
falsely trigger a watchpoint exception, leading to potential data aborts
during exception return and/or livelock.

This patch resolves the issue in the following ways:

  - Replacing our uses of CLREX with a dummy STREX sequence instead (as
    we did for v6 CPUs).

  - Removing the clrex code from v7_exit_coherency_flush and derivatives,
    since this only exists as a minor performance improvement when
    non-cached exclusives are in use (Linux doesn't use these).

Benchmarking on a variety of ARM cores revealed no measurable
performance difference with this change applied, so the change is
performed unconditionally and no new Kconfig entry is added.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[lizf: Backported to 3.4:
 - Drop changes to arch/arm/include/asm/cacheflush.h and
   arch/arm/mach-exynos/mcpm-exynos.c]
Signed-off-by: Zefan Li <lizefan@huawei.com>
2f3e285
@jhovold jhovold USB: serial: fix potential stack buffer overflow
commit d979e9f upstream.

Make sure to verify the maximum number of endpoints per type to avoid
writing beyond the end of a stack-allocated array.

The current usb-serial implementation is limited to eight ports per
interface but failed to verify that the number of endpoints of a certain
type reported by a device did not exceed this limit.

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
62148f7
@jhovold jhovold USB: serial: fix potential heap buffer overflow
commit 5654699 upstream.

Make sure to verify the number of ports requested by subdriver to avoid
writing beyond the end of fixed-size array in interface data.

The current usb-serial implementation is limited to eight ports per
interface but failed to verify that the number of ports requested by a
subdriver (which could have been determined from device descriptors) did
not exceed this limit.

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4: s/ddev/\&interface->dev/]
Signed-off-by: Zefan Li <lizefan@huawei.com>
c804743
Andi Kleen slab/mempolicy: always use local policy from interrupt context
commit e7b691b upstream.

slab_node() could access current->mempolicy from interrupt context.
However there's a race condition during exit where the mempolicy
is first freed and then the pointer zeroed.

Using this from interrupts seems bogus anyways. The interrupt
will interrupt a random process and therefore get a random
mempolicy. Many times, this will be idle's, which noone can change.

Just disable this here and always use local for slab
from interrupts. I also cleaned up the callers of slab_node a bit
which always passed the same argument.

I believe the original mempolicy code did that in fact,
so it's likely a regression.

v2: send version with correct logic
v3: simplify. fix typo.
Reported-by: Arun Sharma <asharma@fb.com>
Cc: penberg@kernel.org
Cc: cl@linux.com
Signed-off-by: Andi Kleen <ak@linux.intel.com>
[tdmackey@twitter.com: Rework control flow based on feedback from
cl@linux.com, fix logic, and cleanup current task_struct reference]
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: David Mackey <tdmackey@twitter.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
69db2d4
@ffainelli ffainelli MIPS: perf: Fix build error caused by unused counters_per_cpu_to_total()
commit 6c37c95 upstream.

cc1: warnings being treated as errors
arch/mips/kernel/perf_event_mipsxx.c:166: error: 'counters_per_cpu_to_total' defined but not used
make[2]: *** [arch/mips/kernel/perf_event_mipsxx.o] Error 1
make[2]: *** Waiting for unfinished jobs....

It was first introduced by 8209156 [MIPS:
perf: Add support for 64-bit perf counters.] in 3.2.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
Cc: linux-mips@linux-mips.org
Cc: david.daney@cavium.com
Patchwork: https://patchwork.linux-mips.org/patch/3357/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
9a8fa93
@skristiansson skristiansson openrisc: add missing header inclusion
commit 160d837 upstream.

Prevents build issue with updated toolchain

Reported-by: Jack Thomasson <jkt@moonlitsw.com>
Tested-by: Christian Svensson <blue@cmd.nu>
Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Jonas Bonn <jonas@southpole.se>
Signed-off-by: Zefan Li <lizefan@huawei.com>
ab22539
@ralfbaechle ralfbaechle MIPS: Fix accessing to per-cpu data when flushing the cache
commit ff52205 upstream.

This fixes the following issue

BUG: using smp_processor_id() in preemptible [00000000] code: kjournald/1761
caller is blast_dcache32+0x30/0x254
Call Trace:
[<8047f02c>] dump_stack+0x8/0x34
[<802e7e40>] debug_smp_processor_id+0xe0/0xf0
[<80114d94>] blast_dcache32+0x30/0x254
[<80118484>] r4k_dma_cache_wback_inv+0x200/0x288
[<80110ff0>] mips_dma_map_sg+0x108/0x180
[<80355098>] ide_dma_prepare+0xf0/0x1b8
[<8034eaa4>] do_rw_taskfile+0x1e8/0x33c
[<8035951c>] ide_do_rw_disk+0x298/0x3e4
[<8034a3c4>] do_ide_request+0x2e0/0x704
[<802bb0dc>] __blk_run_queue+0x44/0x64
[<802be000>] queue_unplugged.isra.36+0x1c/0x54
[<802beb94>] blk_flush_plug_list+0x18c/0x24c
[<802bec6c>] blk_finish_plug+0x18/0x48
[<8026554c>] journal_commit_transaction+0x3b8/0x151c
[<80269648>] kjournald+0xec/0x238
[<8014ac00>] kthread+0xb8/0xc0
[<8010268c>] ret_from_kernel_thread+0x14/0x1c

Caches in most systems are identical - but not always, so we can't avoid
the use of smp_call_function() by just looking at the boot CPU's data,
have to fiddle with preemption instead.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5835
Signed-off-by: Zefan Li <lizefan@huawei.com>
c1bc007
@gxt gxt UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference…
… between native and cross compiler

commit 10e1e99 upstream.

For kernel/bound.c being compiled by native compiler, it will generate following errors in gcc 4.4.3:
  CC      kernel/bounds.s
In file included from include/linux/bug.h:4,
                 from include/linux/page-flags.h:9,
                 from kernel/bounds.c:9:
arch/unicore32/include/asm/bug.h:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
arch/unicore32/include/asm/bug.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'

So, we moved definitions in asm/bug.h to arch/unicore32/kernel/setup.h to solve the problem.

Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Zefan Li <lizefan@huawei.com>
4e36063
@gxt gxt UniCore32-bugfix: fix mismatch return value of __xchg_bad_pointer
commit 195d457 upstream.

When disintegrate system.h, I left an error in asm/cmpxchg.h, which
will result in following error:

arch/unicore32/include/asm/cmpxchg.h: In function '__xchg':
arch/unicore32/include/asm/cmpxchg.h:38: error: void value not ignored as it ought to be

Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Zefan Li <lizefan@huawei.com>
92a6e26
Michael Cree alpha: Fix fall-out from disintegrating asm/system.h
commit d1b5153 upstream.

Commit ec22120 ("Disintegrate asm/system.h for Alpha") removed
asm/system.h however arch/alpha/oprofile/common.c requires definitions
that were shifted from asm/system.h to asm/special_insns.h.  Include
that.

Signed-off-by: Michael Cree <mcree@orcon.net.nz>
Acked-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Zefan Li <lizefan@huawei.com>
f79bb94
@fengguang fengguang unicore32: select generic atomic64_t support
commit 82e54a6 upstream.

It's required for the core fs/namespace.c and many other basic features.

Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Zefan Li <lizefan@huawei.com>
62cdcce
@paulgortmaker paulgortmaker 8250_pci: fix warnings in backport of Broadcom TruManage support
commit 7400ce7 (v3.4.92-76-g7400ce7ee959)
was a backport of commit ebebd49 upstream
("8250/16?50: Add support for Broadcom TruManage redirected serial port")

However, in the context of 3.4.x kernels, the pci setup code was
expecting a struct uart_port and not a struct uart_8250_port, leading to
the following concerning warnings:

drivers/tty/serial/8250/8250_pci.c: In function ‘pci_brcm_trumanage_setup’:
drivers/tty/serial/8250/8250_pci.c:1086:2: warning: passing argument 3 of ‘pci_default_setup’ from incompatible pointer type [enabled by default]
  int ret = pci_default_setup(priv, board, port, idx);
  ^
drivers/tty/serial/8250/8250_pci.c:1036:1: note: expected ‘struct uart_port *’ but argument is of type ‘struct uart_8250_port *’
 pci_default_setup(struct serial_private *priv,
 ^
drivers/tty/serial/8250/8250_pci.c: At top level:
drivers/tty/serial/8250/8250_pci.c:1746:3: warning: initialization from incompatible pointer type [enabled by default]
   .setup  = pci_brcm_trumanage_setup,
   ^
drivers/tty/serial/8250/8250_pci.c:1746:3: warning: (near initialization for ‘pci_serial_quirks[56].setup’) [enabled by default]

I'd also expect the initialization to not function correctly, and
perhaps dereference random garbage due to this.  Since the uart_port
is a field within the uart_8250_port, the adaptation to fix these
warnings is a straightforward removal of a layer of indirection.

Cc: Stephen Hurd <shurd@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Rui Xiang <rui.xiang@huawei.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
82a938a
Michael Cree alpha: add io{read,write}{16,32}be functions
commit 25534eb upstream.

These functions are used in some PCI drivers with big-endian
MMIO space.

Admittedly it is almost certain that no one this side of the
Moon would use such a card in an Alpha but it does get us
closer to being able to build allyesconfig or allmodconfig,
and it enables the Debian default generic config to build.

Tested-by: Raúl Porcel <armin76@gentoo.org>
Signed-off-by: Michael Cree <mcree@orcon.net.nz>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Zefan Li <lizefan@huawei.com>
618dea4
@jankara jankara ext2: Fix fs corruption in ext2_get_xip_mem()
commit 7ba3ec5 upstream.

Commit 8e3dffc "Ext2: mark inode dirty after the function
dquot_free_block_nodirty is called" unveiled a bug in __ext2_get_block()
called from ext2_get_xip_mem(). That function called ext2_get_block()
mistakenly asking it to map 0 blocks while 1 was intended. Before the
above mentioned commit things worked out fine by luck but after that commit
we started returning that we allocated 0 blocks while we in fact
allocated 1 block and thus allocation was looping until all blocks in
the filesystem were exhausted.

Fix the problem by properly asking for one block and also add assertion
in ext2_get_blocks() to catch similar problems.

Reported-and-tested-by: Andiry Xu <andiry.xu@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Wang Nan <wangnan0@huawei.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
3a8f613
@lizf-os lizf-os Linux 3.4.104 bb4a05a
@koct9i koct9i referenced this pull request in koct9i/linux Sep 27, 2014
mmotm auto import linux-next
GIT 2cf50762577a191f2f646e4034cc21f4764d90ab

commit 68c7ed167ef564c83a0022f2d0fe15cbdac0c5a4
Author: Peter Foley <pefoley2@pefoley.com>
Date:   Thu Sep 25 10:34:04 2014 +1000

    Documentation: disable vdso_test to avoid breakage with old glibc
    
    glibc versions older than 2.16 don't include sys/auxv.h which this
    executable uses.
    Since we don't have a good way to test for specific glibc versions in
    kbuild, just disable it for now.
    
    Signed-off-by: Peter Foley <pefoley2@pefoley.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>

commit 03979f1100aca61cf16ac7f3e464d7f11747e86b
Author: Peter Foley <pefoley2@pefoley.com>
Date:   Thu Sep 25 10:34:04 2014 +1000

    Documentation: update vDSO makefile to build portable examples
    
    Signed-off-by: Peter Foley <pefoley2@pefoley.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>

commit 13770826a9872de445703ee6c05b44f525f78513
Author: Peter Foley <pefoley2@pefoley.com>
Date:   Thu Sep 25 10:34:04 2014 +1000

    Documentation: update .gitignore files
    
    Add some missing files to .gitignore.
    Push Documentation/.gitignore down into subdirectories.
    
    Signed-off-by: Peter Foley <pefoley2@pefoley.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>

commit ce0f3b2691c066255fcf25c77e929ff8cda73417
Author: Peter Foley <pefoley2@pefoley.com>
Date:   Thu Sep 25 10:34:03 2014 +1000

    Documentation: support glibc versions without htole macros
    
    glibc 2.9 introduced the htole<16/32/64> macros, add them to
    tools/include to support older versions of glibc.
    
    Reported-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Peter Foley <pefoley2@pefoley.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>

commit 77cb6d96708f5b681969ce144057ae1ebda96057
Author: Mark Brown <broonie@kernel.org>
Date:   Thu Sep 25 10:34:03 2014 +1000

    v4l2-pci-skeleton: Only build if PCI is available
    
    Currently arm64 does not support PCI but it does support v4l2. Since the
    PCI skeleton driver is built unconditionally as a module with no dependency
    on PCI this causes build failures for arm64 allmodconfig. Fix this by
    defining a symbol VIDEO_PCI_SKELETON for the skeleton and conditionalising
    the build on that.
    
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org> [added VIDEO dependencies]

commit 112a45ca901ced590ff71c5fd7d717f8771717ce
Author: Peter Foley <pefoley2@pefoley.com>
Date:   Thu Sep 25 10:34:03 2014 +1000

    Documentation: fix misc. warnings
    
    Fix a few warnings that gcc emits during a default build.
    
    Signed-off-by: Peter Foley <pefoley2@pefoley.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>

commit b0fc375fe2c09477b5effc8e030668203d24c897
Author: Peter Foley <pefoley2@pefoley.com>
Date:   Thu Sep 25 10:34:03 2014 +1000

    Documentation: make functions static to avoid prototype warnings
    
    Signed-off-by: Peter Foley <pefoley2@pefoley.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>

commit 593ed472bcea93949c72ddc45e340fee47a05aa3
Author: Peter Foley <pefoley2@pefoley.com>
Date:   Thu Sep 25 10:34:03 2014 +1000

    Documentation: add makefiles for more targets
    
    Add a bunch of previously unbuilt source files to the Documentation build
    machinery.
    
    Signed-off-by: Peter Foley <pefoley2@pefoley.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>

commit cc67d673f252264535cef654c37c8dd621340e8b
Author: Peter Foley <pefoley2@pefoley.com>
Date:   Thu Sep 25 10:34:02 2014 +1000

    Documentation: use subdir-y to avoid unnecessary built-in.o files
    
    Change the Documentation makefiles from obj-m to subdir-y
    to avoid generating unnecessary built-in.o files since nothing
    in Documentation/ is ever linked in to vmlinux.
    
    Signed-off-by: Peter Foley <pefoley2@pefoley.com>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>

commit bb69afeca345380203c89d2f19e95eca786b5a4c
Author: Peter Foley <pefoley2@pefoley.com>
Date:   Thu Sep 25 10:34:02 2014 +1000

    Documentation: remove networking/.gitignore
    
    Remove empty networking/.gitignore
    
    Signed-off-by: Peter Foley <pefoley2@pefoley.com>
    Cc: rdunlap@infradead.org
    Cc: linux-doc@vger.kernel.org
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>

commit 4d96fb1ec81118c6406fe6d3670f172b2faaedf3
Author: Heiko Stuebner <heiko.stuebner@bq.com>
Date:   Tue Sep 23 22:42:16 2014 +0200

    power: gpio-charger: do not use gpio value directly
    
    Some gpio implementations return interesting values for gpio_get_value when
    the value is not 0 - as seen on a imx6sl board. Therefore do not use the
    value returned from gpio_get_value directly but simply check for 0 or not 0.
    
    Signed-off-by: Heiko Stuebner <heiko.stuebner@bq.com>
    Reviewed-by: Doug Anderson <dianders@chromium.org>
    Tested-by: Doug Anderson <dianders@chromium.org>
    Signed-off-by: Sebastian Reichel <sre@kernel.org>

commit ddd26dff757d08d4eb309a28bf2a02372387e71f
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Sep 16 18:10:41 2014 +0200

    power: max8925: Use of_get_child_by_name
    
    Use of_get_child_by_name to obtain reference to charger node instead of
    of_find_node_by_name which can walk outside of the parent node.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Sebastian Reichel <sre@kernel.org>

commit 920ac5be91bc447c5ef82f457207a169aa79c5f6
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Tue Sep 16 18:10:40 2014 +0200

    power: max8925: Fix NULL ptr dereference on memory allocation failure
    
    Check the return value of devm_kzalloc() to fix possible NULL pointer
    dereference and properly exit the probe() on memory allocation failure.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Sebastian Reichel <sre@kernel.org>

commit 628ef02c56e515430dd8d8439126dd0ecb8ce8bb
Author: Puthikorn Voravootivat <puthik@chromium.org>
Date:   Tue Sep 9 12:20:35 2014 -0700

    bq27x00_battery: Add support to bq27742
    
    Add support to bq27742 in bq27x00 driver. bq27742 register
    addresses are mostly mostly the same as bq27500 addresses
    with minor differences.
    
    Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
    Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
    Reviewed-by: Rhyland Klein <rklein@nvidia.com>
    Reviewed-by: Benson Leung <bleung@chromium.org>
    Signed-off-by: Sebastian Reichel <sre@kernel.org>

commit 042e1c79166b9250edd8262bea84e1703f27ad2e
Author: Jin Yao <yao.jin@linux.intel.com>
Date:   Mon Sep 22 10:31:14 2014 -0700

    Input: soc_button_array - convert to platform bus
    
    ACPI device enumeration mechanism changed a lot since 3.16-rc1.
    ACPI device objects with _HID will be enumerated to platform bus by default.
    For the existing PNP drivers that probe the PNPACPI devices, the device ids
    are listed explicitly in drivers/acpi/acpi_pnp.c.
    But ACPI folks will continue their effort on shrinking this id list by
    converting the PNP drivers to platform drivers, for the devices that don't
    belong to PNP bus in nature.
    
    Signed-off-by: Jin Yao <yao.jin@intel.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit 3049683eafdbbbd7350b0e5ca02a2d8c026a3362
Author: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Date:   Wed Sep 24 16:00:33 2014 -0700

    Input: i8042 - fix Asus X450LCP touchpad detection
    
    We need to add this module to the nomux table to be able to detect the
    touchpad.
    
    Cc: stablevger.kernel.org
    Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit 3f3d0463636e38a27c3000d59889b8bdc9072ce1
Author: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date:   Thu Sep 25 08:23:26 2014 +0900

    ARM: dts: Remove display timings node from exynos5250-snow
    
    Commit a3d72cad63ed ("ARM: dts: Clean up exynos5250-snow")
    improved the Snow DTS but the patch was rebased due conflicting
    changes and the merge resolution added a device node removed by
    commit a98c3c23868f ("ARM: dts: update display related nodes for
    exynos5250-snow").
    
    This patch removes the node again to keep the DTS as before.
    
    Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
    Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

commit dd12ac7fb3988be113465f499ad91b30b8aa4bdd
Author: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date:   Thu Sep 25 08:21:25 2014 +0900

    ARM: dts: Fix chip select GPIO on exynos5250-smdk5250
    
    Commit 65bbe3fee0e1 ("ARM: dts: Clean up exynos5250-smdk5250")
    improved the smdk5250 DTS but the patch was rebased due conflicting
    changes and the merge resolution added a regression of the bug fixed
    in commit e138d4333aa0 ("ARM: dts: fix the chip select gpios definition
    in the SPI nodes").
    
    This patch fixes the issue by removing the old cs-gpio and using
    the generic cs-gpios property.
    
    Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
    Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

commit 5c4dd348af35a6f6db97b4f2401f74c71f7f3c7d
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Sep 25 00:53:44 2014 +0200

    Revert "PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free()"
    
    Revert commit 6efde38f0769 (PM / Hibernate: Iterate over set bits
    instead of PFNs in swsusp_free()) that introduced a NULL pointer
    dereference during system resume from hibernation:
    
    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [<ffffffff810a8cc1>] swsusp_free+0x21/0x190
    PGD b39c2067 PUD b39c1067 PMD 0
    Oops: 0000 [#1] SMP
    Modules linked in: <irrelevant list of modules>
    CPU: 1 PID: 4898 Comm: s2disk Tainted: G         C     3.17-rc5-amd64 #1 Debian 3.17~rc5-1~exp1
    Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
    task: ffff88023155ea40 ti: ffff8800b3b14000 task.ti: ffff8800b3b14000
    RIP: 0010:[<ffffffff810a8cc1>]  [<ffffffff810a8cc1>]
    swsusp_free+0x21/0x190
    RSP: 0018:ffff8800b3b17ea8  EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff8800b39bab00 RCX: 0000000000000001
    RDX: ffff8800b39bab10 RSI: ffff8800b39bab00 RDI: 0000000000000000
    RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000
    R10: ffff8800b39bab10 R11: 0000000000000246 R12: ffffea0000000000
    R13: ffff880232f485a0 R14: ffff88023ac27cd8 R15: ffff880232927590
    FS:  00007f406d83b700(0000) GS:ffff88023bc80000(0000)
    knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000000 CR3: 00000000b3a62000 CR4: 00000000000007e0
    Stack:
     ffff8800b39bab00 0000000000000010 ffff880232927590 ffffffff810acb4a
     ffff8800b39bab00 ffffffff811a955a ffff8800b39bab10 0000000000000000
     ffff88023155f098 ffffffff81a6b8c0 ffff88023155ea40 0000000000000007
    Call Trace:
     [<ffffffff810acb4a>] ? snapshot_release+0x2a/0xb0
     [<ffffffff811a955a>] ? __fput+0xca/0x1d0
     [<ffffffff81080627>] ? task_work_run+0x97/0xd0
     [<ffffffff81012d89>] ? do_notify_resume+0x69/0xa0
     [<ffffffff8151452a>] ? int_signal+0x12/0x17
    Code: 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 41 54 48 8b 05 ba 62 9c 00 49 bc 00 00 00 00 00 ea ff ff 48 8b 3d a1 62 9c 00 55 53 <48> 8b 10 48 89 50 18 48 8b 52 20 48 c7 40 28 00 00 00 00 c7 40
    RIP  [<ffffffff810a8cc1>] swsusp_free+0x21/0x190
     RSP <ffff8800b3b17ea8>
    CR2: 0000000000000000
    ---[ end trace f02be86a1ec0cccb ]---
    
    due to forbidden_pages_map being NULL in swsusp_free().
    
    Fixes: 6efde38f0769 "PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free()"
    Reported-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit a928f97152ea39c31f8ea89b60dd30a169d4ed6e
Author: Peter Hüwe <PeterHuewe@gmx.de>
Date:   Fri Sep 12 21:09:47 2014 +0200

    i2c: acpi: Fix NULL Pointer dereference
    
    If adapter->dev.parent == NULL there is a NULL pointer dereference in
    acpi_i2c_install_space_handler and acpi_i2c_remove_space_handler.
    
    This is present since introduction of this code:
    366047515c6e "i2c: rework kernel config I2C_ACPI" or even
    da3c6647ee08 "I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI"
    
    The adapter->dev.parent == NULL case is valid for the i2c_stub,
    so loading i2c_stub with ACPI_I2C_OPREGION enabled results in an oops.
    This is also valid at least for i2c_tiny_usb and i2c_robotfuzz_osif.
    
    Fix by checking whether it is null before calling ACPI_HANDLE.
    
    Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

commit c15d821ddb9dac9ac6b5beb75bf942f3bc3a4004
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Tue Sep 23 10:35:54 2014 +0800

    gpio / ACPI: Use pin index and bit length
    
    Fix code when the operation region callback is for an gpio, which
    is not at index 0 and for partial pins in a GPIO definition.
    For example:
    Name (GMOD, ResourceTemplate ()
    {
    	//3 Outputs that define the Power mode of the device
    	GpioIo (Exclusive, PullDown, , , , "\\_SB.GPI2") {10, 11, 12}
    	})
    }
    
    If opregion callback calls is for:
    - Set pin 10, then address = 0 and bit length = 1
    - Set pin 11, then address = 1 and bit length = 1
    - Set for both pin 11 and pin 12, then address = 1, bit length = 2
    
    This change requires updated ACPICA gpio operation handler code to
    send the pin index and bit length.
    
    Fixes: 473ed7be0da0 (gpio / ACPI: Add support for ACPI GPIO operation regions)
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: 3.15+ <stable@vger.kernel.org> # 3.15+: 75ec6e55f138 ACPICA: Update to GPIO region handler interface.
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 75ec6e55f1384548311a13ce4fcb39c516053314
Author: Bob Moore <Robert.Moore@intel.com>
Date:   Tue Sep 23 10:35:47 2014 +0800

    ACPICA: Update to GPIO region handler interface.
    
    Changes to correct several GPIO issues:
    
    1) The update_rule in a GPIO field definition is now ignored;
    a read-modify-write operation is never performed for GPIO fields.
    (Internally, this means that the field assembly/disassembly
    code is completely bypassed for GPIO.)
    
    2) The Address parameter passed to a GPIO region handler is
    now the bit offset of the field from a previous Connection()
    operator. Thus, it becomes a "Pin Number Index" into the
    Connection() resource descriptor.
    
    3) The bit_width parameter passed to a GPIO region handler is
    now the exact bit width of the GPIO field. Thus, it can be
    interpreted as "number of pins".
    
    Overall, we can now say that the region handler interface
    to GPIO handlers is a raw "bit/pin" addressed interface, not
    a byte-addressed interface like the system_memory handler interface.
    
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 457920817e645a7dee42c2a75c81c5ed8e12ee1c
Author: Fu Zhonghui <zhonghui.fu@linux.intel.com>
Date:   Wed Sep 24 22:42:26 2014 +0200

    ACPI / platform / LPSS: disable async suspend/resume of LPSS devices
    
    On some systems (Asus T100 in particular) there are strict ordering
    dependencies between LPSS devices with respect to power management
    that break if they suspend/resume asynchronously.
    
    In theory it should be possible to follow those dependencies in the
    async suspend/resume case too (the ACPI tables tell as that the
    dependencies are there), but since we're missing infrastructure
    for that at the moment, disable async suspend/resume for all of
    the LPSS devices for the time being.
    
    Link: http://marc.info/?l=linux-acpi&m=141158962321905&w=2
    Fixes: 8ce62f85a81f (ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices)
    Signed-off-by: Li Aubrey <aubrey.li@linux.intel.com>
    Signed-off-by: Fu Zhonghui <zhonghui.fu@linux.intel.com>
    Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
    [ rjw: Changelog ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit c7da579763f29cf45a861ad4c339aba590d8b80d
Author: Johan Hedberg <johan.hedberg@intel.com>
Date:   Wed Sep 24 22:41:46 2014 +0300

    Bluetooth: Add retransmission effort into SCO parameter table
    
    It is expected that new parameter combinations will have the
    retransmission effort value different between some entries (mainly
    because of the new S4 configuration added by HFP 1.7), so it makes sense
    to move it into the table instead of having it hard coded based on the
    selected SCO_AIRMODE_*.
    
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

commit b2fc3f3c6d397d434174147eca3db1ec778195ce
Author: Olof Johansson <olof@lixom.net>
Date:   Wed Sep 24 11:42:38 2014 -0700

    drivers/soc: ti: fix build break with modules
    
    Fixes below build break by not switching to stubs when the driver is a module:
    
    drivers/soc/ti/knav_dma.c:418:7: error: redefinition of 'knav_dma_open_channel'
     void *knav_dma_open_channel(struct device *dev, const char *name,
           ^
    In file included from drivers/soc/ti/knav_dma.c:26:0:
    include/linux/soc/ti/knav_dma.h:165:21: note: previous definition of 'knav_dma_open_channel' was here
     static inline void *knav_dma_open_channel(struct device *dev, const char *name,
                         ^
    
    Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 2d9251e3501356ceb44444a8f9a393b57163dc6a
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: multi_v7_defconfig: Enable Mediatek platform
    
    Enable Mediatek platform support for multi_v7_defconfig.
    
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit d66820853251e8a9b53125a95a773e482cd79136
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: mediatek: Add earlyprintk support for mt6589
    
    Enable low-level debug for Mediatek mt6589 SoC on UART0.
    
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 7e9b2828f25ec156623da0c2156604066de5514d
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: dts: mt6589: Change compatible string for GIC
    
    This patch changes the compatible string of the GIC to the
    new "arm,cortex-a7-gic" which does reflect the actual hardware.
    
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 6e9cb2633698ddadd2493b3793dbc9723f570538
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: dts: mediatek: Add compatible property for aquaris5
    
    Add the missing 'compatible' property to device tree root node of
    
     - mt6589-aquaris5.dts
    
    and document the new values.
    
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit d82df11466df3e0934c7e7aa2f5e08c284e1fd9d
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: dts: mt6589-aquaris5: Add boot argument earlyprintk
    
    Add boot argument for earlyprintk to the aquaris5 device tree file.
    
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 510f1d72e526e776243397142cbcd459dd2a2efa
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: dts: mt6589: Fix typo in GIC unit address
    
    This changes the unit address of the gic node to it's first register area.
    
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 995425883e4087a4bfd61d12e442089d1201fc5c
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date:   Mon Aug 18 16:58:00 2014 +0200

    ARM: dts: Build dtb for Mediatek board
    
    This allows the "make dtbs" to build the aquaris5 dtb for the Mediatek
    SoC.
    
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 00e978180b1fa211c30642139149ea448ff06c55
Author: Pawel Moll <pawel.moll@arm.com>
Date:   Mon Sep 15 15:33:48 2014 +0100

    bus: arm-ccn: Fix spurious warning message
    
    Because CCN's cycle counter always runs, it will generate
    an interrupt on overflow even if the relevant perf event
    was not requested, causing a spurious warning message.
    
    Fixed now by warning on only normal counter unwanted
    overflows. Also cleaning the overflow mask at init now,
    not to warn on event previously requested by firmware.
    
    Signed-off-by: Pawel Moll <pawel.moll@arm.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 94e57fea62020dbf6e5d0093eabcd28366e86044
Author: Francesco Ruggeri <fruggeri@arista.com>
Date:   Wed Sep 24 10:12:41 2014 -0700

    PCI: Move PCI_VENDOR_ID_VMWARE to pci_ids.h
    
    Move PCI_VENDOR_ID_VMWARE from device-specific files to pci_ids.h.
    It is useful to always have access to it, especially when accessing
    subsystem_vendor_id on emulated devices.
    
    [bhelgaas: keep pci_ids.h sorted and use lower-case hex]
    Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit 17497acbdce9506fd6a75115dee4ab80c3cc5ee5
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 24 13:31:50 2014 -0400

    blk-mq, percpu_ref: start q->mq_usage_counter in atomic mode
    
    blk-mq uses percpu_ref for its usage counter which tracks the number
    of in-flight commands and used to synchronously drain the queue on
    freeze.  percpu_ref shutdown takes measureable wallclock time as it
    involves a sched RCU grace period.  This means that draining a blk-mq
    takes measureable wallclock time.  One would think that this shouldn't
    matter as queue shutdown should be a rare event which takes place
    asynchronously w.r.t. userland.
    
    Unfortunately, SCSI probing involves synchronously setting up and then
    tearing down a lot of request_queues back-to-back for non-existent
    LUNs.  This means that SCSI probing may take above ten seconds when
    scsi-mq is used.
    
      [    0.949892] scsi host0: Virtio SCSI HBA
      [    1.007864] scsi 0:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    1.1. PQ: 0 ANSI: 5
      [    1.021299] scsi 0:0:1:0: Direct-Access     QEMU     QEMU HARDDISK    1.1. PQ: 0 ANSI: 5
      [    1.520356] tsc: Refined TSC clocksource calibration: 2491.910 MHz
    
      <stall>
    
      [   16.186549] sd 0:0:0:0: Attached scsi generic sg0 type 0
      [   16.190478] sd 0:0:1:0: Attached scsi generic sg1 type 0
      [   16.194099] osd: LOADED open-osd 0.2.1
      [   16.203202] sd 0:0:0:0: [sda] 31457280 512-byte logical blocks: (16.1 GB/15.0 GiB)
      [   16.208478] sd 0:0:0:0: [sda] Write Protect is off
      [   16.211439] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
      [   16.218771] sd 0:0:1:0: [sdb] 31457280 512-byte logical blocks: (16.1 GB/15.0 GiB)
      [   16.223264] sd 0:0:1:0: [sdb] Write Protect is off
      [   16.225682] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    
    This is also the reason why request_queues start in bypass mode which
    is ended on blk_register_queue() as shutting down a fully functional
    queue also involves a RCU grace period and the queues for non-existent
    SCSI devices never reach registration.
    
    blk-mq basically needs to do the same thing - start the mq in a
    degraded mode which is faster to shut down and then make it fully
    functional only after the queue reaches registration.  percpu_ref
    recently grew facilities to force atomic operation until explicitly
    switched to percpu mode, which can be used for this purpose.  This
    patch makes blk-mq initialize q->mq_usage_counter in atomic mode and
    switch it to percpu mode only once blk_register_queue() is reached.
    
    Note that this issue was previously worked around by 0a30288da1ae
    ("blk-mq, percpu_ref: implement a kludge for SCSI blk-mq stall during
    probe") for v3.17.  The temp fix was reverted in preparation of adding
    persistent atomic mode to percpu_ref by 9eca80461a45 ("Revert "blk-mq,
    percpu_ref: implement a kludge for SCSI blk-mq stall during probe"").
    This patch and the prerequisite percpu_ref changes will be merged
    during v3.18 devel cycle.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Christoph Hellwig <hch@infradead.org>
    Link: http://lkml.kernel.org/g/20140919113815.GA10791@lst.de
    Fixes: add703fda981 ("blk-mq: use percpu_ref for mq usage count")
    Reviewed-by: Kent Overstreet <kmo@daterainc.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Johannes Weiner <hannes@cmpxchg.org>

commit e4de4d412fc0d07f820906dcd70ede06dad312e2
Author: Olof Johansson <olof@lixom.net>
Date:   Wed Sep 24 10:34:06 2014 -0700

    ARM: at91: Fix bad conflict resolution in board-dt-sama5.c
    
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 3c9703a87bdda1fef221ab0957a3ec2a2126f129
Author: Olof Johansson <olof@lixom.net>
Date:   Wed Sep 24 10:32:20 2014 -0700

    Revert "ARM: make arrays containing machine compatible strings const"
    
    I dropped it from next/cleanup, doing a revert on for-next instead of
    rebuilding the branch.
    
    This reverts commit fbce9bc876ab2c905f1f82a78bc25745e98760d9.

commit 1cae13e75b7a7848c03138636d4eb8d8a5054dd5
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 24 13:31:50 2014 -0400

    percpu_ref: make INIT_ATOMIC and switch_to_atomic() sticky
    
    Currently, a percpu_ref which is initialized with
    PERPCU_REF_INIT_ATOMIC or switched to atomic mode via
    switch_to_atomic() automatically reverts to percpu mode on the first
    percpu_ref_reinit().  This makes the atomic mode difficult to use for
    cases where a percpu_ref is used as a persistent on/off switch which
    may be cycled multiple times.
    
    This patch makes such atomic state sticky so that it survives through
    kill/reinit cycles.  After this patch, atomic state is cleared only by
    an explicit percpu_ref_switch_to_percpu() call.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Kent Overstreet <kmo@daterainc.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Johannes Weiner <hannes@cmpxchg.org>

commit 2aad2a86f6685c10360ec8a5a55eb9ab7059cb72
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 24 13:31:50 2014 -0400

    percpu_ref: add PERCPU_REF_INIT_* flags
    
    With the recent addition of percpu_ref_reinit(), percpu_ref now can be
    used as a persistent switch which can be turned on and off repeatedly
    where turning off maps to killing the ref and waiting for it to drain;
    however, there currently isn't a way to initialize a percpu_ref in its
    off (killed and drained) state, which can be inconvenient for certain
    persistent switch use cases.
    
    Similarly, percpu_ref_switch_to_atomic/percpu() allow dynamic
    selection of operation mode; however, currently a newly initialized
    percpu_ref is always in percpu mode making it impossible to avoid the
    latency overhead of switching to atomic mode.
    
    This patch adds @flags to percpu_ref_init() and implements the
    following flags.
    
    * PERCPU_REF_INIT_ATOMIC	: start ref in atomic mode
    * PERCPU_REF_INIT_DEAD		: start ref killed and drained
    
    These flags should be able to serve the above two use cases.
    
    v2: target_core_tpg.c conversion was missing.  Fixed.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Kent Overstreet <kmo@daterainc.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Johannes Weiner <hannes@cmpxchg.org>

commit f47ad45784611297b699f3dffb6c7222b76afe64
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 24 13:31:49 2014 -0400

    percpu_ref: decouple switching to percpu mode and reinit
    
    percpu_ref has treated the dropping of the base reference and
    switching to atomic mode as an integral operation; however, there's
    nothing inherent tying the two together.
    
    The use cases for percpu_ref have been expanding continuously.  While
    the current init/kill/reinit/exit model can cover a lot, the coupling
    of kill/reinit with atomic/percpu mode switching is turning out to be
    too restrictive for use cases where many percpu_refs are created and
    destroyed back-to-back with only some of them reaching extended
    operation.  The coupling also makes implementing always-atomic debug
    mode difficult.
    
    This patch separates out percpu mode switching into
    percpu_ref_switch_to_percpu() and reimplements percpu_ref_reinit() on
    top of it.
    
    * DEAD still requires ATOMIC.  A dead ref can't be switched to percpu
      mode w/o going through reinit.
    
    v2: __percpu_ref_switch_to_percpu() was missing static.  Fixed.
        Reported by Fengguang aka kbuild test robot.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Kent Overstreet <kmo@daterainc.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: kbuild test robot <fengguang.wu@intel.com>

commit 490c79a65708873228cf114cf00e32c204e4e907
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 24 13:31:49 2014 -0400

    percpu_ref: decouple switching to atomic mode and killing
    
    percpu_ref has treated the dropping of the base reference and
    switching to atomic mode as an integral operation; however, there's
    nothing inherent tying the two together.
    
    The use cases for percpu_ref have been expanding continuously.  While
    the current init/kill/reinit/exit model can cover a lot, the coupling
    of kill/reinit with atomic/percpu mode switching is turning out to be
    too restrictive for use cases where many percpu_refs are created and
    destroyed back-to-back with only some of them reaching extended
    operation.  The coupling also makes implementing always-atomic debug
    mode difficult.
    
    This patch separates out atomic mode switching into
    percpu_ref_switch_to_atomic() and reimplements
    percpu_ref_kill_and_confirm() on top of it.
    
    * The handling of __PERCPU_REF_ATOMIC and __PERCPU_REF_DEAD is now
      differentiated.  Among get/put operations, percpu_ref_tryget_live()
      is the only one which cares about DEAD.
    
    * percpu_ref_switch_to_atomic() can be called multiple times on the
      same ref.  This means that multiple @confirm_switch may get queued
      up which we can't do reliably without extra memory area.  This is
      handled by making the later invocation synchronously wait for the
      completion of the previous one.  This isn't particularly desirable
      but such synchronous waits shouldn't happen in most cases.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Kent Overstreet <kmo@daterainc.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Johannes Weiner <hannes@cmpxchg.org>

commit 27344a9017cdaff82a167827da3001a0918afdc3
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 24 13:31:49 2014 -0400

    percpu_ref: add PCPU_REF_DEAD
    
    percpu_ref will be restructured so that percpu/atomic mode switching
    and reference killing are dedoupled.  In preparation, add
    PCPU_REF_DEAD and PCPU_REF_ATOMIC_DEAD which is OR of ATOMIC and DEAD.
    For now, ATOMIC and DEAD are changed together and all PCPU_REF_ATOMIC
    uses are converted to PCPU_REF_ATOMIC_DEAD without causing any
    behavior changes.
    
    percpu_ref_init() now specifies an explicit alignment when allocating
    the percpu counters so that the pointer has enough unused low bits to
    accomodate the flags.  Note that one flag was fine as min alignment
    for percpu memory is 2 bytes but two flags are already too many for
    the natural alignment of unsigned longs on archs like cris and m68k.
    
    v2: The original patch had BUILD_BUG_ON() which triggers if unsigned
        long's alignment isn't enough to accomodate the flags, which
        triggered on cris and m64k.  percpu_ref_init() updated to specify
        the required alignment explicitly.  Reported by Fengguang.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Kent Overstreet <kmo@daterainc.com>
    Cc: kbuild test robot <fengguang.wu@intel.com>

commit 9e804d1f58da1eca079f796347c1cf1d1df564e2
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 24 13:31:48 2014 -0400

    percpu_ref: rename things to prepare for decoupling percpu/atomic mode switch
    
    percpu_ref will be restructured so that percpu/atomic mode switching
    and reference killing are dedoupled.  In preparation, do the following
    renames.
    
    * percpu_ref->confirm_kill	-> percpu_ref->confirm_switch
    * __PERCPU_REF_DEAD		-> __PERCPU_REF_ATOMIC
    * __percpu_ref_alive()		-> __ref_is_percpu()
    
    This patch is pure rename and doesn't introduce any functional
    changes.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Kent Overstreet <kmo@daterainc.com>

commit eecc16ba9a49b05dd847a317af166a6728eb56ca
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 24 13:31:48 2014 -0400

    percpu_ref: replace pcpu_ prefix with percpu_
    
    percpu_ref uses pcpu_ prefix for internal stuff and percpu_ for
    externally visible ones.  This is the same convention used in the
    percpu allocator implementation.  It works fine there but percpu_ref
    doesn't have too much internal-only stuff and scattered usages of
    pcpu_ prefix are confusing than helpful.
    
    This patch replaces all pcpu_ prefixes with percpu_.  This is pure
    rename and there's no functional change.  Note that PCPU_REF_DEAD is
    renamed to __PERCPU_REF_DEAD to signify that the flag is internal.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Kent Overstreet <kmo@daterainc.com>

commit 6251f9976af7656b6970a8820153f356430f5de2
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 24 13:31:48 2014 -0400

    percpu_ref: minor code and comment updates
    
    * Some comments became stale.  Updated.
    * percpu_ref_tryget() unnecessarily initializes @ret.  Removed.
    * A blank line removed from percpu_ref_kill_rcu().
    * Explicit function name in a WARN format string replaced with __func__.
    * WARN_ON() in percpu_ref_reinit() converted to WARN_ON_ONCE().
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Kent Overstreet <kmo@daterainc.com>

commit a2237370194484ee6aeeff04b617e4b14d178966
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 24 13:31:48 2014 -0400

    percpu_ref: relocate percpu_ref_reinit()
    
    percpu_ref is gonna go through restructuring.  Move
    percpu_ref_reinit() after percpu_ref_kill_and_confirm().  This will
    make later changes easier to follow and result in cleaner
    organization.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Kent Overstreet <kmo@daterainc.com>

commit 1aafa57340c6d906a285d7823e0fe68696c1ae07
Author: Wei Xu <xuwei5@hisilicon.com>
Date:   Wed Sep 24 17:07:48 2014 +0800

    ARM: hisi: Fix platmcpm compilation when ARMv6 is selected
    
    When compiling with "ARCH=arm" and "allmodconfig",
    with commit: 9cdc99919a95e8b54c1998b65bb1bfdabd47d27b [2/7] ARM: hisi: enable MCPM implementation
    we will get:
    
       /tmp/cc6DjYjT.s: Assembler messages:
       /tmp/cc6DjYjT.s:63: Error: selected processor does not support ARM mode `ubfx r1,r0,#8,#8'
       /tmp/cc6DjYjT.s:761: Error: selected processor does not support ARM mode `isb '
       /tmp/cc6DjYjT.s:762: Error: selected processor does not support ARM mode `dsb '
       /tmp/cc6DjYjT.s:769: Error: selected processor does not support ARM mode `isb '
       /tmp/cc6DjYjT.s:775: Error: selected processor does not support ARM mode `isb '
       /tmp/cc6DjYjT.s:776: Error: selected processor does not support ARM mode `dsb '
       /tmp/cc6DjYjT.s:795: Error: selected processor does not support ARM mode `isb '
       /tmp/cc6DjYjT.s:801: Error: selected processor does not support ARM mode `isb '
       /tmp/cc6DjYjT.s:802: Error: selected processor does not support ARM mode `dsb '
    
    Fix platmcpm compilation when ARMv6 is selected.
    
    Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 495aa2e1facebf770224c33aae2a01541889e54e
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date:   Tue Sep 23 20:01:14 2014 +0100

    arm64: Add architectural support for PCI
    
    Use the generic PCI domain and OF functions to provide support for PCI
    on arm64.
    
    [bhelgaas: Change comments to use generic PCI, not just PCIe.  Nothing at
    this level is PCIe-specific.]
    Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>

commit b766eafe68281a12169f9eb8c06fd80d2e7897d7
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date:   Tue Sep 23 20:01:13 2014 +0100

    PCI: Add pci_remap_iospace() to map bus I/O resources
    
    Add pci_remap_iospace() to map bus I/O resources into the CPU virtual
    address space.  Architectures with special needs may provide their own
    version, but most should be able to use this one.
    
    This function is useful for PCI host bridge drivers that need to map the
    PCI I/O resources into virtual memory space.
    
    [bhelgaas: phys_addr description, drop temporary "err" variable]
    Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    CC: Arnd Bergmann <arnd@arndb.de>

commit 5a4f662d44116022e3378b32a1a79b718e110096
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date:   Tue Sep 23 20:01:12 2014 +0100

    PCI: Assign unassigned bus resources in pci_scan_root_bus()
    
    If the firmware has not assigned all the bus resources and we are not just
    probing the PCI buses, it makes sense to assign the unassigned resources
    in pci_scan_root_bus().
    
    Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: Arnd Bergmann <arnd@arndb.de>
    CC: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    CC: Rob Herring <robh+dt@kernel.org>

commit 07428b62addb624a3b51b6e8a213fec9b97dbfd0
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date:   Wed Sep 24 11:27:33 2014 -0600

    of/pci: Add support for parsing PCI host bridge resources from DT
    
    Provide a function to parse the PCI DT ranges that can be used to create a
    pci_host_bridge structure together with its associated bus.
    
    Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
    [make io_base parameter optional]
    Signed-off-by: Robert Richter <rrichter@cavium.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: Arnd Bergmann <arnd@arndb.de>
    CC: Grant Likely <grant.likely@linaro.org>
    CC: Rob Herring <robh+dt@kernel.org>
    CC: Catalin Marinas <catalin.marinas@arm.com>

commit 9eca80461a45177e456219a9cd944c27675d6512
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 24 13:07:33 2014 -0400

    Revert "blk-mq, percpu_ref: implement a kludge for SCSI blk-mq stall during probe"
    
    This reverts commit 0a30288da1aec914e158c2d7a3482a85f632750f, which
    was a temporary fix for SCSI blk-mq stall issue.  The following
    patches will fix the issue properly by introducing atomic mode to
    percpu_ref.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Kent Overstreet <kmo@daterainc.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Christoph Hellwig <hch@lst.de>

commit 83417b202bf5aa2cd82637aa81aa9f065cfe5f21
Author: Wolfram Sang <wsa@the-dreams.de>
Date:   Mon Sep 22 19:41:00 2014 +0200

    i2c: move acpi code back into the core
    
    Commit 5d98e61d337c ("I2C/ACPI: Add i2c ACPI operation region support")
    renamed the i2c-core module. This may cause regressions for
    distributions, so put the ACPI code back into the core.
    
    Reported-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
    Cc: Lan Tianyu <tianyu.lan@intel.com>

commit 964356938fcd3c0001a786f55b9f0a0fbe47656a
Author: Andreas Werner <andreas.werner@men.de>
Date:   Wed Aug 27 19:53:06 2014 +0200

    hwmon: (menf21bmc) Introduce MEN14F021P00 BMC HWMON driver
    
    Added driver to support the 14F021P00 BMC Hardware Monitoring.
    The BMC is a Board Management Controller including monitoring of the
    board voltages.
    
    Signed-off-by: Andreas Werner <andreas.werner@men.de>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

commit 38433639af915deeb0b0e28462dd740ce57b72fd
Author: Andreas Werner <andreas.werner@men.de>
Date:   Wed Aug 27 19:52:36 2014 +0200

    leds: leds-menf21bmc: Introduce MEN 14F021P00 BMC LED driver
    
    Added driver to support the 14F021P00 BMC LEDs.
    The BMC is a Board Management Controller including four LEDs which
    can be switched on and off.
    
    Signed-off-by: Andreas Werner <andreas.werner@men.de>
    Acked-by: Bryan Wu <cooloney@gmail.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

commit 5033263992eece84e19946d2cab940c86ec862ba
Author: Andreas Werner <andreas.werner@men.de>
Date:   Wed Aug 27 19:52:06 2014 +0200

    watchdog: menf21bmc_wdt: Introduce MEN 14F021P00 BMC Watchdog driver
    
    Added driver to support the 14F021P00 BMC Watchdog.
    The BMC is a Board Management Controller including watchdog functionality.
    
    Signed-off-by: Andreas Werner <andreas.werner@men.de>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

commit d6cc1f5824cbca392d099f3bb0c441efd9e54de9
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Fri Sep 12 08:54:00 2014 +0200

    Documentation: charger: max14577: Document exported sysfs entry
    
    Document the 'fast charge timer' setting exported by max14577 driver
    through sysfs entry.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

commit 8d70d68d7a1b3082ca5a3808be18103a83ae348d
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Fri Sep 12 08:53:59 2014 +0200

    devicetree: mfd: max14577: Add device tree bindings document
    
    Add document describing device tree bindings for MAX14577 MFD
    drivers: MFD core, extcon, regulator and charger.
    
    Both MAX14577 and MAX77836 chipsets are documented.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Reviewed-by: Tomasz Figa <t.figa@samsung.com>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

commit 2c33e9296202cd11bf2e2f801b69ffba0953748a
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Fri Sep 12 08:53:58 2014 +0200

    power: max17040: Add ID for MAX77836 Fuel Gauge block
    
    MAX77836 has the same Fuel Gauge as MAX17040/17048. The max17040 driver
    can be safely re-used. The patch adds MAX77836 device to the array of
    i2c_device_id. Additionally it removes the id associated with MAX17040
    device as the value is not used.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

commit e30110e9c96f48aea01abc3e6dfadb369cbafec3
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Fri Sep 12 08:53:57 2014 +0200

    charger: max14577: Configure battery-dependent settings from DTS and sysfs
    
    Remove hard-coded values for:
     - Fast Charge current,
     - End Of Charge current,
     - Fast Charge timer,
     - Overvoltage Protection Threshold,
     - Battery Constant Voltage,
    and use DTS or sysfs to configure them. This allows using the max14577 charger
    driver with different batteries.
    
    Now the charger driver requires valid configuration data from DTS. In
    case of wrong configuration data it fails during probe.
    
    The fast charge timer is configured through sysfs entry.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

commit b8f139f68f2099b7f8b4ef470a1e53210e3aa025
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Fri Sep 12 08:53:56 2014 +0200

    regulator/mfd: max14577: Export symbols for calculating charger current
    
    This patch prepares for changing the max14577 charger driver to allow
    configuring battery-dependent settings from DTS.
    
    The patch moves from regulator driver to MFD core driver and exports:
     - function for calculating register value for charger's current;
     - table of limits for chargers (MAX14577, MAX77836).
    
    Previously they were used only by the max14577 regulator driver. In next
    patch the charger driver will use them as well. Exporting them will
    reduce unnecessary code duplication.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Acked-by: Mark Brown <broonie@linaro.org>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

commit 3682a8ee87f9107253e51733f42da10160ce41e3
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Fri Sep 12 08:53:55 2014 +0200

    charger: max14577: Add support for MAX77836 charger
    
    Add support for MAX77836 charger to the max14577 driver. The MAX77836
    charger is almost the same as 14577 model except:
     - No dead-battery detection;
     - Support for special charger (like in MAX77693);
     - Support for DX over-voltage protection (like in MAX77693);
     - Lower values of charging current (two times lower current for
       slow/fast charge, much lower EOC current);
     - Slightly different values in ChgTyp field of STATUS2 register. On
       MAX14577 0x6 is reserved and 0x7 dead battery. On the MAX77836 the
       0x6 means special charger and 0x7 is reserved. Regardless of these
       differences the driver maps them to one enum max14577_muic_charger_type.
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

commit 2f4096e311ef0922c42cbf7bc5df44efb3aff716
Author: Quentin Lambert <lambert.quentin@gmail.com>
Date:   Sun Sep 7 20:04:28 2014 +0200

    PCI: Remove assignment from complicated "if" conditions
    
    The modifications effectively change the value of len_tmp
    in the case where the first condition is not met.
    
    Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit 79e50e72986c9fcb06d707ce587cfd24fefa33e3
Author: Quentin Lambert <lambert.quentin@gmail.com>
Date:   Sun Sep 7 20:03:32 2014 +0200

    PCI: Remove assignment from "if" conditions
    
    The following Coccinelle semantic patch was used to find and correct cases
    of assignments in "if" conditions:
    
    @@
    expression var, expr;
    statement S;
    @@
    
    + var = expr;
      if(
    - (var = expr)
    + var
      ) S
    
    Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit 656f978f9af9d8d77436e8159f51f7aa1e673309
Author: Quentin Lambert <lambert.quentin@gmail.com>
Date:   Sun Sep 7 20:02:47 2014 +0200

    PCI: Remove unnecessary curly braces
    
    Remove curly braces in simple "if" cases.
    
    No functional change.
    
    Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit e0c524049f8279d00d2fbd4748b03234a2726fdd
Author: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date:   Thu Jul 10 11:30:08 2014 -0400

    MAINTAINERS: Add Keystone Multicore Navigator drivers entry
    
    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

commit 88139ed030583557751e279968e13e892ae10825
Author: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date:   Sun Mar 30 17:29:04 2014 -0400

    soc: ti: add Keystone Navigator DMA support
    
    The Keystone Navigator DMA driver sets up the dma channels and flows for
    the QMSS(Queue Manager SubSystem) who triggers the actual data movements
    across clients using destination queues. Every client modules like
    NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO
    Engines has its own instance of packet dma hardware. QMSS has also
    an internal packet DMA module which is used as an infrastructure
    DMA with zero copy.
    
    Initially this driver was proposed as DMA engine driver but since the
    hardware is not typical DMA engine and hence doesn't comply with typical
    DMA engine driver needs, that approach was naked. Link to that
    discussion -
    	https://lkml.org/lkml/2014/3/18/340
    
    As aligned, now we pair the Navigator DMA with its companion Navigator
    QMSS subsystem driver.
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Kumar Gala <galak@codeaurora.org>
    Cc: Olof Johansson <olof@lixom.net>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Grant Likely <grant.likely@linaro.org>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

commit 8172296d8717be1951da4bb4feb2700a60e8cdde
Author: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date:   Sun Mar 30 17:29:04 2014 -0400

    Documentation: dt: soc: add Keystone Navigator DMA bindings
    
    The Keystone Navigator DMA driver sets up the dma channels and flows for
    the QMSS(Queue Manager SubSystem) who triggers the actual data movements
    across clients using destination queues. Every client modules like
    NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO
    Engines has its own instance of packet dma hardware. QMSS has also
    an internal packet DMA module which is used as an infrastructure
    DMA with zero copy.
    
    Initially this driver was proposed as DMA engine driver but since the
    hardware is not typical DMA engine and hence doesn't comply with typical
    DMA engine driver needs, that approach was naked. Link to that
    discussion -
    	https://lkml.org/lkml/2014/3/18/340
    
    As aligned, now we pair the Navigator DMA with its companion Navigator
    QMSS subsystem driver.
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Kumar Gala <galak@codeaurora.org>
    Cc: Olof Johansson <olof@lixom.net>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Grant Likely <grant.likely@linaro.org>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

commit 41f93af900a20d1a0a358b522b5129c89677e9dc
Author: Sandeep Nair <sandeep_n@ti.com>
Date:   Fri Feb 28 10:47:50 2014 -0500

    soc: ti: add Keystone Navigator QMSS driver
    
    The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
    the main hardware sub system which forms the backbone of the Keystone
    Multi-core Navigator. QMSS consist of queue managers, packed-data structure
    processors(PDSP), linking RAM, descriptor pools and infrastructure
    Packet DMA.
    
    The Queue Manager is a hardware module that is responsible for accelerating
    management of the packet queues. Packets are queued/de-queued by writing or
    reading descriptor address to a particular memory mapped location. The PDSPs
    perform QMSS related functions like accumulation, QoS, or event management.
    Linking RAM registers are used to link the descriptors which are stored in
    descriptor RAM. Descriptor RAM is configurable as internal or external memory.
    
    The QMSS driver manages the PDSP setups, linking RAM regions,
    queue pool management (allocation, push, pop and notify) and descriptor
    pool management. The specifics on the device tree bindings for
    QMSS can be found in:
    	Documentation/devicetree/bindings/soc/keystone-navigator-qmss.txt
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Kumar Gala <galak@codeaurora.org>
    Cc: Olof Johansson <olof@lixom.net>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Grant Likely <grant.likely@linaro.org>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

commit a4dfb8c41043dd6c2b9defbe846c44389c4b6f02
Author: Sandeep Nair <sandeep_n@ti.com>
Date:   Fri Feb 28 10:47:50 2014 -0500

    Documentation: dt: soc: add Keystone Navigator QMSS bindings
    
    The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
    the main hardware sub system which forms the backbone of the Keystone
    Multi-core Navigator. QMSS consist of queue managers, packed-data structure
    processors(PDSP), linking RAM, descriptor pools and infrastructure
    Packet DMA.
    
    The Queue Manager is a hardware module that is responsible for accelerating
    management of the packet queues. Packets are queued/de-queued by writing or
    reading descriptor address to a particular memory mapped location. The PDSPs
    perform QMSS related functions like accumulation, QoS, or event management.
    Linking RAM registers are used to link the descriptors which are stored in
    descriptor RAM. Descriptor RAM is configurable as internal or external memory.
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Kumar Gala <galak@codeaurora.org>
    Cc: Olof Johansson <olof@lixom.net>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Grant Likely <grant.likely@linaro.org>
    Cc: Rob Herring <robh+dt@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

commit 382a9c9adc1cd540f5b714b65db315fc1c0b553d
Author: Quentin Lambert <lambert.quentin@gmail.com>
Date:   Sun Sep 7 20:02:04 2014 +0200

    PCI: Add space before open parenthesis
    
    Add space before open parenthesis as is conventional.
    
    No functional change.
    
    [bhelgaas: fix a few more in ibmphp, shpchp]
    Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit fe6ce32189136370b3d236d1c32ab812b93cd0d8
Author: Yijing Wang <wangyijing@huawei.com>
Date:   Wed Sep 24 11:09:59 2014 +0800

    PCI/MSI: Rename __read_msi_msg() to read_msi_msg()
    
    Rename __read_msi_msg() to read_msi_msg().
    
    No functional change.
    
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit c2eb2dc3461e522d6452e1f74e36194633d4db0d
Author: Yijing Wang <wangyijing@huawei.com>
Date:   Wed Sep 24 11:09:53 2014 +0800

    PCI/MSI: Remove unused read_msi_msg()
    
    Now no one uses read_msi_msg(), so remove it.
    
    No functional change.
    
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit 11c013fd8afbc7c6b2e15608ed5fc2c249552998
Author: Yijing Wang <wangyijing@huawei.com>
Date:   Wed Sep 24 11:09:45 2014 +0800

    MSI/powerpc: Use __read_msi_msg() instead of read_msi_msg()
    
    rtas_setup_msi_irqs() already has the struct msi_desc pointer required by
    __read_msi_msg(), so call it directly instead of having read_msi_msg() look
    it up from the IRQ.
    
    No functional change.
    
    [bhelgaas: changelog]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Michael Ellerman <mpe@ellerman.id.au>
    CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    CC: linuxppc-dev@lists.ozlabs.org

commit eeeda4cd06e828b331b15741a204ff9f5874d28d
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Wed Sep 24 13:30:12 2014 +0100

    x86/relocs: Make per_cpu_load_addr static
    
    per_cpu_load_addr is only used for 64-bit relocations, but is
    declared in both configurations of relocs.c - with different
    types.  This has undefined behaviour in general.  GNU ld is
    documented to use the larger size in this case, but other tools
    may differ and some warn about this.
    
    References: https://bugs.debian.org/748577
    Reported-by: Michael Tautschnig <mt@debian.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: 748577@bugs.debian.org
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1411561812.3659.23.camel@decadent.org.uk
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 212be3b2320bcf33eff648bc4e1f0edbf4d90acf
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Sun Sep 21 20:42:32 2014 +0200

    x86/lib/Makefile: Remove the unnecessary "+= thunk_64.o"
    
    Trivial. We have "lib-y += thunk_$(BITS).o" at the start, no
    need to add thunk_64.o if !CONFIG_X86_32.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Andy Lutomirski <luto@amacapital.net>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20140921184232.GB23727@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 0ad6e3c5199be12c9745da8f8b9e3c9f8066c235
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Sun Sep 21 20:41:53 2014 +0200

    x86: Speed up ___preempt_schedule*() by using THUNK helpers
    
    ___preempt_schedule() does SAVE_ALL/RESTORE_ALL but this is
    suboptimal, we do not need to save/restore the callee-saved
    register. And we already have arch/x86/lib/thunk_*.S which
    implements the similar asm wrappers, so it makes sense to
    redefine ___preempt_schedule() as "THUNK ..." and remove
    preempt.S altogether.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Reviewed-by: Andy Lutomirski <luto@amacapital.net>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20140921184153.GA23727@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 03bd4e1f7265548832a76e7919a81f3137c44fd1
Author: Wanpeng Li <wanpeng.li@linux.intel.com>
Date:   Wed Sep 24 16:38:05 2014 +0800

    sched: Fix unreleased llc_shared_mask bit during CPU hotplug
    
    The following bug can be triggered by hot adding and removing a large number of
    xen domain0's vcpus repeatedly:
    
    	BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [..] find_busiest_group
    	PGD 5a9d5067 PUD 13067 PMD 0
    	Oops: 0000 [#3] SMP
    	[...]
    	Call Trace:
    	load_balance
    	? _raw_spin_unlock_irqrestore
    	idle_balance
    	__schedule
    	schedule
    	schedule_timeout
    	? lock_timer_base
    	schedule_timeout_uninterruptible
    	msleep
    	lock_device_hotplug_sysfs
    	online_store
    	dev_attr_store
    	sysfs_write_file
    	vfs_write
    	SyS_write
    	system_call_fastpath
    
    Last level cache shared mask is built during CPU up and the
    build_sched_domain() routine takes advantage of it to setup
    the sched domain CPU topology.
    
    However, llc_shared_mask is not released during CPU disable,
    which leads to an invalid sched domainCPU topology.
    
    This patch fix it by releasing the llc_shared_mask correctly
    during CPU disable.
    
    Yasuaki also reported that this can happen on real hardware:
    
      https://lkml.org/lkml/2014/7/22/1018
    
    His case is here:
    
    	==
    	Here is an example on my system.
    	My system has 4 sockets and each socket has 15 cores and HT is
    	enabled. In this case, each core of sockes is numbered as
    	follows:
    
    		 | CPU#
    	Socket#0 | 0-14 , 60-74
    	Socket#1 | 15-29, 75-89
    	Socket#2 | 30-44, 90-104
    	Socket#3 | 45-59, 105-119
    
    	Then llc_shared_mask of CPU#30 has 0x3fff80000001fffc0000000.
    
    	It means that last level cache of Socket#2 is shared with
    	CPU#30-44 and 90-104.
    
    	When hot-removing socket#2 and #3, each core of sockets is
    	numbered as follows:
    
    		 | CPU#
    	Socket#0 | 0-14 , 60-74
    	Socket#1 | 15-29, 75-89
    
    	But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30
    	remains having 0x3fff80000001fffc0000000.
    
    	After that, when hot-adding socket#2 and #3, each core of
    	sockets is numbered as follows:
    
    		 | CPU#
    	Socket#0 | 0-14 , 60-74
    	Socket#1 | 15-29, 75-89
    	Socket#2 | 30-59
    	Socket#3 | 90-119
    
    	Then llc_shared_mask of CPU#30 becomes
    	0x3fff8000fffffffc0000000. It means that last level cache of
    	Socket#2 is shared with CPU#30-59 and 90-104. So the mask has
    	the wrong value.
    
    Signed-off-by: Wanpeng Li <wanpeng.li@linux.intel.com>
    Tested-by: Linn Crosetto <linn@hp.com>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Toshi Kani <toshi.kani@hp.com>
    Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Cc: <stable@vger.kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Steven Rostedt <srostedt@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1411547885-48165-1-git-send-email-wanpeng.li@linux.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 24832b4de315ad00e5430a53772750dfcf18514d
Author: Minghuan Lian <Minghuan.Lian@freescale.com>
Date:   Tue Sep 23 22:28:59 2014 +0800

    PCI: designware: Add get_msi_data() to pcie_host_ops
    
    Add a struct pcie_host_ops .get_msi_data() method for platforms to return
    their special MSI message data.
    
    Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Mohit KUMAR <mohit.kumar@st.com>

commit ee1b5b165c0a2f04d2107e634e51f05d0eb107de
Author: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Date:   Wed Sep 24 00:26:24 2014 +0100

    x86/intel/quark: Switch off CR4.PGE so TLB flush uses CR3 instead
    
    Quark x1000 advertises PGE via the standard CPUID method
    PGE bits exist in Quark X1000's PTEs. In order to flush
    an individual PTE it is necessary to reload CR3 irrespective
    of the PTE.PGE bit.
    
    See Quark Core_DevMan_001.pdf section 6.4.11
    
    This bug was fixed in Galileo kernels, unfixed vanilla kernels are expected to
    crash and burn on this platform.
    
    Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/1411514784-14885-1-git-send-email-pure.logic@nexus-software.ie
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 450e344e421b9f555261a2d97952d9e71d4cb082
Author: Minghuan Lian <Minghuan.Lian@freescale.com>
Date:   Tue Sep 23 22:28:58 2014 +0800

    PCI: designware: Rename get_msi_data() to get_msi_addr()
    
    The struct pcie_host_ops .get_msi_data() method returns the MSI message
    address.  To accurately express its purpose, rename it to .get_msi_addr().
    
    Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Mohit KUMAR <mohit.kumar@st.com>

commit 0c61ea77cceafd1134225099961c2df0866b500f
Author: Minghuan Lian <Minghuan.Lian@fre…
3ade1b1
@aryabinin aryabinin referenced this pull request in aryabinin/linux Oct 3, 2014
mmotm auto import linux-next
GIT 6fe676b243e5a0cb4cc4d9a4b094de8db0cdbf74

commit e500f488c27659bb6f5d313b336621f3daa67701
Author: Fabian Frederick <fabf@skynet.be>
Date:   Wed Oct 1 06:52:06 2014 +0200

    net/dccp/ccid.c: add __init to ccid_activate
    
    ccid_activate is only called by __init ccid_initialize_builtins in same module.
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 0c5b8a46294d43fc63788839d3c18de0961ec1bc
Author: Fabian Frederick <fabf@skynet.be>
Date:   Wed Oct 1 06:48:03 2014 +0200

    net/dccp/proto.c: add __init to dccp_mib_init
    
    dccp_mib_init is only called by __init dccp_init in same module.
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 082f58ac4a48d3f5cb4597232cb2ac6823a96f43
Author: Quinn Tran <quinn.tran@qlogic.com>
Date:   Thu Sep 25 06:22:28 2014 -0400

    target: Fix queue full status NULL pointer for SCF_TRANSPORT_TASK_SENSE
    
    During temporary resource starvation at lower transport layer, command
    is placed on queue full retry path, which expose this problem.  The TCM
    queue full handling of SCF_TRANSPORT_TASK_SENSE currently sends the same
    cmd twice to lower layer.  The 1st time led to cmd normal free path.
    The 2nd time cause Null pointer access.
    
    This regression bug was originally introduced v3.1-rc code in the
    following commit:
    
    commit e057f53308a5f071556ee80586b99ee755bf07f5
    Author: Christoph Hellwig <hch@infradead.org>
    Date:   Mon Oct 17 13:56:41 2011 -0400
    
        target: remove the transport_qf_callback se_cmd callback
    
    Signed-off-by: Quinn Tran <quinn.tran@qlogic.com>
    Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
    Cc: <stable@vger.kernel.org> # v3.1+
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit db3a99b9921f27fe71ca8c0f218ee810e0e7fb69
Author: Joern Engel <joern@logfs.org>
Date:   Tue Sep 16 16:23:19 2014 -0400

    qla_target: rearrange struct qla_tgt_prm
    
    On most (non-x86) 64bit platforms this will remove 8 padding bytes
    from the structure.
    
    Signed-off-by: Joern Engel <joern@logfs.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit f9b6721a9cef94908467abf7a2cacbd15a7d23cb
Author: Joern Engel <joern@logfs.org>
Date:   Tue Sep 16 16:23:18 2014 -0400

    qla_target: improve qlt_unmap_sg()
    
    Remove the inline attribute.  Modern compilers ignore it and the
    function has grown beyond where inline made sense anyway.
    Remove the BUG_ON(!cmd->sg_mapped), and instead return if sg_mapped is
    not set.  Every caller is doing this check, so we might as well have it
    in one place instead of four.
    
    Signed-off-by: Joern Engel <joern@logfs.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 55a9066fffd2f533e7ed434b072469ef09d6c476
Author: Joern Engel <joern@logfs.org>
Date:   Tue Sep 16 16:23:15 2014 -0400

    qla_target: make some global functions static
    
    Also removes the declarations from the header - including two
    declarations without function definitions or callers.
    
    Signed-off-by: Joern Engel <joern@logfs.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit c57010420654aca179c500f61e86315a337244ca
Author: Joern Engel <joern@logfs.org>
Date:   Tue Sep 16 16:23:14 2014 -0400

    qla_target: remove unused parameter
    
    Signed-off-by: Joern Engel <joern@logfs.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit f81ccb489a7a641c1bed41b49cf8d72c199c68d5
Author: Joern Engel <joern@logfs.org>
Date:   Tue Sep 16 16:23:13 2014 -0400

    target: simplify core_tmr_abort_task
    
    list_for_each_entry_safe is necessary if list objects are deleted from
    the list while traversing it.  Not the case here, so we can use the base
    list_for_each_entry variant.
    
    Signed-off-by: Joern Engel <joern@logfs.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 33940d09937276cd3c81f2874faf43e37c2db0e2
Author: Joern Engel <joern@logfs.org>
Date:   Tue Sep 16 16:23:12 2014 -0400

    target: encapsulate smp_mb__after_atomic()
    
    The target code has a rather generous helping of smp_mb__after_atomic()
    throughout the code base.  Most atomic operations were followed by one
    and none were preceded by smp_mb__before_atomic(), nor accompanied by a
    comment explaining the need for a barrier.
    
    Instead of trying to prove for every case whether or not it is needed,
    this patch introduces atomic_inc_mb() and atomic_dec_mb(), which
    explicitly include the memory barriers before and after the atomic
    operation.  For now they are defined in a target header, although they
    could be of general use.
    
    Most of the existing atomic/mb combinations were replaced by the new
    helpers.  In a few cases the atomic was sandwiched in
    spin_lock/spin_unlock and I simply removed the barrier.
    
    I suspect that in most cases the correct conversion would have been to
    drop the barrier.  I also suspect that a few cases exist where a) the
    barrier was necessary and b) a second barrier before the atomic would
    have been necessary and got added by this patch.
    
    Signed-off-by: Joern Engel <joern@logfs.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 74ed7e62289dc6d388996d7c8f89c2e7e95b9657
Author: Joern Engel <joern@logfs.org>
Date:   Tue Sep 16 16:23:11 2014 -0400

    target: remove some smp_mb__after_atomic()s
    
    atomic_inc_return() already does an implicit memory barrier and the
    second case was moved from an atomic to a plain flag operation.  If a
    barrier were needed in the second case, it would have to be smp_mb(),
    not a variant optimized away for x86 and other architectures.
    
    Signed-off-by: Joern Engel <joern@logfs.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 8f83269048628d7b139dacbfc6cc97befcbdd2e9
Author: Joern Engel <joern@logfs.org>
Date:   Tue Sep 16 16:23:10 2014 -0400

    target: simplify core_tmr_release_req()
    
    And while at it, do minimal coding style fixes in the area.
    
    Signed-off-by: Joern Engel <joern@logfs.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 9c7d6154bc4b9dfefd580490cdca5f7c72321464
Author: Andy Grover <agrover@redhat.com>
Date:   Mon Jun 30 16:39:46 2014 -0700

    target: Remove core_tpg_release_virtual_lun0 function
    
    Simple and just called from one place.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit cd9d7cbaec8b622eee4edcd8bf481c4047f74915
Author: Andy Grover <agrover@redhat.com>
Date:   Mon Jun 30 16:39:44 2014 -0700

    target: Change core_dev_del_lun to take a se_lun instead of unpacked_lun
    
    Remove core_tpg_pre_dellun entirely, since we don't need to get/check
    a pointer we already have.
    
    Nothing else can return an error, so core_dev_del_lun can return void.
    
    Rename core_tpg_post_dellun to remove_lun - a clearer name, now that
    pre_dellun is gone.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit cc83881f2c57caaf4b14adaffa65595640a59661
Author: Andy Grover <agrover@redhat.com>
Date:   Mon Jun 30 16:39:43 2014 -0700

    target: core_tpg_post_dellun can return void
    
    Nothing in it can raise an error.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 49be17235c0acd96f2ff0fe282867fe3a83f554c
Author: hayeswang <hayeswang@realtek.com>
Date:   Wed Oct 1 13:25:11 2014 +0800

    r8152: disable power cut for RTL8153
    
    The firmware would be clear when the power cut is enabled for
    RTL8153.
    
    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 204c8704128943bf3f8b605f4b40bdc2b6bd89dc
Author: hayeswang <hayeswang@realtek.com>
Date:   Wed Oct 1 13:25:10 2014 +0800

    r8152: remove clearing bp
    
    The xxx_clear_bp() is used to halt the firmware. It only necessary
    for updating the new firmware. Besides, depend on the version of
    the current firmware, it may have problem to halt the firmware
    directly. Finally, halt the firmware would let the firmware code
    useless, and the bugs which are fixed by the firmware would occur.
    
    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit aa55c8e2f7a395dfc9e67fc6637321e19ce9bfe1
Author: Masahiro Yamada <yamada.m@jp.panasonic.com>
Date:   Tue Sep 9 20:02:24 2014 +0900

    kbuild: handle C=... and M=... after entering into build directory
    
    This commit avoids processing C=... and M=... twice
    when O=... is also given.
    
    Besides, we can also remove KBUILD_EXTMOD="$(KBUILD_EXTMOD)"
    in the sub-make target.
    
    Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
    Acked-by: Peter Foley <pefoley2@pefoley.com>
    Signed-off-by: Michal Marek <mmarek@suse.cz>

commit 745a254322c898dadf019342cd7140f7867d2d0f
Author: Masahiro Yamada <yamada.m@jp.panasonic.com>
Date:   Tue Sep 9 20:02:23 2014 +0900

    kbuild: use $(Q) for sub-make target
    
    Since commit 066b7ed9558087a7957a1128f27d7a3462ff117f
    (kbuild: Do not print the build directory with make -s),
    "Q" is defined above the sub-make target.
    
    This commit takes advantage of that and replaces
    "$(if $(KBUILD_VERBOSE:1=),@)" with "$(Q)".
    
    Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
    Acked-by: Peter Foley <pefoley2@pefoley.com>
    Signed-off-by: Michal Marek <mmarek@suse.cz>

commit 7ff525712acf9325e9acdb27bbc93049ea2e850c
Author: Masahiro Yamada <yamada.m@jp.panasonic.com>
Date:   Tue Sep 9 20:02:22 2014 +0900

    kbuild: fake the "Entering directory ..." message more simply
    
    Commit c2e28dc975ea87feed84415006ae143424912ac7
    (kbuild: Print the name of the build directory)
    added a gimmick to show the "Entering directory ...".
    
    Instead of echoing the hard-coded message (that is, we need to know
    the exact message), moving --no-print-directory would be easier.
    
    Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
    Acked-by: Peter Foley <pefoley2@pefoley.com>
    Signed-off-by: Michal Marek <mmarek@suse.cz>

commit 1b0ecb28b0cc216535ce6477d39aa610c3ff68a1
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Tue Sep 30 19:39:37 2014 -0400

    bnx2: Correctly receive full sized 802.1ad fragmes
    
    This driver, similar to tg3, has a check that will
    cause full sized 802.1ad frames to be dropped.  The
    frame will be larger then the standard mtu due to the
    presense of vlan header that has not been stripped.
    The driver should not drop this frame and should process
    it just like it does for 802.1q.
    
    CC: Sony Chacko <sony.chacko@qlogic.com>
    CC: Dept-HSGLinuxNICDev@qlogic.com
    Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 7d3083ee36b51e425b6abd76778a2046906b0fd3
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Tue Sep 30 19:39:36 2014 -0400

    tg3: Allow for recieve of full-size 8021AD frames
    
    When receiving a vlan-tagged frame that still contains
    a vlan header, the length of the packet will be greater
    then MTU+ETH_HLEN since it will account of the extra
    vlan header.  TG3 checks this for the case for 802.1Q,
    but not for 802.1ad.  As a result, full sized 802.1ad
    frames get dropped by the card.
    
    Add a check for 802.1ad protocol when receving full
    sized frames.
    
    Suggested-by: Prashant Sreedharan <prashant@broadcom.com>
    CC: Prashant Sreedharan <prashant@broadcom.com>
    CC: Michael Chan <mchan@broadcom.com>
    Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 1e918876853aa85435e0f17fd8b4a92dcfff53d6
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Oct 1 13:38:03 2014 +0200

    r8169: add support for Byte Queue Limits
    
    tested on RTL8168d/8111d model using 'super_netperf 40' with TCP/UDP_STREAM.
    
    Output of
    while true; do
        for n in inflight limit; do
              echo -n $n\ ; cat $n;
        done;
        sleep 1;
    done
    
    during netperf run, 100mbit peer:
    
    inflight 0
    limit 3028
    inflight 6056
    limit 4542
    
    [ trimmed output for brevity, no limit/inflight changes during
      test steady-state ]
    
    limit 4542
    inflight 3028
    limit 6122
    inflight 0
    limit 6122
    [ changed cable to 1gbit peer, restart netperf ]
    inflight 37850
    limit 36336
    inflight 33308
    limit 31794
    inflight 33308
    limit 31794
    inflight 27252
    limit 25738
    [ again, no changes during test ]
    inflight 27252
    limit 25738
    inflight 0
    limit 28766
    [ change cable to 100mbit peer, restart netperf ]
    limit 28766
    inflight 27370
    limit 28766
    inflight 4542
    limit 5990
    inflight 6056
    limit 4542
    [ .. ]
    inflight 6056
    limit 4542
    inflight 0
    
    [end of test]
    
    Cc: Francois Romieu <romieu@fr.zoreil.com>
    Cc: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Tom Herbert <therbert@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d0bf4a9e92b9a93ffeeacbd7b6cb83e0ee3dc2ef
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Sep 29 13:29:15 2014 -0700

    net: cleanup and document skb fclone layout
    
    Lets use a proper structure to clearly document and implement
    skb fast clones.
    
    Then, we might experiment more easily alternative layouts.
    
    This patch adds a new skb_fclone_busy() helper, used by tcp and xfrm,
    to stop leaking of implementation details.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 0f1ca65ee50df042051e8fa3a14f73b0c71d45b9
Author: Arianna Avanzini <avanzini.arianna@gmail.com>
Date:   Fri Aug 22 13:20:02 2014 +0200

    xen, blkfront: factor out flush-related checks from do_blkif_request()
    
    This commit factors out some checks related to the request insertion
    path, which can be done in an function instead of by itself.
    
    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 61cecca865280bef4f8a9748d0a9afa5df351ac2
Author: Roger Pau Monné <roger.pau@citrix.com>
Date:   Mon Sep 15 11:55:27 2014 +0200

    xen-blkback: fix leak on grant map error path
    
    Fix leaking a page when a grant mapping has failed.
    
    CC: stable@vger.kernel.org
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reported-and-Tested-by: Tao Chen <boby.chen@huawei.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 12ea729645ace01e08f9654df155622898d3aae6
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Mon Sep 8 15:21:33 2014 +0200

    xen/blkback: unmap all persistent grants when frontend gets disconnected
    
    blkback does not unmap persistent grants when frontend goes to Closed
    state (e.g. when blkfront module is being removed). This leads to the
    following in guest's dmesg:
    
    [  343.243825] xen:grant_table: WARNING: g.e. 0x445 still in use!
    [  343.243825] xen:grant_table: WARNING: g.e. 0x42a still in use!
    ...
    
    When load module -> use device -> unload module sequence is performed multiple times
    it is possible to hit BUG() condition in blkfront module:
    
    [  343.243825] kernel BUG at drivers/block/xen-blkfront.c:954!
    [  343.243825] invalid opcode: 0000 [#1] SMP
    [  343.243825] Modules linked in: xen_blkfront(-) ata_generic pata_acpi [last unloaded: xen_blkfront]
    ...
    [  343.243825] Call Trace:
    [  343.243825]  [<ffffffff814111ef>] ? unregister_xenbus_watch+0x16f/0x1e0
    [  343.243825]  [<ffffffffa0016fbf>] blkfront_remove+0x3f/0x140 [xen_blkfront]
    ...
    [  343.243825] RIP  [<ffffffffa0016aae>] blkif_free+0x34e/0x360 [xen_blkfront]
    [  343.243825]  RSP <ffff88001eb8fdc0>
    
    We don't need to keep these grants if we're disconnecting as frontend might already
    forgot about them. Solve the issue by moving xen_blkbk_free_caches() call from
    xen_blkif_free() to xen_blkif_disconnect().
    
    Now we can see the following:
    [  928.590893] xen:grant_table: WARNING: g.e. 0x587 still in use!
    [  928.591861] xen:grant_table: WARNING: g.e. 0x372 still in use!
    ...
    [  929.592146] xen:grant_table: freeing g.e. 0x587
    [  929.597174] xen:grant_table: freeing g.e. 0x372
    ...
    
    Backend does not keep persistent grants any more, reconnect works fine.
    
    CC: stable@vger.kernel.org
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit b248230c34970a6c1c17c591d63b464e8d2cfc33
Author: Yuchung Cheng <ycheng@google.com>
Date:   Mon Sep 29 13:20:38 2014 -0700

    tcp: abort orphan sockets stalling on zero window probes
    
    Currently we have two different policies for orphan sockets
    that repeatedly stall on zero window ACKs. If a socket gets
    a zero window ACK when it is transmitting data, the RTO is
    used to probe the window. The socket is aborted after roughly
    tcp_orphan_retries() retries (as in tcp_write_timeout()).
    
    But if the socket was idle when it received the zero window ACK,
    and later wants to send more data, we use the probe timer to
    probe the window. If the receiver always returns zero window ACKs,
    icsk_probes keeps getting reset in tcp_ack() and the orphan socket
    can stall forever until the system reaches the orphan limit (as
    commented in tcp_probe_timer()). This opens up a simple attack
    to create lots of hanging orphan sockets to burn the memory
    and the CPU, as demonstrated in the recent netdev post "TCP
    connection will hang in FIN_WAIT1 after closing if zero window is
    advertised." http://www.spinics.net/lists/netdev/msg296539.html
    
    This patch follows the design in RTO-based probe: we abort an orphan
    socket stalling on zero window when the probe timer reaches both
    the maximum backoff and the maximum RTO. For example, an 100ms RTT
    connection will timeout after roughly 153 seconds (0.3 + 0.6 +
    .... + 76.8) if the receiver keeps the window shut. If the orphan
    socket passes this check, but the system already has too many orphans
    (as in tcp_out_of_resources()), we still abort it but we'll also
    send an RST packet as the connection may still be active.
    
    In addition, we change TCP_USER_TIMEOUT to cover (life or dead)
    sockets stalled on zero-window probes. This changes the semantics
    of TCP_USER_TIMEOUT slightly because it previously only applies
    when the socket has pending transmission.
    
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Reported-by: Andrey Dmitrov <andrey.dmitrov@oktetlabs.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 3edfe0030bb7a82dab2a30a29ea6e1800e600c4b
Author: Helge Deller <deller@gmx.de>
Date:   Wed Oct 1 22:11:01 2014 +0200

    parisc: Fix serial console for machines with serial port on superio chip
    
    Fix the serial console on machines where the serial port is located on
    the SuperIO chip.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: Peter Hurley <peter@hurleysoftware.com>

commit baf378126b08474de2e2428b16e62a69df0339d9
Author: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date:   Wed Oct 1 14:07:39 2014 -0600

    rsxx: Remove deprecated IRQF_DISABLED
    
    This removes the use of the IRQF_DISABLED flag
    from drivers/block/rsxx/core.c
    
    It's a NOOP since 2.6.35 and it will be removed one day.
    
    Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
    Acked-by Philip Kelleher <pjk1939@linux.vnet.ibm.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>

commit cb57659a15c6c0576493cc8a10474ce7ffd44eb3
Author: Fabian Frederick <fabf@skynet.be>
Date:   Wed Oct 1 19:30:03 2014 +0200

    cipso: add __init to cipso_v4_cache_init
    
    cipso_v4_cache_init is only called by __init cipso_v4_init
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 57a02c39c1c20ed03a86f8014c11a8c18b94cac3
Author: Fabian Frederick <fabf@skynet.be>
Date:   Wed Oct 1 19:18:57 2014 +0200

    inet: frags: add __init to ip4_frags_ctl_register
    
    ip4_frags_ctl_register is only called by __init ipfrag_init
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 47d7a88c188f06ffaea3a539f84fe10cb4e77787
Author: Fabian Frederick <fabf@skynet.be>
Date:   Wed Oct 1 18:27:50 2014 +0200

    tcp: add __init to tcp_init_mem
    
    tcp_init_mem is only called by __init tcp_init.
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ee7a1beb9759c94aea67dd887faf5e447a5c6710
Author: Chun-Hao Lin <hau@realtek.com>
Date:   Wed Oct 1 23:17:21 2014 +0800

    r8169:call "rtl8168_driver_start" "rtl8168_driver_stop" only when hardware dash function is enabled
    
    These two functions are used to inform dash firmware that driver is been
    brought up or brought down. So call these two functions only when hardware dash
    function is enabled.
    
    Signed-off-by: Chun-Hao Lin <hau@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 2a9b4d9670e71784896d95c41c9b0acd50db1dbb
Author: Chun-Hao Lin <hau@realtek.com>
Date:   Wed Oct 1 23:17:20 2014 +0800

    r8169:modify the behavior of function "rtl8168_oob_notify"
    
    In function "rtl8168_oob_notify", using function "rtl_eri_write" to access
    eri register 0xe8, instead of using MAC register "ERIDR" and "ERIAR" to
    access it.
    
    For using function "rtl_eri_write" in function "rtl8168_oob_notify", need to
    move down "rtl8168_oob_notify" related functions under the function
    "rtl_eri_write".
    
    Signed-off-by: Chun-Hao Lin <hau@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 2f8c040ce6791ef0477e6d59768ee3d5fd0df0fd
Author: Chun-Hao Lin <hau@realtek.com>
Date:   Wed Oct 1 23:17:19 2014 +0800

    r8169:change the name of function "r8168dp_check_dash" to "r8168_check_dash"
    
    DASH function not only RTL8168DP can support, but also RTL8168EP.
    So change the name of function "r8168dp_check_dash" to "r8168_check_dash".
    
    Signed-off-by: Chun-Hao Lin <hau@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 706123d06c18b55da5e9da21e2d138ee789bf8f4
Author: Chun-Hao Lin <hau@realtek.com>
Date:   Wed Oct 1 23:17:18 2014 +0800

    r8169:change the name of function"rtl_w1w0_eri"
    
    Change the name of function "rtl_w1w0_eri" to "rtl_w0w1_eri".
    
    In this function, the local variable "val" is "write zeros then write ones".
    Please see below code.
    
    (val & ~m) | p
    
    In this patch, change the function name from "xx_w1w0_xx" to "xx_w0w1_xx".
    The changed function name is more suitable for it's behavior.
    
    Signed-off-by: Chun-Hao Lin <hau@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 7656442824f6174b56a19c664fe560972df56ad4
Author: Chun-Hao Lin <hau@realtek.com>
Date:   Wed Oct 1 23:17:17 2014 +0800

    r8169:for function "rtl_w1w0_phy" change its name and behavior
    
    Change function name from "rtl_w1w0_phy" to "rtl_w0w1_phy".
    And its behavior from "write ones then write zeros" to
    "write zeros then write ones".
    
    In Realtek internal driver, bitwise operations are almost "write zeros then
    write ones". For easy to port hardware parameters from Realtek internal driver
    to Linux kernal driver "r8169", we would like to change this function's
    behavior and its name.
    
    Signed-off-by: Chun-Hao Lin <hau@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ac85bcdbc0ffd3903d6db4abcd769ecacf98605b
Author: Chun-Hao Lin <hau@realtek.com>
Date:   Wed Oct 1 23:17:16 2014 +0800

    r8169:add more chips to support magic packet v2
    
    For RTL8168F RTL8168FB RTL8168G RTL8168GU RTL8411 RTL8411B RTL8402 RTL8107E,
    the magic packet enable bit is changed to eri 0xde bit0.
    
    In this patch, change magic packet enable bit of these chips to eri 0xde bit0.
    
    Signed-off-by: Chun-Hao Lin <hau@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 89cceb2729c752e6ff9b3bc8650a70f29884f116
Author: Chun-Hao Lin <hau@realtek.com>
Date:   Wed Oct 1 23:17:15 2014 +0800

    r8169:add support more chips to get mac address from backup mac address register
    
    RTL8168FB RTL8168G RTL8168GU RTL8411 RTL8411B RTL8106EUS RTL8402 can
    support get mac address from backup mac address register.
    
    Signed-off-by: Chun-Hao Lin <hau@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 42fde7371035144037844f41bd16950de9912bdb
Author: Chun-Hao Lin <hau@realtek.com>
Date:   Wed Oct 1 23:17:14 2014 +0800

    r8169:add disable/enable RTL8411B pll function
    
    RTL8411B can support disable/enable pll function.
    
    Signed-off-by: Chun-Hao Lin <hau@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit b8e5e6ad7115befef13a4493f1d2b8e438abc058
Author: Chun-Hao Lin <hau@realtek.com>
Date:   Wed Oct 1 23:17:13 2014 +0800

    r8169:add disable/enable RTL8168G pll function
    
    RTL8168G also can disable/enable pll function.
    
    Signed-off-by: Chun-Hao Lin <hau@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 05b9687bb3606190304f08c2e4cd63de8717e30b
Author: Chun-Hao Lin <hau@realtek.com>
Date:   Wed Oct 1 23:17:12 2014 +0800

    r8169:change uppercase number to lowercase number
    
    Signed-off-by: Chun-Hao Lin <hau@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a29c9c43bb633a9965909cd548879fee4aa789a4
Author: David L Stevens <david.stevens@oracle.com>
Date:   Wed Oct 1 11:05:27 2014 -0400

    sunvnet: fix potential NULL pointer dereference
    
    One of the error cases for vnet_start_xmit()'s "out_dropped" label
    is port == NULL, so only mess with port->clean_timer when port is not NULL.
    
    Signed-off-by: David L Stevens <david.stevens@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e506d405ac7d34d03996c97ac68aa2ac010be64a
Author: Thierry Reding <treding@nvidia.com>
Date:   Wed Oct 1 13:59:00 2014 +0200

    net: dsa: Fix build warning for !PM_SLEEP
    
    The dsa_switch_suspend() and dsa_switch_resume() functions are only used
    when PM_SLEEP is enabled, so they need #ifdef CONFIG_PM_SLEEP protection
    to avoid a compiler warning.
    
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 84ac1f2ca41f5888cc995944c073a5220f3ed549
Author: Tanmay Inamdar <tinamdar@apm.com>
Date:   Fri Sep 26 14:08:25 2014 -0700

    arm64: dts: Add APM X-Gene PCIe device tree nodes
    
    Add the device tree nodes for APM X-Gene PCIe host controller and PCIe
    clock interface.  Since X-Gene SOC supports maximum 5 ports, 5 dts nodes
    are added.
    
    Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit 2896e4418b17363f211e084471b589e3c06a7248
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed Oct 1 13:01:35 2014 -0600

    PCI: xgene: Add APM X-Gene PCIe driver
    
    Add the AppliedMicro X-Gene SOC PCIe host controller driver.  The X-Gene
    PCIe controller supports up to 8 lanes and GEN3 speed.  The X-Gene SOC
    supports up to 5 PCIe ports.
    
    [bhelgaas: folded in MAINTAINERS and bindings updates]
    Tested-by: Ming Lei <ming.lei@canonical.com>
    Tested-by: Dann Frazier <dann.frazier@canonical.com>
    Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com> (driver)

commit 3c87dcbfb36ce6d3d9087f0163c02ba5690d9a85
Author: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Date:   Wed Oct 1 11:01:17 2014 +0200

    net: ll_temac: Remove unnecessary ether_setup after alloc_etherdev
    
    Calling ether_setup is redundant since alloc_etherdev calls it.
    
    Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 8493ecca74a7b4a66e19676de1a0f14194179941
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Wed Oct 1 11:59:47 2014 -0400

    HID: uHID: fix excepted report type
    
    When uhid_get_report() or uhid_set_report() are called, they emit on the
    char device a UHID_GET_REPORT or UHID_SET_REPORT message. Then, the
    protocol says that the user space asnwers with UHID_GET_REPORT_REPLY
    or UHID_SET_REPORT_REPLY.
    
    Unfortunatelly, the current code waits for an event of type UHID_GET_REPORT
    or UHID_SET_REPORT instead of the reply one.
    Add 1 to UHID_GET_REPORT or UHID_SET_REPORT to actually wait for the
    reply, and validate the reply.
    
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit c8df6ac9452e8f47a6f660993c526d13e858a6f3
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Tue Sep 30 18:36:27 2014 +0200

    PCI: designware: Remove open-coded bitmap operations
    
    Replace them by using the standard kernel bitmap ops.  No functional
    change, but makes the code a lot cleaner.
    
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Pratyush Anand <pratyush.anand@st.com>
    Acked-by: Jingoo Han <jg1.han@samsung.com>

commit 2199f0608864cf4e8c93d37842a5ee50c8d79843
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Mar 28 15:51:56 2014 -0400

    dm crypt: sort writes
    
    Write requests are sorted in a red-black tree structure and are
    submitted in the sorted order.
    
    In theory the sorting should be performed by the underlying disk
    scheduler, however, in practice the disk scheduler only accepts and
    sorts a finite number of requests.  To allow the sorting of all
    requests, dm-crypt needs to implement its own own sorting.
    
    The overhead associated with rbtree-based sorting is considered
    negligible so it is not used conditionally.  Even on SSD sorting can be
    beneficial since in-order request dispatch promotes lower latency IO
    completion to the upper layers.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 648fee35be4c75667aa18bf513f7e7e65c01640b
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Mar 28 15:51:56 2014 -0400

    dm crypt: offload writes to thread
    
    Submitting write bios directly in the encryption thread caused serious
    performance degradation.  On a multiprocessor machine, encryption requests
    finish in a different order than they were submitted.  Consequently, write
    requests would be submitted in a different order and it could cause severe
    performance degradation.
    
    Move the submission of write requests to a separate thread so that the
    requests can be sorted before submitting.  But this commit improves
    dm-crypt performance even without having dm-crypt perform request
    sorting (in particular it enables IO schedulers like CFQ to sort more
    effectively).
    
    Note: it is required that a previous commit ("dm crypt: don't allocate
    pages for a partial request") be applied before applying this patch.
    Otherwise, this commit could introduce a crash.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 4a0d7e0464226eee625a5b77484c339334453882
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Mar 28 15:51:55 2014 -0400

    dm crypt: use unbound workqueue for request processing
    
    Use unbound workqueue so that work is automatically balanced between
    available CPUs.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 72bfc40ca3b393cb0bc6b5e2ce364e6c6ce0f390
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu May 29 14:18:12 2014 -0400

    dm crypt: remove io_pending refcount member from dm_crypt_io
    
    Commit "dm crypt: don't allocate pages for a partial request" changed
    the code to allocate all pages for one request.  There is always just
    one pending request, so the io_pending refcount may be removed.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 42196fec8945cc84c032b7f59deaffee82036245
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Mar 28 15:51:56 2014 -0400

    dm crypt: remove unused io_pool and _crypt_io_pool
    
    The previous commits ("dm crypt: use per-bio data") and ("dm crypt:
    don't allocate pages for a partial request") stopped using the
    io_pool slab mempool and backing _crypt_io_pool kmem cache.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit ebfda24b1e1bf483accdb900f8625151d8f01383
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Mar 28 15:51:56 2014 -0400

    dm crypt: avoid deadlock in mempools
    
    Fix a theoretical deadlock introduced in the previous commit ("dm crypt:
    don't allocate pages for a partial request").
    
    The function crypt_alloc_buffer may be called concurrently.  If we allocate
    from the mempool concurrently, there is a possibility of deadlock.  For
    example, if we have mempool of 256 pages, two processes, each wanting
    256, pages allocate from the mempool concurrently, it may deadlock in a
    situation where both processes have allocated 128 pages and the mempool
    is exhausted.
    
    In order to avoid such a scenario, we allocate the pages under a mutex.
    
    In order to not degrade performance with excessive locking, we try
    non-blocking allocations without a mutex first and if it fails, we
    fallback to a blocking allocation with a mutex.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit b9ea7cb3fb237078be400522880932008c630fb7
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Mar 28 15:51:56 2014 -0400

    dm crypt: don't allocate pages for a partial request
    
    Change crypt_alloc_buffer so that it only ever allocates pages for a
    full request.
    
    This change is a prerequisite for the commit "dm crypt: offload writes
    to thread".  Which implies this change is effectively required for the
    upcoming cpu parallelization changes.
    
    But this change simplifies the dm-crypt code at the expense of reduced
    throughput in low memory conditions (where allocation for a partial
    request is most useful).
    
    This change also enables the removal of the io_pending refcount.
    
    Note: the next commit ("dm-crypt: avoid deadlock in mempools") is needed
    to fix a theoretical deadlock.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 117cd3e12232afea97dd31489fbde8888ad22b3e
Author: Heinz Mauelshagen <heinzm@redhat.com>
Date:   Wed Sep 24 17:47:19 2014 +0200

    dm raid: add discard support for RAID levels 4, 5 and 6
    
    In case of RAID levels 4, 5 and 6 we have to verify each RAID members'
    ability to zero data on discards to avoid stripe data corruption -- if
    discard_zeroes_data is not set for each RAID member discard support must
    be disabled.
    
    Also add an 'ignore_discard' table argument to the target in order to
    ignore discard processing completely on a RAID array, hence not passing
    down discards to MD personalities.
    
    This 'ignore_discard' control provides the ability to:
    - prohibit discards in case of _potential_ data corruptions in RAID4/5/6
      (e.g. if ability to zero data on discard is flawed in a RAID member)
    - avoid discard processing overhead
    
    Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 04c308f43a90a9b3b84c344b324d6af29288da05
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Oct 1 13:29:48 2014 -0400

    dm bufio: when done scanning return from __scan immediately
    
    When __scan frees the required number of buffer entries that the
    shrinker requested (nr_to_scan becomes zero) it must return.  Before
    this fix the __scan code exited only the inner loop and continued in the
    outer loop.
    
    Also, move dm_bufio_cond_resched to __scan's inner loop, so that
    iterating the bufio client's lru lists doesn't result in scheduling
    latency.
    
    Reported-by: Joe Thornber <thornber@redhat.com>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org # 3.2+

commit 5ec094057c7df5ff80f5e7fe282f47ad205fb976
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Sep 23 14:38:28 2014 -0600

    PCI/MSI: Remove unnecessary temporary variable
    
    The only use of "status" is to hold a value which is immediately returned,
    so just return and remove the variable directly.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit 56b72b40957947f7c08771f030102351d4c906df
Author: Yijing Wang <wangyijing@huawei.com>
Date:   Mon Sep 29 18:35:16 2014 -0600

    PCI/MSI: Use __write_msi_msg() instead of write_msi_msg()
    
    default_restore_msi_irq() already has the struct msi_desc pointer required
    by __write_msi_msg(), so call it directly instead of having write_msi_msg()
    look it up from the IRQ.
    
    No functional change.
    
    [bhelgaas: split into separate patch]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit 1e8f4cc82eded0c3c97ef6e2f119782e42deda35
Author: Yijing Wang <wangyijing@huawei.com>
Date:   Wed Sep 24 11:09:45 2014 +0800

    MSI/powerpc: Use __read_msi_msg() instead of read_msi_msg()
    
    rtas_setup_msi_irqs() already has the struct msi_desc pointer required by
    __read_msi_msg(), so call it directly instead of having read_msi_msg() look
    it up from the IRQ.
    
    No functional change.
    
    [bhelgaas: changelog]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Michael Ellerman <mpe@ellerman.id.au>
    CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    CC: linuxppc-dev@lists.ozlabs.org

commit 2b260085e466c345e78f23b1c9ad1d123d509ef8
Author: Yijing Wang <wangyijing@huawei.com>
Date:   Tue Sep 23 13:27:25 2014 +0800

    PCI/MSI: Use __get_cached_msi_msg() instead of get_cached_msi_msg()
    
    Both callers of get_cached_msi_msg() start with a struct irq_data pointer,
    look up the corresponding IRQ number, and pass it to get_cached_msi_msg(),
    which then uses irq_get_irq_data() to look up the struct irq_data again to
    call __get_cached_msi_msg().
    
    Since we already have the struct irq_data, call __get_cached_msi_msg()
    directly and skip the lookup work done by get_cached_msi_msg().
    
    No functional change.
    
    [bhelgaas: changelog]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: Tony Luck <tony.luck@intel.com>
    CC: linux-ia64@vger.kernel.org

commit 468ff15a3ab98ed7153c29c68229ffb97f15a251
Author: Yijing Wang <wangyijing@huawei.com>
Date:   Tue Sep 23 13:27:24 2014 +0800

    PCI/MSI: Add "msi_bus" sysfs MSI/MSI-X control for endpoints
    
    The "msi_bus" sysfs file for bridges sets a bus flag to allow or disallow
    future driver requests for MSI or MSI-X.  Previously, the sysfs file
    existed for endpoints but did nothing.
    
    Add "msi_bus" support for endpoints, so an administrator can prevent the
    use of MSI and MSI-X for individual devices.
    
    Note that as for bridges, these changes only affect future driver requests
    for MSI or MSI-X, so drivers may need to be reloaded.
    
    Add documentation for the "msi_bus" sysfs file.
    
    [bhelgaas: changelog, comments, add "subordinate", add endpoint printk,
    rework bus_flags setting, make bus_flags printk unconditional]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit 48c3c38f003c25d50a09d3da558667c5ecd530aa
Author: Yijing Wang <wangyijing@huawei.com>
Date:   Tue Sep 23 11:02:42 2014 -0600

    PCI/MSI: Remove "pos" from the struct msi_desc msi_attrib
    
    "msi_attrib.pos" is only used for MSI (not MSI-X), and we already cache the
    MSI capability offset in "dev->msi_cap".
    
    Remove "pos" from the struct msi_attrib and use "dev->msi_cap" directly.
    
    [bhelgaas: changelog, fix whitespace]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit 81052769e48609525c452d8f078a5786b673e178
Author: Yijing Wang <wangyijing@huawei.com>
Date:   Tue Sep 23 13:27:22 2014 +0800

    PCI/MSI: Remove unused kobject from struct msi_desc
    
    After commit 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not
    kobjects"), the kobject in struct msi_desc is unused.
    
    Remove the unused struct kobject from struct msi_desc.
    
    [bhelgaas: changelog]
    Fixes: 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not kobjects")
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a06cd74cefe754341f747ddc4cf7b0058fa9bff8
Author: Alexander Gordeev <agordeev@redhat.com>
Date:   Tue Sep 23 12:45:58 2014 -0600

    PCI/MSI: Rename pci_msi_check_device() to pci_msi_supported()
    
    Rename pci_msi_check_device() to pci_msi_supported() for clarity.  Note
    that pci_msi_supported() returns true if MSI/MSI-X is supported, so code
    like:
    
      if (pci_msi_supported(...))
    
    reads naturally.