Skip to content

Loading…

7601 #67

Open
wants to merge 6,673 commits into from
@danss70

No description provided.

@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#67: FILE: kernel/kmod.c:214:
+	 * Kthreadd can be restricted to a set of processors if the user wants to

WARNING: line over 80 characters
#69: FILE: kernel/kmod.c:216:
+	 * we do not want to disturb the other processors here either so we start

WARNING: line over 80 characters
#70: FILE: kernel/kmod.c:217:
+	 * the usermode helper threads only on the processors allowed for kthreadd.

total: 0 errors, 3 warnings, 44 lines checked

./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
e49a5ee
@hardkernel hardkernel referenced this pull request in hardkernel/linux
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#67: FILE: kernel/kmod.c:214:
+	 * Kthreadd can be restricted to a set of processors if the user wants to

WARNING: line over 80 characters
#69: FILE: kernel/kmod.c:216:
+	 * we do not want to disturb the other processors here either so we start

WARNING: line over 80 characters
#70: FILE: kernel/kmod.c:217:
+	 * the usermode helper threads only on the processors allowed for kthreadd.

total: 0 errors, 3 warnings, 44 lines checked

./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ca4985b
@koenkooi koenkooi pushed a commit to koenkooi/linux that referenced this pull request
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
@koenkooi koenkooi pushed a commit to koenkooi/linux that referenced this pull request
@jejb jejb [SCSI] Revert "sg: push file descriptor list locking down to per-devi…
…ce locking"

This reverts commit 1f962eb.

This is one of four patches that was causing this bug

[  205.372823] ================================================
[  205.372901] [ BUG: lock held when returning to user space! ]
[  205.372979] 3.12.0-rc6-hw-debug-pagealloc+ #67 Not tainted
[  205.373055] ------------------------------------------------
[  205.373132] megarc.bin/5283 is leaving the kernel with locks still held!
[  205.373212] 1 lock held by megarc.bin/5283:
[  205.373285]  #0:  (&sdp->o_sem){.+.+..}, at: [<ffffffff8161e650>] sg_open+0x3a0/0x4d0

Cc: Vaughan Cao <vaughan.cao@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
c0d3b9c
@koenkooi koenkooi pushed a commit to koenkooi/linux that referenced this pull request
@jejb jejb [SCSI] Revert "sg: checking sdp->detached isn't protected when open"
This reverts commit e32c9e6.

This is one of four patches that was causing this bug

[  205.372823] ================================================
[  205.372901] [ BUG: lock held when returning to user space! ]
[  205.372979] 3.12.0-rc6-hw-debug-pagealloc+ #67 Not tainted
[  205.373055] ------------------------------------------------
[  205.373132] megarc.bin/5283 is leaving the kernel with locks still held!
[  205.373212] 1 lock held by megarc.bin/5283:
[  205.373285]  #0:  (&sdp->o_sem){.+.+..}, at: [<ffffffff8161e650>] sg_open+0x3a0/0x4d0

Cc: Vaughan Cao <vaughan.cao@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
bafc8ad
@koenkooi koenkooi pushed a commit to koenkooi/linux that referenced this pull request
@jejb jejb [SCSI] Revert "sg: no need sg_open_exclusive_lock"
This reverts commit 00b2d9d.

This is one of four patches that was causing this bug

[  205.372823] ================================================
[  205.372901] [ BUG: lock held when returning to user space! ]
[  205.372979] 3.12.0-rc6-hw-debug-pagealloc+ #67 Not tainted
[  205.373055] ------------------------------------------------
[  205.373132] megarc.bin/5283 is leaving the kernel with locks still held!
[  205.373212] 1 lock held by megarc.bin/5283:
[  205.373285]  #0:  (&sdp->o_sem){.+.+..}, at: [<ffffffff8161e650>] sg_open+0x3a0/0x4d0

Cc: Vaughan Cao <vaughan.cao@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
98481ff
@koenkooi koenkooi pushed a commit to koenkooi/linux that referenced this pull request
@jejb jejb [SCSI] Revert "sg: use rwsem to solve race during exclusive open"
This reverts commit 15b06f9.

This is one of four patches that was causing this bug

[  205.372823] ================================================
[  205.372901] [ BUG: lock held when returning to user space! ]
[  205.372979] 3.12.0-rc6-hw-debug-pagealloc+ #67 Not tainted
[  205.373055] ------------------------------------------------
[  205.373132] megarc.bin/5283 is leaving the kernel with locks still held!
[  205.373212] 1 lock held by megarc.bin/5283:
[  205.373285]  #0:  (&sdp->o_sem){.+.+..}, at: [<ffffffff8161e650>] sg_open+0x3a0/0x4d0

Cc: Vaughan Cao <vaughan.cao@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
065b4a2
@koenkooi koenkooi pushed a commit to koenkooi/linux that referenced this pull request
@johnstultz-work johnstultz-work cpuset: Fix potential deadlock w/ set_mems_allowed
After adding lockdep support to seqlock/seqcount structures,
I started seeing the following warning:

[    1.070907] ======================================================
[    1.072015] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
[    1.073181] 3.11.0+ #67 Not tainted
[    1.073801] ------------------------------------------------------
[    1.074882] kworker/u4:2/708 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[    1.076088]  (&p->mems_allowed_seq){+.+...}, at: [<ffffffff81187d7f>] new_slab+0x5f/0x280
[    1.077572]
[    1.077572] and this task is already holding:
[    1.078593]  (&(&q->__queue_lock)->rlock){..-...}, at: [<ffffffff81339f03>] blk_execute_rq_nowait+0x53/0xf0
[    1.080042] which would create a new lock dependency:
[    1.080042]  (&(&q->__queue_lock)->rlock){..-...} -> (&p->mems_allowed_seq){+.+...}
[    1.080042]
[    1.080042] but this new dependency connects a SOFTIRQ-irq-safe lock:
[    1.080042]  (&(&q->__queue_lock)->rlock){..-...}
[    1.080042] ... which became SOFTIRQ-irq-safe at:
[    1.080042]   [<ffffffff810ec179>] __lock_acquire+0x5b9/0x1db0
[    1.080042]   [<ffffffff810edfe5>] lock_acquire+0x95/0x130
[    1.080042]   [<ffffffff818968a1>] _raw_spin_lock+0x41/0x80
[    1.080042]   [<ffffffff81560c9e>] scsi_device_unbusy+0x7e/0xd0
[    1.080042]   [<ffffffff8155a612>] scsi_finish_command+0x32/0xf0
[    1.080042]   [<ffffffff81560e91>] scsi_softirq_done+0xa1/0x130
[    1.080042]   [<ffffffff8133b0f3>] blk_done_softirq+0x73/0x90
[    1.080042]   [<ffffffff81095dc0>] __do_softirq+0x110/0x2f0
[    1.080042]   [<ffffffff81095fcd>] run_ksoftirqd+0x2d/0x60
[    1.080042]   [<ffffffff810bc506>] smpboot_thread_fn+0x156/0x1e0
[    1.080042]   [<ffffffff810b3916>] kthread+0xd6/0xe0
[    1.080042]   [<ffffffff818980ac>] ret_from_fork+0x7c/0xb0
[    1.080042]
[    1.080042] to a SOFTIRQ-irq-unsafe lock:
[    1.080042]  (&p->mems_allowed_seq){+.+...}
[    1.080042] ... which became SOFTIRQ-irq-unsafe at:
[    1.080042] ...  [<ffffffff810ec1d3>] __lock_acquire+0x613/0x1db0
[    1.080042]   [<ffffffff810edfe5>] lock_acquire+0x95/0x130
[    1.080042]   [<ffffffff810b3df2>] kthreadd+0x82/0x180
[    1.080042]   [<ffffffff818980ac>] ret_from_fork+0x7c/0xb0
[    1.080042]
[    1.080042] other info that might help us debug this:
[    1.080042]
[    1.080042]  Possible interrupt unsafe locking scenario:
[    1.080042]
[    1.080042]        CPU0                    CPU1
[    1.080042]        ----                    ----
[    1.080042]   lock(&p->mems_allowed_seq);
[    1.080042]                                local_irq_disable();
[    1.080042]                                lock(&(&q->__queue_lock)->rlock);
[    1.080042]                                lock(&p->mems_allowed_seq);
[    1.080042]   <Interrupt>
[    1.080042]     lock(&(&q->__queue_lock)->rlock);
[    1.080042]
[    1.080042]  *** DEADLOCK ***

The issue stems from the kthreadd() function calling set_mems_allowed
with irqs enabled. While its possibly unlikely for the actual deadlock
to trigger, a fix is fairly simple: disable irqs before taking the
mems_allowed_seq lock.

Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Link: http://lkml.kernel.org/r/1381186321-4906-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
db751fe
@jlelli jlelli pushed a commit to jlelli/linux that referenced this pull request
@jerinjacobk jerinjacobk MIPS: DMA: Fix BUG due to smp_processor_id() in preemptible code
The use of current_cpu_type() in cpu_is_noncoherent_r10000() is not preemption-safe.
Use boot_cpu_type() instead to make it preemption-safe.

<log>
/ # insmod mtd_readtest.ko dev=4
mtd_readtest: MTD device: 4
mtd_readtest: MTD device size 996671488, eraseblock size 524288, page size 4096, count of eraseblocks 1901, pages per eraseblock 128, OOB size 224
mtd_readtest: scanning for bad eraseblocks
mtd_readtest: scanned 1901 eraseblocks, 0 are bad
mtd_readtest: testing page read
BUG: using smp_processor_id() in preemptible [00000000] code: insmod/99
caller is mips_dma_sync_single_for_cpu+0x2c/0x128
CPU: 2 PID: 99 Comm: insmod Not tainted 3.10.4 #67
Stack : 00000006 69735f63 00000000 00000000 00000000 00000000 808273d6 00000032
          80820000 00000002 8d700000 8de48fa0 00000000 00000000 00000000 00000000
          00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
          00000000 00000000 00000000 8d6afb00 8d6afb24 80721f24 807b9927 8012c130
          80820000 80721f24 00000002 00000063 8de48fa0 8082333c 807b98e6 8d6afaa0
          ...
Call Trace:
[<80109984>] show_stack+0x64/0x7c
[<80666230>] dump_stack+0x20/0x2c
[<803a2210>] debug_smp_processor_id+0xe0/0xf0
[<801116f0>] mips_dma_sync_single_for_cpu+0x2c/0x128
[<8043456c>] nand_plat_read_page+0x16c/0x234
[<8042fad4>] nand_do_read_ops+0x194/0x480
[<804301dc>] nand_read+0x50/0x7c
[<804261c8>] part_read+0x70/0xc0
[<804231dc>] mtd_read+0x80/0xe4
[<c0431354>] init_module+0x354/0x6f8 [mtd_readtest]
[<8010057c>] do_one_initcall+0x140/0x1a4
[<80176d7c>] load_module+0x1b5c/0x2258
[<8017752c>] SyS_init_module+0xb4/0xec
[<8010f3fc>] stack_done+0x20/0x44

BUG: using smp_processor_id() in preemptible [00000000] code: insmod/99
</log>

Signed-off-by: Jerin Jacob <jerinjacobk@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5800/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
d451e73
@tobiasjakobi tobiasjakobi pushed a commit that referenced this pull request
@lizf-os lizf-os shm: fix null pointer deref when userspace specifies invalid hugepage…
… size

commit 091d0d5 upstream.

Dave reported an oops triggered by trinity:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: newseg+0x10d/0x390
  PGD cf8c1067 PUD cf8c2067 PMD 0
  Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
  CPU: 2 PID: 7636 Comm: trinity-child2 Not tainted 3.9.0+#67
  ...
  Call Trace:
    ipcget+0x182/0x380
    SyS_shmget+0x5a/0x60
    tracesys+0xdd/0xe2

This bug was introduced by commit af73e4d ("hugetlbfs: fix mmap
failure in unaligned size request").

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Li Zefan <lizfan@huawei.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Acked-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
74b4473
@tobiasjakobi tobiasjakobi pushed a commit that referenced this pull request
@lizf-os lizf-os shm: fix null pointer deref when userspace specifies invalid hugepage…
… size

BugLink: http://bugs.launchpad.net/bugs/1187551

commit 091d0d5 upstream.

Dave reported an oops triggered by trinity:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: newseg+0x10d/0x390
  PGD cf8c1067 PUD cf8c2067 PMD 0
  Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
  CPU: 2 PID: 7636 Comm: trinity-child2 Not tainted 3.9.0+#67
  ...
  Call Trace:
    ipcget+0x182/0x380
    SyS_shmget+0x5a/0x60
    tracesys+0xdd/0xe2

This bug was introduced by commit af73e4d ("hugetlbfs: fix mmap
failure in unaligned size request").

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Li Zefan <lizfan@huawei.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Acked-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
c2e02c1
@plbossart plbossart pushed a commit to plbossart/sound that referenced this pull request
@lizf-os lizf-os shm: fix null pointer deref when userspace specifies invalid hugepage…
… size

Dave reported an oops triggered by trinity:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: newseg+0x10d/0x390
  PGD cf8c1067 PUD cf8c2067 PMD 0
  Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
  CPU: 2 PID: 7636 Comm: trinity-child2 Not tainted 3.9.0+#67
  ...
  Call Trace:
    ipcget+0x182/0x380
    SyS_shmget+0x5a/0x60
    tracesys+0xdd/0xe2

This bug was introduced by commit af73e4d ("hugetlbfs: fix mmap
failure in unaligned size request").

Reported-by: Dave Jones <davej@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Li Zefan <lizfan@huawei.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Acked-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
091d0d5
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#67: FILE: kernel/kmod.c:214:
+	 * Kthreadd can be restricted to a set of processors if the user wants to

WARNING: line over 80 characters
#69: FILE: kernel/kmod.c:216:
+	 * we do not want to disturb the other processors here either so we start

WARNING: line over 80 characters
#70: FILE: kernel/kmod.c:217:
+	 * the usermode helper threads only on the processors allowed for kthreadd.

total: 0 errors, 3 warnings, 44 lines checked

./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
93ba3a4
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#67: FILE: kernel/kmod.c:214:
+	 * Kthreadd can be restricted to a set of processors if the user wants to

WARNING: line over 80 characters
#69: FILE: kernel/kmod.c:216:
+	 * we do not want to disturb the other processors here either so we start

WARNING: line over 80 characters
#70: FILE: kernel/kmod.c:217:
+	 * the usermode helper threads only on the processors allowed for kthreadd.

total: 0 errors, 3 warnings, 44 lines checked

./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
1962be7
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#67: FILE: kernel/kmod.c:214:
+	 * Kthreadd can be restricted to a set of processors if the user wants to

WARNING: line over 80 characters
#69: FILE: kernel/kmod.c:216:
+	 * we do not want to disturb the other processors here either so we start

WARNING: line over 80 characters
#70: FILE: kernel/kmod.c:217:
+	 * the usermode helper threads only on the processors allowed for kthreadd.

total: 0 errors, 3 warnings, 44 lines checked

./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
f80e1c7
@Naoya-Horiguchi Naoya-Horiguchi pushed a commit that referenced this pull request
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#67: FILE: kernel/kmod.c:214:
+	 * Kthreadd can be restricted to a set of processors if the user wants to

WARNING: line over 80 characters
#69: FILE: kernel/kmod.c:216:
+	 * we do not want to disturb the other processors here either so we start

WARNING: line over 80 characters
#70: FILE: kernel/kmod.c:217:
+	 * the usermode helper threads only on the processors allowed for kthreadd.

total: 0 errors, 3 warnings, 44 lines checked

./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
5388713
@zeitgeist87 zeitgeist87 pushed a commit to zeitgeist87/linux that referenced this pull request
Andrew Morton mm-add-debugfs-tunable-for-fault_around_order-checkpatch-fixes
WARNING: Prefer pr_warn(... to pr_warning(...
#67: FILE: mm/memory.c:3376:
+		pr_warning("Failed to create fault_around_order in debugfs");

total: 0 errors, 1 warnings, 96 lines checked

./patches/mm-add-debugfs-tunable-for-fault_around_order.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: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2c42ccb
@zeitgeist87 zeitgeist87 pushed a commit to zeitgeist87/linux that referenced this pull request
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#67: FILE: kernel/kmod.c:214:
+	 * Kthreadd can be restricted to a set of processors if the user wants to

WARNING: line over 80 characters
#69: FILE: kernel/kmod.c:216:
+	 * we do not want to disturb the other processors here either so we start

WARNING: line over 80 characters
#70: FILE: kernel/kmod.c:217:
+	 * the usermode helper threads only on the processors allowed for kthreadd.

total: 0 errors, 3 warnings, 44 lines checked

./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
9a49037
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request
Andrew Morton mm-add-debugfs-tunable-for-fault_around_order-checkpatch-fixes
WARNING: Prefer pr_warn(... to pr_warning(...
#67: FILE: mm/memory.c:3376:
+		pr_warning("Failed to create fault_around_order in debugfs");

total: 0 errors, 1 warnings, 96 lines checked

./patches/mm-add-debugfs-tunable-for-fault_around_order.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: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
c935c1c
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#67: FILE: kernel/kmod.c:214:
+	 * Kthreadd can be restricted to a set of processors if the user wants to

WARNING: line over 80 characters
#69: FILE: kernel/kmod.c:216:
+	 * we do not want to disturb the other processors here either so we start

WARNING: line over 80 characters
#70: FILE: kernel/kmod.c:217:
+	 * the usermode helper threads only on the processors allowed for kthreadd.

total: 0 errors, 3 warnings, 44 lines checked

./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
c334b7f
@zeitgeist87 zeitgeist87 pushed a commit to zeitgeist87/linux that referenced this pull request
Andrew Morton mm-add-debugfs-tunable-for-fault_around_order-checkpatch-fixes
WARNING: Prefer pr_warn(... to pr_warning(...
#67: FILE: mm/memory.c:3376:
+		pr_warning("Failed to create fault_around_order in debugfs");

total: 0 errors, 1 warnings, 96 lines checked

./patches/mm-add-debugfs-tunable-for-fault_around_order.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: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
1ae2863
@zeitgeist87 zeitgeist87 pushed a commit to zeitgeist87/linux that referenced this pull request
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#67: FILE: kernel/kmod.c:214:
+	 * Kthreadd can be restricted to a set of processors if the user wants to

WARNING: line over 80 characters
#69: FILE: kernel/kmod.c:216:
+	 * we do not want to disturb the other processors here either so we start

WARNING: line over 80 characters
#70: FILE: kernel/kmod.c:217:
+	 * the usermode helper threads only on the processors allowed for kthreadd.

total: 0 errors, 3 warnings, 44 lines checked

./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
6655e58
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request
Andrew Morton mm-add-debugfs-tunable-for-fault_around_order-checkpatch-fixes
WARNING: Prefer pr_warn(... to pr_warning(...
#67: FILE: mm/memory.c:3376:
+		pr_warning("Failed to create fault_around_order in debugfs");

total: 0 errors, 1 warnings, 96 lines checked

./patches/mm-add-debugfs-tunable-for-fault_around_order.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: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
daafd18
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request
Andrew Morton kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2-checkpa…
…tch-fixes

WARNING: line over 80 characters
#67: FILE: kernel/kmod.c:214:
+	 * Kthreadd can be restricted to a set of processors if the user wants to

WARNING: line over 80 characters
#69: FILE: kernel/kmod.c:216:
+	 * we do not want to disturb the other processors here either so we start

WARNING: line over 80 characters
#70: FILE: kernel/kmod.c:217:
+	 * the usermode helper threads only on the processors allowed for kthreadd.

total: 0 errors, 3 warnings, 44 lines checked

./patches/kmod-run-usermodehelpers-only-on-cpus-allowed-for-kthreadd-v2.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: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ee2bbd7
@gregnietsky gregnietsky pushed a commit to Distrotech/linux that referenced this pull request
@lizf-os lizf-os shm: fix null pointer deref when userspace specifies invalid hugepage…
… size

commit 091d0d5 upstream.

Dave reported an oops triggered by trinity:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: newseg+0x10d/0x390
  PGD cf8c1067 PUD cf8c2067 PMD 0
  Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
  CPU: 2 PID: 7636 Comm: trinity-child2 Not tainted 3.9.0+#67
  ...
  Call Trace:
    ipcget+0x182/0x380
    SyS_shmget+0x5a/0x60
    tracesys+0xdd/0xe2

This bug was introduced by commit af73e4d ("hugetlbfs: fix mmap
failure in unaligned size request").

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Li Zefan <lizfan@huawei.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Acked-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
159590f
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
5fcdc8b
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
a166f46
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
7070bac
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
c754042
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
4612ca9
@JoonsooKim JoonsooKim pushed a commit to JoonsooKim/linux that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
5865f94
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
4fa21f9
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
3bbe91c
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
bb72a87
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
178a08b
@cyndis cyndis pushed a commit to cyndis/linux that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
e74da88
@tom3q tom3q pushed a commit to tom3q/linux that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
37cf44f
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
aa11f9b
@Naoya-Horiguchi Naoya-Horiguchi pushed a commit that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
60b1404
@Gnurou Gnurou pushed a commit to Gnurou/linux that referenced this pull request
Andrew Morton mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no…
…-zone_normal-checkpatch-fixes

ERROR: code indent should use tabs where possible
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

WARNING: please, no spaces at the start of a line
#66: FILE: mm/vmscan.c:2585:
+        for_each_zone_zonelist_nodemask(zone, z, zonelist,$

ERROR: code indent should use tabs where possible
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

WARNING: please, no spaces at the start of a line
#67: FILE: mm/vmscan.c:2586:
+                                        gfp_mask, nodemask) {$

total: 2 errors, 2 warnings, 56 lines checked

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

./patches/mm-vmscan-do-not-throttle-based-on-pfmemalloc-reserves-if-node-has-no-zone_normal.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: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
5fa6e6e
Kevin McKinney and others added some commits
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
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
@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
@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
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
Anson Jacob usb: gadget: f_accessory: Enabled Zero Length Packet (ZLP) for acc_write
Accessory connected to Android Device requires
Zero Length Packet (ZLP) to be written when data
transferred out from the Android device are multiples
of wMaxPacketSize (64bytes (Full-Speed) / 512bytes (High-Speed))
to end the transfer.

Change-Id: Ib2c2c0ab98ef9afa10e74a720142deca5c0ed476
Signed-off-by: Anson Jacob <ansonkuzhumbil@gmail.com>
e512280
Gu Zheng cpuset,mempolicy: fix sleeping function called from invalid context
commit 391acf9 upstream.

When runing with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586
[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python
[ 9969.441175] INFO: lockdep is turned off.
[ 9969.488184] CPU: 26 PID: 160655 Comm: python Tainted: G       A      3.15.0-rc7+ #85
[ 9969.581032] Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB, BIOS PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012
[ 9969.706052]  ffffffff81a20e60 ffff8803e941fbd0 ffffffff8162f523 ffff8803e941fd18
[ 9969.795323]  ffff8803e941fbe0 ffffffff8109995a ffff8803e941fc58 ffffffff81633e6c
[ 9969.884710]  ffffffff811ba5dc ffff880405c6b480 ffff88041fdd90a0 0000000000002000
[ 9969.974071] Call Trace:
[ 9970.003403]  [<ffffffff8162f523>] dump_stack+0x4d/0x66
[ 9970.065074]  [<ffffffff8109995a>] __might_sleep+0xfa/0x130
[ 9970.130743]  [<ffffffff81633e6c>] mutex_lock_nested+0x3c/0x4f0
[ 9970.200638]  [<ffffffff811ba5dc>] ? kmem_cache_alloc+0x1bc/0x210
[ 9970.272610]  [<ffffffff81105807>] cpuset_mems_allowed+0x27/0x140
[ 9970.344584]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150
[ 9970.409282]  [<ffffffff811b1385>] __mpol_dup+0xe5/0x150
[ 9970.471897]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150
[ 9970.536585]  [<ffffffff81068c86>] ? copy_process.part.23+0x606/0x1d40
[ 9970.613763]  [<ffffffff810bf28d>] ? trace_hardirqs_on+0xd/0x10
[ 9970.683660]  [<ffffffff810ddddf>] ? monotonic_to_bootbased+0x2f/0x50
[ 9970.759795]  [<ffffffff81068cf0>] copy_process.part.23+0x670/0x1d40
[ 9970.834885]  [<ffffffff8106a598>] do_fork+0xd8/0x380
[ 9970.894375]  [<ffffffff81110e4c>] ? __audit_syscall_entry+0x9c/0xf0
[ 9970.969470]  [<ffffffff8106a8c6>] SyS_clone+0x16/0x20
[ 9971.030011]  [<ffffffff81642009>] stub_clone+0x69/0x90
[ 9971.091573]  [<ffffffff81641c29>] ? system_call_fastpath+0x16/0x1b

The cause is that cpuset_mems_allowed() try to take
mutex_lock(&callback_mutex) under the rcu_read_lock(which was hold in
__mpol_dup()). And in cpuset_mems_allowed(), the access to cpuset is
under rcu_read_lock, so in __mpol_dup, we can reduce the rcu_read_lock
protection region to protect the access to cpuset only in
current_cpuset_is_being_rebound(). So that we can avoid this bug.

This patch is a temporary solution that just addresses the bug
mentioned above, can not fix the long-standing issue about cpuset.mems
rebinding on fork():

"When the forker's task_struct is duplicated (which includes
 ->mems_allowed) and it races with an update to cpuset_being_rebound
 in update_tasks_nodemask() then the task's mems_allowed doesn't get
 updated. And the child task's mems_allowed can be wrong if the
 cpuset's nodemask changes before the child has been added to the
 cgroup's tasklist."

Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
f54e041
@ka87 ka87 USB: cp210x: add support for Corsair usb dongle
commit b932605 upstream.

Corsair USB Dongles are shipped with Corsair AXi series PSUs.
These are cp210x serial usb devices, so make driver detect these.
I have a program, that can get information from these PSUs.

Tested with 2 different dongles shipped with Corsair AX860i and
AX1200i units.

Signed-off-by: Andras Kovacs <andras@sth.sze.hu>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d45a238
Bernd Wachter usb: option: Add ID for Telewell TW-LTE 4G v2
commit 3d28bd8 upstream.

Add ID of the Telewell 4G v2 hardware to option driver to get legacy
serial interface working

Signed-off-by: Bernd Wachter <bernd.wachter@jolla.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fd7afe2
@biot biot USB: ftdi_sio: Add extra PID.
commit 5a7fbe7 upstream.

This patch adds PID 0x0003 to the VID 0x128d (Testo). At least the
Testo 435-4 uses this, likely other gear as well.

Signed-off-by: Bert Vermeulen <bert@biot.com>
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d06191b
@rolandd rolandd x86, ioremap: Speed up check for RAM pages
commit c81c8a1 upstream.

In __ioremap_caller() (the guts of ioremap), we loop over the range of
pfns being remapped and checks each one individually with page_is_ram().
For large ioremaps, this can be very slow.  For example, we have a
device with a 256 GiB PCI BAR, and ioremapping this BAR can take 20+
seconds -- sometimes long enough to trigger the soft lockup detector!

Internally, page_is_ram() calls walk_system_ram_range() on a single
page.  Instead, we can make a single call to walk_system_ram_range()
from __ioremap_caller(), and do our further checks only for any RAM
pages that we find.  For the common case of MMIO, this saves an enormous
amount of work, since the range being ioremapped doesn't intersect
system RAM at all.

With this change, ioremap on our 256 GiB BAR takes less than 1 second.

Signed-off-by: Roland Dreier <roland@purestorage.com>
Link: http://lkml.kernel.org/r/1399054721-1331-1-git-send-email-roland@kernel.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d824be9
Thomas Gleixner rtmutex: Fix deadlock detector for real
commit 397335f upstream.

The current deadlock detection logic does not work reliably due to the
following early exit path:

	/*
	 * Drop out, when the task has no waiters. Note,
	 * top_waiter can be NULL, when we are in the deboosting
	 * mode!
	 */
	if (top_waiter && (!task_has_pi_waiters(task) ||
			   top_waiter != task_top_pi_waiter(task)))
		goto out_unlock_pi;

So this not only exits when the task has no waiters, it also exits
unconditionally when the current waiter is not the top priority waiter
of the task.

So in a nested locking scenario, it might abort the lock chain walk
and therefor miss a potential deadlock.

Simple fix: Continue the chain walk, when deadlock detection is
enabled.

We also avoid the whole enqueue, if we detect the deadlock right away
(A-A). It's an optimization, but also prevents that another waiter who
comes in after the detection and before the task has undone the damage
observes the situation and detects the deadlock and returns
-EDEADLOCK, which is wrong as the other task is not in a deadlock
situation.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Link: http://lkml.kernel.org/r/20140522031949.725272460@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
90b421b
@antonblanchard antonblanchard powerpc/perf: Never program book3s PMCs with values >= 0x80000000
commit f560294 upstream.

We are seeing a lot of PMU warnings on POWER8:

    Can't find PMC that caused IRQ

Looking closer, the active PMC is 0 at this point and we took a PMU
exception on the transition from negative to 0. Some versions of POWER8
have an issue where they edge detect and not level detect PMC overflows.

A number of places program the PMC with (0x80000000 - period_left),
where period_left can be negative. We can either fix all of these or
just ensure that period_left is always >= 1.

This patch takes the second option.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
7b9eab8
Christian König drm/radeon: stop poisoning the GART TLB
commit 0986c1a upstream.

When we set the valid bit on invalid GART entries they are
loaded into the TLB when an adjacent entry is loaded. This
poisons the TLB with invalid entries which are sometimes
not correctly removed on TLB flush.

For stable inclusion the patch probably needs to be modified a bit.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fa1bd9b
Thomas Gleixner rtmutex: Detect changes in the pi lock chain
commit 8208498 upstream.

When we walk the lock chain, we drop all locks after each step. So the
lock chain can change under us before we reacquire the locks. That's
harmless in principle as we just follow the wrong lock path. But it
can lead to a false positive in the dead lock detection logic:

T0 holds L0
T0 blocks on L1 held by T1
T1 blocks on L2 held by T2
T2 blocks on L3 held by T3
T4 blocks on L4 held by T4

Now we walk the chain

lock T1 -> lock L2 -> adjust L2 -> unlock T1 ->
     lock T2 ->  adjust T2 ->  drop locks

T2 times out and blocks on L0

Now we continue:

lock T2 -> lock L0 -> deadlock detected, but it's not a deadlock at all.

Brad tried to work around that in the deadlock detection logic itself,
but the more I looked at it the less I liked it, because it's crystal
ball magic after the fact.

We actually can detect a chain change very simple:

lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->

     next_lock = T2->pi_blocked_on->lock;

drop locks

T2 times out and blocks on L0

Now we continue:

lock T2 ->

     if (next_lock != T2->pi_blocked_on->lock)
     	   return;

So if we detect that T2 is now blocked on a different lock we stop the
chain walk. That's also correct in the following scenario:

lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->

     next_lock = T2->pi_blocked_on->lock;

drop locks

T3 times out and drops L3
T2 acquires L3 and blocks on L4 now

Now we continue:

lock T2 ->

     if (next_lock != T2->pi_blocked_on->lock)
     	   return;

We don't have to follow up the chain at that point, because T2
propagated our priority up to T4 already.

[ Folded a cleanup patch from peterz ]

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Brad Mouring <bmouring@ni.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140605152801.930031935@linutronix.de
Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
307e2e0
Thomas Gleixner rtmutex: Handle deadlock detection smarter
commit 3d5c934 upstream.

Even in the case when deadlock detection is not requested by the
caller, we can detect deadlocks. Right now the code stops the lock
chain walk and keeps the waiter enqueued, even on itself. Silly not to
yell when such a scenario is detected and to keep the waiter enqueued.

Return -EDEADLK unconditionally and handle it at the call sites.

The futex calls return -EDEADLK. The non futex ones dequeue the
waiter, throw a warning and put the task into a schedule loop.

Tagged for stable as it makes the code more robust.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Brad Mouring <bmouring@ni.com>
Link: http://lkml.kernel.org/r/20140605152801.836501969@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ea018da
Thomas Gleixner rtmutex: Plug slow unlock race
commit 27e3571 upstream.

When the rtmutex fast path is enabled the slow unlock function can
create the following situation:

spin_lock(foo->m->wait_lock);
foo->m->owner = NULL;
	    			rt_mutex_lock(foo->m); <-- fast path
				free = atomic_dec_and_test(foo->refcnt);
				rt_mutex_unlock(foo->m); <-- fast path
				if (free)
				   kfree(foo);

spin_unlock(foo->m->wait_lock); <--- Use after free.

Plug the race by changing the slow unlock to the following scheme:

     while (!rt_mutex_has_waiters(m)) {
     	    /* Clear the waiters bit in m->owner */
	    clear_rt_mutex_waiters(m);
      	    owner = rt_mutex_owner(m);
      	    spin_unlock(m->wait_lock);
      	    if (cmpxchg(m->owner, owner, 0) == owner)
      	       return;
      	    spin_lock(m->wait_lock);
     }

So in case of a new waiter incoming while the owner tries the slow
path unlock we have two situations:

 unlock(wait_lock);
					lock(wait_lock);
 cmpxchg(p, owner, 0) == owner
 	    	   			mark_rt_mutex_waiters(lock);
	 				acquire(lock);

Or:

 unlock(wait_lock);
					lock(wait_lock);
	 				mark_rt_mutex_waiters(lock);
 cmpxchg(p, owner, 0) != owner
					enqueue_waiter();
					unlock(wait_lock);
 lock(wait_lock);
 wakeup_next waiter();
 unlock(wait_lock);
					lock(wait_lock);
					acquire(lock);

If the fast path is disabled, then the simple

   m->owner = NULL;
   unlock(m->wait_lock);

is sufficient as all access to m->owner is serialized via
m->wait_lock;

Also document and clarify the wakeup_next_waiter function as suggested
by Oleg Nesterov.

Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140611183852.937945560@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2a77794
@rostedt rostedt tracing: Remove ftrace_stop/start() from reading the trace file
commit 099ed15 upstream.

Disabling reading and writing to the trace file should not be able to
disable all function tracing callbacks. There's other users today
(like kprobes and perf). Reading a trace file should not stop those
from happening.

Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bf09db9
@AxelLin AxelLin hwmon: (amc6821) Fix permissions for temp2_input
commit df86754 upstream.

temp2_input should not be writable, fix it.

Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5cc80fb
@AxelLin AxelLin hwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div
commit 1035a9e upstream.

Writing to fanX_div does not clear the cache. As a result, reading
from fanX_div may return the old value for up to two seconds
after writing a new value.

This patch ensures the fan_div cache is updated in set_fan_div().

Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
30bbd39
@tytso tytso ext4: clarify error count warning messages
commit ae0f78d upstream.

Make it clear that values printed are times, and that it is error
since last fsck. Also add note about fsck version required.

Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ef01826
Lan Tianyu ACPI / battery: Retry to get battery information if failed during pro…
…bing

commit 75646e7 upstream.

Some machines (eg. Lenovo Z480) ECs are not stable during boot up
and causes battery driver fails to be loaded due to failure of getting
battery information from EC sometimes. After several retries, the
operation will work. This patch is to retry to get battery information 5
times if the first try fails.

[ backport to 3.14.5: removed second parameter in acpi_battery_update(),
introduced by the commit 9e50bc1 (ACPI /
battery: Accelerate battery resume callback)]

[naszar <naszar@ya.ru>: backport to 3.14.5]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581
Reported-and-tested-by: naszar <naszar@ya.ru>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cd0c28d
@gregkh gregkh Linux 3.4.99 0758142
@jwrdegoede jwrdegoede cgroup: Take css_set_lock from cgroup_css_sets_empty()
As indicated in the comment above cgroup_css_sets_empty it needs the
css_set_lock. But neither of the 2 call points have it, so rather then fixing
the callers just take the lock inside cgroup_css_sets_empty().

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Change-Id: If7aea71824f6d0e3f2cc6c1ce236c3ae6be2037b
192ccd0
@jwrdegoede jwrdegoede cgroup: Fix use after free of cgrp (cgrp->css_sets)
Running a 3.4 kernel + Fedora-18 (systemd) userland on my Allwinner A10
(arm cortex a8), I'm seeing repeated, reproducable list_del list corruption
errors when build with CONFIG_DEBUG_LIST, and the backtrace always shows
free_css_set_work as the function making the problematic list_del call.

I've tracked this doen to a use after free of the cgrp struct, specifically
of the cgrp->css_sets list_head, which gets cleared by free_css_set_work.

Since free_css_set_work runs form a workqueue, it is possible for it to not be
done with clearing the list when the cgrp gets free-ed. To avoid this the code
adding the links increases cgrp->count, and the freeing code running from the
workqueue decreases cgrp->count *after* doing list_del, and then if the count
goes to 0 calls cgroup_wakeup_rmdir_waiter().

However cgroup_rmdir() is missing a check for cgrp->count != 0, causing it
to still continue with the rmdir (which leads to the free-ing of the cgrp),
before free_css_set_work is done. Sometimes the free-ed memory is re-used
before free_css_set_work gets around to unlinking link->cgrp_link_list,
triggering the list_del list corruption messages.

This patch fixes this by properly checking for cgrp->count != 0 and waiting
for the cgroup_rmdir_waitq in that case.

Change-Id: I9dbc02a0a75d5dffa1b65d67456e00139dea57c3
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
b519f21
Mark Salyzyn Revert "s3c2410_wdt: Add locking to cpu frequency transition notifier"
This reverts commit 037e771.

Change-Id: I32a81c1fb2d9ac2eb8570438699e8f9ff01f4c93
1d9dbe3
Anson Jacob usb: gadget: f_audio_source: change max ISO packet size
Re-applying from
https://gitorious.org/shr/linux/commit/eb4c9d2db894c3492c0a848581bd4f6790f93d5f

Most USB-AUDIO devices are limited to 256 byte for max iso buffer size.
If a IN_EP_MAX_PACKET_SIZE is bigger than a USB-AUDIO device's max iso
buffer size, it will cause noise. This patch will prevent this case as
possibe by reducing packet size. When using 44.1khz, 2ch, 16bit audio
data, if max packet size is bigger than 176 bytes, it's no problem.

Credits to: Iliyan Malchev <malchev@google.com>

Change-Id: I61435bc9ad7ab05faba16cf80bfb9ff0431c3002
Signed-off-by: Anson Jacob <ansonkuzhumbil@gmail.com>
a4c9d98
Anson Jacob usb: gadget: f_audio_source: Fixed USB Audio Class Interface Descriptor
Fixed Android Issue #56549.

When both Vendor Class and Audio Class are activated for AOA 2.0,
the baInterfaceNr of the AudioControl Interface Descriptor points
to wrong interface numbers. They should be pointing to
Audio Control Device and Audio Streaming interfaces.

Replaced baInterfaceNr with the correct value.

Change-Id: Ib20f20c1d65887bac051b7ff9453dc53fc23a8d0
Signed-off-by: Anson Jacob <ansonkuzhumbil@gmail.com>
5901dd6
Ashwin net: wireless: bcmdhd: Add support for hidden ssid PNO scan
Changes to support hidden ssid config to be sent to FW. Earlier
all ssids were hard coded as hidden, now only those indicated
as such by supplicant will be.

Change-Id: I927030fe12f162c52c93277b2ebfb4bf55daef4a
Signed-off-by: Ashwin <ashwin.bhat@broadcom.com>
c4651bd
@markus-oberhumer markus-oberhumer crypto: testmgr - update LZO compression test vectors
commit 0ec7382 upstream.

Update the LZO compression test vectors according to the latest compressor
version.

Signed-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>
Cc: Derrick Pallas <pallas@meraki.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
64fb4e2
Hugh Dickins shmem: fix faulting into a hole while it's punched
commit f00cdc6 upstream.

Trinity finds that mmap access to a hole while it's punched from shmem
can prevent the madvise(MADV_REMOVE) or fallocate(FALLOC_FL_PUNCH_HOLE)
from completing, until the reader chooses to stop; with the puncher's
hold on i_mutex locking out all other writers until it can complete.

It appears that the tmpfs fault path is too light in comparison with its
hole-punching path, lacking an i_data_sem to obstruct it; but we don't
want to slow down the common case.

Extend shmem_fallocate()'s existing range notification mechanism, so
shmem_fault() can refrain from faulting pages into the hole while it's
punched, waiting instead on i_mutex (when safe to sleep; or repeatedly
faulting when not).

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Tested-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Dave Jones <davej@redhat.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>
a62f374
Hugh Dickins shmem: fix faulting into a hole, not taking i_mutex
commit 8e205f7 upstream.

Commit f00cdc6 ("shmem: fix faulting into a hole while it's
punched") was buggy: Sasha sent a lockdep report to remind us that
grabbing i_mutex in the fault path is a no-no (write syscall may already
hold i_mutex while faulting user buffer).

We tried a completely different approach (see following patch) but that
proved inadequate: good enough for a rational workload, but not good
enough against trinity - which forks off so many mappings of the object
that contention on i_mmap_mutex while hole-puncher holds i_mutex builds
into serious starvation when concurrent faults force the puncher to fall
back to single-page unmap_mapping_range() searches of the i_mmap tree.

So return to the original umbrella approach, but keep away from i_mutex
this time.  We really don't want to bloat every shmem inode with a new
mutex or completion, just to protect this unlikely case from trinity.
So extend the original with wait_queue_head on stack at the hole-punch
end, and wait_queue item on the stack at the fault end.

This involves further use of i_lock to guard against the races: lockdep
has been happy so far, and I see fs/inode.c:unlock_new_inode() holds
i_lock around wake_up_bit(), which is comparable to what we do here.
i_lock is more convenient, but we could switch to shmem's info->lock.

This issue has been tagged with CVE-2014-4171, which will require commit
f00cdc6 and this and the following patch to be backported: we
suggest to 3.1+, though in fact the trinity forkbomb effect might go
back as far as 2.6.16, when madvise(,,MADV_REMOVE) came in - or might
not, since much has changed, with i_mmap_mutex a spinlock before 3.0.
Anyone running trinity on 3.0 and earlier? I don't think we need care.

Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Tested-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Lukas Czerner <lczerner@redhat.com>
Cc: Dave Jones <davej@redhat.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>
0f5a4a0
@manuels manuels dns_resolver: assure that dns_query() result is null-terminated
[ Upstream commit 84a7c0b ]

dns_query() credulously assumes that keys are null-terminated and
returns a copy of a memory block that is off by one.

Signed-off-by: Manuel Schölling <manuel.schoelling@gmx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
c304a23
Li RongQing 8021q: fix a potential memory leak
[ Upstream commit 916c168 ]

skb_cow called in vlan_reorder_header does not free the skb when it failed,
and vlan_reorder_header returns NULL to reset original skb when it is called
in vlan_untag, lead to a memory leak.

Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d7f5473
Neal Cardwell tcp: fix tcp_match_skb_to_sack() for unaligned SACK at end of an skb
[ Upstream commit 2cd0d74 ]

If there is an MSS change (or misbehaving receiver) that causes a SACK
to arrive that covers the end of an skb but is less than one MSS, then
tcp_match_skb_to_sack() was rounding up pkt_len to the full length of
the skb ("Round if necessary..."), then chopping all bytes off the skb
and creating a zero-byte skb in the write queue.

This was visible now because the recently simplified TLP logic in
bef1909 ("tcp: fixing TLP's FIN recovery") could find that 0-byte
skb at the end of the write queue, and now that we do not check that
skb's length we could send it as a TLP probe.

Consider the following example scenario:

 mss: 1000
 skb: seq: 0 end_seq: 4000  len: 4000
 SACK: start_seq: 3999 end_seq: 4000

The tcp_match_skb_to_sack() code will compute:

 in_sack = false
 pkt_len = start_seq - TCP_SKB_CB(skb)->seq = 3999 - 0 = 3999
 new_len = (pkt_len / mss) * mss = (3999/1000)*1000 = 3000
 new_len += mss = 4000

Previously we would find the new_len > skb->len check failing, so we
would fall through and set pkt_len = new_len = 4000 and chop off
pkt_len of 4000 from the 4000-byte skb, leaving a 0-byte segment
afterward in the write queue.

With this new commit, we notice that the new new_len >= skb->len check
succeeds, so that we return without trying to fragment.

Fixes: adb92db ("tcp: Make SACK code to split only at mss boundaries")
Reported-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Ilpo Jarvinen <ilpo.jarvinen@helsinki.fi>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
06c84e9
Yuchung Cheng tcp: fix false undo corner cases
[ Upstream commit 6e08d5e ]

The undo code assumes that, upon entering loss recovery, TCP
1) always retransmit something
2) the retransmission never fails locally (e.g., qdisc drop)

so undo_marker is set in tcp_enter_recovery() and undo_retrans is
incremented only when tcp_retransmit_skb() is successful.

When the assumption is broken because TCP's cwnd is too small to
retransmit or the retransmit fails locally. The next (DUP)ACK
would incorrectly revert the cwnd and the congestion state in
tcp_try_undo_dsack() or tcp_may_undo(). Subsequent (DUP)ACKs
may enter the recovery state. The sender repeatedly enter and
(incorrectly) exit recovery states if the retransmits continue to
fail locally while receiving (DUP)ACKs.

The fix is to initialize undo_retrans to -1 and start counting on
the first retransmission. Always increment undo_retrans even if the
retransmissions fail locally because they couldn't cause DSACKs to
undo the cwnd reduction.

Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
f37e491
@dingtianhong dingtianhong igmp: fix the problem when mc leave group
[ Upstream commit 52ad353 ]

The problem was triggered by these steps:

1) create socket, bind and then setsockopt for add mc group.
   mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37");
   mreq.imr_interface.s_addr = inet_addr("192.168.1.2");
   setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));

2) drop the mc group for this socket.
   mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37");
   mreq.imr_interface.s_addr = inet_addr("0.0.0.0");
   setsockopt(sockfd, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));

3) and then drop the socket, I found the mc group was still used by the dev:

   netstat -g

   Interface       RefCnt Group
   --------------- ------ ---------------------
   eth2		   1	  255.0.0.37

Normally even though the IP_DROP_MEMBERSHIP return error, the mc group still need
to be released for the netdev when drop the socket, but this process was broken when
route default is NULL, the reason is that:

The ip_mc_leave_group() will choose the in_dev by the imr_interface.s_addr, if input addr
is NULL, the default route dev will be chosen, then the ifindex is got from the dev,
then polling the inet->mc_list and return -ENODEV, but if the default route dev is NULL,
the in_dev and ifIndex is both NULL, when polling the inet->mc_list, the mc group will be
released from the mc_list, but the dev didn't dec the refcnt for this mc group, so
when dropping the socket, the mc_list is NULL and the dev still keep this group.

v1->v2: According Hideaki's suggestion, we should align with IPv6 (RFC3493) and BSDs,
	so I add the checking for the in_dev before polling the mc_list, make sure when
	we remove the mc group, dec the refcnt to the real dev which was using the mc address.
	The problem would never happened again.

Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fbaf3a0
@krieger-od krieger-od appletalk: Fix socket referencing in skb
[ Upstream commit 36beddc ]

Setting just skb->sk without taking its reference and setting a
destructor is invalid. However, in the places where this was done, skb
is used in a way not requiring skb->sk setting. So dropping the setting
of skb->sk.
Thanks to Eric Dumazet <eric.dumazet@gmail.com> for correct solution.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79441
Reported-by: Ed Martin <edman007@edman007.com>
Signed-off-by: Andrey Utkin <andrey.krieger.utkin@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3fa1f50
Jon Paul Maloy tipc: clear 'next'-pointer of message fragments before reassembly
[ Upstream commit 9994175 ]

If the 'next' pointer of the last fragment buffer in a message is not
zeroed before reassembly, we risk ending up with a corrupt message,
since the reassembly function itself isn't doing this.

Currently, when a buffer is retrieved from the deferred queue of the
broadcast link, the next pointer is not cleared, with the result as
described above.

This commit corrects this, and thereby fixes a bug that may occur when
long broadcast messages are transmitted across dual interfaces. The bug
has been present since 40ba3cd ("tipc:
message reassembly using fragment chain")

This commit should be applied to both net and net-next.

Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d1558f7
Suresh Reddy be2net: set EQ DB clear-intr bit in be_open()
[ Upstream commit 4cad9f3 ]

On BE3, if the clear-interrupt bit of the EQ doorbell is not set the first
time it is armed, ocassionally we have observed that the EQ doesn't raise
anymore interrupts even if it is in armed state.
This patch fixes this by setting the clear-interrupt bit when EQs are
armed for the first time in be_open().

Signed-off-by: Suresh Reddy <Suresh.Reddy@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3c656d4
@borkmann borkmann net: sctp: fix information leaks in ulpevent layer
[ Upstream commit 8f2e5ae ]

While working on some other SCTP code, I noticed that some
structures shared with user space are leaking uninitialized
stack or heap buffer. In particular, struct sctp_sndrcvinfo
has a 2 bytes hole between .sinfo_flags and .sinfo_ppid that
remains unfilled by us in sctp_ulpevent_read_sndrcvinfo() when
putting this into cmsg. But also struct sctp_remote_error
contains a 2 bytes hole that we don't fill but place into a skb
through skb_copy_expand() via sctp_ulpevent_make_remote_error().

Both structures are defined by the IETF in RFC6458:

* Section 5.3.2. SCTP Header Information Structure:

  The sctp_sndrcvinfo structure is defined below:

  struct sctp_sndrcvinfo {
    uint16_t sinfo_stream;
    uint16_t sinfo_ssn;
    uint16_t sinfo_flags;
    <-- 2 bytes hole  -->
    uint32_t sinfo_ppid;
    uint32_t sinfo_context;
    uint32_t sinfo_timetolive;
    uint32_t sinfo_tsn;
    uint32_t sinfo_cumtsn;
    sctp_assoc_t sinfo_assoc_id;
  };

* 6.1.3. SCTP_REMOTE_ERROR:

  A remote peer may send an Operation Error message to its peer.
  This message indicates a variety of error conditions on an
  association. The entire ERROR chunk as it appears on the wire
  is included in an SCTP_REMOTE_ERROR event. Please refer to the
  SCTP specification [RFC4960] and any extensions for a list of
  possible error formats. An SCTP error notification has the
  following format:

  struct sctp_remote_error {
    uint16_t sre_type;
    uint16_t sre_flags;
    uint32_t sre_length;
    uint16_t sre_error;
    <-- 2 bytes hole  -->
    sctp_assoc_t sre_assoc_id;
    uint8_t  sre_data[];
  };

Fix this by setting both to 0 before filling them out. We also
have other structures shared between user and kernel space in
SCTP that contains holes (e.g. struct sctp_paddrthlds), but we
copy that buffer over from user space first and thus don't need
to care about it in that cases.

While at it, we can also remove lengthy comments copied from
the draft, instead, we update the comment with the correct RFC
number where one can look it up.

Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9de2be6
@kristovschulz kristovschulz net: pppoe: use correct channel MTU when using Multilink PPP
[ Upstream commit a8a3e41 ]

The PPP channel MTU is used with Multilink PPP when ppp_mp_explode() (see
ppp_generic module) tries to determine how big a fragment might be. According
to RFC 1661, the MTU excludes the 2-byte PPP protocol field, see the
corresponding comment and code in ppp_mp_explode():

		/*
		 * hdrlen includes the 2-byte PPP protocol field, but the
		 * MTU counts only the payload excluding the protocol field.
		 * (RFC1661 Section 2)
		 */
		mtu = pch->chan->mtu - (hdrlen - 2);

However, the pppoe module *does* include the PPP protocol field in the channel
MTU, which is wrong as it causes the PPP payload to be 1-2 bytes too big under
certain circumstances (one byte if PPP protocol compression is used, two
otherwise), causing the generated Ethernet packets to be dropped. So the pppoe
module has to subtract two bytes from the channel MTU. This error only
manifests itself when using Multilink PPP, as otherwise the channel MTU is not
used anywhere.

In the following, I will describe how to reproduce this bug. We configure two
pppd instances for multilink PPP over two PPPoE links, say eth2 and eth3, with
a MTU of 1492 bytes for each link and a MRRU of 2976 bytes. (This MRRU is
computed by adding the two link MTUs and subtracting the MP header twice, which
is 4 bytes long.) The necessary pppd statements on both sides are "multilink
mtu 1492 mru 1492 mrru 2976". On the client side, we additionally need "plugin
rp-pppoe.so eth2" and "plugin rp-pppoe.so eth3", respectively; on the server
side, we additionally need to start two pppoe-server instances to be able to
establish two PPPoE sessions, one over eth2 and one over eth3. We set the MTU
of the PPP network interface to the MRRU (2976) on both sides of the connection
in order to make use of the higher bandwidth. (If we didn't do that, IP
fragmentation would kick in, which we want to avoid.)

Now we send a ICMPv4 echo request with a payload of 2948 bytes from client to
server over the PPP link. This results in the following network packet:

   2948 (echo payload)
 +    8 (ICMPv4 header)
 +   20 (IPv4 header)
---------------------
   2976 (PPP payload)

These 2976 bytes do not exceed the MTU of the PPP network interface, so the
IP packet is not fragmented. Now the multilink PPP code in ppp_mp_explode()
prepends one protocol byte (0x21 for IPv4), making the packet one byte bigger
than the negotiated MRRU. So this packet would have to be divided in three
fragments. But this does not happen as each link MTU is assumed to be two bytes
larger. So this packet is diveded into two fragments only, one of size 1489 and
one of size 1488. Now we have for that bigger fragment:

   1489 (PPP payload)
 +    4 (MP header)
 +    2 (PPP protocol field for the MP payload (0x3d))
 +    6 (PPPoE header)
--------------------------
   1501 (Ethernet payload)

This packet exceeds the link MTU and is discarded.

If one configures the link MTU on the client side to 1501, one can see the
discarded Ethernet frames with tcpdump running on the client. A

ping -s 2948 -c 1 192.168.15.254

leads to the smaller fragment that is correctly received on the server side:

(tcpdump -vvvne -i eth3 pppoes and ppp proto 0x3d)
52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
  length 1514: PPPoE  [ses 0x3] MLPPP (0x003d), length 1494: seq 0x000,
  Flags [end], length 1492

and to the bigger fragment that is not received on the server side:

(tcpdump -vvvne -i eth2 pppoes and ppp proto 0x3d)
52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
  length 1515: PPPoE  [ses 0x5] MLPPP (0x003d), length 1495: seq 0x000,
  Flags [begin], length 1493

With the patch below, we correctly obtain three fragments:

52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
  length 1514: PPPoE  [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
  Flags [begin], length 1492
52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
  length 1514: PPPoE  [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
  Flags [none], length 1492
52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
  length 27: PPPoE  [ses 0x1] MLPPP (0x003d), length 7: seq 0x000,
  Flags [end], length 5

And the ICMPv4 echo request is successfully received at the server side:

IP (tos 0x0, ttl 64, id 21925, offset 0, flags [DF], proto ICMP (1),
  length 2976)
    192.168.222.2 > 192.168.15.254: ICMP echo request, id 30530, seq 0,
      length 2956

The bug was introduced in commit c9aa689
("[PPPOE]: Advertise PPPoE MTU") from the very beginning. This patch applies
to 3.10 upwards but the fix can be applied (with minor modifications) to
kernels as old as 2.6.32.

Signed-off-by: Christoph Schulz <develop@kristov.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
48b83df
@sowminiv sowminiv sunvnet: clean up objects created in vnet_new() on vnet_exit()
[ Upstream commit a4b70a0 ]

Nothing cleans up the objects created by
vnet_new(), they are completely leaked.

vnet_exit(), after doing the vio_unregister_driver() to clean
up ports, should call a helper function that iterates over vnet_list
and cleans up those objects. This includes unregister_netdevice()
as well as free_netdev().

Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Reviewed-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>
7670d47
Hugh Dickins shmem: fix splicing from a hole while it's punched
commit b1a3665 upstream.

shmem_fault() is the actual culprit in trinity's hole-punch starvation,
and the most significant cause of such problems: since a page faulted is
one that then appears page_mapped(), needing unmap_mapping_range() and
i_mmap_mutex to be unmapped again.

But it is not the only way in which a page can be brought into a hole in
the radix_tree while that hole is being punched; and Vlastimil's testing
implies that if enough other processors are busy filling in the hole,
then shmem_undo_range() can be kept from completing indefinitely.

shmem_file_splice_read() is the main other user of SGP_CACHE, which can
instantiate shmem pagecache pages in the read-only case (without holding
i_mutex, so perhaps concurrently with a hole-punch).  Probably it's
silly not to use SGP_READ already (using the ZERO_PAGE for holes): which
ought to be safe, but might bring surprises - not a change to be rushed.

shmem_read_mapping_page_gfp() is an internal interface used by
drivers/gpu/drm GEM (and next by uprobes): it should be okay.  And
shmem_file_read_iter() uses the SGP_DIRTY variant of SGP_CACHE, when
called internally by the kernel (perhaps for a stacking filesystem,
which might rely on holes to be reserved): it's unclear whether it could
be provoked to keep hole-punch busy or not.

We could apply the same umbrella as now used in shmem_fault() to
shmem_file_splice_read() and the others; but it looks ugly, and use over
a range raises questions - should it actually be per page? can these get
starved themselves?

The origin of this part of the problem is my v3.1 commit d082357
("mm: pincer in truncate_inode_pages_range"), once it was duplicated
into shmem.c.  It seemed like a nice idea at the time, to ensure
(barring RCU lookup fuzziness) that there's an instant when the entire
hole is empty; but the indefinitely repeated scans to ensure that make
it vulnerable.

Revert that "enhancement" to hole-punch from shmem_undo_range(), but
retain the unproblematic rescanning when it's truncating; add a couple
of comments there.

Remove the "indices[0] >= end" test: that is now handled satisfactorily
by the inner loop, and mem_cgroup_uncharge_start()/end() are too light
to be worth avoiding here.

But if we do not always loop indefinitely, we do need to handle the case
of swap swizzled back to page before shmem_free_swap() gets it: add a
retry for that case, as suggested by Konstantin Khlebnikov; and for the
case of page swizzled back to swap, as suggested by Johannes Weiner.

Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Lukas Czerner <lczerner@redhat.com>
Cc: Dave Jones <davej@redhat.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>
21618a8
Takao Indoh iommu/vt-d: Disable translation if already enabled
commit 3a93c84 upstream.

This patch disables translation(dma-remapping) before its initialization
if it is already enabled.

This is needed for kexec/kdump boot. If dma-remapping is enabled in the
first kernel, it need to be disabled before initializing its page table
during second kernel boot. Wei Hu also reported that this is needed
when second kernel boots with intel_iommu=off.

Basically iommu->gcmd is used to know whether translation is enabled or
disabled, but it is always zero at boot time even when translation is
enabled since iommu->gcmd is initialized without considering such a
case. Therefor this patch synchronizes iommu->gcmd value with global
command register when iommu structure is allocated.

Signed-off-by: Takao Indoh <indou.takao@jp.fujitsu.com>
Signed-off-by: Joerg Roedel <joro@8bytes.org>
[wyj: Backported to 3.4: adjust context]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
21870a3
Amitkumar Karwar mwifiex: fix Tx timeout issue
commit d76744a upstream.

https://bugzilla.kernel.org/show_bug.cgi?id=70191
https://bugzilla.kernel.org/show_bug.cgi?id=77581

It is observed that sometimes Tx packet is downloaded without
adding driver's txpd header. This results in firmware parsing
garbage data as packet length. Sometimes firmware is unable
to read the packet if length comes out as invalid. This stops
further traffic and timeout occurs.

The root cause is uninitialized fields in tx_info(skb->cb) of
packet used to get garbage values. In this case if
MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd
header was skipped. This patch makes sure that tx_info is
correctly initialized to fix the problem.

Reported-by: Andrew Wiley <wiley.andrew.j@gmail.com>
Reported-by: Linus Gasser <list@markas-al-nour.org>
Reported-by: Michael Hirsch <hirsch@teufel.de>
Tested-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Maithili Hinge <maithili@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ed37976
@d-hatayama d-hatayama perf/x86/intel: ignore CondChgd bit to avoid false NMI handling
commit b292d7a upstream.

Currently, any NMI is falsely handled by a NMI handler of NMI watchdog
if CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR is set.

For example, we use external NMI to make system panic to get crash
dump, but in this case, the external NMI is falsely handled do to the
issue.

This commit deals with the issue simply by ignoring CondChgd bit.

Here is explanation in detail.

On x86 NMI watchdog uses performance monitoring feature to
periodically signal NMI each time performance counter gets overflowed.

intel_pmu_handle_irq() is called as a NMI_LOCAL handler from a NMI
handler of NMI watchdog, perf_event_nmi_handler(). It identifies an
owner of a given NMI by looking at overflow status bits in
MSR_CORE_PERF_GLOBAL_STATUS MSR. If some of the bits are set, then it
handles the given NMI as its own NMI.

The problem is that the intel_pmu_handle_irq() doesn't distinguish
CondChgd bit from other bits. Unlike the other status bits, CondChgd
bit doesn't represent overflow status for performance counters. Thus,
CondChgd bit cannot be thought of as a mark indicating a given NMI is
NMI watchdog's.

As a result, if CondChgd bit is set, any NMI is falsely handled by the
NMI handler of NMI watchdog. Also, if type of the falsely handled NMI
is either NMI_UNKNOWN, NMI_SERR or NMI_IO_CHECK, the corresponding
action is never performed until CondChgd bit is cleared.

I noticed this behavior on systems with Ivy Bridge processors: Intel
Xeon CPU E5-2630 v2 and Intel Xeon CPU E7-8890 v2. On both systems,
CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR has already been set
in the beginning at boot. Then the CondChgd bit is immediately cleared
by next wrmsr to MSR_CORE_PERF_GLOBAL_CTRL MSR and appears to remain
0.

On the other hand, on older processors such as Nehalem, Xeon E7540,
CondChgd bit is not set in the beginning at boot.

I'm not sure about exact behavior of CondChgd bit, in particular when
this bit is set. Although I read Intel System Programmer's Manual to
figure out that, the descriptions I found are:

  In 18.9.1:

  "The MSR_PERF_GLOBAL_STATUS MSR also provides a ¡sticky bit¢ to
   indicate changes to the state of performancmonitoring hardware"

  In Table 35-2 IA-32 Architectural MSRs

  63 CondChg: status bits of this register has changed.

These are different from the bahviour I see on the actual system as I
explained above.

At least, I think ignoring CondChgd bit should be enough for NMI
watchdog perspective.

Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/20140625.103503.409316067.d.hatayama@jp.fujitsu.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
a2b2c03
@johnstultz-work johnstultz-work alarmtimer: Fix bug where relative alarm timers were treated as absolute
commit 1692777 upstream.

Sharvil noticed with the posix timer_settime interface, using the
CLOCK_REALTIME_ALARM or CLOCK_BOOTTIME_ALARM clockid, if the users
tried to specify a relative time timer, it would incorrectly be
treated as absolute regardless of the state of the flags argument.

This patch corrects this, properly checking the absolute/relative flag,
as well as adds further error checking that no invalid flag bits are set.

Reported-by: Sharvil Nanavati <sharvil@google.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Sharvil Nanavati <sharvil@google.com>
Link: http://lkml.kernel.org/r/1404767171-6902-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
299e667
Alex Deucher drm/radeon: avoid leaking edid data
commit 0ac66ef upstream.

In some cases we fetch the edid in the detect() callback
in order to determine what sort of monitor is connected.
If that happens, don't fetch the edid again in the get_modes()
callback or we will leak the edid.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
b63dd4c
@tiwai tiwai PM / sleep: Fix request_firmware() error at resume
commit 4320f6b upstream.

The commit [247bc03: PM / Sleep: Mitigate race between the freezer
and request_firmware()] introduced the finer state control, but it
also leads to a new bug; for example, a bug report regarding the
firmware loading of intel BT device at suspend/resume:
  https://bugzilla.novell.com/show_bug.cgi?id=873790

The root cause seems to be a small window between the process resume
and the clear of usermodehelper lock.  The request_firmware() function
checks the UMH lock and gives up when it's in UMH_DISABLE state.  This
is for avoiding the invalid  f/w loading during suspend/resume phase.
The problem is, however, that usermodehelper_enable() is called at the
end of thaw_processes().  Thus, a thawed process in between can kick
off the f/w loader code path (in this case, via btusb_setup_intel())
even before the call of usermodehelper_enable().  Then
usermodehelper_read_trylock() returns an error and request_firmware()
spews WARN_ON() in the end.

This oneliner patch fixes the issue just by setting to UMH_FREEZING
state again before restarting tasks, so that the call of
request_firmware() will be blocked until the end of this function
instead of returning an error.

Fixes: 247bc03 (PM / Sleep: Mitigate race between the freezer and request_firmware())
Link: https://bugzilla.novell.com/show_bug.cgi?id=873790
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5dc1c88
@bwhacks bwhacks dns_resolver: Null-terminate the right string
[ Upstream commit 640d7ef ]

*_result[len] is parsed as *(_result[len]) which is not at all what we
want to touch here.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: 84a7c0b ("dns_resolver: assure that dns_query() result is null-terminated")
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
4427f9a
Eric Dumazet ipv4: fix buffer overflow in ip_options_compile()
[ Upstream commit 10ec947 ]

There is a benign buffer overflow in ip_options_compile spotted by
AddressSanitizer[1] :

Its benign because we always can access one extra byte in skb->head
(because header is followed by struct skb_shared_info), and in this case
this byte is not even used.

[28504.910798] ==================================================================
[28504.912046] AddressSanitizer: heap-buffer-overflow in ip_options_compile
[28504.913170] Read of size 1 by thread T15843:
[28504.914026]  [<ffffffff81802f91>] ip_options_compile+0x121/0x9c0
[28504.915394]  [<ffffffff81804a0d>] ip_options_get_from_user+0xad/0x120
[28504.916843]  [<ffffffff8180dedf>] do_ip_setsockopt.isra.15+0x8df/0x1630
[28504.918175]  [<ffffffff8180ec60>] ip_setsockopt+0x30/0xa0
[28504.919490]  [<ffffffff8181e59b>] tcp_setsockopt+0x5b/0x90
[28504.920835]  [<ffffffff8177462f>] sock_common_setsockopt+0x5f/0x70
[28504.922208]  [<ffffffff817729c2>] SyS_setsockopt+0xa2/0x140
[28504.923459]  [<ffffffff818cfb69>] system_call_fastpath+0x16/0x1b
[28504.924722]
[28504.925106] Allocated by thread T15843:
[28504.925815]  [<ffffffff81804995>] ip_options_get_from_user+0x35/0x120
[28504.926884]  [<ffffffff8180dedf>] do_ip_setsockopt.isra.15+0x8df/0x1630
[28504.927975]  [<ffffffff8180ec60>] ip_setsockopt+0x30/0xa0
[28504.929175]  [<ffffffff8181e59b>] tcp_setsockopt+0x5b/0x90
[28504.930400]  [<ffffffff8177462f>] sock_common_setsockopt+0x5f/0x70
[28504.931677]  [<ffffffff817729c2>] SyS_setsockopt+0xa2/0x140
[28504.932851]  [<ffffffff818cfb69>] system_call_fastpath+0x16/0x1b
[28504.934018]
[28504.934377] The buggy address ffff880026382828 is located 0 bytes to the right
[28504.934377]  of 40-byte region [ffff880026382800, ffff880026382828)
[28504.937144]
[28504.937474] Memory state around the buggy address:
[28504.938430]  ffff880026382300: ........ rrrrrrrr rrrrrrrr rrrrrrrr
[28504.939884]  ffff880026382400: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28504.941294]  ffff880026382500: .....rrr rrrrrrrr rrrrrrrr rrrrrrrr
[28504.942504]  ffff880026382600: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28504.943483]  ffff880026382700: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28504.944511] >ffff880026382800: .....rrr rrrrrrrr rrrrrrrr rrrrrrrr
[28504.945573]                         ^
[28504.946277]  ffff880026382900: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.094949]  ffff880026382a00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.096114]  ffff880026382b00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.097116]  ffff880026382c00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.098472]  ffff880026382d00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.099804] Legend:
[28505.100269]  f - 8 freed bytes
[28505.100884]  r - 8 redzone bytes
[28505.101649]  . - 8 allocated bytes
[28505.102406]  x=1..7 - x allocated bytes + (8-x) redzone bytes
[28505.103637] ==================================================================

[1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
26adeae
redpig and others added some commits
@redpig redpig Documentation: prctl/seccomp_filter
Documents how system call filtering using Berkeley Packet
Filter programs works and how it may be used.
Includes an example for x86 and a semi-generic
example using a macro-based code generator.

Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Will Drewry <wad@chromium.org>

v18: - added acked by
     - update no new privs numbers
v17: - remove @compat note and add Pitfalls section for arch checking
       (keescook@chromium.org)
v16: -
v15: -
v14: - rebase/nochanges
v13: - rebase on to 88ebdda
v12: - comment on the ptrace_event use
     - update arch support comment
     - note the behavior of SECCOMP_RET_DATA when there are multiple filters
       (keescook@chromium.org)
     - lots of samples/ clean up incl 64-bit bpf-direct support
       (markus@chromium.org)
     - rebase to linux-next
v11: - overhaul return value language, updates (keescook@chromium.org)
     - comment on do_exit(SIGSYS)
v10: - update for SIGSYS
     - update for new seccomp_data layout
     - update for ptrace option use
v9: - updated bpf-direct.c for SIGILL
v8: - add PR_SET_NO_NEW_PRIVS to the samples.
v7: - updated for all the new stuff in v7: TRAP, TRACE
    - only talk about PR_SET_SECCOMP now
    - fixed bad JLE32 check (coreyb@linux.vnet.ibm.com)
    - adds dropper.c: a simple system call disabler
v6: - tweak the language to note the requirement of
      PR_SET_NO_NEW_PRIVS being called prior to use. (luto@mit.edu)
v5: - update sample to use system call arguments
    - adds a "fancy" example using a macro-based generator
    - cleaned up bpf in the sample
    - update docs to mention arguments
    - fix prctl value (eparis@redhat.com)
    - language cleanup (rdunlap@xenotime.net)
v4: - update for no_new_privs use
    - minor tweaks
v3: - call out BPF <-> Berkeley Packet Filter (rdunlap@xenotime.net)
    - document use of tentative always-unprivileged
    - guard sample compilation for i386 and x86_64
v2: - move code to samples (corbet@lwn.net)
3e5a21d
@redpig redpig ptrace,seccomp: Add PTRACE_SECCOMP support
This change adds support for a new ptrace option, PTRACE_O_TRACESECCOMP,
and a new return value for seccomp BPF programs, SECCOMP_RET_TRACE.

When a tracer specifies the PTRACE_O_TRACESECCOMP ptrace option, the
tracer will be notified, via PTRACE_EVENT_SECCOMP, for any syscall that
results in a BPF program returning SECCOMP_RET_TRACE.  The 16-bit
SECCOMP_RET_DATA mask of the BPF program return value will be passed as
the ptrace_message and may be retrieved using PTRACE_GETEVENTMSG.

If the subordinate process is not using seccomp filter, then no
system call notifications will occur even if the option is specified.

If there is no tracer with PTRACE_O_TRACESECCOMP when SECCOMP_RET_TRACE
is returned, the system call will not be executed and an -ENOSYS errno
will be returned to userspace.

This change adds a dependency on the system call slow path.  Any future
efforts to use the system call fast path for seccomp filter will need to
address this restriction.

Signed-off-by: Will Drewry <wad@chromium.org>
Acked-by: Eric Paris <eparis@redhat.com>

v18: - rebase
     - comment fatal_signal check
     - acked-by
     - drop secure_computing_int comment
v17: - ...
v16: - update PT_TRACE_MASK to 0xbf4 so that STOP isn't clear on SETOPTIONS call (indan@nul.nu)
       [note PT_TRACE_MASK disappears in linux-next]
v15: - add audit support for non-zero return codes
     - clean up style (indan@nul.nu)
v14: - rebase/nochanges
v13: - rebase on to 88ebdda
       (Brings back a change to ptrace.c and the masks.)
v12: - rebase to linux-next
     - use ptrace_event and update arch/Kconfig to mention slow-path dependency
     - drop all tracehook changes and inclusion (oleg@redhat.com)
v11: - invert the logic to just make it a PTRACE_SYSCALL accelerator
       (indan@nul.nu)
v10: - moved to PTRACE_O_SECCOMP / PT_TRACE_SECCOMP
v9:  - n/a
v8:  - guarded PTRACE_SECCOMP use with an ifdef
v7:  - introduced
f33422b
Stephen Rothwell seccomp: use a static inline for a function stub
Fixes this error message when CONFIG_SECCOMP is not set:

arch/powerpc/kernel/ptrace.c: In function 'do_syscall_trace_enter':
arch/powerpc/kernel/ptrace.c:1713:2: error: statement with no effect [-Werror=unused-value]

Signed-off-by: Stephen Rothwell <sfr@ozlabs.au.ibm.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
ef7720c
@redpig redpig seccomp: ignore secure_computing return values
This change is inspired by
  https://lkml.org/lkml/2012/4/16/14
which fixes the build warnings for arches that don't support
CONFIG_HAVE_ARCH_SECCOMP_FILTER.

In particular, there is no requirement for the return value of
secure_computing() to be checked unless the architecture supports
seccomp filter.  Instead of silencing the warnings with (void)
a new static inline is added to encode the expected behavior
in a compiler and human friendly way.

v2: - cleans things up with a static inline
    - removes sfr's signed-off-by since it is a different approach
v1: - matches sfr's original change

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Will Drewry <wad@chromium.org>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>
dc46412
Sasha Levitskiy Change-Id: I7c9d49079d4e18390c2d520513a4afd55e6eaa3e d4f8f7e
@redpig redpig CHROMIUM: arch/arm: add asm/syscall.h
(I will post this upstream after the 3.5 merge window)

Provide an ARM implementation for asm-generic/syscall.h.
This is a pre-requisite for CONFIG_HAVE_ARCH_TRACEHOOK and
CONFIG_HAVE_ARCH_SECCOMP_FILTER.  The latter is the forcing
function for this patch.

Change-Id: Idc5fa7b72691ec9d75418849733633df33482e53
Signed-off-by: Will Drewry <wad@chromium.org>

BUG=chromium-os:27878
TEST=compiles for arm. Need to test on a live machine.

Change-Id: I7b911b51085424aedd2beaf40683c3348b6cede1
Reviewed-on: https://gerrit.chromium.org/gerrit/21375
Reviewed-by: Will Drewry <wad@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
Signed-off-by: Sasha Levitskiy <sanek@google.com>
1c0d3df
@redpig redpig CHROMIUM: arch/arm: move secure_computing into trace; respect return …
…code

There is very little difference in the TIF_SECCOMP and TIF_SYSCALL_TRACE
patsh in entry-common.S. In order to add support for
CONFIG_HAVE_ARCH_SECCOMP_FILTER without mangling the assembly too
badly, seccomp was moved into the syscall_trace() handler.

Additionally, the return value for secure_computing() is now checked
and a -1 value will result in the system call being skipped.

(Reworked for 3.4 merge to just piggyback on the audit enter path.)

Signed-off-by: Will Drewry <wad@chromium.org>

BUG=chromium-os:27878
TEST=compiles for arm. Need to test on a live machine.

Change-Id: I9493f28c30356a10eccb320e0a2d1a141388af9a
Reviewed-on: https://gerrit.chromium.org/gerrit/21376
Reviewed-by: Will Drewry <wad@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
Signed-off-by: Sasha Levitskiy <sanek@google.com>
66a240a
@redpig redpig CHROMIUM: arch/arm: select HAVE_ARCH_SECCOMP_FILTER
(I will post this upstream after the 3.5 merge window)

Reflect architectural support for seccomp filter.

Change-Id: I163078260e73a8fb7b9967ce740bd21f83902b8e
Signed-off-by: Will Drewry <wad@chromium.org>

BUG=chromium-os:27878
TEST=compiles for arm. Need to test on a live machine.

Change-Id: Ic0286cc7d150838fbfa05e259ea908aeeef1b864
Reviewed-on: https://gerrit.chromium.org/gerrit/21377
Reviewed-by: Will Drewry <wad@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
Signed-off-by: Sasha Levitskiy <sanek@google.com>
0d245c7
@redpig redpig seccomp: fix build warnings when there is no CONFIG_SECCOMP_FILTER
If both audit and seccomp filter support are disabled, 'ret' is marked
as unused.

If just seccomp filter support is disabled, data and skip are considered
unused.

This change fixes those build warnings.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Will Drewry <wad@chromium.org>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>
7119ba4
@redpig redpig samples/seccomp: fix dependencies on arch macros
This change fixes the compilation error reported for
i386 allmodconfig here:
  http://kisskb.ellerman.id.au/kisskb/buildresult/6123842/

Logic attempting to predict the host architecture has been
removed from the Makefile.  Instead, the bpf-direct sample
should now compile on any architecture, but if the architecture
is not supported, it will compile a minimal main() function.

This change also ensures the samples are not compiled when
there is no seccomp filter support.

Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Suggested-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Will Drewry <wad@chromium.org>
0d38273
@redpig redpig CHROMIUM: ARM: arch/arm: allow a scno of -1 to not cause a SIGILL
On tracehook-friendly platforms, a system call number of -1 falls
through without running much code or taking much action.

ARM is different.  This adds a lightweight check to arm_syscall()
to make sure that ARM behaves the same way.

Signed-off-by: Will Drewry <wad@chromium.org>
TEST=building on tegra2 now. Will live test with seccomp testsuite. It was through SIGILL.
BUG=chromium-os:27878

Change-Id: Ie3896b54e9bfa21c22e0df456a47ad03c8d0aa3f
Reviewed-on: https://gerrit.chromium.org/gerrit/21251
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
Signed-off-by: Sasha Levitskiy <sanek@google.com>
b99d845
@redpig redpig CHROMIUM: seccomp: set -ENOSYS if there is no tracer
[Will attempt to add to -next, but this may need to wait
 until there is a motivating usecase, like ARM, since x86
 does the right thing already.]

On some arches, -ENOSYS is not set as the default system call
return value.  This means that a skipped or invalid system call
does not yield this response.  That behavior is not inline with
the stated ABI of seccomp filter.  To that end, we ensure we set
that value here to avoid arch idiosyncrasies.

Signed-off-by: Will Drewry <wad@chromium.org>
TEST=tegra2_kaen; boot, strace works, seccomp testsuite  trace tests pass
BUG=chromium-os:27878

Change-Id: I03a5e633d2fbb5d3d3cc33c067b2887068364c17
Reviewed-on: https://gerrit.chromium.org/gerrit/21337
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
Signed-off-by: Sasha Levitskiy <sanek@google.com>
2e48e52
@redpig redpig CHROMIUM: ARM: r1->r0 for get/set arguments
ARM reuses r0 as the first argument. This fixes the mistaken
assumption in the original patchset.  These will be merged
into one change when sent upstream.

Signed-off-by: Will Drewry <wad@chromium.org>
TEST=emerge tegra2_kaen; run seccomp testsuite
BUG=chromium-os:27878

Change-Id: Iaaa09995d35f78ee8cef7b600d526e71f3b2fcec
Reviewed-on: https://gerrit.chromium.org/gerrit/21342
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
Signed-off-by: Sasha Levitskiy <sanek@google.com>
4e93e06
@kees kees seccomp: create internal mode-setting function
In preparation for having other callers of the seccomp mode setting
logic, split the prctl entry point away from the core logic that performs
seccomp mode setting.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>
1cf256f
@kees kees seccomp: extract check/assign mode helpers
To support splitting mode 1 from mode 2, extract the mode checking and
assignment logic into common functions.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>
bd8e1ca
@kees kees MAINTAINERS: create seccomp entry
Add myself as seccomp maintainer.

Suggested-by: James Morris <jmorris@namei.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
5255fd2
@kees kees sched: move no_new_privs into new atomic flags
Since seccomp transitions between threads requires updates to the
no_new_privs flag to be atomic, the flag must be part of an atomic flag
set. This moves the nnp flag into a separate task field, and introduces
accessors.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>

Conflicts:
	fs/exec.c
	include/linux/sched.h
	kernel/sys.c
db8ca0a
@kees kees ARM: add seccomp syscall
Wires up the new seccomp syscall.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>

Conflicts:
	arch/arm/include/uapi/asm/unistd.h
	arch/arm/kernel/calls.S
13b77e1
@kees kees seccomp: split mode setting routines
Separates the two mode setting paths to make things more readable with
fewer #ifdefs within function bodies.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>
4adf2cd
@kees kees seccomp: add "seccomp" syscall
This adds the new "seccomp" syscall with both an "operation" and "flags"
parameter for future expansion. The third argument is a pointer value,
used with the SECCOMP_SET_MODE_FILTER operation. Currently, flags must
be 0. This is functionally equivalent to prctl(PR_SET_SECCOMP, ...).

In addition to the TSYNC flag later in this patch series, there is a
non-zero chance that this syscall could be used for configuring a fixed
argument area for seccomp-tracer-aware processes to pass syscall arguments
in the future. Hence, the use of "seccomp" not simply "seccomp_add_filter"
for this syscall. Additionally, this syscall uses operation, flags,
and user pointer for arguments because strictly passing arguments via
a user pointer would mean seccomp itself would be unable to trivially
filter the seccomp syscall itself.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>

Conflicts:
	arch/x86/syscalls/syscall_32.tbl
	arch/x86/syscalls/syscall_64.tbl
	include/linux/syscalls.h
	include/uapi/asm-generic/unistd.h
	include/uapi/linux/seccomp.h
	kernel/seccomp.c
	kernel/sys_ni.c
64d484e
@kees kees seccomp: split filter prep from check and apply
In preparation for adding seccomp locking, move filter creation away
from where it is checked and applied. This will allow for locking where
no memory allocation is happening. The validation, filter attachment,
and seccomp mode setting can all happen under the future locks.

For extreme defensiveness, I've added a BUG_ON check for the calculated
size of the buffer allocation in case BPF_MAXINSN ever changes, which
shouldn't ever happen. The compiler should actually optimize out this
check since the test above it makes it impossible.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>

Conflicts:
	kernel/seccomp.c
850c366
@utrace utrace introduce for_each_thread() to replace the buggy while_each_thread()
while_each_thread() and next_thread() should die, almost every lockless
usage is wrong.

1. Unless g == current, the lockless while_each_thread() is not safe.

   while_each_thread(g, t) can loop forever if g exits, next_thread()
   can't reach the unhashed thread in this case. Note that this can
   happen even if g is the group leader, it can exec.

2. Even if while_each_thread() itself was correct, people often use
   it wrongly.

   It was never safe to just take rcu_read_lock() and loop unless
   you verify that pid_alive(g) == T, even the first next_thread()
   can point to the already freed/reused memory.

This patch adds signal_struct->thread_head and task->thread_node to
create the normal rcu-safe list with the stable head.  The new
for_each_thread(g, t) helper is always safe under rcu_read_lock() as
long as this task_struct can't go away.

Note: of course it is ugly to have both task_struct->thread_node and the
old task_struct->thread_group, we will kill it later, after we change
the users of while_each_thread() to use for_each_thread().

Perhaps we can kill it even before we convert all users, we can
reimplement next_thread(t) using the new thread_head/thread_node.  But
we can't do this right now because this will lead to subtle behavioural
changes.  For example, do/while_each_thread() always sees at least one
task, while for_each_thread() can do nothing if the whole thread group
has died.  Or thread_group_empty(), currently its semantics is not clear
unless thread_group_leader(p) and we need to audit the callers before we
can change it.

So this patch adds the new interface which has to coexist with the old
one for some time, hopefully the next changes will be more or less
straightforward and the old one will go away soon.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Sergey Dyasly <dserrg@gmail.com>
Tested-by: Sergey Dyasly <dserrg@gmail.com>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Acked-by: David Rientjes <rientjes@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mandeep Singh Baines <msb@chromium.org>
Cc: "Ma, Xindong" <xindong.ma@intel.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: "Tu, Xiaobing" <xiaobing.tu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Conflicts:
	kernel/fork.c
4202973
@kees kees seccomp: implement SECCOMP_FILTER_FLAG_TSYNC
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code that is linked in). While it is
possible to apply permissive programs prior to process start up, it is
difficult to further restrict the kernel ABI to those threads after that
point.

This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for
synchronizing thread group seccomp filters at filter installation time.

When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC,
filter) an attempt will be made to synchronize all threads in current's
threadgroup to its new seccomp filter program. This is possible iff all
threads are using a filter that is an ancestor to the filter current is
attempting to synchronize to. NULL filters (where the task is running as
SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be
transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS,
...) has been set on the calling thread, no_new_privs will be set for
all synchronized threads too. On success, 0 is returned. On failure,
the pid of one of the failing threads will be returned and no filters
will have been applied.

The race conditions against another thread are:
- requesting TSYNC (already handled by sighand lock)
- performing a clone (already handled by sighand lock)
- changing its filter (already handled by sighand lock)
- calling exec (handled by cred_guard_mutex)
The clone case is assisted by the fact that new threads will have their
seccomp state duplicated from their parent before appearing on the tasklist.

Holding cred_guard_mutex means that seccomp filters cannot be assigned
while in the middle of another thread's exec (potentially bypassing
no_new_privs or similar). The call to de_thread() may kill threads waiting
for the mutex.

Changes across threads to the filter pointer includes a barrier.

Based on patches by Will Drewry.

Suggested-by: Julien Tinnes <jln@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>

Conflicts:
	include/linux/seccomp.h
	include/uapi/linux/seccomp.h
f1a3422
@kees kees seccomp: allow mode setting across threads
This changes the mode setting helper to allow threads to change the
seccomp mode from another thread. We must maintain barriers to keep
TIF_SECCOMP synchronized with the rest of the seccomp state.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>

Conflicts:
	kernel/seccomp.c
a4c269c
@kees kees seccomp: introduce writer locking
Normally, task_struct.seccomp.filter is only ever read or modified by
the task that owns it (current). This property aids in fast access
during system call filtering as read access is lockless.

Updating the pointer from another task, however, opens up race
conditions. To allow cross-thread filter pointer updates, writes to the
seccomp fields are now protected by the sighand spinlock (which is shared
by all threads in the thread group). Read access remains lockless because
pointer updates themselves are atomic.  However, writes (or cloning)
often entail additional checking (like maximum instruction counts)
which require locking to perform safely.

In the case of cloning threads, the child is invisible to the system
until it enters the task list. To make sure a child can't be cloned from
a thread and left in a prior state, seccomp duplication is additionally
moved under the sighand lock. Then parent and child are certain have
the same seccomp state when they exit the lock.

Based on patches by Will Drewry and David Drysdale.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>

Conflicts:
	kernel/fork.c
4cad9be
@rsesek rsesek seccomp: Use atomic operations that are present in kernel 3.4.
Signed-off-by: Robert Sesek <rsesek@google.com>
a94cffc
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
Trond Myklebust 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
@dvdhrm dvdhrm HID: input: generic hidinput_input_event handler
The hidinput_input_event() callback converts input events written from
userspace into HID reports and sends them to the device. We currently
implement this in every HID transport driver, even though most of them do
the same.

This provides a generic hidinput_input_event() implementation which is
mostly copied from usbhid. It uses a delayed worker to allow multiple LED
events to be collected into a single output event.
We use the custom ->request() transport driver callback to allow drivers
to adjust the outgoing report and handle the request asynchronously. If no
custom ->request() callback is available, we fall back to the generic raw
output report handler (which is synchronous).

Drivers can still provide custom hidinput_input_event() handlers (see
logitech-dj) if the generic implementation doesn't fit their needs.

Conflicts:
	drivers/hid/hid-input.c

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Michael Wright <michaelwr@google.com>
Change-Id: I89ccc3f675b3e8a7bbd812a6ebe12588d737cfd6
0b20c61
@paulkocialkowski paulkocialkowski sun4i-keyboard: 250Hz LRADC sampling
This is required to have fast enough key presses with sun4i-keyboard
(actually used on sun4i, sun5i and sun7i) on CWM recovery, an Android
initramfs that allows easy flashing of the devices. With any lower
sampling rate, close key presses are not distinguished and reported
as one long press.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
c4901d9
@ssvb ssvb sunxi: axp209: Protect dcdc3 voltage from modification
The dcdc3 voltage is expected to be set by the bootloader and the right
voltage depends on the DRAM settings (higher clock speed needs more
voltage). Allowing to use the 'dcdc3_vol' parameter from the FEX file
only introduces an unnecessary fragile dependency between the settings
in u-boot and the settings in FEX. So now we ignore this parameter in
FEX and keep the original dcdc3 voltage set by the bootloader.

The dmesg log now looks like this:

[    2.212941] axp20_ldo1: 1300 mV
[    2.221370] axp20_ldo2: 1800 <--> 3300 mV at 3000 mV
[    2.231662] axp20_ldo3: 700 <--> 3500 mV at 2800 mV
[    2.241747] axp20_ldo4: 1250 <--> 3300 mV at 2800 mV
[    2.251906] axp20_buck2: 700 <--> 2275 mV at 1400 mV
[    2.263430] somebody is trying to set dcdc3 range to (1300000, 1300000) uV
[    2.275327] but we keep dcdc3 = 1250000 uV from the bootloader
[    2.285406] axp20_buck3: 700 <--> 3500 mV at 1250 mV
[    2.295299] axp20_ldoio0: 1800 <--> 3300 mV at 2800 mV

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
5052b83
@ssvb ssvb sunxi: Calculate PLL5P clock divisors for G2D, ACE and DEBE
When PLL5P is used as a parent clock for some of the peripherals,
the current code just selects some hardcoded divisors. This happens
to work, but only under assumption that the PLL5P clock speed is
somewhere between 360MHz and 480MHz (the typical DRAM clock speeds).

However with some tweaks for the DRAM parameters, it is possible to
clock DRAM up to 600MHz and more on some devices:

    http://lists.denx.de/pipermail/u-boot/2014-July/183981.html

And this introduces concerns about the hardcoded divisors in the
kernel, which may cause some peripherals to operate at abnormally
high clock speeds if the PLL5 clock speed is too fast (PLL5 is used
for clocking DRAM).

Moreover, it makes sense to avoid pre-dividing PLL5P and make it run
even faster than DRAM. This provides better granularity of the clock
speed selection for MBUS, G2D and everything else that is using PLL5P
as the parent clock. but running PLL5P faster means that the hardcoded
divisors become even more inappropriate.

This patch improves the clock divisors selection for G2D, ACE and
DEBE to insure that they can work correctly with any PLL5P clock
speed.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
9a1cd03
Ruchi Kandoi power: Avoids bogus error messages for the suspend aborts.
Avoids printing bogus error message "tasks refusing to freeze", in cases
where pending wakeup source caused the suspend abort.

Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Change-Id: I913ad290f501b31cd536d039834c8d24c6f16928
e4ac161
Ruchi Kandoi cpufreq: Avoid using global variable total_cpus
The change is to compile on kernels where cpufreq stats are compiled as
a module (CONFIG_CPU_FREQ_STAT=m), because total_cpus is not exported for
module use.

Reported-By: Emilio López <elopez93@gmail.com>
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Change-Id: I4f3c74f0fac5e8d9449655b26bf3b407b0fe4290
e01bd6b
@amery amery Merge tag 'v3.4.104' into reference-3.4
This is the 3.4.104 stable release
a4df1cd
@amery amery Merge remote-tracking branch 'origin/mirror/android-3.4' into referen…
…ce-3.4
7cf03b1
@amery amery Merge branch 'reference-3.4' into stage/sunxi-3.4 a8f8ba9
@amery amery Revert "driver-core: cpu: export total_cpus to fix CPU_FREQ_STAT=m bu…
…ild"

This reverts commit 83af551.
fde9bcc
Eddy Beaupre SUNXI-GMAC driver logs every vlan frame...
Hello!

Don't know if i'm the only one who's using vlan with sunxi-gmac, but the
current driver is terribly spammy for the logs, it log every single vlan
frame at the INFO level. Personally i don't think that information is
useful at all but if you want to keep it enable, it should log it at the
DEBUG level instead. So i propose this little simple modification to the
source (or better, remove the whole line.):
d5b9172
@tisdall tisdall remove sunxi_nand from sun7i_defconfig
There's a known issue with sunxi_nand on A20 devices where
it will try to read a NAND chip and then make modifications
such that it becomes corrupted.  Until this situation is
resolved, the module should _not_ be included in the defconfig
for A20 devices.

Signed-off-by: Tim Tisdall <tisdall@gmail.com>
Acked-by: Luc Verhaegen <libv@skynet.be>
2e1c5c5
@rellla rellla Sunxi SATA driver should be built in-kernel in order to allow root fi…
…lesystems on sata per default.
cc0e490
@rellla rellla Cleanup sun7i_defconfig based on sun4i_defconfig. 50ca729
@kvalo kvalo added a commit to kvalo/ath that referenced this pull request
Michal Kazior ath10k: avoid possible deadlock with scan timeout
This should prevent deadlock predicted by the
following splat:

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.17.0-wl-ath+ #67 Not tainted
 -------------------------------------------------------
 kworker/u32:1/7230 is trying to acquire lock:
  (&ar->conf_mutex){+.+.+.}, at: [<ffffffffa040a57d>] ath10k_scan_timeout_work+0x2d/0x50 [ath10k_core]

 but task is already holding lock:
  ((&(&ar->scan.timeout)->work)){+.+...}, at: [<ffffffff8106dae1>] process_one_work+0x151/0x470

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 ((&(&ar->scan.timeout)->work)){+.+...}:
        [<ffffffff810a12e5>] lock_acquire+0x85/0x100
        [<ffffffff8106cb4d>] flush_work+0x3d/0x270
        [<ffffffff8106e49d>] __cancel_work_timer+0x7d/0x110
        [<ffffffff8106e543>] cancel_delayed_work_sync+0x13/0x20
        [<ffffffffa0409f16>] ath10k_cancel_remain_on_channel+0x36/0x60 [ath10k_core]
        [<ffffffffa028c75c>] ieee80211_cancel_roc+0x1cc/0x2f0 [mac80211]
        [<ffffffffa028c8a2>] ieee80211_mgmt_tx_cancel_wait+0x22/0x30 [mac80211]
        [<ffffffffa0132288>] nl80211_tx_mgmt_cancel_wait+0xa8/0x130 [cfg80211]
        [<ffffffff816654a5>] genl_family_rcv_msg+0x1a5/0x3c0
        [<ffffffff81665749>] genl_rcv_msg+0x89/0xc0
        [<ffffffff81664e91>] netlink_rcv_skb+0xb1/0xc0
        [<ffffffff816650bc>] genl_rcv+0x2c/0x40
        [<ffffffff8166474d>] netlink_unicast+0x18d/0x200
        [<ffffffff81664add>] netlink_sendmsg+0x31d/0x430
        [<ffffffff8161a9ac>] sock_sendmsg+0x9c/0xd0
        [<ffffffff8161b469>] ___sys_sendmsg+0x389/0x3a0
        [<ffffffff8161bed9>] __sys_sendmsg+0x49/0x90
        [<ffffffff8161bf32>] SyS_sendmsg+0x12/0x20
        [<ffffffff8174c456>] system_call_fastpath+0x1a/0x1f

 -> #0 (&ar->conf_mutex){+.+.+.}:
        [<ffffffff810a0bde>] __lock_acquire+0x1b6e/0x1ce0
        [<ffffffff810a12e5>] lock_acquire+0x85/0x100
        [<ffffffff817491eb>] mutex_lock_nested+0x4b/0x370
        [<ffffffffa040a57d>] ath10k_scan_timeout_work+0x2d/0x50 [ath10k_core]
        [<ffffffff8106db41>] process_one_work+0x1b1/0x470
        [<ffffffff8106df63>] worker_thread+0x123/0x460
        [<ffffffff81073f34>] kthread+0xe4/0x100
        [<ffffffff8174c3ac>] ret_from_fork+0x7c/0xb0

 other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock((&(&ar->scan.timeout)->work));
                                lock(&ar->conf_mutex);
                                lock((&(&ar->scan.timeout)->work));
   lock(&ar->conf_mutex);

  *** DEADLOCK ***

Reported-by: Marek Puzyniak <marek.puzyniak@tieto.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
4eb2e16
rellla and others added some commits
@rellla rellla arm:sunxi:defconfig: Re-Enable symmetric multiprocessing for sun7i
Signed-off-by: Andreas Baierl<ichgeh@imkreisrum.de>
Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
1bffd2c
@rellla rellla arm:sunxi:defconfig: Enable CONFIG_FHANDLE required for systemd >= 209
Signed-off-by: Andreas Baierl<ichgeh@imkreisrum.de>
Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
c9ec08b
@jwrdegoede jwrdegoede sunxi: axp152: Keep DRAM / Vddr at bootloader set value
Some fex files contain wrong values, causing stability issues.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
c4c4664
@jwrdegoede jwrdegoede sunxi: nand: Fix nand clk calculation
Before the u-boot dram cleanup u-boot would always set PLL5 factor m to
2 (reg value 1) and div p to 1, and get_cmu_clk in the nand code
would calculate the pll5p clk like this:

clk = 24 * factor_n * factor_k / div_p / factor_m;

aka:

clk = 24 * factor_n * factor_k / (div_p * factor_m);

This is wrong however, factor_m is not used to calculate pll5p, and div_p is
not a straight divider, but it divides by 2 ^ div_p. Since with the m == 2 and
p == 1 settings used before the dram cleanup, this happend to do the right
thing in the form of dividing by 2. But with the new dram code div_p is 0,
and then the old get_cmu_clk code fails with a divide by 0 error.

This commit fixes this, by changing the clk calculation to the correct form of:

clk = (24 * factor_n * factor_k) >> div_p;

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
ade08aa
@aryabinin aryabinin referenced this pull request in aryabinin/linux
mmotm auto import linux-next
GIT c04878ff13662bf8e5361d3f96ce3e38bf3bf1f2

commit c04878ff13662bf8e5361d3f96ce3e38bf3bf1f2
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Wed Nov 19 18:49:07 2014 +1100

    sparc: io: fix for implement dummy relaxed accessor macros for writes
    
    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

commit 882407763830dd34fc527dc96998bd4d124ed799
Author: Matthew Garrett <matthew.garrett@nebula.com>
Date:   Tue Feb 18 11:28:29 2014 -0500

    Change ACPI IPMI support to "default y"
    
    The ACPI IPMI driver implements IPMI operation region support for the ACPI
    core. Systems that declare ACPI operation regions may reference them at any
    time, including during kernel initialisation. These accesses will fail
    unless the ACPI IPMI driver is present, and undesirable system behaviour
    may result. Set the default to Y in order to encourage distributions and
    users to configure kernels to avoid awkward surprises.
    
    Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>

commit 0d7c4ceb16d175f719fbe728799f9a7d4fd69297
Author: Corey Minyard <cminyard@mvista.com>
Date:   Mon Nov 10 21:24:45 2014 -0600

    ipmi: Handle I2C parms in the SSIF driver.
    
    Signed-off-by: Corey Minyard <cminyard@mvista.com>

commit 99a7a9582a0206ca2fded95d85fddfd399cfcbe4
Author: Corey Minyard <cminyard@mvista.com>
Date:   Mon Nov 10 21:10:49 2014 -0600

    i2c: Add parameters to sysfs-added i2c devices
    
    Some devices might need parameters to control their operation,
    add the ability to pass these parameters to the client.
    
    This also makes the parsing of sysfs-added I2C devices a little
    more flexible, allowing tabs and arbitrary numbers of spaces.
    
    Signed-off-by: Corey Minyard <cminyard@mvista.com>

commit 451b7a67f772a923135e57e0e710f7aeed62b5bf
Author: Jeremy Kerr <jk@ozlabs.org>
Date:   Wed Nov 12 15:41:05 2014 +0800

    drivers/char/ipmi: Add powernv IPMI driver
    
    This change adds an initial IPMI driver for powerpc OPAL firmware. The
    interface is exposed entirely through firmware: we have two functions to
    send and receive IPMI messages, and an interrupt notification from the
    firmware to signify that a message is available.
    
    Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>

commit 5ad7fb122df9e16d0f3bdb3723995b70e978e035
Author: Jeremy Kerr <jk@ozlabs.org>
Date:   Thu Nov 6 11:38:27 2014 +0800

    powerpc/powernv: Add OPAL IPMI interface
    
    Recent OPAL firmare adds a couple of functions to send and receive IPMI
    messages:
    
      https://github.com/open-power/skiboot/commit/b2a374da
    
    This change updates the token list and wrappers to suit, and adds the
    platform devices for any IPMI interfaces.
    
    Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

commit 02b8f3c67cf074350611983f8b963d9f00b02d64
Author: Corey Minyard <cminyard@mvista.com>
Date:   Mon Mar 19 16:00:55 2012 -0500

    ipmi: Add SMBus interface driver (SSIF)
    
    This patch adds the SMBus interface to the IPMI driver.
    
    Signed-off-by: Corey Minyard <minyard@acm.org>
    
     Documentation/IPMI.txt       |   32
     drivers/char/ipmi/Kconfig    |   11
     drivers/char/ipmi/Makefile   |    1
     drivers/char/ipmi/ipmi_smb.c | 1737 +++++++++++++++++++++++++++++++++++++++++++
     4 files changed, 1769 insertions(+), 12 deletions(-)

commit 08bb7beae7fe102939fe5931222fc09e10d27cda
Author: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Date:   Sun Nov 16 22:45:43 2014 +0800

    HID: i2c-hid: print the correct data in dbg msg
    
    Report is received in "buffer"; fix the following i2c_hid_dbg()
    to dump data from the correct pointer.
    
    Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
    [Antonio Borneo: cleanup and rebase to v3.17]
    Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit 11bf7828a59880427403e13dcff8228d67e9e0f7
Author: Joe Stringer <joestringer@nicira.com>
Date:   Mon Nov 17 16:24:54 2014 -0800

    vxlan: Inline vxlan_gso_check().
    
    Suggested-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Joe Stringer <joestringer@nicira.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e3e3217029a35c579bf100998b43976d0b1cb8d7
Author: Rick Jones <rick.jones2@hp.com>
Date:   Mon Nov 17 14:04:29 2014 -0800

    icmp: Remove some spurious dropped packet profile hits from the ICMP path
    
    If icmp_rcv() has successfully processed the incoming ICMP datagram, we
    should use consume_skb() rather than kfree_skb() because a hit on the likes
    of perf -e skb:kfree_skb is not called-for.
    
    Signed-off-by: Rick Jones <rick.jones2@hp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 54aeba7f06323e04d59a6053ee3c6023079667b2
Author: Fabian Frederick <fabf@skynet.be>
Date:   Mon Nov 17 22:23:17 2014 +0100

    dev_ioctl: use sizeof(x) instead of sizeof x
    
    Also remove spaces after cast.
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e56f735913c8d3c417c65c7e7fcdd65011f8d96f
Author: Fabian Frederick <fabf@skynet.be>
Date:   Mon Nov 17 22:08:22 2014 +0100

    net/core: include linux/types.h instead of asm/types.h
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 1d2398dc7c78f32c50ee23a21ad9141e5e08a2ed
Author: Fabian Frederick <fabf@skynet.be>
Date:   Mon Nov 17 22:04:03 2014 +0100

    net: fix spelling for synchronized
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a77b634367d4987718012b896c3d19c4cd7e8b4c
Author: Fabian Frederick <fabf@skynet.be>
Date:   Mon Nov 17 22:00:22 2014 +0100

    dccp: spelling s/reseting/resetting
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 02c31d2e56dfc6e65ebf5891cf6953e3391ce590
Author: Fabian Frederick <fabf@skynet.be>
Date:   Mon Nov 17 21:58:37 2014 +0100

    dccp: replace min/casting by min_t
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 54da7996b85b3a3e7388c5010ec0f1d866fc4830
Author: Fabian Frederick <fabf@skynet.be>
Date:   Mon Nov 17 21:54:58 2014 +0100

    dccp: remove blank lines between function/EXPORT_SYMBOL
    
    See Documentation/CodingStyle chapter 6.
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 6d80c4732bbbd8a76057337cb758ed64cf34f804
Author: Fabian Frederick <fabf@skynet.be>
Date:   Mon Nov 17 21:51:21 2014 +0100

    dccp: kerneldoc warning fixes
    
    Signed-off-by: Fabian Frederick <fabf@skynet.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit c20e599bb57bf12177cd5404d124cae0b6fc7970
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Mon Nov 17 10:51:24 2014 +0100

    net: fec: remove unused return value from swap_buffer()
    
    The return value of swap_buffer() is not used by any caller, thus
    remove it.
    
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 7b487d070a0edea01816135d3b1a9c8f2c069657
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Mon Nov 17 10:51:23 2014 +0100

    net: fec: simplify loop counter handling in swap_buffer()
    
    Eliminate the DIV_ROUND_UP() and change the loop counter increment to
    4 instead. This results in saving 6 instructions in the functions
    assembly code.
    
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e453789a66ab152ecee80ded3279539d826c48ed
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Mon Nov 17 10:51:22 2014 +0100

    net: fec: use swab32s() instead of cpu_to_be32()
    
    when swap_buffer() is being called, we know for sure, that we need to
    byte swap the data. Furthermore, this function is called for swapping
    data in both directions. Thus cpu_to_be32() is semantically not
    correct for all use cases. Use swab32s() to reflect this.
    
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 6b7e4008389c8cb8140a9aef424b10048c44da39
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Mon Nov 17 10:51:21 2014 +0100

    net: fec: improve access to quirk flags by copying them into fec_enet_private struct
    
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 217b5844e279c279414fdeb47a89959fad1fbc8f
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Mon Nov 17 10:51:20 2014 +0100

    net: fec: change type of 'bufdesc_ex' to bool
    
    fep->bufdesc_ex is treated as a boolean value, thus declare it as
    such.
    
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit df406bc9c0d002ef52671dc7b6887ff1bb9142e9
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Mon Nov 17 10:51:19 2014 +0100

    net: fec: properly parenthesize macro args
    
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 745f42ba2a52d5b95594c24fb3755ff678f669f9
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Mon Nov 17 10:51:18 2014 +0100

    net: fec: consistently use lower case chars as hex digits
    
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ea209de3dded8acd37677cf4e2f5fc06b791e052
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Mon Nov 17 10:51:17 2014 +0100

    net: fec: indentation cleanup
    
    consistently use TABs for indentation
    
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit be603bbb7bc12a006f1db36c338ac1c7f20c5a4a
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Wed Oct 29 14:23:21 2014 -0400

    OOPS

commit 92424e9c63e5d74ff1c282258f3e5c82bf1d913b
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Nov 6 15:11:36 2014 -0500

    nfsd: implement DATA_SYNC4 support
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit 14fdfac3e8fe1f6f73578a3ea964dab2f844e52c
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Wed Nov 12 18:04:04 2014 -0500

    SUNRPC: Fix locking around callback channel reply receive
    
    Both xprt_lookup_rqst() and xprt_complete_rqst() require that you
    take the transport lock in order to avoid races with xprt_transmit().
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Reviewed-by: Jeff Layton <jlayton@primarydata.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit ffa21a408184e95424035234496ec1b0cdde4b79
Author: Jeff Layton <jlayton@primarydata.com>
Date:   Mon Nov 17 17:02:57 2014 -0500

    sunrpc: eliminate the XPT_DETACHED flag
    
    All it does is indicate whether a xprt has already been deleted from
    a list or not, which is unnecessary since we use list_del_init and it's
    always set and checked under the sv_lock anyway.
    
    Signed-off-by: Jeff Layton <jlayton@primarydata.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit ea7aaa26273431650cb94e712c7c7cfec4306587
Author: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date:   Mon Nov 17 14:35:47 2014 +0100

    ARM: dts: berlin: enable USB on the Google Chromecast
    
    Enable usb1 on Google Chromecast which is connected to micro-USB
    plug used for external power supply, too.
    
    Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
    Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

commit e802b3a2bfd4f52a9b23037800fa0965aae92013
Author: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date:   Mon Nov 17 14:35:46 2014 +0100

    ARM: dts: berlin: add BG2CD nodes for USB support
    
    Adds nodes describing the Marvell Berlin BG2CD USB PHY and USB. The BG2CD
    SoC has 2 USB ChipIdea controllers, with usb0 host-only and usb1 dual-role
    capable.
    
    Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
    Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

commit fe354939edffe1f2579b4b372bad44e72bd9a9b3
Author: Antoine Tenart <antoine.tenart@free-electrons.com>
Date:   Mon Nov 17 14:35:45 2014 +0100

    ARM: dts: Berlin: enable USB on the BG2Q DMP
    
    Enable the 2 available USB PHY and USB nodes on the Marvell Berlin BG2Q
    DMP.
    
    Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
    Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

commit c539711ee79f997b0cdc136382167963932461b8
Author: Antoine Tenart <antoine.tenart@free-electrons.com>
Date:   Mon Nov 17 14:35:44 2014 +0100

    ARM: dts: berlin: add BG2Q nodes for USB support
    
    Adds nodes describing the Marvell Berlin BG2Q USB PHY and USB. The BG2Q
    SoC has 3 USB host controller, compatible with ChipIdea.
    
    Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
    Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

commit 81906906d8d95837c87b934a1a929cc43b61f4ee
Author: Antoine Tenart <antoine.tenart@free-electrons.com>
Date:   Mon Nov 17 14:33:12 2014 +0100

    ARM: berlin: do not select RESET_CONTROLLER
    
    RESET_CONTROLLER is meant to be user-selectable. To respect that,
    do not select it automatically when using ARCH_BERLIN.
    
    Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
    Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

commit 7943c0f329d33f531607d66f5781f2210e1e278c
Author: Alexei Starovoitov <ast@plumgrid.com>
Date:   Thu Nov 13 17:36:50 2014 -0800

    bpf: remove test map scaffolding and user proper types
    
    proper types and function helpers are ready. Use them in verifier testsuite.
    Remove temporary stubs
    
    Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d0003ec01c667b731c139e23de3306a8b328ccf5
Author: Alexei Starovoitov <ast@plumgrid.com>
Date:   Thu Nov 13 17:36:49 2014 -0800

    bpf: allow eBPF programs to use maps
    
    expose bpf_map_lookup_elem(), bpf_map_update_elem(), bpf_map_delete_elem()
    map accessors to eBPF programs
    
    Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ffb65f27a15583379567b6a59a9758163b7f5750
Author: Alexei Starovoitov <ast@plumgrid.com>
Date:   Thu Nov 13 17:36:48 2014 -0800

    bpf: add a testsuite for eBPF maps
    
    . check error conditions and sanity of hash and array map APIs
    . check large maps (that kernel gracefully switches to vmalloc from kmalloc)
    . check multi-process parallel access and stress test
    
    Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a1854d6ac0008518bfc45e791172ad250999c2a2
Author: Alexei Starovoitov <ast@plumgrid.com>
Date:   Thu Nov 13 17:36:47 2014 -0800

    bpf: fix BPF_MAP_LOOKUP_ELEM command return code
    
    fix errno of BPF_MAP_LOOKUP_ELEM command as bpf manpage
    described it in commit b4fc1a460f30("Merge branch 'bpf-next'"):
    -----
    BPF_MAP_LOOKUP_ELEM
        int bpf_lookup_elem(int fd, void *key, void *value)
        {
            union bpf_attr attr = {
                .map_fd = fd,
                .key = ptr_to_u64(key),
                .value = ptr_to_u64(value),
            };
    
            return bpf(BPF_MAP_LOOKUP_ELEM, &attr, sizeof(attr));
        }
        bpf() syscall looks up an element with given key in  a  map  fd.
        If  element  is found it returns zero and stores element's value
        into value.  If element is not found  it  returns  -1  and  sets
        errno to ENOENT.
    
    and further down in manpage:
    
       ENOENT For BPF_MAP_LOOKUP_ELEM or BPF_MAP_DELETE_ELEM,  indicates  that
              element with given key was not found.
    -----
    
    In general all BPF commands return ENOENT when map element is not found
    (including BPF_MAP_GET_NEXT_KEY and BPF_MAP_UPDATE_ELEM with
     flags == BPF_MAP_UPDATE_ONLY)
    
    Subsequent patch adds a testsuite to check return values for all of
    these combinations.
    
    Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 28fbcfa08d8ed7c5a50d41a0433aad222835e8e3
Author: Alexei Starovoitov <ast@plumgrid.com>
Date:   Thu Nov 13 17:36:46 2014 -0800

    bpf: add array type of eBPF maps
    
    add new map type BPF_MAP_TYPE_ARRAY and its implementation
    
    - optimized for fastest possible lookup()
      . in the future verifier/JIT may recognize lookup() with constant key
        and optimize it into constant pointer. Can optimize non-constant
        key into direct pointer arithmetic as well, since pointers and
        value_size are constant for the life of the eBPF program.
        In other words array_map_lookup_elem() may be 'inlined' by verifier/JIT
        while preserving concurrent access to this map from user space
    
    - two main use cases for array type:
      . 'global' eBPF variables: array of 1 element with key=0 and value is a
        collection of 'global' variables which programs can use to keep the state
        between events
      . aggregation of tracing events into fixed set of buckets
    
    - all array elements pre-allocated and zero initialized at init time
    
    - key as an index in array and can only be 4 byte
    
    - map_delete_elem() returns EINVAL, since elements cannot be deleted
    
    - map_update_elem() replaces elements in an non-atomic way
      (for atomic updates hashtable type should be used instead)
    
    Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 0f8e4bd8a1fc8c4185f1630061d0a1f2d197a475
Author: Alexei Starovoitov <ast@plumgrid.com>
Date:   Thu Nov 13 17:36:45 2014 -0800

    bpf: add hashtable type of eBPF maps
    
    add new map type BPF_MAP_TYPE_HASH and its implementation
    
    - maps are created/destroyed by userspace. Both userspace and eBPF programs
      can lookup/update/delete elements from the map
    
    - eBPF programs can be called in_irq(), so use spin_lock_irqsave() mechanism
      for concurrent updates
    
    - key/value are opaque range of bytes (aligned to 8 bytes)
    
    - user space provides 3 configuration attributes via BPF syscall:
      key_size, value_size, max_entries
    
    - map takes care of allocating/freeing key/value pairs
    
    - map_update_elem() must fail to insert new element when max_entries
      limit is reached to make sure that eBPF programs cannot exhaust memory
    
    - map_update_elem() replaces elements in an atomic way
    
    - optimized for speed of lookup() which can be called multiple times from
      eBPF program which itself is triggered by high volume of events
      . in the future JIT compiler may recognize lookup() call and optimize it
        further, since key_size is constant for life of eBPF program
    
    Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 3274f52073d88b62f3c5ace82ae9d48546232e72
Author: Alexei Starovoitov <ast@plumgrid.com>
Date:   Thu Nov 13 17:36:44 2014 -0800

    bpf: add 'flags' attribute to BPF_MAP_UPDATE_ELEM command
    
    the current meaning of BPF_MAP_UPDATE_ELEM syscall command is:
    either update existing map element or create a new one.
    Initially the plan was to add a new command to handle the case of
    'create new element if it didn't exist', but 'flags' style looks
    cleaner and overall diff is much smaller (more code reused), so add 'flags'
    attribute to BPF_MAP_UPDATE_ELEM command with the following meaning:
     #define BPF_ANY	0 /* create new element or update existing */
     #define BPF_NOEXIST	1 /* create new element if it didn't exist */
     #define BPF_EXIST	2 /* update existing element */
    
    bpf_update_elem(fd, key, value, BPF_NOEXIST) call can fail with EEXIST
    if element already exists.
    
    bpf_update_elem(fd, key, value, BPF_EXIST) can fail with ENOENT
    if element doesn't exist.
    
    Userspace will call it as:
    int bpf_update_elem(int fd, void *key, void *value, __u64 flags)
    {
        union bpf_attr attr = {
            .map_fd = fd,
            .key = ptr_to_u64(key),
            .value = ptr_to_u64(value),
            .flags = flags;
        };
    
        return bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
    }
    
    First two bits of 'flags' are used to encode style of bpf_update_elem() command.
    Bits 2-63 are reserved for future use.
    
    Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 2d791d2259d465ba1669a4cf3d7395d54f5e9772
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Tue Nov 18 18:47:13 2014 +0100

    MIPS: Zero variable read by get_user / __get_user in case of an error.
    
    This wasn't happening in all cases.
    
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit cadaecd2188b99d93de676150007f0e097223232
Author: Denis Kirjanov <kda@linux-powerpc.org>
Date:   Mon Nov 17 23:07:41 2014 +0300

    PPC: bpf_jit_comp: Unify BPF_MOD | BPF_X and BPF_DIV | BPF_X
    
    Reduce duplicated code by unifying
    BPF_ALU | BPF_MOD | BPF_X and BPF_ALU | BPF_DIV | BPF_X
    
    CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
    CC: Daniel Borkmann<dborkman@redhat.com>
    CC: Philippe Bergheaud<felix@linux.vnet.ibm.com>
    Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
    Acked-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a0e27f51ba8a04125c22a95c4d3e98297a7191de
Author: Soren Brinkmann <soren.brinkmann@xilinx.com>
Date:   Thu Nov 6 07:38:51 2014 -0800

    documentation: pinctrl bindings: Fix trivial typo 'abitrary'
    
    A misspelled 'arbitrary' propagated to quite a few locations in the DT
    binding documentation for pin-controllers. Fixing by:
      git grep abitrary | cut -f1 -d: | xargs sed -i 's/abitrary/arbitrary/'
    
    Reported-by: Andreas Färber <afaerber@suse.de>
    Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
    Signed-off-by: Rob Herring <robh@kernel.org>

commit 5641c09226f401ee054e48521707fb185380e8d3
Author: bpqw <bpqw@micron.com>
Date:   Wed Nov 12 14:26:42 2014 +0000

    devicetree: bindings: Add vendor prefix for Micron Technology, Inc.
    
    This patch is used to add vendor prefix for Micron Technology, Inc. in
    the vendor-prefixes.txt file.
    
    Micron Technology, Inc. is an American multinational corporation based
    in Boise, Idaho, best known for producing many forms of semiconductor
    devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs.
    
    Signed-off-by: Bean Huo <bpqw@micron.com>
    [robh: cleanup commit msg formatting and company name]
    Signed-off-by: Rob Herring <robh@kernel.org>

commit f9cb89b63db8cb2755a5179843a0643cc284f1ef
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Wed May 14 11:24:43 2014 +0200

    of: Add vendor prefix for Chips&Media, Inc.
    
    Chips&Media is a developer of Video Codec IP cores.
    
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    [robh: fix-up alphabetical ordering]
    Signed-off-by: Rob Herring <robh@kernel.org>

commit 746c9e9f92dde2789908e51a354ba90a1962a2eb
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Nov 14 17:55:03 2014 +1100

    of/base: Fix PowerPC address parsing hack
    
    We have a historical hack that treats missing ranges properties as the
    equivalent of an empty one. This is needed for ancient PowerMac "bad"
    device-trees, and shouldn't be enabled for any other PowerPC platform,
    otherwise we get some nasty layout of devices in sysfs or even
    duplication when a set of otherwise identically named devices is
    created multiple times under a different parent node with no ranges
    property.
    
    This fix is needed for the PowerNV i2c busses to be exposed properly
    and will fix a number of other embedded cases.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    CC: <stable@vger.kernel.org>
    Acked-by: Grant Likely <grant.likely@linaro.org>
    Signed-off-by: Rob Herring <robh@kernel.org>

commit 9b6eab07588c2de102423fe99c875fc4bfda2508
Author: Antony Pavlov <antonynpavlov@gmail.com>
Date:   Sun Nov 9 01:37:34 2014 +0300

    devicetree: vendor-prefixes.txt: fix whitespace
    
    Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
    Signed-off-by: Rob Herring <robh@kernel.org>

commit ab74d00a39f70e1bc34a01322bb59f3750ca7a8c
Author: Kevin Cernekee <cernekee@gmail.com>
Date:   Sun Nov 9 00:55:47 2014 -0800

    of: Fix crash if an earlycon driver is not found
    
    __earlycon_of_table_sentinel.compatible is a char[128], not a pointer, so
    it will never be NULL.  Checking it against NULL causes the match loop to
    run past the end of the array, and eventually match a bogus entry, under
    the following conditions:
    
     - Kernel command line specifies "earlycon" with no parameters
     - DT has a stdout-path pointing to a UART node
     - The UART driver doesn't use OF_EARLYCON_DECLARE (or maybe the console
       driver is compiled out)
    
    Fix this by checking to see if match->compatible is a non-empty string.
    
    Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
    Cc: <stable@vger.kernel.org> # 3.16+
    Signed-off-by: Rob Herring <robh@kernel.org>

commit 66865de4314caca30598244b86817e774c188afa
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Sat Nov 1 17:35:31 2014 -0600

    of/irq: Drop obsolete 'interrupts' vs 'interrupts-extended' text
    
    a9ecdc0fdc54 ("of/irq: Fix lookup to use 'interrupts-extended' property
    first") updated the description to say that:
    
      - Both 'interrupts' and 'interrupts-extended' may be present
      - Software should prefer 'interrupts-extended'
      - Software that doesn't comprehend 'interrupts-extended' may use
        'interrupts'
    
    But there is still a paragraph at the end that prohibits having both and
    says 'interrupts' should be preferred.
    
    Remove the contradictory text.
    
    Fixes: a9ecdc0fdc54 ("of/irq: Fix lookup to use 'interrupts-extended' property first")
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: stable@vger.kernel.org	# v3.13+
    Acked-by: Brian Norris <computersforpeace@gmail.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Rob Herring <robh@kernel.org>

commit 27b3383a1432127bfcf9f8a63bf184ff4d866141
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Oct 22 11:49:01 2014 +0200

    of: Spelling s/stucture/structure/
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: Grant Likely <grant.likely@linaro.org>
    Cc: Rob Herring <robh+dt@kernel.org>
    Signed-off-by: Rob Herring <robh@kernel.org>

commit f2a306c29d024193b1272cd014108882f7887a9e
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date:   Fri Sep 26 00:26:27 2014 +0200

    devicetree: bindings: add sandisk to the vendor prefixes
    
    Add sandisk to the list of vendors. This prefix should be used
    also for companies absorbed by Sandisk, like M-Systems.
    
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Rob Herring <robh@kernel.org>

commit 00e4c3b6e285da90e736fbefff3d9e74a200ee54
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Tue Nov 18 16:25:27 2014 +0000

    ASoC: wm_adsp: Move core_ena to be co-located with start bit
    
    Many firmwares do not wait for the start bit before they begin
    processing audio, whilst this is a bug on the firmware side there are
    too many such firmwares in the wild to ignore the situation. This patch
    moves the core enable to happen at same time as the start, the firmware
    looses the ability to overlap its own startup with the audio path bring
    up but we ensure that all firmwares behave.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 17c1861eabd12f28c24d4929efcc8aba8920b88f
Author: Alexey Ishchuk <aishchuk@linux.vnet.ibm.com>
Date:   Fri Nov 14 14:27:58 2014 +0100

    s390/kernel: add system calls for access PCI memory
    
    Add the new __NR_s390_pci_mmio_write and __NR_s390_pci_mmio_read
    system calls to allow user space applications to access device PCI I/O
    memory pages on s390x platform.
    
    [ Martin Schwidefsky: some code beautification ]
    
    Signed-off-by: Alexey Ishchuk <aishchuk@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 6d1e2e1783deecb7b922716295ca17deebbd3d0e
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Fri Nov 14 16:37:47 2014 +0100

    s390: fix ptrace of user area if the inferior uses vector registers
    
    The floating point registers f a process that uses vector instruction are
    not store into task->thread.fp_regs anymore but in the upper halves of the
    first 16 vector registers.
    The ptrace interface for the peeks and pokes to the user area fails to take
    this into account. Fix __peek_user[_compat] and __poke_user[_compat]
    to use the vector array for the floating pointer register if the process
    has one.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit afaa7d29bc04bf0fcf2e7bda2a802392a38d059b
Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
Date:   Fri Nov 14 11:01:37 2014 +0100

    s390/irq: use irq 0
    
    Irq 0 is currently unused on s390. Since there is no reason to
    do this start counting at the beginning and gain an additional
    irq. Also correctly report the smallest usable irq number for
    dynamic allocation.
    
    Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 99e97b7106d492a3cac4f7963f4a89935d2fbca4
Author: Frank Blaschka <frank.blaschka@de.ibm.com>
Date:   Thu Nov 6 13:17:06 2014 +0100

    s390/io: add ioport_map stubs
    
    add ioport_map stubs to make vfio build on s390.
    
    Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit a6b42afa3fc452339e157ad5245320804cf1206f
Author: Thomas Huth <thuth@linux.vnet.ibm.com>
Date:   Tue Oct 28 15:12:23 2014 +0100

    s390/docs: Remove sections that are not related to s390
    
    Information how to use the GCC pre-processor, objdump, strace, top, etc.
    are generic and not specific to the S390 architecture, so we do not need
    this information in Debugging390.txt
    
    Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit b19556231156ce3e58ffd677747bf3ef7890a937
Author: Thomas Huth <thuth@linux.vnet.ibm.com>
Date:   Fri Oct 31 14:10:14 2014 +0100

    s390/docs: Fix the documentation of the address spaces
    
    The information about the address spaces was completely outdated, since
    the usage of the address spaces changed quite a bit since the early days.
    This patch now updates the information about the usage of the address
    spaces, mostly by using the description from Heiko's patch "rework uaccess
    code - fix locking issues" (457f2180951cdcbfb4657ddcc83b486e93497f56).
    
    Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 5f217f905bc5e9d609d0aac830736bcfc087c7f5
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Tue Nov 18 23:59:40 2014 +0900

    ALSA: firewire-lib: fix kerneldoc errors
    
    Complete missing parameters, correct wrong reference, and add an explaination
    about the differences between the latest specification and our implementation.
    
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit d6d521799fac14e14dead4e9428158340ff6b95f
Author: JS Park <aitdark.park@samsung.com>
Date:   Tue Nov 18 16:07:22 2014 +0000

    ASoC: wm_adsp: Fix memory leak in wm_adsp_setup_algs
    
    Signed-off-by: JS Park <aitdark.park@samsung.com>
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 139768895309c6c1d6913e909e9c9422f81a1640
Author: Jens Axboe <axboe@fb.com>
Date:   Tue Nov 18 08:45:31 2014 -0700

    NVMe: enable IO stats by default
    
    Before the blk-mq conversion they were on by default, we should
    not change behavior there.
    
    Signed-off-by: Jens Axboe <axboe@fb.com>

commit a5a267cf9ca9937b0ef946b502657ae7638282f6
Author: Sudip Mukherjee <sudip@vectorindia.org>
Date:   Tue Nov 18 17:42:54 2014 +0530

    ASoC: rt286: build warning of section mismatch
    
    while building we were getting the following build warning:
    
    Section mismatch in reference from the function rt286_i2c_probe()
    to the variable .init.data:force_combo_jack_table
    The function rt286_i2c_probe() references
    the variable __initdata force_combo_jack_table.
    This is often because rt286_i2c_probe lacks a __initdata
    annotation or the annotation of force_combo_jack_table is wrong.
    
    we were getting the warning as force_combo_jack_table was marked
    with __initdata
    
    Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 358a8bb5628420529e4f0b77068155ca8fa8973b
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Nov 10 22:41:53 2014 +0100

    ASoC: ac97: Push snd_ac97 pointer to the driver level
    
    Now that the ASoC core no longer needs a handle to the AC'97 device that is
    associated with a CODEC we can remove it from the snd_soc_codec struct and
    push it into the individual driver state structs like we do for other
    communication buses. Doing so creates a clean separation between the AC'97
    bus support and the ASoC core.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit bc2632140435cc84f9817f1c362479b23dbdfebc
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Nov 10 22:41:52 2014 +0100

    ASoC: Rename snd_soc_dai_driver struct ac97_control field to bus_control
    
    Setting the ac97_control field on a CPU DAI tells the ASoC core that this
    DAI in addition to audio data also transports control data to the CODEC.
    This causes the core to suspend the DAI after the CODEC and resume it before
    the CODEC so communication to the CODEC is still possible. This is not
    necessarily something that is specific to AC'97 and can be used by other
    buses with the same requirement. This patch renames the flag from
    ac97_control to bus_control to make this explicit.
    
    While we are at it also change the type from int to bool.
    
    The following semantich patch was used for automatic conversion of the
    drivers:
    // <smpl>
    @@
    identifier drv;
    @@
    struct snd_soc_dai_driver drv = {
    -	.ac97_control
    +	.bus_control
    	=
    -	1
    +	true
    };
    // </smpl>
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 4bafcf074aca3bd191e4d93c6a140ca52654f192
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Nov 10 22:41:51 2014 +0100

    ASoC: Drop ac97_control initialization from CODEC driver DAIs
    
    This is no longer necessary as there is no code anymore that uses this for
    CODEC DAIs.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 6794f709b7124ff1e574c4f4c9494418ab56c4b4
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Nov 10 22:41:50 2014 +0100

    ASoC: ac97: Drop delayed device registration
    
    We have all the information and dependencies we need to initialize and
    register the device available in snd_soc_new_ac97_codec(). So there is no
    need to delay the device registration until after the card itself as been
    registered.
    
    This makes the code significantly simpler and also makes it possible to use
    the AC'97 device in the CODECs probe function. The later will be required to
    be able to convert the AC'97 CODEC drivers to regmap.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit ca005f324ee38308b319c693f40523d959027acf
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Nov 10 22:41:49 2014 +0100

    ASoC: ac97: Drop support for setting platform data via the CPU DAI
    
    This has no users since commit f0fba2ad1b6b ("ASoC: multi-component - ASoC
    Multi-Component Support") which was almost 5 years ago. Given that this runs
    after CODEC probe functions have been run it also doesn't seem to be that
    useful.
    
    So drop it altogether to make the code simpler.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit bdfd60e3c0affb914549f1d22e8aeef71e7828e6
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Nov 10 22:41:48 2014 +0100

    ASoC: ac97: Merge soc_ac97_dev_{un,}register()/soc_{un,}register_ac97_codec()
    
    soc_{un,}register_ac97_codec() is just a simple wrapper around
    soc_ac97_dev_{un,}register(). There is no need to split these up into two
    different sets of functions.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit eda1a701fd9589b6ed15b109558bd4f6202e3829
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Nov 10 22:41:47 2014 +0100

    ASoC: ac97: Use static ac97_bus
    
    We always pass soc_ac97_ops to snd_soc_new_ac97_codec(). So instead of
    allocating a snd_ac97_bus in snd_soc_new_ac97_codec() just use a static one
    that gets initialized when snd_soc_set_ac97_ops() is called.
    
    Also drop the device number parameter from snd_soc_new_ac97_codec(). We
    currently only support one device per bus and all drivers pass 0 for the
    device number. And if we should ever support multiple devices per bus it
    wouldn't be up to individual AC'97 device drivers to pick their number, but
    rather either the AC'97 adapter driver or the core code will assign them.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 336b8423e285174ebecf02a743d69913b83bbc48
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Nov 10 22:41:46 2014 +0100

    ASoC: Move AC'97 support to its own file
    
    Currently the AC'97 support is splattered all throughout soc-core.c. Some
    parts are #ifdef'd some parts are not. This patch moves the AC'97 support to
    its own file, this should make the code a bit more clearer and also makes it
    possible to easily not compile it into the kernel when not needed.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 70f3af3ca15affaef3d026a5aa6e44c4627ea6c7
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Nov 10 22:41:45 2014 +0100

    ASoC: Properly handle AC'97 device lifetime management
    
    The memory that a struct device is contained in must not be freed except
    from within the device's release callback. The ASoC code currently does not
    adhere to this rule for the AC'97 device. This patch fixes it by moving the
    freeing of the AC'97 to the release callback and splitting up the
    registration and unregistration of the device into separate steps for
    getting/putting the reference to the device and adding/removing it to the
    device hierarchy.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 65c72efd1ea370f0311a5d89754996fff9fc0747
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Nov 10 22:41:44 2014 +0100

    ASoC: mpc5200_dma: Don't overwrite ac97 device private_data
    
    The mpc5200_dma overwrites the private_data field of the CODEC's AC'97
    device with the DMA drivers private data, but never actually reads it again.
    Given that the private_data field is supposed to be owned by the AC'97
    driver, overwriting it may cause undefined behavior. This patch removes the
    code that overwrites the field from the driver.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 35480e3536cdab1ee1976675e798f16d707f5356
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon Nov 10 22:41:43 2014 +0100

    ASoC: mpc5200_psc_ac97: Remove unused on-stack snd_ac97 device
    
    The mpc5200_psc_ac97 driver puts a snd_ac97 device on the stack in the
    driver probe function, initializes the private data member of the device and
    the never uses the device again. It should be safe to remove it.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 77c1aa84de0096792de673aa1c64c36b38553cf5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Nov 18 13:27:07 2014 +0100

    drm/i915: Don't print header in error state for non-existing CS
    
    This goes back to
    
    commit 362b8af7ad1d91266aa4931e62be45c1e5cf753b
    Author: Ben Widawsky <benjamin.widawsky@intel.com>
    Date:   Thu Jan 30 00:19:38 2014 -0800
    
        drm/i915: Move per ring error state to ring_error
    
    Spotted while reading error states.
    
    Cc: Ben Widawsky <benjamin.widawsky@intel.com>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

commit 6dcc0cf6cb3120cedc0d4c12171894f3d6415981
Author: Jens Axboe <axboe@fb.com>
Date:   Tue Nov 18 08:21:18 2014 -0700

    NVMe: nvme_submit_async_admin_req() must use atomic rq allocation
    
    We are called for async event notification issues, and the
    nvmeq lock is already held. If we fail the request allocation,
    we'll just retry next time.
    
    Reported-by: Julia Lawall <julia.lawall@lip6.fr>
    Signed-off-by: Jens Axboe <axboe@fb.com>

commit 30021e3707a75cc29dc1252c062d374151c5985f
Author: Beniamino Galvani <b.galvani@gmail.com>
Date:   Thu Nov 13 20:32:01 2014 +0100

    i2c: add support for Amlogic Meson I2C controller
    
    This is a driver for the I2C controller found in Amlogic Meson SoCs.
    
    Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

commit c9449affad2ae0824927df5a207705e07f346fb1
Author: Gerlando Falauto <gerlando.falauto@keymile.com>
Date:   Thu Nov 13 14:39:56 2014 +0100

    i2c: mux: create "channel-n" symlinks for child segments in the mux device
    
    This makes the topology clearer. For instance, by adding a pca9547
    device with address 0x70 to bus i2c-0, you get:
    
    /sys/class/i2c-dev/i2c-0/device/0-0070/channel-0 -> i2c-1
    ...
    /sys/class/i2c-dev/i2c-0/device/0-0070/channel-7 -> i2c-8
    
    Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
    [wsa: simplified sysfs-usage and fixed format string usage]
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Acked-by: Martin Belanger <martin.belanger@cyaninc.com>
    Acked-by: Danielle Costantino <danielle.costantino@gmail.com>

commit 51cf3b0e2a72bb08cd280be6c0ead4e08ed50a2c
Author: Wolfram Sang <wsa@the-dreams.de>
Date:   Thu Nov 13 14:39:55 2014 +0100

    i2c: mux: create symlink to actual mux device
    
    The current implementation creates muxed i2c-<n> busses as immediate
    children of their i2c-<n> parent bus. In case of multiple muxes on one
    bus, it is impossible to determine which muxed bus comes from which mux.
    
    It could be argued that the parent device should be changed from the
    parent adapter to the mux device. This has pros and cons. To improve the
    topology, simply add a "mux_device" symlink pointing to the actual
    muxing device, so we can distinguish muxed busses. Doing it this way, we
    don't break the ABI.
    
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Tested-by: Guenter Roeck <linux@roeck-us.net>

commit 4470c725ba7b86481c31466640ab487f927de6b7
Author: Wolfram Sang <wsa@the-dreams.de>
Date:   Tue Nov 18 15:12:43 2014 +0100

    i2c: acpi: remove unneeded variable initialization
    
    No need to initialize 'ret' if it gets assigned directly after that.
    
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>

commit bb29a93b38610d2adc6ead40b75e1a1991617550
Author: Masanari Iida <standby24x7@gmail.com>
Date:   Wed Nov 12 00:52:23 2014 +0900

    ASoC: jack: Fix warning while make htmldocs caused by soc-jack.c
    
    This patch fix following errors while "make htmldocs" on
    linux-next-20141110.
    
    Warning(.//sound/soc/soc-jack.c:126): No description found for
    parameter 'zones'
    Warning(.//sound/soc/soc-jack.c:126): Excess function parameter
    'zone' description in 'snd_soc_jack_add_zones'
    
    Signed-off-by: Masanari Iida <standby24x7@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit ce1a78840ff7ab846065d5b65eaac959bafe1949
Author: Yao Yuan <yao.yuan@freescale.com>
Date:   Tue Nov 18 18:31:06 2014 +0800

    i2c: imx: add DMA support for freescale i2c driver
    
    Add dma support for i2c. This function depend on DMA driver.
    You can turn on it by write both the dmas and dma-name properties in dts node.
    DMA is optional, even DMA request unsuccessfully, i2c can also work well.
    
    Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

commit 2fbed5119d6a07a6777b2131262587df338df22b
Author: Yao Yuan <yao.yuan@freescale.com>
Date:   Tue Nov 18 18:31:05 2014 +0800

    i2c: imx: Sort include headers alphabetically
    
    If the inlcude headers aren't sorted alphabetically, then the
    logical choice is to append new ones, however that creates a
    lot of potential for conflicts or duplicates because every change
    will then add new includes in the same location.
    
    Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

commit fcc50e5cd2deb8316d19e446d8efdfc9b35646ef
Author: Qipan Li <Qipan.Li@csr.com>
Date:   Mon Nov 17 23:17:03 2014 +0800

    spi: sirf: assign spi_master's max_speed_hz member
    
    if spi device has no frequency, spi core will setup the default frequency
    to max_speed_hz of spi_master according to
    int spi_setup(struct spi_device *spi)
    {
    	...
            if (!spi->max_speed_hz)
                    spi->max_speed_hz = spi->master->max_speed_hz;
    	...
    }
    this patch moves CSR SiRFSoC SPI frequency set to follow SPI core behaviour.
    
    Signed-off-by: Qipan Li <Qipan.Li@csr.com>
    Signed-off-by: Barry Song <Baohua.Song@csr.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 9c4b19a07dddda3ba35a2eb9b4134d485908e2f5
Author: Qipan Li <Qipan.Li@csr.com>
Date:   Mon Nov 17 23:17:02 2014 +0800

    spi: sirf: fix word width configuration
    
    commit 8c328a262f ("spi: sirf: Avoid duplicate code in various
    bits_per_word cases") is wrong in setting data width register of
    fifo is not right, it should use sspi->word_width >> 1 to set
    related bits. According to hardware spec, the mapping between
    register value and data width:
    0 - byte
    1 - WORD
    2 - DWORD
    
    Fixes: 8c328a262f ("spi: sirf: Avoid duplicate code in various bits_per_word cases") is wrong in setting data width register of
    Signed-off-by: Qipan Li <Qipan.Li@csr.com>
    Signed-off-by: Barry Song <Baohua.Song@csr.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org

commit 864b94adfcba752aa902ee34497bbe58b97aa8d3
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Sun Nov 9 22:48:03 2014 +0800

    pci, ACPI, iommu: Enhance pci_root to support DMAR device hotplug
    
    Finally enhance pci_root driver to support DMAR device hotplug when
    hot-plugging PCI host bridges.
    
    Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
    Reviewed-by: Yijing Wang <wangyijing@huawei.com>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>

commit 30badc9543490f41497c42f004db02f1e8a29341
Author: Markus Elfring <elfring@users.sourceforge.net>
Date:   Tue Nov 18 11:31:23 2014 +0100

    GFS2: Deletion of unnecessary checks before two function calls
    
    The functions iput() and put_pid() test whether their argument is NULL
    and then return immediately. Thus the test around the call is not needed.
    
    This issue was detected by using the Coccinelle software.
    
    Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>

commit 0690cbd2e55a72a8eae557c389d1a136ed9fa142
Author: Joerg Roedel <jroedel@suse.de>
Date:   Wed Nov 5 15:28:30 2014 +0100

    powerpc/iommu: Rename iommu_[un]map_sg functions
    
    The IOMMU-API gained support for a new iommu_map_sg
    function. This causes compile failures on powerpc because
    the function name is already globally used there.
    This patch renames adds a ppc_ prefix to these functions to
    solve the compile problem.
    
    Signed-off-by: Joerg Roedel <jroedel@suse.de>

commit ffebeb46dd34736c90ffbca1ccb0bef8f4827c44
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Sun Nov 9 22:48:02 2014 +0800

    iommu/vt-d: Enhance intel-iommu driver to support DMAR unit hotplug
    
    Implement required callback functions for intel-iommu driver
    to support DMAR unit hotplug.
    
    Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
    Reviewed-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>

commit 51acce33c4df6ee23b5ad4c2e6c239e0d6f25771
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Sun Nov 9 22:48:01 2014 +0800

    iommu/vt-d: Enhance error recovery in function intel_enable_irq_remapping()
    
    Enhance error recovery in function intel_enable_irq_remapping()
    by tearing down all created data structures.
    
    Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
    Reviewed-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>

commit a7a3dad944344caf034699b0c0e8dc51b469cf20
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Sun Nov 9 22:48:00 2014 +0800

    iommu/vt-d: Enhance intel_irq_remapping driver to support DMAR unit hotplug
    
    Implement required callback functions for intel_irq_remapping driver
    to support DMAR unit hotplug.
    
    Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>

commit d35165a955f095095cdb8512cb7cd8f63101649a
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Sun Nov 9 22:47:59 2014 +0800

    iommu/vt-d: Search for ACPI _DSM method for DMAR hotplug
    
    According to Intel VT-d specification, _DSM method to support DMAR
    hotplug should exist directly under corresponding ACPI object
    representing PCI host bridge. But some BIOSes doesn't conform to
    this, so search for _DSM method in the subtree starting from the
    ACPI object representing the PCI host bridge.
    
    Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
    Reviewed-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>

commit 6b1972493a84f8fe13ff9d202745590f6c53d670
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Sun Nov 9 22:47:58 2014 +0800

    iommu/vt-d: Implement DMAR unit hotplug framework
    
    On Intel platforms, an IO Hub (PCI/PCIe host bridge) may contain DMAR
    units, so we need to support DMAR hotplug when supporting PCI host
    bridge hotplug on Intel platforms.
    
    According to Section 8.8 "Remapping Hardware Unit Hot Plug" in "Intel
    Virtualization Technology for Directed IO Architecture Specification
    Rev 2.2", ACPI BIOS should implement ACPI _DSM method under the ACPI
    object for the PCI host bridge to support DMAR hotplug.
    
    This patch introduces interfaces to parse ACPI _DSM method for
    DMAR unit hotplug. It also implements state machines for DMAR unit
    hot-addition and hot-removal.
    
    The PCI host bridge hotplug driver should call dmar_hotplug_hotplug()
    before scanning PCI devices connected for hot-addition and after
    destroying all PCI devices for hot-removal.
    
    Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
    Reviewed-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>

commit 78d8e7046111425bb688cddc4303d79cb0f0d281
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Sun Nov 9 22:47:57 2014 +0800

    iommu/vt-d: Dynamically allocate and free seq_id for DMAR units
    
    Introduce functions to support dynamic IOMMU seq_id allocating and
    releasing, which will be used to support DMAR hotplug.
    
    Also rename IOMMU_UNITS_SUPPORTED as DMAR_UNITS_SUPPORTED.
    
    Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
    Reviewed-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>

commit c2a0b538d2c778aef7bf2fbe7973229192c9a392
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Sun Nov 9 22:47:56 2014 +0800

    iommu/vt-d: Introduce helper function dmar_walk_resources()
    
    Introduce helper function dmar_walk_resources to walk resource entries
    in DMAR table and ACPI buffer object returned by ACPI _DSM method
    for IOMMU hot-plug.
    
    Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>

commit eb45fa0b93e03b03848cd048dcc57648409c8125
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Nov 18 12:11:29 2014 +0200

    drm/i915/audio: fix monitor presence indication after disable
    
    Indicate the monitor has been disconnected on disable.
    
    The regression has been introduced in
    
    commit 5fad84a7530f8e7664cdc6f490cb90653fed1266
    Author: Jani Nikula <jani.nikula@intel.com>
    Date:   Tue Nov 4 10:30:23 2014 +0200
    
        drm/i915: rewrite hsw/bdw audio codec enable/disable sequences
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86424
    Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 6676f3081f7e3dae64e05b87d47a041b782f898a
Author: Hui Wang <hui.wang@canonical.com>
Date:   Tue Nov 18 17:57:41 2014 +0800

    ALSA: hda - fix the mic mute led problem for Latitude E5550
    
    The microphone mute led on the Latitude E5550 can't work. We need to
    apply DELL_WMI_MIC_MUTE_LED quirk to this machine.
    
    The machine uses alc293 codec and already applied the quirk
    ALC293_FIXUP_DELL1_MIC_NO_PRESENCE through pin_fixup_tbl[].
    
    Here we just let DELL_WMI_MIC_MUTE_LED be chained to
    ALC269_FIXUP_HEADSET_MODE, then the machine will have these
    quirks ALC293_FIXUP_DELL1_MIC_NO_PRESENCE-->
    ALC269_FIXUP_HEADSET_MODE-->ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED.
    
    BugLink: https://bugs.launchpad.net/bugs/1381856
    Reported-and-tested-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 4a83d42ae2041d5b76f1a0662bc3a5a85e4eb0d1
Author: Hui Wang <hui.wang@canonical.com>
Date:   Tue Nov 18 17:57:40 2014 +0800

    ALSA: hda - move DELL_WMI_MIC_MUTE_LED to the tail in the quirk chain
    
    We have one more Dell machine needs DELL_WMI_MIC_MUTE_LED quirk, but
    the machine uses alc293 instead of alc255. So if
    DELL_WMI_MIC_MUTE_LED still chain ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
    the machine can't use this quirk.
    
    To change this situation, let the DELL_WMI_MIC_MUTE_LED to be a
    standalone quirk, and let other quirks chain it.
    
    After this change, this quirk can be chained to any existing quirks,
    and as a result, it is possible that this quirk is applied to
    a non-Dell machine or a Dell machine without mic mute led on it, but
    it is still safe since alc_fixup_dell_wmi() will return an error in
    these situations.
    
    And remove the quirk for machine with subsystem id 0x6010 and 0x601f,
    these two machines will fall back to the quirk
    ALC255_FIXUP_DELL1_MIC_NO_PRESENCE-->ALC255_FIXUP_HEADSET_MODE-->
    ALC255_FIXUP_DELL_WMI_MIC_MUTE_LED through pin_fixup_tbl[].
    
    BugLink: https://bugs.launchpad.net/bugs/1381856
    Reported-and-tested-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 3ffa037d7f78ceb25115eda29176c2bd2844866f
Author: Neerav Parikh <neerav.parikh@intel.com>
Date:   Wed Nov 12 00:19:02 2014 +0000

    i40e: Set XPS bit mask to zero in DCB mode
    
    Due to DCBX configuration change if the VSI needs to use more than 1 TC;
    it needs to disable the XPS maps that were set when operating in 1 TC mode.
    Without disabling XPS the netdev layer will select queues based on those
    settings and not use the TC queue mapping to make the queue selection.
    
    This patch allows the driver to enable/disable the XPS based on the number
    of TCs being enabled for the given VSI.
    
    Change-ID: Idc4dec47a672d2a509f6d7fe11ed1ee65b4f0e08
    Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
    Tested-By: Jack Morgan <jack.morgan@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

commit 4b7698cb95638693e3d9a2fc01a2bdbd8710ff81
Author: Neerav Parikh <neerav.parikh@intel.com>
Date:   Wed Nov 12 00:18:57 2014 +0000

    i40e: Prevent link flow control settings when PFC is enabled
    
    When PFC is enabled we should not proceed with setting the link flow control
    parameters.  Also, always report the link flow Tx/Rx settings as off when
    PFC is enabled.
    
    Change-ID: Ib09ec58afdf0b2e587ac9d8851a5c80ad58206c4
    Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
    Tested-By: Jack Morgan <jack.morgan@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

commit d341b7a52be79520f8e8b1ed0e3df657b2442e5b
Author: Neerav Parikh <neerav.parikh@intel.com>
Date:   Wed Nov 12 00:18:51 2014 +0000

    i40e: Do not disable/enable FCoE VSI with DCB reconfig
    
    FCoE VSI Tx queue disable times out when reconfiguring as a result of
    DCB TC configuration change event.
    
    The hardware allows us to skip disabling and enabling of Tx queues for
    VSIs with single TC enabled. As FCoE VSI is configured to have only
    single TC we skip it from disable/enable flow.
    
    Change-ID: Ia73ff3df8785ba2aa3db91e6f2c9005e61ebaec2
    Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
    Tested-By: Jack Morgan <jack.morgan@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

commit 69129dc39fac45e0ea1dbbca995abdac279df376
Author: Neerav Parikh <neerav.parikh@intel.com>
Date:   Wed Nov 12 00:18:46 2014 +0000

    i40e: Modify Tx disable wait flow in case of DCB reconfiguration
    
    When DCB TC configuration changes the firmware suspends the port's Tx.
    Now, as DCB TCs may have changed the PF driver tries to reconfigure the
    TC configuration of the VSIs it manages. As part of this process it disables
    the VSI queues but the Tx queue disable will not complete as the port's
    Tx has been suspended. So, waiting for Tx queues to go to disable state
    in this flow may lead to detection of Tx queue disable timeout errors.
    
    Hence, this patch adds a new PF state so that if a port's Tx is in
    suspended state the Tx queue disable flow would just put the request for
    the queue to be disabled and return without waiting for the queue to be
    actually disabled.
    Once the VSI(s) TC reconfiguration has been done and driver has called
    firmware AQC "Resume PF Traffic" the driver checks the Tx queues requested
    to be disabled are actually disabled before re-enabling them again.
    
    Change-ID: If3e03ce4813a4e342dbd5a1eb1d2861e952b7544
    Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
    Tested-By: Jack Morgan <jack.morgan@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

commit 23cd1f095adf110d118ef972914c714176cd48d0
Author: Neerav Parikh <neerav.parikh@intel.com>
Date:   Wed Nov 12 00:18:41 2014 +0000

    i40e: Update VEB's enabled_tc after reconfiguration
    
    When the port TC configuration changes as a result of DCBx the driver
    modifies the enabled TCs for the VEBs it manages. But, in the process
    it did not update the enabled_tc value that it caches on a per VEB basis.
    
    So, when the next reconfiguration event occurs where the number of TC
    value is same as the value cached in enabled_tc for a given VEB; driver
    does not modify it's TC configuration by calling appropriate AQ command
    believing it is running with the same configuration as requested.
    Now, as the VEB is not actually enabled for the TCs that are there any
    TC configuration command for VSI attached to that VEB with TCs that are
    not enabled for the VEB fails.
    
    This patch fixes this issue.
    
    Change-ID: Ife5694469b05494228e0d850429ea1734738cf29
    Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
    Tested-By: Jack Morgan <jack.morgan@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

commit e1c4751ee22f5d5f6f6cfcb70614e18e4218892e
Author: Neerav Parikh <neerav.parikh@intel.com>
Date:   Wed Nov 12 00:18:30 2014 +0000

    i40e: Check for LLDP AdminStatus before querying DCBX
    
    This patch adds a check whether LLDP Agent's default AdminStatus is
    enabled or disabled on a given port. If it is disabled then it sets
    the DCBX status to disabled as well; and would not query firmware for
    any DCBX configuration data.
    
    Change-ID: I73c0b9f0adbf4cae177d14914b20a48c9a8f50fd
    Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
    Tested-By: Jack Morgan <jack.morgan@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

commit 9fa61dd2153a4ff3a57891d4866a2595eb9ac81a
Author: Neerav Parikh <neerav.parikh@intel.com>
Date:   Wed Nov 12 00:18:25 2014 +0000

    i40e: Add support to firmware CEE DCBX mode
    
    This patch allows i40e driver to query and use DCB configuration from
    firmware when firmware DCBX agent is in CEE mode.
    
    Change-ID: I30f92a67eb890f0f024f35339696e6e83d49a274
    Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
    Tested-By: Jack Morgan <jack.morgan@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

commit 2fd75f31f6bacaed38061f95f0fee26de3e01170
Author: Neerav Parikh <neerav.parikh@intel.com>
Date:   Wed Nov 12 00:18:20 2014 +0000

    i40e: Resume Port Tx after DCB event
    
    When there are DCB configuration changes based on DCBX the firmware suspends
    the port's Tx and generates an event to the PF. The PF is then responsible
    to reconfigure the PF VSIs and switching topology as per the updated DCB
    configuration and then resume the port's Tx by calling the "Resume Port Tx"
    AQ command.
    
    This patch adds this call to the flow that handles DCB re-configuration in
    the PF.
    
    Change-ID: I5b860ad48abfbf379b003143c4d3453e2ed5cc1c
    Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
    Tested-By: Jack Morgan <jack.morgan@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

commit 7bda87c7fb2eaab8e144d6d0a2638099d7b6e5f5
Author: Catherine Sullivan <catherine.sullivan@intel.com>
Date:   Tue Nov 11 03:15:06 2014 +0000

    i40e: Bump version to 1.1.23
    
    Bumping minor version as this will be the second SW release and it
    should be 1.
    
    Change-ID: If0bd102095d2f059ae0c9b7f4ad625535ffbbdee
    Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirshe…
e82a8ca
@aryabinin aryabinin referenced this pull request in aryabinin/linux
mmotm auto import linux-next
GIT 30a727e4802f48182d33e2bdaca586bfb6a62868

commit 6d4e81ed89c092cb156c8d19cb68c8733cd502b3
Author: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Date:   Mon Nov 24 10:08:03 2014 +0100

    cpufreq: Ref the policy object sooner
    
    Do it before it's assigned to cpufreq_cpu_data, otherwise when a driver
    tries to get the cpu frequency during initialization the policy kobj is
    referenced and we get this warning:
    
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 64 at include/linux/kref.h:47 kobject_get+0x64/0x70()
    Modules linked in:
    CPU: 1 PID: 64 Comm: irq/77-tegra-ac Not tainted 3.18.0-rc4-next-20141114ccu-00050-g3eff942 #326
    [<c0016fac>] (unwind_backtrace) from [<c001272c>] (show_stack+0x10/0x14)
    [<c001272c>] (show_stack) from [<c06085d8>] (dump_stack+0x98/0xd8)
    [<c06085d8>] (dump_stack) from [<c002892c>] (warn_slowpath_common+0x84/0xb4)
    [<c002892c>] (warn_slowpath_common) from [<c00289f8>] (warn_slowpath_null+0x1c/0x24)
    [<c00289f8>] (warn_slowpath_null) from [<c0220290>] (kobject_get+0x64/0x70)
    [<c0220290>] (kobject_get) from [<c03e944c>] (cpufreq_cpu_get+0x88/0xc8)
    [<c03e944c>] (cpufreq_cpu_get) from [<c03e9500>] (cpufreq_get+0xc/0x64)
    [<c03e9500>] (cpufreq_get) from [<c0285288>] (actmon_thread_isr+0x134/0x198)
    [<c0285288>] (actmon_thread_isr) from [<c0069008>] (irq_thread_fn+0x1c/0x40)
    [<c0069008>] (irq_thread_fn) from [<c0069324>] (irq_thread+0x134/0x174)
    [<c0069324>] (irq_thread) from [<c0040290>] (kthread+0xdc/0xf4)
    [<c0040290>] (kthread) from [<c000f4b8>] (ret_from_fork+0x14/0x3c)
    ---[ end trace b7bd64a81b340c59 ]---
    
    Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit e874bf5f7647a9fdf14d72dbb376ec95327e3a81
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Tue Nov 25 21:41:03 2014 +0100

    ASoC: Disable regmap helpers if regmap is disabled
    
    If regmap is disabled there will be no users of the ASoC regmap helpers.