[PATCH 4.9 050/116] drivers/gpu/drm/ast: Fix infinite loop if read fails

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Russell Currey 

commit 298360af3dab45659810fdc51aba0c9f4097e4f6 upstream.

ast_get_dram_info() configures a window in order to access BMC memory.
A BMC register can be configured to disallow this, and if so, causes
an infinite loop in the ast driver which renders the system unusable.

Fix this by erroring out if an error is detected.  On powerpc systems with
EEH, this leads to the device being fenced and the system continuing to
operate.

Signed-off-by: Russell Currey 
Reviewed-by: Joel Stanley 
Signed-off-by: Daniel Vetter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20161215051241.20815-1-rus...@russell.cc
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/ast/ast_main.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -223,7 +223,8 @@ static int ast_get_dram_info(struct drm_
ast_write32(ast, 0x1, 0xfc600309);
 
do {
-   ;
+   if (pci_channel_offline(dev->pdev))
+   return -EIO;
} while (ast_read32(ast, 0x1) != 0x01);
data = ast_read32(ast, 0x10004);
 
@@ -428,7 +429,9 @@ int ast_driver_load(struct drm_device *d
ast_detect_chip(dev, _post);
 
if (ast->chip != AST1180) {
-   ast_get_dram_info(dev);
+   ret = ast_get_dram_info(dev);
+   if (ret)
+   goto out_free;
ast->vram_size = ast_get_vram_info(dev);
DRM_INFO("dram %d %d %d %08x\n", ast->mclk, ast->dram_type, 
ast->dram_bus_width, ast->vram_size);
}

[PATCH 4.9 053/116] block: protect iterate_bdevs() against concurrent close

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Rabin Vincent 

commit af309226db916e2c6e08d3eba3fa5c34225200c4 upstream.

If a block device is closed while iterate_bdevs() is handling it, the
following NULL pointer dereference occurs because bdev->b_disk is NULL
in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in
turn called by the mapping_cap_writeback_dirty() call in
__filemap_fdatawrite_range()):

 BUG: unable to handle kernel NULL pointer dereference at 0508
 IP: [] blk_get_backing_dev_info+0x10/0x20
 PGD 9e62067 PUD 9ee8067 PMD 0
 Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
 Modules linked in:
 CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
 task: 880009f4d700 ti: 880009f5c000 task.ti: 880009f5c000
 RIP: 0010:[]  [] 
blk_get_backing_dev_info+0x10/0x20
 RSP: 0018:880009f5fe68  EFLAGS: 00010246
 RAX:  RBX: 88000ec17a38 RCX: 81a4e940
 RDX: 7fff RSI:  RDI: 88000ec176c0
 RBP: 880009f5fe68 R08:  R09: 
 R10: 0001 R11:  R12: 88000ec17860
 R13: 811b25c0 R14: 88000ec178e0 R15: 88000ec17a38
 FS:  7faee505d700() GS:88000fb0() knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: 0508 CR3: 09e8a000 CR4: 06e0
 Stack:
  880009f5feb8 8112e7f5  7fff
    7fff 0001
  88000ec178e0 88000ec17860 880009f5fec8 8112e81f
 Call Trace:
  [] __filemap_fdatawrite_range+0x85/0x90
  [] filemap_fdatawrite+0x1f/0x30
  [] fdatawrite_one_bdev+0x16/0x20
  [] iterate_bdevs+0xf2/0x130
  [] sys_sync+0x63/0x90
  [] entry_SYSCALL_64_fastpath+0x12/0x76
 Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d
 RIP  [] blk_get_backing_dev_info+0x10/0x20
  RSP 
 CR2: 0508
 ---[ end trace 2487336ceb3de62d ]---

The crash is easily reproducible by running the following command, if an
msleep(100) is inserted before the call to func() in iterate_devs():

 while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done

Fix it by holding the bd_mutex across the func() call and only calling
func() if the bdev is opened.

Fixes: 5c0d6b60a0ba ("vfs: Create function for iterating over block devices")
Reported-and-tested-by: Wei Fang 
Signed-off-by: Rabin Vincent 
Signed-off-by: Jan Kara 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/block_dev.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1950,6 +1950,7 @@ void iterate_bdevs(void (*func)(struct b
spin_lock(_superblock->s_inode_list_lock);
list_for_each_entry(inode, _superblock->s_inodes, i_sb_list) {
struct address_space *mapping = inode->i_mapping;
+   struct block_device *bdev;
 
spin_lock(>i_lock);
if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW) ||
@@ -1970,8 +1971,12 @@ void iterate_bdevs(void (*func)(struct b
 */
iput(old_inode);
old_inode = inode;
+   bdev = I_BDEV(inode);
 
-   func(I_BDEV(inode), arg);
+   mutex_lock(>bd_mutex);
+   if (bdev->bd_openers)
+   func(bdev, arg);
+   mutex_unlock(>bd_mutex);
 
spin_lock(_superblock->s_inode_list_lock);
}

[PATCH 4.9 070/116] md/raid5: limit request size according to implementation limits

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Konstantin Khlebnikov 

commit e8d7c33232e5fdfa761c3416539bc5b4acd12db5 upstream.

Current implementation employ 16bit counter of active stripes in lower
bits of bio->bi_phys_segments. If request is big enough to overflow
this counter bio will be completed and freed too early.

Fortunately this not happens in default configuration because several
other limits prevent that: stripe_cache_size * nr_disks effectively
limits count of active stripes. And small max_sectors_kb at lower
disks prevent that during normal read/write operations.

Overflow easily happens in discard if it's enabled by module parameter
"devices_handle_discard_safely" and stripe_cache_size is set big enough.

This patch limits requests size with 256Mb - 8Kb to prevent overflows.

Signed-off-by: Konstantin Khlebnikov 
Cc: Shaohua Li 
Cc: Neil Brown 
Signed-off-by: Shaohua Li 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/raid5.c |9 +
 1 file changed, 9 insertions(+)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -6984,6 +6984,15 @@ static int raid5_run(struct mddev *mddev
stripe = (stripe | (stripe-1)) + 1;
mddev->queue->limits.discard_alignment = stripe;
mddev->queue->limits.discard_granularity = stripe;
+
+   /*
+* We use 16-bit counter of active stripes in bi_phys_segments
+* (minus one for over-loaded initialization)
+*/
+   blk_queue_max_hw_sectors(mddev->queue, 0xfffe * STRIPE_SECTORS);
+   blk_queue_max_discard_sectors(mddev->queue,
+ 0xfffe * STRIPE_SECTORS);
+
/*
 * unaligned part of discard request will be ignored, so can't
 * guarantee discard_zeroes_data

[PATCH 4.9 039/116] drm/nouveau/ttm: wait for bo fence to signal before unmapping vmas

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Skeggs 

commit 10dcab3e7f477bffee88d518aad57d06777cfdf4 upstream.

TTM was changed a while back to allow for pipelining of buffer moves, and
part of this was the removal of waiting for a BO to idle before calling
move(), placing the responsibility on the driver to do this if required.

That's all well and good, except, we make use of move_notify() to handle
mapping/unmapping from the GPU VMM as move() isn't called on all paths.

This commit adds a wait before unmapping from a VMM in move_notify(), to
prevent GPU page faults where a buffer is still being accessed.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/nouveau/nouveau_bo.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1209,6 +1209,7 @@ nouveau_bo_move_ntfy(struct ttm_buffer_o
   nvbo->page_shift != vma->vm->mmu->lpg_shift)) {
nvkm_vm_map(vma, new_mem->mm_node);
} else {
+   WARN_ON(ttm_bo_wait(bo, false, false));
nvkm_vm_unmap(vma);
}
}

[PATCH 4.9 050/116] drivers/gpu/drm/ast: Fix infinite loop if read fails

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Russell Currey 

commit 298360af3dab45659810fdc51aba0c9f4097e4f6 upstream.

ast_get_dram_info() configures a window in order to access BMC memory.
A BMC register can be configured to disallow this, and if so, causes
an infinite loop in the ast driver which renders the system unusable.

Fix this by erroring out if an error is detected.  On powerpc systems with
EEH, this leads to the device being fenced and the system continuing to
operate.

Signed-off-by: Russell Currey 
Reviewed-by: Joel Stanley 
Signed-off-by: Daniel Vetter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20161215051241.20815-1-rus...@russell.cc
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/ast/ast_main.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -223,7 +223,8 @@ static int ast_get_dram_info(struct drm_
ast_write32(ast, 0x1, 0xfc600309);
 
do {
-   ;
+   if (pci_channel_offline(dev->pdev))
+   return -EIO;
} while (ast_read32(ast, 0x1) != 0x01);
data = ast_read32(ast, 0x10004);
 
@@ -428,7 +429,9 @@ int ast_driver_load(struct drm_device *d
ast_detect_chip(dev, _post);
 
if (ast->chip != AST1180) {
-   ast_get_dram_info(dev);
+   ret = ast_get_dram_info(dev);
+   if (ret)
+   goto out_free;
ast->vram_size = ast_get_vram_info(dev);
DRM_INFO("dram %d %d %d %08x\n", ast->mclk, ast->dram_type, 
ast->dram_bus_width, ast->vram_size);
}

[PATCH 4.9 053/116] block: protect iterate_bdevs() against concurrent close

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Rabin Vincent 

commit af309226db916e2c6e08d3eba3fa5c34225200c4 upstream.

If a block device is closed while iterate_bdevs() is handling it, the
following NULL pointer dereference occurs because bdev->b_disk is NULL
in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in
turn called by the mapping_cap_writeback_dirty() call in
__filemap_fdatawrite_range()):

 BUG: unable to handle kernel NULL pointer dereference at 0508
 IP: [] blk_get_backing_dev_info+0x10/0x20
 PGD 9e62067 PUD 9ee8067 PMD 0
 Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
 Modules linked in:
 CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
 task: 880009f4d700 ti: 880009f5c000 task.ti: 880009f5c000
 RIP: 0010:[]  [] 
blk_get_backing_dev_info+0x10/0x20
 RSP: 0018:880009f5fe68  EFLAGS: 00010246
 RAX:  RBX: 88000ec17a38 RCX: 81a4e940
 RDX: 7fff RSI:  RDI: 88000ec176c0
 RBP: 880009f5fe68 R08:  R09: 
 R10: 0001 R11:  R12: 88000ec17860
 R13: 811b25c0 R14: 88000ec178e0 R15: 88000ec17a38
 FS:  7faee505d700() GS:88000fb0() knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: 0508 CR3: 09e8a000 CR4: 06e0
 Stack:
  880009f5feb8 8112e7f5  7fff
    7fff 0001
  88000ec178e0 88000ec17860 880009f5fec8 8112e81f
 Call Trace:
  [] __filemap_fdatawrite_range+0x85/0x90
  [] filemap_fdatawrite+0x1f/0x30
  [] fdatawrite_one_bdev+0x16/0x20
  [] iterate_bdevs+0xf2/0x130
  [] sys_sync+0x63/0x90
  [] entry_SYSCALL_64_fastpath+0x12/0x76
 Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d
 RIP  [] blk_get_backing_dev_info+0x10/0x20
  RSP 
 CR2: 0508
 ---[ end trace 2487336ceb3de62d ]---

The crash is easily reproducible by running the following command, if an
msleep(100) is inserted before the call to func() in iterate_devs():

 while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done

Fix it by holding the bd_mutex across the func() call and only calling
func() if the bdev is opened.

Fixes: 5c0d6b60a0ba ("vfs: Create function for iterating over block devices")
Reported-and-tested-by: Wei Fang 
Signed-off-by: Rabin Vincent 
Signed-off-by: Jan Kara 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/block_dev.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1950,6 +1950,7 @@ void iterate_bdevs(void (*func)(struct b
spin_lock(_superblock->s_inode_list_lock);
list_for_each_entry(inode, _superblock->s_inodes, i_sb_list) {
struct address_space *mapping = inode->i_mapping;
+   struct block_device *bdev;
 
spin_lock(>i_lock);
if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW) ||
@@ -1970,8 +1971,12 @@ void iterate_bdevs(void (*func)(struct b
 */
iput(old_inode);
old_inode = inode;
+   bdev = I_BDEV(inode);
 
-   func(I_BDEV(inode), arg);
+   mutex_lock(>bd_mutex);
+   if (bdev->bd_openers)
+   func(bdev, arg);
+   mutex_unlock(>bd_mutex);
 
spin_lock(_superblock->s_inode_list_lock);
}

[PATCH 4.9 070/116] md/raid5: limit request size according to implementation limits

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Konstantin Khlebnikov 

commit e8d7c33232e5fdfa761c3416539bc5b4acd12db5 upstream.

Current implementation employ 16bit counter of active stripes in lower
bits of bio->bi_phys_segments. If request is big enough to overflow
this counter bio will be completed and freed too early.

Fortunately this not happens in default configuration because several
other limits prevent that: stripe_cache_size * nr_disks effectively
limits count of active stripes. And small max_sectors_kb at lower
disks prevent that during normal read/write operations.

Overflow easily happens in discard if it's enabled by module parameter
"devices_handle_discard_safely" and stripe_cache_size is set big enough.

This patch limits requests size with 256Mb - 8Kb to prevent overflows.

Signed-off-by: Konstantin Khlebnikov 
Cc: Shaohua Li 
Cc: Neil Brown 
Signed-off-by: Shaohua Li 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/raid5.c |9 +
 1 file changed, 9 insertions(+)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -6984,6 +6984,15 @@ static int raid5_run(struct mddev *mddev
stripe = (stripe | (stripe-1)) + 1;
mddev->queue->limits.discard_alignment = stripe;
mddev->queue->limits.discard_granularity = stripe;
+
+   /*
+* We use 16-bit counter of active stripes in bi_phys_segments
+* (minus one for over-loaded initialization)
+*/
+   blk_queue_max_hw_sectors(mddev->queue, 0xfffe * STRIPE_SECTORS);
+   blk_queue_max_discard_sectors(mddev->queue,
+ 0xfffe * STRIPE_SECTORS);
+
/*
 * unaligned part of discard request will be ignored, so can't
 * guarantee discard_zeroes_data

[PATCH 4.9 039/116] drm/nouveau/ttm: wait for bo fence to signal before unmapping vmas

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Skeggs 

commit 10dcab3e7f477bffee88d518aad57d06777cfdf4 upstream.

TTM was changed a while back to allow for pipelining of buffer moves, and
part of this was the removal of waiting for a BO to idle before calling
move(), placing the responsibility on the driver to do this if required.

That's all well and good, except, we make use of move_notify() to handle
mapping/unmapping from the GPU VMM as move() isn't called on all paths.

This commit adds a wait before unmapping from a VMM in move_notify(), to
prevent GPU page faults where a buffer is still being accessed.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/nouveau/nouveau_bo.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1209,6 +1209,7 @@ nouveau_bo_move_ntfy(struct ttm_buffer_o
   nvbo->page_shift != vma->vm->mmu->lpg_shift)) {
nvkm_vm_map(vma, new_mem->mm_node);
} else {
+   WARN_ON(ttm_bo_wait(bo, false, false));
nvkm_vm_unmap(vma);
}
}

[PATCH 4.9 037/116] drm/nouveau/bios: require checksum to match for fast acpi shadow method

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Skeggs 

commit 5dc7f4aa9d84ea94b54a9bfcef095f0289f1ebda upstream.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h   |1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c |7 +--
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c |1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h
@@ -12,6 +12,7 @@ struct nvbios_source {
bool rw;
bool ignore_checksum;
bool no_pcir;
+   bool require_checksum;
 };
 
 int nvbios_extend(struct nvkm_bios *, u32 length);
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -86,9 +86,12 @@ shadow_image(struct nvkm_bios *bios, int
nvbios_checksum(>data[image.base], image.size)) {
nvkm_debug(subdev, "%08x: checksum failed\n",
   image.base);
-   if (mthd->func->rw)
+   if (!mthd->func->require_checksum) {
+   if (mthd->func->rw)
+   score += 1;
score += 1;
-   score += 1;
+   } else
+   return 0;
} else {
score += 3;
}
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
@@ -99,6 +99,7 @@ nvbios_acpi_fast = {
.init = acpi_init,
.read = acpi_read_fast,
.rw = false,
+   .require_checksum = true,
 };
 
 const struct nvbios_source

[PATCH 4.9 072/116] KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Mackerras 

commit 0d808df06a44200f52262b6eb72bcb6042f5a7c5 upstream.

When switching from/to a guest that has a transaction in progress,
we need to save/restore the checkpointed register state.  Although
XER is part of the CPU state that gets checkpointed, the code that
does this saving and restoring doesn't save/restore XER.

This fixes it by saving and restoring the XER.  To allow userspace
to read/write the checkpointed XER value, we also add a new ONE_REG
specifier.

The visible effect of this bug is that the guest may see its XER
value being corrupted when it uses transactions.

Fixes: e4e38121507a ("KVM: PPC: Book3S HV: Add transactional memory support")
Fixes: 0a8eccefcb34 ("KVM: PPC: Book3S HV: Add missing code for transaction 
reclaim on guest exit")
Signed-off-by: Paul Mackerras 
Reviewed-by: Thomas Huth 
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman 

---
 Documentation/virtual/kvm/api.txt   |1 +
 arch/powerpc/include/asm/kvm_host.h |1 +
 arch/powerpc/include/uapi/asm/kvm.h |1 +
 arch/powerpc/kernel/asm-offsets.c   |1 +
 arch/powerpc/kvm/book3s_hv.c|6 ++
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |4 
 6 files changed, 14 insertions(+)

--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2050,6 +2050,7 @@ registers, find a list below:
   PPC   | KVM_REG_PPC_TM_VSCR   | 32
   PPC   | KVM_REG_PPC_TM_DSCR   | 64
   PPC   | KVM_REG_PPC_TM_TAR| 64
+  PPC   | KVM_REG_PPC_TM_XER| 64
 |   |
   MIPS  | KVM_REG_MIPS_R0   | 64
   ...
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -546,6 +546,7 @@ struct kvm_vcpu_arch {
u64 tfiar;
 
u32 cr_tm;
+   u64 xer_tm;
u64 lr_tm;
u64 ctr_tm;
u64 amr_tm;
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -596,6 +596,7 @@ struct kvm_get_htab_header {
 #define KVM_REG_PPC_TM_VSCR(KVM_REG_PPC_TM | KVM_REG_SIZE_U32 | 0x67)
 #define KVM_REG_PPC_TM_DSCR(KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x68)
 #define KVM_REG_PPC_TM_TAR (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x69)
+#define KVM_REG_PPC_TM_XER (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x6a)
 
 /* PPC64 eXternal Interrupt Controller Specification */
 #define KVM_DEV_XICS_GRP_SOURCES   1   /* 64-bit source attributes */
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -569,6 +569,7 @@ int main(void)
DEFINE(VCPU_VRS_TM, offsetof(struct kvm_vcpu, arch.vr_tm.vr));
DEFINE(VCPU_VRSAVE_TM, offsetof(struct kvm_vcpu, arch.vrsave_tm));
DEFINE(VCPU_CR_TM, offsetof(struct kvm_vcpu, arch.cr_tm));
+   DEFINE(VCPU_XER_TM, offsetof(struct kvm_vcpu, arch.xer_tm));
DEFINE(VCPU_LR_TM, offsetof(struct kvm_vcpu, arch.lr_tm));
DEFINE(VCPU_CTR_TM, offsetof(struct kvm_vcpu, arch.ctr_tm));
DEFINE(VCPU_AMR_TM, offsetof(struct kvm_vcpu, arch.amr_tm));
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1288,6 +1288,9 @@ static int kvmppc_get_one_reg_hv(struct
case KVM_REG_PPC_TM_CR:
*val = get_reg_val(id, vcpu->arch.cr_tm);
break;
+   case KVM_REG_PPC_TM_XER:
+   *val = get_reg_val(id, vcpu->arch.xer_tm);
+   break;
case KVM_REG_PPC_TM_LR:
*val = get_reg_val(id, vcpu->arch.lr_tm);
break;
@@ -1498,6 +1501,9 @@ static int kvmppc_set_one_reg_hv(struct
case KVM_REG_PPC_TM_CR:
vcpu->arch.cr_tm = set_reg_val(id, *val);
break;
+   case KVM_REG_PPC_TM_XER:
+   vcpu->arch.xer_tm = set_reg_val(id, *val);
+   break;
case KVM_REG_PPC_TM_LR:
vcpu->arch.lr_tm = set_reg_val(id, *val);
break;
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -2600,11 +2600,13 @@ kvmppc_save_tm:
mfctr   r7
mfspr   r8, SPRN_AMR
mfspr   r10, SPRN_TAR
+   mfxer   r11
std r5, VCPU_LR_TM(r9)
stw r6, VCPU_CR_TM(r9)
std r7, VCPU_CTR_TM(r9)
std r8, VCPU_AMR_TM(r9)
std r10, VCPU_TAR_TM(r9)
+   std r11, VCPU_XER_TM(r9)
 
/* Restore r12 as trap number. */
lwz r12, VCPU_TRAP(r9)
@@ -2697,11 +2699,13 @@ kvmppc_restore_tm:
ld  r7, VCPU_CTR_TM(r4)
ld  r8, VCPU_AMR_TM(r4)
ld  r9, VCPU_TAR_TM(r4)
+   ld  r10, VCPU_XER_TM(r4)
mtlrr5
mtcrr6
mtctr   r7
mtspr   SPRN_AMR, r8
mtspr   SPRN_TAR, r9
+ 

[PATCH 4.9 037/116] drm/nouveau/bios: require checksum to match for fast acpi shadow method

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Skeggs 

commit 5dc7f4aa9d84ea94b54a9bfcef095f0289f1ebda upstream.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h   |1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c |7 +--
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c |1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h
@@ -12,6 +12,7 @@ struct nvbios_source {
bool rw;
bool ignore_checksum;
bool no_pcir;
+   bool require_checksum;
 };
 
 int nvbios_extend(struct nvkm_bios *, u32 length);
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -86,9 +86,12 @@ shadow_image(struct nvkm_bios *bios, int
nvbios_checksum(>data[image.base], image.size)) {
nvkm_debug(subdev, "%08x: checksum failed\n",
   image.base);
-   if (mthd->func->rw)
+   if (!mthd->func->require_checksum) {
+   if (mthd->func->rw)
+   score += 1;
score += 1;
-   score += 1;
+   } else
+   return 0;
} else {
score += 3;
}
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
@@ -99,6 +99,7 @@ nvbios_acpi_fast = {
.init = acpi_init,
.read = acpi_read_fast,
.rw = false,
+   .require_checksum = true,
 };
 
 const struct nvbios_source

[PATCH 4.9 072/116] KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Mackerras 

commit 0d808df06a44200f52262b6eb72bcb6042f5a7c5 upstream.

When switching from/to a guest that has a transaction in progress,
we need to save/restore the checkpointed register state.  Although
XER is part of the CPU state that gets checkpointed, the code that
does this saving and restoring doesn't save/restore XER.

This fixes it by saving and restoring the XER.  To allow userspace
to read/write the checkpointed XER value, we also add a new ONE_REG
specifier.

The visible effect of this bug is that the guest may see its XER
value being corrupted when it uses transactions.

Fixes: e4e38121507a ("KVM: PPC: Book3S HV: Add transactional memory support")
Fixes: 0a8eccefcb34 ("KVM: PPC: Book3S HV: Add missing code for transaction 
reclaim on guest exit")
Signed-off-by: Paul Mackerras 
Reviewed-by: Thomas Huth 
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman 

---
 Documentation/virtual/kvm/api.txt   |1 +
 arch/powerpc/include/asm/kvm_host.h |1 +
 arch/powerpc/include/uapi/asm/kvm.h |1 +
 arch/powerpc/kernel/asm-offsets.c   |1 +
 arch/powerpc/kvm/book3s_hv.c|6 ++
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |4 
 6 files changed, 14 insertions(+)

--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2050,6 +2050,7 @@ registers, find a list below:
   PPC   | KVM_REG_PPC_TM_VSCR   | 32
   PPC   | KVM_REG_PPC_TM_DSCR   | 64
   PPC   | KVM_REG_PPC_TM_TAR| 64
+  PPC   | KVM_REG_PPC_TM_XER| 64
 |   |
   MIPS  | KVM_REG_MIPS_R0   | 64
   ...
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -546,6 +546,7 @@ struct kvm_vcpu_arch {
u64 tfiar;
 
u32 cr_tm;
+   u64 xer_tm;
u64 lr_tm;
u64 ctr_tm;
u64 amr_tm;
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -596,6 +596,7 @@ struct kvm_get_htab_header {
 #define KVM_REG_PPC_TM_VSCR(KVM_REG_PPC_TM | KVM_REG_SIZE_U32 | 0x67)
 #define KVM_REG_PPC_TM_DSCR(KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x68)
 #define KVM_REG_PPC_TM_TAR (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x69)
+#define KVM_REG_PPC_TM_XER (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x6a)
 
 /* PPC64 eXternal Interrupt Controller Specification */
 #define KVM_DEV_XICS_GRP_SOURCES   1   /* 64-bit source attributes */
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -569,6 +569,7 @@ int main(void)
DEFINE(VCPU_VRS_TM, offsetof(struct kvm_vcpu, arch.vr_tm.vr));
DEFINE(VCPU_VRSAVE_TM, offsetof(struct kvm_vcpu, arch.vrsave_tm));
DEFINE(VCPU_CR_TM, offsetof(struct kvm_vcpu, arch.cr_tm));
+   DEFINE(VCPU_XER_TM, offsetof(struct kvm_vcpu, arch.xer_tm));
DEFINE(VCPU_LR_TM, offsetof(struct kvm_vcpu, arch.lr_tm));
DEFINE(VCPU_CTR_TM, offsetof(struct kvm_vcpu, arch.ctr_tm));
DEFINE(VCPU_AMR_TM, offsetof(struct kvm_vcpu, arch.amr_tm));
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1288,6 +1288,9 @@ static int kvmppc_get_one_reg_hv(struct
case KVM_REG_PPC_TM_CR:
*val = get_reg_val(id, vcpu->arch.cr_tm);
break;
+   case KVM_REG_PPC_TM_XER:
+   *val = get_reg_val(id, vcpu->arch.xer_tm);
+   break;
case KVM_REG_PPC_TM_LR:
*val = get_reg_val(id, vcpu->arch.lr_tm);
break;
@@ -1498,6 +1501,9 @@ static int kvmppc_set_one_reg_hv(struct
case KVM_REG_PPC_TM_CR:
vcpu->arch.cr_tm = set_reg_val(id, *val);
break;
+   case KVM_REG_PPC_TM_XER:
+   vcpu->arch.xer_tm = set_reg_val(id, *val);
+   break;
case KVM_REG_PPC_TM_LR:
vcpu->arch.lr_tm = set_reg_val(id, *val);
break;
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -2600,11 +2600,13 @@ kvmppc_save_tm:
mfctr   r7
mfspr   r8, SPRN_AMR
mfspr   r10, SPRN_TAR
+   mfxer   r11
std r5, VCPU_LR_TM(r9)
stw r6, VCPU_CR_TM(r9)
std r7, VCPU_CTR_TM(r9)
std r8, VCPU_AMR_TM(r9)
std r10, VCPU_TAR_TM(r9)
+   std r11, VCPU_XER_TM(r9)
 
/* Restore r12 as trap number. */
lwz r12, VCPU_TRAP(r9)
@@ -2697,11 +2699,13 @@ kvmppc_restore_tm:
ld  r7, VCPU_CTR_TM(r4)
ld  r8, VCPU_AMR_TM(r4)
ld  r9, VCPU_TAR_TM(r4)
+   ld  r10, VCPU_XER_TM(r4)
mtlrr5
mtcrr6
mtctr   r7
mtspr   SPRN_AMR, r8
mtspr   SPRN_TAR, r9
+   mtxer   r10
 
/*
 * Load up PPR and DSCR values but don't put them in the actual 

[PATCH 4.9 000/116] 4.9.2-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 4.9.2 release.
There are 116 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Jan  8 21:38:42 UTC 2017.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.2-rc1.gz
or in the git tree and branch at:
  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 4.9.2-rc1

Mika Kuoppala 
drm/i915: Fix setting of boost freq tunable

Paulo Zanoni 
drm/i915: skip the first 4k of stolen memory on everything >= gen8

Ville Syrjälä 
drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time

Ville Syrjälä 
drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

Hans de Goede 
drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from 
vlv_init_display_clock_gating

Hans de Goede 
drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting

Thomas Petazzoni 
net: mvpp2: fix dma unmapping of TX buffers for fragments

Al Viro 
sg_write()/bsg_write() is not fit to be called under KERNEL_DS

Ben Hutchings 
kconfig/nconf: Fix hang when editing symbol with a long prompt

Andy Grover 
target/user: Fix use-after-free of tcmu_cmds if they are expired

Dan Williams 
libnvdimm, pfn: fix align attribute

David Daney 
of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not 
possible.

Nicholas Piggin 
powerpc/boot: Request no dynamic linker for boot wrapper

Geoff Levand 
powerpc/ps3: Fix system hang with GCC 5 builds

Nicholas Piggin 
powerpc/64e: Convert cmpi to cmpwi in head_64.S

NeilBrown 
SUNRPC: fix refcounting problems with auth_gss messages.

Trond Myklebust 
pNFS: Fix a deadlock between read resends and layoutreturn

Trond Myklebust 
pNFS: Clear NFS_LAYOUT_RETURN_REQUESTED when invalidating the layout stateid

Trond Myklebust 
pNFS: Don't clear the layout stateid if a layout return is outstanding

Trond Myklebust 
pNFS: On error, do not send LAYOUTGET until the LAYOUTRETURN has completed

Al Viro 
nfs_write_end(): fix handling of short copies

Ilya Dryomov 
libceph: verify authorize reply on connect

Alan Stern 
PCI: Check for PME in targeted sleep state

Shiraz Saleem 
i40iw: Use correct src address in memcpy to rdma stats counters

Miklos Szeredi 
bad_inode: add missing i_op initializers

Jingkui Wang 
Input: drv260x - fix input device's parent assignment

Laurent Pinchart 
v4l: tvp5150: Add missing break in set control handler

Andrey Utkin 
media: solo6x10: fix lockup by avoiding delayed register write

Marek Szyprowski 
s5p-mfc: fix failure path of s5p_mfc_alloc_memdev()

Antti Palosaari 
mn88473: fix chip id check on probe

Antti Palosaari 
mn88472: fix chip id check on probe

Bart Van Assche 
IB/cma: Fix a race condition in iboe_addr_get_sgid()

Bart Van Assche 
IB/rxe: Fix a memory leak in rxe_qp_cleanup()

Bart Van Assche 
IB/multicast: Check ib_find_pkey() return value

Bart Van Assche 
IPoIB: Avoid reading an uninitialized member variable

Bart Van Assche 
IB/mad: Fix an array index check

Steven Rostedt (Red Hat) 
fgraph: Handle a case where a tracer ignores set_graph_notrace

Thomas Gleixner 
x86/smpboot: Make logical package management more robust

Marcos Paulo de Souza 
platform/x86: asus-nb-wmi.c: Add X45U quirk

Steven Rostedt (Red Hat) 
ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short 
jumps to it

Michael S. Tsirkin 
vsock/virtio: fix src/dst cid format

Jan Kara 

[PATCH 4.9 045/116] drm/radeon/si: load the proper firmware on 0x87 oland boards

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Alex Deucher 

commit abb2e3c1ce64c8bba678973800c34ea1dc97c42c upstream.

New variant.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/si.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -1714,6 +1714,7 @@ static int si_init_microcode(struct rade
(rdev->pdev->revision == 0x80) ||
(rdev->pdev->revision == 0x81) ||
(rdev->pdev->revision == 0x83) ||
+   (rdev->pdev->revision == 0x87) ||
(rdev->pdev->device == 0x6604) ||
(rdev->pdev->device == 0x6605))
new_smc = true;

[PATCH 4.9 004/116] perf/x86: Fix exclusion of BTS and LBR for Goldmont

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Andi Kleen 

commit b0c1ef52959582144bbea9a2b37db7f4c9e399f7 upstream.

An earlier patch allowed enabling PT and LBR at the same
time on Goldmont. However it also allowed enabling BTS and LBR
at the same time, which is still not supported. Fix this by
bypassing the check only for PT.

Signed-off-by: Andi Kleen 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: alexander.shish...@intel.com
Cc: kan.li...@intel.com
Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the 
core supports it")
Link: http://lkml.kernel.org/r/20161209001417.4713-1-a...@firstfloor.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/events/core.c   |8 ++--
 arch/x86/events/perf_event.h |2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -365,7 +365,11 @@ int x86_add_exclusive(unsigned int what)
 {
int i;
 
-   if (x86_pmu.lbr_pt_coexist)
+   /*
+* When lbr_pt_coexist we allow PT to coexist with either LBR or BTS.
+* LBR and BTS are still mutually exclusive.
+*/
+   if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt)
return 0;
 
if (!atomic_inc_not_zero(_pmu.lbr_exclusive[what])) {
@@ -388,7 +392,7 @@ fail_unlock:
 
 void x86_del_exclusive(unsigned int what)
 {
-   if (x86_pmu.lbr_pt_coexist)
+   if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt)
return;
 
atomic_dec(_pmu.lbr_exclusive[what]);
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -604,7 +604,7 @@ struct x86_pmu {
u64 lbr_sel_mask;  /* LBR_SELECT valid bits */
const int   *lbr_sel_map;  /* lbr_select mappings */
boollbr_double_abort;  /* duplicated lbr aborts */
-   boollbr_pt_coexist;/* LBR may coexist with PT */
+   boollbr_pt_coexist;/* (LBR|BTS) may coexist 
with PT */
 
/*
 * Intel PT/LBR/BTS are exclusive

[PATCH 4.9 049/116] drm/amdgpu: fix init save/restore list in gfx_v8.0

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Rex Zhu 

commit 202e0b227b906cb80a2791f21216a55d9468d61b upstream.

set valid data to mmRLC_SRM_INDEX_CNTL_ADDRx/DATAx.

Signed-off-by: Rex Zhu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -3947,8 +3947,12 @@ static int gfx_v8_0_init_save_restore_li
temp = mmRLC_SRM_INDEX_CNTL_ADDR_0;
data = mmRLC_SRM_INDEX_CNTL_DATA_0;
for (i = 0; i < sizeof(unique_indices) / sizeof(int); i++) {
-   amdgpu_mm_wreg(adev, temp + i, unique_indices[i] & 0x3, 
false);
-   amdgpu_mm_wreg(adev, data + i, unique_indices[i] >> 20, false);
+   if (unique_indices[i] != 0) {
+   amdgpu_mm_wreg(adev, temp + i,
+   unique_indices[i] & 0x3, false);
+   amdgpu_mm_wreg(adev, data + i,
+   unique_indices[i] >> 20, false);
+   }
}
kfree(register_list_format);
 

[PATCH 4.9 044/116] drm/radeon: add additional pci revision to dpm workaround

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Alex Deucher 

commit 8729675c00a8d13cb2094d617d70a4a4da7d83c5 upstream.

New variant.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/si_dpm.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3026,6 +3026,7 @@ static void si_apply_state_adjust_rules(
(rdev->pdev->revision == 0x80) ||
(rdev->pdev->revision == 0x81) ||
(rdev->pdev->revision == 0x83) ||
+   (rdev->pdev->revision == 0x87) ||
(rdev->pdev->device == 0x6604) ||
(rdev->pdev->device == 0x6605)) {
max_sclk = 75000;

[PATCH 4.9 045/116] drm/radeon/si: load the proper firmware on 0x87 oland boards

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Alex Deucher 

commit abb2e3c1ce64c8bba678973800c34ea1dc97c42c upstream.

New variant.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/si.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -1714,6 +1714,7 @@ static int si_init_microcode(struct rade
(rdev->pdev->revision == 0x80) ||
(rdev->pdev->revision == 0x81) ||
(rdev->pdev->revision == 0x83) ||
+   (rdev->pdev->revision == 0x87) ||
(rdev->pdev->device == 0x6604) ||
(rdev->pdev->device == 0x6605))
new_smc = true;

[PATCH 4.9 004/116] perf/x86: Fix exclusion of BTS and LBR for Goldmont

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Andi Kleen 

commit b0c1ef52959582144bbea9a2b37db7f4c9e399f7 upstream.

An earlier patch allowed enabling PT and LBR at the same
time on Goldmont. However it also allowed enabling BTS and LBR
at the same time, which is still not supported. Fix this by
bypassing the check only for PT.

Signed-off-by: Andi Kleen 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: alexander.shish...@intel.com
Cc: kan.li...@intel.com
Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the 
core supports it")
Link: http://lkml.kernel.org/r/20161209001417.4713-1-a...@firstfloor.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/events/core.c   |8 ++--
 arch/x86/events/perf_event.h |2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -365,7 +365,11 @@ int x86_add_exclusive(unsigned int what)
 {
int i;
 
-   if (x86_pmu.lbr_pt_coexist)
+   /*
+* When lbr_pt_coexist we allow PT to coexist with either LBR or BTS.
+* LBR and BTS are still mutually exclusive.
+*/
+   if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt)
return 0;
 
if (!atomic_inc_not_zero(_pmu.lbr_exclusive[what])) {
@@ -388,7 +392,7 @@ fail_unlock:
 
 void x86_del_exclusive(unsigned int what)
 {
-   if (x86_pmu.lbr_pt_coexist)
+   if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt)
return;
 
atomic_dec(_pmu.lbr_exclusive[what]);
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -604,7 +604,7 @@ struct x86_pmu {
u64 lbr_sel_mask;  /* LBR_SELECT valid bits */
const int   *lbr_sel_map;  /* lbr_select mappings */
boollbr_double_abort;  /* duplicated lbr aborts */
-   boollbr_pt_coexist;/* LBR may coexist with PT */
+   boollbr_pt_coexist;/* (LBR|BTS) may coexist 
with PT */
 
/*
 * Intel PT/LBR/BTS are exclusive

[PATCH 4.9 049/116] drm/amdgpu: fix init save/restore list in gfx_v8.0

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Rex Zhu 

commit 202e0b227b906cb80a2791f21216a55d9468d61b upstream.

set valid data to mmRLC_SRM_INDEX_CNTL_ADDRx/DATAx.

Signed-off-by: Rex Zhu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -3947,8 +3947,12 @@ static int gfx_v8_0_init_save_restore_li
temp = mmRLC_SRM_INDEX_CNTL_ADDR_0;
data = mmRLC_SRM_INDEX_CNTL_DATA_0;
for (i = 0; i < sizeof(unique_indices) / sizeof(int); i++) {
-   amdgpu_mm_wreg(adev, temp + i, unique_indices[i] & 0x3, 
false);
-   amdgpu_mm_wreg(adev, data + i, unique_indices[i] >> 20, false);
+   if (unique_indices[i] != 0) {
+   amdgpu_mm_wreg(adev, temp + i,
+   unique_indices[i] & 0x3, false);
+   amdgpu_mm_wreg(adev, data + i,
+   unique_indices[i] >> 20, false);
+   }
}
kfree(register_list_format);
 

[PATCH 4.9 000/116] 4.9.2-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 4.9.2 release.
There are 116 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Jan  8 21:38:42 UTC 2017.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.2-rc1.gz
or in the git tree and branch at:
  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 4.9.2-rc1

Mika Kuoppala 
drm/i915: Fix setting of boost freq tunable

Paulo Zanoni 
drm/i915: skip the first 4k of stolen memory on everything >= gen8

Ville Syrjälä 
drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time

Ville Syrjälä 
drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

Hans de Goede 
drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from 
vlv_init_display_clock_gating

Hans de Goede 
drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting

Thomas Petazzoni 
net: mvpp2: fix dma unmapping of TX buffers for fragments

Al Viro 
sg_write()/bsg_write() is not fit to be called under KERNEL_DS

Ben Hutchings 
kconfig/nconf: Fix hang when editing symbol with a long prompt

Andy Grover 
target/user: Fix use-after-free of tcmu_cmds if they are expired

Dan Williams 
libnvdimm, pfn: fix align attribute

David Daney 
of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not 
possible.

Nicholas Piggin 
powerpc/boot: Request no dynamic linker for boot wrapper

Geoff Levand 
powerpc/ps3: Fix system hang with GCC 5 builds

Nicholas Piggin 
powerpc/64e: Convert cmpi to cmpwi in head_64.S

NeilBrown 
SUNRPC: fix refcounting problems with auth_gss messages.

Trond Myklebust 
pNFS: Fix a deadlock between read resends and layoutreturn

Trond Myklebust 
pNFS: Clear NFS_LAYOUT_RETURN_REQUESTED when invalidating the layout stateid

Trond Myklebust 
pNFS: Don't clear the layout stateid if a layout return is outstanding

Trond Myklebust 
pNFS: On error, do not send LAYOUTGET until the LAYOUTRETURN has completed

Al Viro 
nfs_write_end(): fix handling of short copies

Ilya Dryomov 
libceph: verify authorize reply on connect

Alan Stern 
PCI: Check for PME in targeted sleep state

Shiraz Saleem 
i40iw: Use correct src address in memcpy to rdma stats counters

Miklos Szeredi 
bad_inode: add missing i_op initializers

Jingkui Wang 
Input: drv260x - fix input device's parent assignment

Laurent Pinchart 
v4l: tvp5150: Add missing break in set control handler

Andrey Utkin 
media: solo6x10: fix lockup by avoiding delayed register write

Marek Szyprowski 
s5p-mfc: fix failure path of s5p_mfc_alloc_memdev()

Antti Palosaari 
mn88473: fix chip id check on probe

Antti Palosaari 
mn88472: fix chip id check on probe

Bart Van Assche 
IB/cma: Fix a race condition in iboe_addr_get_sgid()

Bart Van Assche 
IB/rxe: Fix a memory leak in rxe_qp_cleanup()

Bart Van Assche 
IB/multicast: Check ib_find_pkey() return value

Bart Van Assche 
IPoIB: Avoid reading an uninitialized member variable

Bart Van Assche 
IB/mad: Fix an array index check

Steven Rostedt (Red Hat) 
fgraph: Handle a case where a tracer ignores set_graph_notrace

Thomas Gleixner 
x86/smpboot: Make logical package management more robust

Marcos Paulo de Souza 
platform/x86: asus-nb-wmi.c: Add X45U quirk

Steven Rostedt (Red Hat) 
ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short 
jumps to it

Michael S. Tsirkin 
vsock/virtio: fix src/dst cid format

Jan Kara 
fsnotify: Fix possible use-after-free in inode iteration on umount

Jim Mattson 
kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)

Paul Mackerras 
KVM: PPC: Book3S HV: Don't lose hardware R/C bit updates in H_PROTECT

Paul Mackerras 
KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state

Kevin Barnett 
scsi: aacraid: remove wildcard for series 9 controllers

Konstantin Khlebnikov 
md/raid5: limit request size according to implementation limits

Josh Cartwright 
sc16is7xx: Drop bogus use of IRQF_ONESHOT

Kees Cook 
latent_entropy: fix ARM build error on earlier gcc

Marc Zyngier 
arm64: KVM: pmu: Reset PMSELR_EL0.SEL to a sane value before entering the 
guest

Heiko Carstens 
s390/kexec: use node 0 when re-adding crash kernel memory

Gerald Schaefer 
s390/vmlogrdr: fix IUCV buffer allocation

Yves-Alexis Perez 
firmware: fix usermode helper fallback loading

Vineet Gupta 
ARC: mm: arc700: Don't assume 2 colours for aliasing VIPT dcache

Wei Fang 
scsi: avoid a permanent stop of the scsi 

[PATCH 4.9 044/116] drm/radeon: add additional pci revision to dpm workaround

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Alex Deucher 

commit 8729675c00a8d13cb2094d617d70a4a4da7d83c5 upstream.

New variant.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/si_dpm.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3026,6 +3026,7 @@ static void si_apply_state_adjust_rules(
(rdev->pdev->revision == 0x80) ||
(rdev->pdev->revision == 0x81) ||
(rdev->pdev->revision == 0x83) ||
+   (rdev->pdev->revision == 0x87) ||
(rdev->pdev->device == 0x6604) ||
(rdev->pdev->device == 0x6605)) {
max_sclk = 75000;

[PATCH 4.9 028/116] ACPI / video: Add force_native quirk for Dell XPS 17 L702X

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Hans de Goede 

commit 350fa038c31b056fc509624efb66348ac2c1e3d0 upstream.

The Dell XPS 17 L702X has a non-working acpi_video0 backlight interface
and an intel_backlight interface which works fine. Add a force_native
quirk for it so that the non-working acpi_video0 interface does not get
registered.

Note that there also is an issue with the brightnesskeys on this laptop,
they do not generate key-press events in anyway. That is not solved by
this patch.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1123661
Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/acpi/video_detect.c |9 +
 1 file changed, 9 insertions(+)

--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -296,6 +296,15 @@ static const struct dmi_system_id video_
DMI_MATCH(DMI_PRODUCT_NAME, "Vostro V131"),
},
},
+   {
+/* https://bugzilla.redhat.com/show_bug.cgi?id=1123661 */
+.callback = video_detect_force_native,
+.ident = "Dell XPS 17 L702X",
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L702X"),
+   },
+   },
{ },
 };
 

[PATCH 4.9 006/116] perf/x86/intel/cstate: Prevent hotplug callback leak

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Gleixner 

commit 834fcd298003c10ce450e66960c78893cb1cc4b5 upstream.

If the pmu registration fails the registered hotplug callbacks are not
removed. Wrong in any case, but fatal in case of a modular driver.

Replace the nonsensical state names with proper ones while at it.

Fixes: 77c34ef1c319 ("perf/x86/intel/cstate: Convert Intel CSTATE to hotplug 
state machine")
Signed-off-by: Thomas Gleixner 
Cc: Sebastian Siewior 
Cc: Peter Zijlstra 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/events/intel/cstate.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -594,6 +594,9 @@ static int __init cstate_probe(const str
 
 static inline void cstate_cleanup(void)
 {
+   cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_ONLINE);
+   cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_STARTING);
+
if (has_cstate_core)
perf_pmu_unregister(_core_pmu);
 
@@ -606,16 +609,16 @@ static int __init cstate_init(void)
int err;
 
cpuhp_setup_state(CPUHP_AP_PERF_X86_CSTATE_STARTING,
- "AP_PERF_X86_CSTATE_STARTING", cstate_cpu_init,
- NULL);
+ "perf/x86/cstate:starting", cstate_cpu_init, NULL);
cpuhp_setup_state(CPUHP_AP_PERF_X86_CSTATE_ONLINE,
- "AP_PERF_X86_CSTATE_ONLINE", NULL, cstate_cpu_exit);
+ "perf/x86/cstate:online", NULL, cstate_cpu_exit);
 
if (has_cstate_core) {
err = perf_pmu_register(_core_pmu, cstate_core_pmu.name, 
-1);
if (err) {
has_cstate_core = false;
pr_info("Failed to register cstate core pmu\n");
+   cstate_cleanup();
return err;
}
}
@@ -629,8 +632,7 @@ static int __init cstate_init(void)
return err;
}
}
-
-   return err;
+   return 0;
 }
 
 static int __init cstate_pmu_init(void)
@@ -655,8 +657,6 @@ module_init(cstate_pmu_init);
 
 static void __exit cstate_pmu_exit(void)
 {
-   cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_ONLINE);
-   cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_STARTING);
cstate_cleanup();
 }
 module_exit(cstate_pmu_exit);

[PATCH 4.9 047/116] drm/amd/powerplay: bypass fan table setup if no fan connected

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Hawking Zhang 

commit 10e2ca346bf74561ff1b7fff6287716ab976cd8c upstream.

If vBIOS noFan bit is set, the fan table parameters in thermal controller
will not get initialized. The driver should avoid to use these uninitialized
parameter to do calculation. Otherwise, it may trigger divide 0 error.

Signed-off-by: Hawking Zhang 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c  |6 ++
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c   |6 ++
 drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c |6 ++
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c |6 ++
 4 files changed, 24 insertions(+)

--- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
@@ -1958,6 +1958,12 @@ int fiji_thermal_setup_fan_table(struct
int res;
uint64_t tmp64;
 
+   if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+   phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_MicrocodeFanControl);
+   return 0;
+   }
+
if (smu_data->smu7_data.fan_table_start == 0) {
phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_MicrocodeFanControl);
--- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
@@ -2006,6 +2006,12 @@ int iceland_thermal_setup_fan_table(stru
if (!phm_cap_enabled(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_MicrocodeFanControl))
return 0;
 
+   if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+   phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_MicrocodeFanControl);
+   return 0;
+   }
+
if (0 == smu7_data->fan_table_start) {
phm_cap_unset(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_MicrocodeFanControl);
return 0;
--- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
@@ -1885,6 +1885,12 @@ int polaris10_thermal_setup_fan_table(st
int res;
uint64_t tmp64;
 
+   if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+   phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_MicrocodeFanControl);
+   return 0;
+   }
+
if (smu_data->smu7_data.fan_table_start == 0) {
phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_MicrocodeFanControl);
--- a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
@@ -2496,6 +2496,12 @@ int tonga_thermal_setup_fan_table(struct
PHM_PlatformCaps_MicrocodeFanControl))
return 0;
 
+   if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+   phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_MicrocodeFanControl);
+   return 0;
+   }
+
if (0 == smu_data->smu7_data.fan_table_start) {
phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_MicrocodeFanControl);

[PATCH 4.9 041/116] drm/nouveau/fifo/gf100-: protect channel preempt with subdev mutex

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Skeggs 

commit b27add13f500469127afdf011dbcc9c649e16e54 upstream.

This avoids an issue that occurs when we're attempting to preempt multiple
channels simultaneously.  HW seems to ignore preempt requests while it's
still processing a previous one, which, well, makes sense.

Fixes random "fifo: SCHED_ERROR 0d []" + GPCCS page faults during parallel
piglit runs on (at least) GM107.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c |9 ++---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c |8 +---
 2 files changed, 11 insertions(+), 6 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c
@@ -60,6 +60,7 @@ gf100_fifo_gpfifo_engine_fini(struct nvk
struct nvkm_gpuobj *inst = chan->base.inst;
int ret = 0;
 
+   mutex_lock(>mutex);
nvkm_wr32(device, 0x002634, chan->base.chid);
if (nvkm_msec(device, 2000,
if (nvkm_rd32(device, 0x002634) == chan->base.chid)
@@ -67,10 +68,12 @@ gf100_fifo_gpfifo_engine_fini(struct nvk
) < 0) {
nvkm_error(subdev, "channel %d [%s] kick timeout\n",
   chan->base.chid, chan->base.object.client->name);
-   ret = -EBUSY;
-   if (suspend)
-   return ret;
+   ret = -ETIMEDOUT;
}
+   mutex_unlock(>mutex);
+
+   if (ret && suspend)
+   return ret;
 
if (offset) {
nvkm_kmap(inst);
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c
@@ -40,7 +40,9 @@ gk104_fifo_gpfifo_kick(struct gk104_fifo
struct nvkm_subdev *subdev = >base.engine.subdev;
struct nvkm_device *device = subdev->device;
struct nvkm_client *client = chan->base.object.client;
+   int ret = 0;
 
+   mutex_lock(>mutex);
nvkm_wr32(device, 0x002634, chan->base.chid);
if (nvkm_msec(device, 2000,
if (!(nvkm_rd32(device, 0x002634) & 0x0010))
@@ -48,10 +50,10 @@ gk104_fifo_gpfifo_kick(struct gk104_fifo
) < 0) {
nvkm_error(subdev, "channel %d [%s] kick timeout\n",
   chan->base.chid, client->name);
-   return -EBUSY;
+   ret = -ETIMEDOUT;
}
-
-   return 0;
+   mutex_unlock(>mutex);
+   return ret;
 }
 
 static u32

[PATCH 4.9 028/116] ACPI / video: Add force_native quirk for Dell XPS 17 L702X

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Hans de Goede 

commit 350fa038c31b056fc509624efb66348ac2c1e3d0 upstream.

The Dell XPS 17 L702X has a non-working acpi_video0 backlight interface
and an intel_backlight interface which works fine. Add a force_native
quirk for it so that the non-working acpi_video0 interface does not get
registered.

Note that there also is an issue with the brightnesskeys on this laptop,
they do not generate key-press events in anyway. That is not solved by
this patch.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1123661
Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/acpi/video_detect.c |9 +
 1 file changed, 9 insertions(+)

--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -296,6 +296,15 @@ static const struct dmi_system_id video_
DMI_MATCH(DMI_PRODUCT_NAME, "Vostro V131"),
},
},
+   {
+/* https://bugzilla.redhat.com/show_bug.cgi?id=1123661 */
+.callback = video_detect_force_native,
+.ident = "Dell XPS 17 L702X",
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L702X"),
+   },
+   },
{ },
 };
 

[PATCH 4.9 006/116] perf/x86/intel/cstate: Prevent hotplug callback leak

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Gleixner 

commit 834fcd298003c10ce450e66960c78893cb1cc4b5 upstream.

If the pmu registration fails the registered hotplug callbacks are not
removed. Wrong in any case, but fatal in case of a modular driver.

Replace the nonsensical state names with proper ones while at it.

Fixes: 77c34ef1c319 ("perf/x86/intel/cstate: Convert Intel CSTATE to hotplug 
state machine")
Signed-off-by: Thomas Gleixner 
Cc: Sebastian Siewior 
Cc: Peter Zijlstra 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/events/intel/cstate.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -594,6 +594,9 @@ static int __init cstate_probe(const str
 
 static inline void cstate_cleanup(void)
 {
+   cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_ONLINE);
+   cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_STARTING);
+
if (has_cstate_core)
perf_pmu_unregister(_core_pmu);
 
@@ -606,16 +609,16 @@ static int __init cstate_init(void)
int err;
 
cpuhp_setup_state(CPUHP_AP_PERF_X86_CSTATE_STARTING,
- "AP_PERF_X86_CSTATE_STARTING", cstate_cpu_init,
- NULL);
+ "perf/x86/cstate:starting", cstate_cpu_init, NULL);
cpuhp_setup_state(CPUHP_AP_PERF_X86_CSTATE_ONLINE,
- "AP_PERF_X86_CSTATE_ONLINE", NULL, cstate_cpu_exit);
+ "perf/x86/cstate:online", NULL, cstate_cpu_exit);
 
if (has_cstate_core) {
err = perf_pmu_register(_core_pmu, cstate_core_pmu.name, 
-1);
if (err) {
has_cstate_core = false;
pr_info("Failed to register cstate core pmu\n");
+   cstate_cleanup();
return err;
}
}
@@ -629,8 +632,7 @@ static int __init cstate_init(void)
return err;
}
}
-
-   return err;
+   return 0;
 }
 
 static int __init cstate_pmu_init(void)
@@ -655,8 +657,6 @@ module_init(cstate_pmu_init);
 
 static void __exit cstate_pmu_exit(void)
 {
-   cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_ONLINE);
-   cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_STARTING);
cstate_cleanup();
 }
 module_exit(cstate_pmu_exit);

[PATCH 4.9 047/116] drm/amd/powerplay: bypass fan table setup if no fan connected

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Hawking Zhang 

commit 10e2ca346bf74561ff1b7fff6287716ab976cd8c upstream.

If vBIOS noFan bit is set, the fan table parameters in thermal controller
will not get initialized. The driver should avoid to use these uninitialized
parameter to do calculation. Otherwise, it may trigger divide 0 error.

Signed-off-by: Hawking Zhang 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c  |6 ++
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c   |6 ++
 drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c |6 ++
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c |6 ++
 4 files changed, 24 insertions(+)

--- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
@@ -1958,6 +1958,12 @@ int fiji_thermal_setup_fan_table(struct
int res;
uint64_t tmp64;
 
+   if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+   phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_MicrocodeFanControl);
+   return 0;
+   }
+
if (smu_data->smu7_data.fan_table_start == 0) {
phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_MicrocodeFanControl);
--- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
@@ -2006,6 +2006,12 @@ int iceland_thermal_setup_fan_table(stru
if (!phm_cap_enabled(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_MicrocodeFanControl))
return 0;
 
+   if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+   phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_MicrocodeFanControl);
+   return 0;
+   }
+
if (0 == smu7_data->fan_table_start) {
phm_cap_unset(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_MicrocodeFanControl);
return 0;
--- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
@@ -1885,6 +1885,12 @@ int polaris10_thermal_setup_fan_table(st
int res;
uint64_t tmp64;
 
+   if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+   phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_MicrocodeFanControl);
+   return 0;
+   }
+
if (smu_data->smu7_data.fan_table_start == 0) {
phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_MicrocodeFanControl);
--- a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
@@ -2496,6 +2496,12 @@ int tonga_thermal_setup_fan_table(struct
PHM_PlatformCaps_MicrocodeFanControl))
return 0;
 
+   if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+   phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_MicrocodeFanControl);
+   return 0;
+   }
+
if (0 == smu_data->smu7_data.fan_table_start) {
phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_MicrocodeFanControl);

[PATCH 4.9 041/116] drm/nouveau/fifo/gf100-: protect channel preempt with subdev mutex

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Skeggs 

commit b27add13f500469127afdf011dbcc9c649e16e54 upstream.

This avoids an issue that occurs when we're attempting to preempt multiple
channels simultaneously.  HW seems to ignore preempt requests while it's
still processing a previous one, which, well, makes sense.

Fixes random "fifo: SCHED_ERROR 0d []" + GPCCS page faults during parallel
piglit runs on (at least) GM107.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c |9 ++---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c |8 +---
 2 files changed, 11 insertions(+), 6 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c
@@ -60,6 +60,7 @@ gf100_fifo_gpfifo_engine_fini(struct nvk
struct nvkm_gpuobj *inst = chan->base.inst;
int ret = 0;
 
+   mutex_lock(>mutex);
nvkm_wr32(device, 0x002634, chan->base.chid);
if (nvkm_msec(device, 2000,
if (nvkm_rd32(device, 0x002634) == chan->base.chid)
@@ -67,10 +68,12 @@ gf100_fifo_gpfifo_engine_fini(struct nvk
) < 0) {
nvkm_error(subdev, "channel %d [%s] kick timeout\n",
   chan->base.chid, chan->base.object.client->name);
-   ret = -EBUSY;
-   if (suspend)
-   return ret;
+   ret = -ETIMEDOUT;
}
+   mutex_unlock(>mutex);
+
+   if (ret && suspend)
+   return ret;
 
if (offset) {
nvkm_kmap(inst);
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c
@@ -40,7 +40,9 @@ gk104_fifo_gpfifo_kick(struct gk104_fifo
struct nvkm_subdev *subdev = >base.engine.subdev;
struct nvkm_device *device = subdev->device;
struct nvkm_client *client = chan->base.object.client;
+   int ret = 0;
 
+   mutex_lock(>mutex);
nvkm_wr32(device, 0x002634, chan->base.chid);
if (nvkm_msec(device, 2000,
if (!(nvkm_rd32(device, 0x002634) & 0x0010))
@@ -48,10 +50,10 @@ gk104_fifo_gpfifo_kick(struct gk104_fifo
) < 0) {
nvkm_error(subdev, "channel %d [%s] kick timeout\n",
   chan->base.chid, client->name);
-   return -EBUSY;
+   ret = -ETIMEDOUT;
}
-
-   return 0;
+   mutex_unlock(>mutex);
+   return ret;
 }
 
 static u32

[PATCH 4.9 021/116] thermal: hwmon: Properly report critical temperature in sysfs

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Krzysztof Kozlowski 

commit f37fabb8643eaf8e3b61a72f683770c85eca upstream.

In the critical sysfs entry the thermal hwmon was returning wrong
temperature to the user-space.  It was reporting the temperature of the
first trip point instead of the temperature of critical trip point.

For example:
/sys/class/hwmon/hwmon0/temp1_crit:5
/sys/class/thermal/thermal_zone0/trip_point_0_temp:5
/sys/class/thermal/thermal_zone0/trip_point_0_type:active
/sys/class/thermal/thermal_zone0/trip_point_3_temp:12
/sys/class/thermal/thermal_zone0/trip_point_3_type:critical

Since commit e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver
have been registering a sysfs entry if get_crit_temp() callback was
provided.  However when accessed, it was calling get_trip_temp() instead
of the get_crit_temp().

Fixes: e68b16abd91d ("thermal: add hwmon sysfs I/F")
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Zhang Rui 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/thermal/thermal_hwmon.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -98,7 +98,7 @@ temp_crit_show(struct device *dev, struc
int temperature;
int ret;
 
-   ret = tz->ops->get_trip_temp(tz, 0, );
+   ret = tz->ops->get_crit_temp(tz, );
if (ret)
return ret;
 

[PATCH 4.9 020/116] clk: bcm2835: Avoid overwriting the div info when disabling a pll_div clk

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Boris Brezillon 

commit 68af4fa8f39b542a6cde7ac19518d88e9b3099dc upstream.

bcm2835_pll_divider_off() is resetting the divider field in the A2W reg
to zero when disabling the clock.

Make sure we preserve this value by reading the previous a2w_reg value
first and ORing the result with A2W_PLL_CHANNEL_DISABLE.

Signed-off-by: Boris Brezillon 
Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio 
domain clocks")
Reviewed-by: Eric Anholt 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/clk/bcm/clk-bcm2835.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -751,7 +751,9 @@ static void bcm2835_pll_divider_off(stru
cprman_write(cprman, data->cm_reg,
 (cprman_read(cprman, data->cm_reg) &
  ~data->load_mask) | data->hold_mask);
-   cprman_write(cprman, data->a2w_reg, A2W_PLL_CHANNEL_DISABLE);
+   cprman_write(cprman, data->a2w_reg,
+cprman_read(cprman, data->a2w_reg) |
+A2W_PLL_CHANNEL_DISABLE);
spin_unlock(>regs_lock);
 }
 

[PATCH 4.9 021/116] thermal: hwmon: Properly report critical temperature in sysfs

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Krzysztof Kozlowski 

commit f37fabb8643eaf8e3b61a72f683770c85eca upstream.

In the critical sysfs entry the thermal hwmon was returning wrong
temperature to the user-space.  It was reporting the temperature of the
first trip point instead of the temperature of critical trip point.

For example:
/sys/class/hwmon/hwmon0/temp1_crit:5
/sys/class/thermal/thermal_zone0/trip_point_0_temp:5
/sys/class/thermal/thermal_zone0/trip_point_0_type:active
/sys/class/thermal/thermal_zone0/trip_point_3_temp:12
/sys/class/thermal/thermal_zone0/trip_point_3_type:critical

Since commit e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver
have been registering a sysfs entry if get_crit_temp() callback was
provided.  However when accessed, it was calling get_trip_temp() instead
of the get_crit_temp().

Fixes: e68b16abd91d ("thermal: add hwmon sysfs I/F")
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Zhang Rui 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/thermal/thermal_hwmon.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -98,7 +98,7 @@ temp_crit_show(struct device *dev, struc
int temperature;
int ret;
 
-   ret = tz->ops->get_trip_temp(tz, 0, );
+   ret = tz->ops->get_crit_temp(tz, );
if (ret)
return ret;
 

[PATCH 4.9 020/116] clk: bcm2835: Avoid overwriting the div info when disabling a pll_div clk

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Boris Brezillon 

commit 68af4fa8f39b542a6cde7ac19518d88e9b3099dc upstream.

bcm2835_pll_divider_off() is resetting the divider field in the A2W reg
to zero when disabling the clock.

Make sure we preserve this value by reading the previous a2w_reg value
first and ORing the result with A2W_PLL_CHANNEL_DISABLE.

Signed-off-by: Boris Brezillon 
Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio 
domain clocks")
Reviewed-by: Eric Anholt 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/clk/bcm/clk-bcm2835.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -751,7 +751,9 @@ static void bcm2835_pll_divider_off(stru
cprman_write(cprman, data->cm_reg,
 (cprman_read(cprman, data->cm_reg) &
  ~data->load_mask) | data->hold_mask);
-   cprman_write(cprman, data->a2w_reg, A2W_PLL_CHANNEL_DISABLE);
+   cprman_write(cprman, data->a2w_reg,
+cprman_read(cprman, data->a2w_reg) |
+A2W_PLL_CHANNEL_DISABLE);
spin_unlock(>regs_lock);
 }
 

[PATCH 4.9 017/116] gpio: stmpe: fix interrupt handling bug

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Linus Walleij 

commit 1516c6350aa2770b8a5e36d40c3ec5078f92ba70 upstream.

commit 43db289d00c6 ("gpio: stmpe: Rework registers access")
reworked the STMPE register access so as to use
[STMPE_IDX_*_LSB + i] to access the 8bit register for a
certain bank, assuming the CSB and MSB will follow after
the enumerator. For this to work the index needs to go from
(size-1) to 0 not 0 to (size-1).

However for the GPIO IRQ handler, the status registers we read
register MSB + 3 bytes ahead for the 24 bit GPIOs and index
registers from MSB upwards and run an index i over the
registers UNLESS we are STMPE1600.

This is not working when we get to clearing the interrupt
EDGE status register STMPE_IDX_GPEDR_[LCM]SB: it is indexed
like all other registers [STMPE_IDX_*_LSB + i] but in this
loop we index from 0 to get the right bank index for the
calculations, and we need to just add i to the MSB.

Before this, interrupts on the STMPE2401 were broken, this
patch fixes it so it works again.

Cc: Patrice Chotard 
Fixes: 43db289d00c6 ("gpio: stmpe: Rework registers access")
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpio-stmpe.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpio/gpio-stmpe.c
+++ b/drivers/gpio/gpio-stmpe.c
@@ -413,7 +413,7 @@ static irqreturn_t stmpe_gpio_irq(int ir
stmpe->partnum != STMPE1801) {
stmpe_reg_write(stmpe, statmsbreg + i, status[i]);
stmpe_reg_write(stmpe,
-   stmpe->regs[STMPE_IDX_GPEDR_LSB + i],
+   stmpe->regs[STMPE_IDX_GPEDR_MSB] + i,
status[i]);
}
}

[PATCH 4.8 80/96] pNFS: On error, do not send LAYOUTGET until the LAYOUTRETURN has completed

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Trond Myklebust 

commit 6604b203fb6394ed1f24c21bfa3c207e5ae8e461 upstream.

If there is an I/O error, we should not call LAYOUTGET until the
LAYOUTRETURN that reports the error is complete.

Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfs/pnfs.c |6 +-
 fs/nfs/pnfs.h |1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -897,6 +897,7 @@ static void pnfs_clear_layoutcommit(stru
 void pnfs_clear_layoutreturn_waitbit(struct pnfs_layout_hdr *lo)
 {
clear_bit_unlock(NFS_LAYOUT_RETURN, >plh_flags);
+   clear_bit(NFS_LAYOUT_RETURN_LOCK, >plh_flags);
smp_mb__after_atomic();
wake_up_bit(>plh_flags, NFS_LAYOUT_RETURN);
rpc_wake_up(_SERVER(lo->plh_inode)->roc_rpcwaitq);
@@ -910,8 +911,9 @@ pnfs_prepare_layoutreturn(struct pnfs_la
/* Serialise LAYOUTGET/LAYOUTRETURN */
if (atomic_read(>plh_outstanding) != 0)
return false;
-   if (test_and_set_bit(NFS_LAYOUT_RETURN, >plh_flags))
+   if (test_and_set_bit(NFS_LAYOUT_RETURN_LOCK, >plh_flags))
return false;
+   set_bit(NFS_LAYOUT_RETURN, >plh_flags);
pnfs_get_layout_hdr(lo);
if (test_bit(NFS_LAYOUT_RETURN_REQUESTED, >plh_flags)) {
if (stateid != NULL) {
@@ -1903,6 +1905,8 @@ void pnfs_error_mark_layout_for_return(s
 
spin_lock(>i_lock);
pnfs_set_plh_return_info(lo, range.iomode, 0);
+   /* Block LAYOUTGET */
+   set_bit(NFS_LAYOUT_RETURN, >plh_flags);
/*
 * mark all matching lsegs so that we are sure to have no live
 * segments at hand when sending layoutreturn. See pnfs_put_lseg()
--- a/fs/nfs/pnfs.h
+++ b/fs/nfs/pnfs.h
@@ -96,6 +96,7 @@ enum {
NFS_LAYOUT_RW_FAILED,   /* get rw layout failed stop trying */
NFS_LAYOUT_BULK_RECALL, /* bulk recall affecting layout */
NFS_LAYOUT_RETURN,  /* layoutreturn in progress */
+   NFS_LAYOUT_RETURN_LOCK, /* Serialise layoutreturn */
NFS_LAYOUT_RETURN_REQUESTED,/* Return this layout ASAP */
NFS_LAYOUT_INVALID_STID,/* layout stateid id is invalid */
NFS_LAYOUT_FIRST_LAYOUTGET, /* Serialize first layoutget */

[PATCH 4.9 014/116] regulator: stw481x-vmmc: fix ages old enable error

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Linus Walleij 

commit 295070e9aa015abb9b92cccfbb1e43954e938133 upstream.

The regulator has never been properly enabled, it has been
dormant all the time. It's strange that MMC was working
at all, but it likely worked by the signals going through
the levelshifter and reaching the card anyways.

Fixes: 3615a34ea1a6 ("regulator: add STw481x VMMC driver")
Signed-off-by: Linus Walleij 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/regulator/stw481x-vmmc.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/regulator/stw481x-vmmc.c
+++ b/drivers/regulator/stw481x-vmmc.c
@@ -47,7 +47,8 @@ static struct regulator_desc vmmc_regula
.volt_table = stw481x_vmmc_voltages,
.enable_time = 200, /* FIXME: look this up */
.enable_reg = STW_CONF1,
-   .enable_mask = STW_CONF1_PDN_VMMC,
+   .enable_mask = STW_CONF1_PDN_VMMC | STW_CONF1_MMC_LS_STATUS,
+   .enable_val = STW_CONF1_PDN_VMMC,
.vsel_reg = STW_CONF1,
.vsel_mask = STW_CONF1_VMMC_MASK,
 };

[PATCH 4.9 013/116] mmc: sdhci: Fix recovery from tuning timeout

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Adrian Hunter 

commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream.

Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.

Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.

Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.

Signed-off-by: Adrian Hunter 
Tested-by: Dan O'Donovan 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/sdhci.c |   20 
 1 file changed, 20 insertions(+)

--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2091,7 +2091,27 @@ static int sdhci_execute_tuning(struct m
ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
+   sdhci_do_reset(host, SDHCI_RESET_CMD);
+   sdhci_do_reset(host, SDHCI_RESET_DATA);
+
err = -EIO;
+
+   if (cmd.opcode != MMC_SEND_TUNING_BLOCK_HS200)
+   goto out;
+
+   sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
+   sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
+
+   spin_unlock_irqrestore(>lock, flags);
+
+   memset(, 0, sizeof(cmd));
+   cmd.opcode = MMC_STOP_TRANSMISSION;
+   cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
+   cmd.busy_timeout = 50;
+   mmc_wait_for_cmd(mmc, , 0);
+
+   spin_lock_irqsave(>lock, flags);
+
goto out;
}
 

[PATCH 4.9 014/116] regulator: stw481x-vmmc: fix ages old enable error

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Linus Walleij 

commit 295070e9aa015abb9b92cccfbb1e43954e938133 upstream.

The regulator has never been properly enabled, it has been
dormant all the time. It's strange that MMC was working
at all, but it likely worked by the signals going through
the levelshifter and reaching the card anyways.

Fixes: 3615a34ea1a6 ("regulator: add STw481x VMMC driver")
Signed-off-by: Linus Walleij 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/regulator/stw481x-vmmc.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/regulator/stw481x-vmmc.c
+++ b/drivers/regulator/stw481x-vmmc.c
@@ -47,7 +47,8 @@ static struct regulator_desc vmmc_regula
.volt_table = stw481x_vmmc_voltages,
.enable_time = 200, /* FIXME: look this up */
.enable_reg = STW_CONF1,
-   .enable_mask = STW_CONF1_PDN_VMMC,
+   .enable_mask = STW_CONF1_PDN_VMMC | STW_CONF1_MMC_LS_STATUS,
+   .enable_val = STW_CONF1_PDN_VMMC,
.vsel_reg = STW_CONF1,
.vsel_mask = STW_CONF1_VMMC_MASK,
 };

[PATCH 4.9 017/116] gpio: stmpe: fix interrupt handling bug

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Linus Walleij 

commit 1516c6350aa2770b8a5e36d40c3ec5078f92ba70 upstream.

commit 43db289d00c6 ("gpio: stmpe: Rework registers access")
reworked the STMPE register access so as to use
[STMPE_IDX_*_LSB + i] to access the 8bit register for a
certain bank, assuming the CSB and MSB will follow after
the enumerator. For this to work the index needs to go from
(size-1) to 0 not 0 to (size-1).

However for the GPIO IRQ handler, the status registers we read
register MSB + 3 bytes ahead for the 24 bit GPIOs and index
registers from MSB upwards and run an index i over the
registers UNLESS we are STMPE1600.

This is not working when we get to clearing the interrupt
EDGE status register STMPE_IDX_GPEDR_[LCM]SB: it is indexed
like all other registers [STMPE_IDX_*_LSB + i] but in this
loop we index from 0 to get the right bank index for the
calculations, and we need to just add i to the MSB.

Before this, interrupts on the STMPE2401 were broken, this
patch fixes it so it works again.

Cc: Patrice Chotard 
Fixes: 43db289d00c6 ("gpio: stmpe: Rework registers access")
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpio-stmpe.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpio/gpio-stmpe.c
+++ b/drivers/gpio/gpio-stmpe.c
@@ -413,7 +413,7 @@ static irqreturn_t stmpe_gpio_irq(int ir
stmpe->partnum != STMPE1801) {
stmpe_reg_write(stmpe, statmsbreg + i, status[i]);
stmpe_reg_write(stmpe,
-   stmpe->regs[STMPE_IDX_GPEDR_LSB + i],
+   stmpe->regs[STMPE_IDX_GPEDR_MSB] + i,
status[i]);
}
}

[PATCH 4.8 80/96] pNFS: On error, do not send LAYOUTGET until the LAYOUTRETURN has completed

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Trond Myklebust 

commit 6604b203fb6394ed1f24c21bfa3c207e5ae8e461 upstream.

If there is an I/O error, we should not call LAYOUTGET until the
LAYOUTRETURN that reports the error is complete.

Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfs/pnfs.c |6 +-
 fs/nfs/pnfs.h |1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -897,6 +897,7 @@ static void pnfs_clear_layoutcommit(stru
 void pnfs_clear_layoutreturn_waitbit(struct pnfs_layout_hdr *lo)
 {
clear_bit_unlock(NFS_LAYOUT_RETURN, >plh_flags);
+   clear_bit(NFS_LAYOUT_RETURN_LOCK, >plh_flags);
smp_mb__after_atomic();
wake_up_bit(>plh_flags, NFS_LAYOUT_RETURN);
rpc_wake_up(_SERVER(lo->plh_inode)->roc_rpcwaitq);
@@ -910,8 +911,9 @@ pnfs_prepare_layoutreturn(struct pnfs_la
/* Serialise LAYOUTGET/LAYOUTRETURN */
if (atomic_read(>plh_outstanding) != 0)
return false;
-   if (test_and_set_bit(NFS_LAYOUT_RETURN, >plh_flags))
+   if (test_and_set_bit(NFS_LAYOUT_RETURN_LOCK, >plh_flags))
return false;
+   set_bit(NFS_LAYOUT_RETURN, >plh_flags);
pnfs_get_layout_hdr(lo);
if (test_bit(NFS_LAYOUT_RETURN_REQUESTED, >plh_flags)) {
if (stateid != NULL) {
@@ -1903,6 +1905,8 @@ void pnfs_error_mark_layout_for_return(s
 
spin_lock(>i_lock);
pnfs_set_plh_return_info(lo, range.iomode, 0);
+   /* Block LAYOUTGET */
+   set_bit(NFS_LAYOUT_RETURN, >plh_flags);
/*
 * mark all matching lsegs so that we are sure to have no live
 * segments at hand when sending layoutreturn. See pnfs_put_lseg()
--- a/fs/nfs/pnfs.h
+++ b/fs/nfs/pnfs.h
@@ -96,6 +96,7 @@ enum {
NFS_LAYOUT_RW_FAILED,   /* get rw layout failed stop trying */
NFS_LAYOUT_BULK_RECALL, /* bulk recall affecting layout */
NFS_LAYOUT_RETURN,  /* layoutreturn in progress */
+   NFS_LAYOUT_RETURN_LOCK, /* Serialise layoutreturn */
NFS_LAYOUT_RETURN_REQUESTED,/* Return this layout ASAP */
NFS_LAYOUT_INVALID_STID,/* layout stateid id is invalid */
NFS_LAYOUT_FIRST_LAYOUTGET, /* Serialize first layoutget */

[PATCH 4.9 013/116] mmc: sdhci: Fix recovery from tuning timeout

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Adrian Hunter 

commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream.

Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.

Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.

Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.

Signed-off-by: Adrian Hunter 
Tested-by: Dan O'Donovan 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/sdhci.c |   20 
 1 file changed, 20 insertions(+)

--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2091,7 +2091,27 @@ static int sdhci_execute_tuning(struct m
ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
+   sdhci_do_reset(host, SDHCI_RESET_CMD);
+   sdhci_do_reset(host, SDHCI_RESET_DATA);
+
err = -EIO;
+
+   if (cmd.opcode != MMC_SEND_TUNING_BLOCK_HS200)
+   goto out;
+
+   sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
+   sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
+
+   spin_unlock_irqrestore(>lock, flags);
+
+   memset(, 0, sizeof(cmd));
+   cmd.opcode = MMC_STOP_TRANSMISSION;
+   cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
+   cmd.busy_timeout = 50;
+   mmc_wait_for_cmd(mmc, , 0);
+
+   spin_lock_irqsave(>lock, flags);
+
goto out;
}
 

[PATCH 4.9 018/116] gpio: chardev: Return error for seek operations

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Lars-Peter Clausen 

commit f4e81c529767b9a33d1b27695c54dc84a14af30d upstream.

The GPIO chardev is used for management tasks (allocating line and event
handles) and does neither support read() nor write() operations. Hence it
does not make much sense to allow seek operations.

Currently the chardev uses noop_llseek() for its seek implementation. This
function does not move the pointer and simply returns the current position
(always 0 for the GPIO chardev). noop_llseek() is primarily meant for
devices that can not support seek, but where there might be a user that
depends on the seek() operation succeeding. For newly added devices that
can not support seek operations it is recommended to use no_llseek(), which
will return an error. For more information see commit 6038f373a3dc
("llseek: automatically add .llseek fop").

Unfortunately this was overlooked when the GPIO chardev ABI was introduced.
But it is highly unlikely that since then userspace applications have
appeared that rely on being able to perform non-failing seek operations on
a GPIO chardev file descriptor. So it should be safe to change from
noop_llseel() to no_seek(). Also use nonseekable_open() in the chardev
open() callback to clear the FMODE_SEEK, FMODE_PREAD and FMODE_PWRITE flags
from the file. Neither of these should be set on a file that does not
support seek operations.

Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs")
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpiolib.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -986,7 +986,8 @@ static int gpio_chrdev_open(struct inode
return -ENODEV;
get_device(>dev);
filp->private_data = gdev;
-   return 0;
+
+   return nonseekable_open(inode, filp);
 }
 
 /**
@@ -1011,7 +1012,7 @@ static const struct file_operations gpio
.release = gpio_chrdev_release,
.open = gpio_chrdev_open,
.owner = THIS_MODULE,
-   .llseek = noop_llseek,
+   .llseek = no_llseek,
.unlocked_ioctl = gpio_ioctl,
 #ifdef CONFIG_COMPAT
.compat_ioctl = gpio_ioctl_compat,

[PATCH 4.9 016/116] timekeeping_Force_unsigned_clocksource_to_nanoseconds_conversion

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Gleixner 

commit 9c1645727b8fa90d07256fdfcc45bf831242a3ab upstream.

The clocksource delta to nanoseconds conversion is using signed math, but
the delta is unsigned. This makes the conversion space smaller than
necessary and in case of a multiplication overflow the conversion can
become negative. The conversion is done with scaled math:

s64 nsec_delta = ((s64)clkdelta * clk->mult) >> clk->shift;

Shifting a signed integer right obvioulsy preserves the sign, which has
interesting consequences:

 - Time jumps backwards

 - __iter_div_u64_rem() which is used in one of the calling code pathes
   will take forever to piecewise calculate the seconds/nanoseconds part.

This has been reported by several people with different scenarios:

David observed that when stopping a VM with a debugger:

 "It was essentially the stopped by debugger case.  I forget exactly why,
  but the guest was being explicitly stopped from outside, it wasn't just
  scheduling lag.  I think it was something in the vicinity of 10 minutes
  stopped."

 When lifting the stop the machine went dead.

The stopped by debugger case is not really interesting, but nevertheless it
would be a good thing not to die completely.

But this was also observed on a live system by Liav:

 "When the OS is too overloaded, delta will get a high enough value for the
  msb of the sum delta * tkr->mult + tkr->xtime_nsec to be set, and so
  after the shift the nsec variable will gain a value similar to
  0xff00."

Unfortunately this has been reintroduced recently with commit 6bd58f09e1d8
("time: Add cycles to nanoseconds translation"). It had been fixed a year
ago already in commit 35a4933a8959 ("time: Avoid signed overflow in
timekeeping_get_ns()").

Though it's not surprising that the issue has been reintroduced because the
function itself and the whole call chain uses s64 for the result and the
propagation of it. The change in this recent commit is subtle:

   s64 nsec;

-  nsec = (d * m + n) >> s:
+  nsec = d * m + n;
+  nsec >>= s;

d being type of cycle_t adds another level of obfuscation.

This wouldn't have happened if the previous change to unsigned computation
would have made the 'nsec' variable u64 right away and a follow up patch
had cleaned up the whole call chain.

There have been patches submitted which basically did a revert of the above
patch leaving everything else unchanged as signed. Back to square one. This
spawned a admittedly pointless discussion about potential users which rely
on the unsigned behaviour until someone pointed out that it had been fixed
before. The changelogs of said patches added further confusion as they made
finally false claims about the consequences for eventual users which expect
signed results.

Despite delta being cycle_t, aka. u64, it's very well possible to hand in
a signed negative value and the signed computation will happily return the
correct result. But nobody actually sat down and analyzed the code which
was added as user after the propably unintended signed conversion.

Though in sensitive code like this it's better to analyze it proper and
make sure that nothing relies on this than hunting the subtle wreckage half
a year later. After analyzing all call chains it stands that no caller can
hand in a negative value (which actually would work due to the s64 cast)
and rely on the signed math to do the right thing.

Change the conversion function to unsigned math. The conversion of all call
chains is done in a follow up patch.

This solves the starvation issue, which was caused by the negative result,
but it does not solve the underlying problem. It merily procrastinates
it. When the timekeeper update is deferred long enough that the unsigned
multiplication overflows, then time going backwards is observable again.

It does neither solve the issue of clocksources with a small counter width
which will wrap around possibly several times and cause random time stamps
to be generated. But those are usually not found on systems used for
virtualization, so this is likely a non issue.

I took the liberty to claim authorship for this simply because
analyzing all callsites and writing the changelog took substantially
more time than just making the simple s/s64/u64/ change and ignore the
rest.

Fixes: 6bd58f09e1d8 ("time: Add cycles to nanoseconds translation")
Reported-by: David Gibson 
Reported-by: Liav Rehana 
Signed-off-by: Thomas Gleixner 
Reviewed-by: David Gibson 
Acked-by: Peter Zijlstra (Intel) 
Cc: Parit Bhargava 
Cc: Laurent Vivier 
Cc: "Christopher S. Hall" 
Cc: Chris Metcalf 
Cc: Richard Cochran 
Cc: John Stultz 

[PATCH 4.9 010/116] ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Vittorio Gambaletta (VittGam) 

commit 79e57dd113d307a6c74773b8aaecf5442068988a upstream.

The active_high LED of my Wistron DNMA-92 is still being recognized as
active_low on 4.7.6 mainline. When I was preparing my former commit
0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92
cards.") to fix that I must have somehow messed up with testing, because
I tested the final version of that patch before sending it, and it was
apparently working; but now it is not working on 4.7.6 mainline.

I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the
PCI_VDEVICE section for 0x0029; but then I moved the former below the
latter after seeing how 0x002A sections were sorted in the file.

This turned out to be wrong: if a generic PCI_VDEVICE entry (that has
both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more
specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will
match first and will be used.

With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.

While I'm at it, let's fix 0x002A too by also moving its generic definition
below its specific ones.

Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 
cards.")
Signed-off-by: Vittorio Gambaletta 
[kv...@qca.qualcomm.com: improve the commit log based on email discussions]
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/pci.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -26,7 +26,6 @@ static const struct pci_device_id ath_pc
{ PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI   */
{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
{ PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI   */
-   { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI   */
 
 #ifdef CONFIG_ATH9K_PCOEM
/* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
@@ -37,7 +36,7 @@ static const struct pci_device_id ath_pc
  .driver_data = ATH9K_PCI_LED_ACT_HI },
 #endif
 
-   { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
+   { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI   */
 
 #ifdef CONFIG_ATH9K_PCOEM
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
@@ -85,7 +84,11 @@ static const struct pci_device_id ath_pc
 0x10CF, /* Fujitsu */
 0x1536),
  .driver_data = ATH9K_PCI_D3_L1_WAR },
+#endif
 
+   { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
+
+#ifdef CONFIG_ATH9K_PCOEM
/* AR9285 card for Asus */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
 0x002B,

[PATCH 4.9 002/116] ath10k: fix soft lockup during firmware crash/hw-restart

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Mohammed Shafi Shajakhan 

commit c2cac2f74ab4bcf0db0dcf3a612f1e5b52d145c8 upstream.

During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.

During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')

'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)

Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'

Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath10k/core.c |2 +-
 drivers/net/wireless/ath/ath10k/mac.c  |1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1534,7 +1534,7 @@ static void ath10k_core_restart(struct w
switch (ar->state) {
case ATH10K_STATE_ON:
ar->state = ATH10K_STATE_RESTARTING;
-   ath10k_hif_stop(ar);
+   ath10k_halt(ar);
ath10k_scan_finish(ar);
ieee80211_restart_hw(ar->hw);
break;
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211
ar->state = ATH10K_STATE_ON;
break;
case ATH10K_STATE_RESTARTING:
-   ath10k_halt(ar);
ar->state = ATH10K_STATE_RESTARTED;
break;
case ATH10K_STATE_ON:

[PATCH 4.9 002/116] ath10k: fix soft lockup during firmware crash/hw-restart

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Mohammed Shafi Shajakhan 

commit c2cac2f74ab4bcf0db0dcf3a612f1e5b52d145c8 upstream.

During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.

During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')

'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)

Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'

Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath10k/core.c |2 +-
 drivers/net/wireless/ath/ath10k/mac.c  |1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1534,7 +1534,7 @@ static void ath10k_core_restart(struct w
switch (ar->state) {
case ATH10K_STATE_ON:
ar->state = ATH10K_STATE_RESTARTING;
-   ath10k_hif_stop(ar);
+   ath10k_halt(ar);
ath10k_scan_finish(ar);
ieee80211_restart_hw(ar->hw);
break;
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211
ar->state = ATH10K_STATE_ON;
break;
case ATH10K_STATE_RESTARTING:
-   ath10k_halt(ar);
ar->state = ATH10K_STATE_RESTARTED;
break;
case ATH10K_STATE_ON:

[PATCH 4.9 016/116] timekeeping_Force_unsigned_clocksource_to_nanoseconds_conversion

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Gleixner 

commit 9c1645727b8fa90d07256fdfcc45bf831242a3ab upstream.

The clocksource delta to nanoseconds conversion is using signed math, but
the delta is unsigned. This makes the conversion space smaller than
necessary and in case of a multiplication overflow the conversion can
become negative. The conversion is done with scaled math:

s64 nsec_delta = ((s64)clkdelta * clk->mult) >> clk->shift;

Shifting a signed integer right obvioulsy preserves the sign, which has
interesting consequences:

 - Time jumps backwards

 - __iter_div_u64_rem() which is used in one of the calling code pathes
   will take forever to piecewise calculate the seconds/nanoseconds part.

This has been reported by several people with different scenarios:

David observed that when stopping a VM with a debugger:

 "It was essentially the stopped by debugger case.  I forget exactly why,
  but the guest was being explicitly stopped from outside, it wasn't just
  scheduling lag.  I think it was something in the vicinity of 10 minutes
  stopped."

 When lifting the stop the machine went dead.

The stopped by debugger case is not really interesting, but nevertheless it
would be a good thing not to die completely.

But this was also observed on a live system by Liav:

 "When the OS is too overloaded, delta will get a high enough value for the
  msb of the sum delta * tkr->mult + tkr->xtime_nsec to be set, and so
  after the shift the nsec variable will gain a value similar to
  0xff00."

Unfortunately this has been reintroduced recently with commit 6bd58f09e1d8
("time: Add cycles to nanoseconds translation"). It had been fixed a year
ago already in commit 35a4933a8959 ("time: Avoid signed overflow in
timekeeping_get_ns()").

Though it's not surprising that the issue has been reintroduced because the
function itself and the whole call chain uses s64 for the result and the
propagation of it. The change in this recent commit is subtle:

   s64 nsec;

-  nsec = (d * m + n) >> s:
+  nsec = d * m + n;
+  nsec >>= s;

d being type of cycle_t adds another level of obfuscation.

This wouldn't have happened if the previous change to unsigned computation
would have made the 'nsec' variable u64 right away and a follow up patch
had cleaned up the whole call chain.

There have been patches submitted which basically did a revert of the above
patch leaving everything else unchanged as signed. Back to square one. This
spawned a admittedly pointless discussion about potential users which rely
on the unsigned behaviour until someone pointed out that it had been fixed
before. The changelogs of said patches added further confusion as they made
finally false claims about the consequences for eventual users which expect
signed results.

Despite delta being cycle_t, aka. u64, it's very well possible to hand in
a signed negative value and the signed computation will happily return the
correct result. But nobody actually sat down and analyzed the code which
was added as user after the propably unintended signed conversion.

Though in sensitive code like this it's better to analyze it proper and
make sure that nothing relies on this than hunting the subtle wreckage half
a year later. After analyzing all call chains it stands that no caller can
hand in a negative value (which actually would work due to the s64 cast)
and rely on the signed math to do the right thing.

Change the conversion function to unsigned math. The conversion of all call
chains is done in a follow up patch.

This solves the starvation issue, which was caused by the negative result,
but it does not solve the underlying problem. It merily procrastinates
it. When the timekeeper update is deferred long enough that the unsigned
multiplication overflows, then time going backwards is observable again.

It does neither solve the issue of clocksources with a small counter width
which will wrap around possibly several times and cause random time stamps
to be generated. But those are usually not found on systems used for
virtualization, so this is likely a non issue.

I took the liberty to claim authorship for this simply because
analyzing all callsites and writing the changelog took substantially
more time than just making the simple s/s64/u64/ change and ignore the
rest.

Fixes: 6bd58f09e1d8 ("time: Add cycles to nanoseconds translation")
Reported-by: David Gibson 
Reported-by: Liav Rehana 
Signed-off-by: Thomas Gleixner 
Reviewed-by: David Gibson 
Acked-by: Peter Zijlstra (Intel) 
Cc: Parit Bhargava 
Cc: Laurent Vivier 
Cc: "Christopher S. Hall" 
Cc: Chris Metcalf 
Cc: Richard Cochran 
Cc: John Stultz 
Link: http://lkml.kernel.org/r/20161208204228.688545...@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/time/timekeeping.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/kernel/time/timekeeping.c
+++ 

[PATCH 4.9 010/116] ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Vittorio Gambaletta (VittGam) 

commit 79e57dd113d307a6c74773b8aaecf5442068988a upstream.

The active_high LED of my Wistron DNMA-92 is still being recognized as
active_low on 4.7.6 mainline. When I was preparing my former commit
0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92
cards.") to fix that I must have somehow messed up with testing, because
I tested the final version of that patch before sending it, and it was
apparently working; but now it is not working on 4.7.6 mainline.

I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the
PCI_VDEVICE section for 0x0029; but then I moved the former below the
latter after seeing how 0x002A sections were sorted in the file.

This turned out to be wrong: if a generic PCI_VDEVICE entry (that has
both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more
specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will
match first and will be used.

With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.

While I'm at it, let's fix 0x002A too by also moving its generic definition
below its specific ones.

Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 
cards.")
Signed-off-by: Vittorio Gambaletta 
[kv...@qca.qualcomm.com: improve the commit log based on email discussions]
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/pci.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -26,7 +26,6 @@ static const struct pci_device_id ath_pc
{ PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI   */
{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
{ PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI   */
-   { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI   */
 
 #ifdef CONFIG_ATH9K_PCOEM
/* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
@@ -37,7 +36,7 @@ static const struct pci_device_id ath_pc
  .driver_data = ATH9K_PCI_LED_ACT_HI },
 #endif
 
-   { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
+   { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI   */
 
 #ifdef CONFIG_ATH9K_PCOEM
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
@@ -85,7 +84,11 @@ static const struct pci_device_id ath_pc
 0x10CF, /* Fujitsu */
 0x1536),
  .driver_data = ATH9K_PCI_D3_L1_WAR },
+#endif
 
+   { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
+
+#ifdef CONFIG_ATH9K_PCOEM
/* AR9285 card for Asus */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
 0x002B,

[PATCH 4.9 018/116] gpio: chardev: Return error for seek operations

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Lars-Peter Clausen 

commit f4e81c529767b9a33d1b27695c54dc84a14af30d upstream.

The GPIO chardev is used for management tasks (allocating line and event
handles) and does neither support read() nor write() operations. Hence it
does not make much sense to allow seek operations.

Currently the chardev uses noop_llseek() for its seek implementation. This
function does not move the pointer and simply returns the current position
(always 0 for the GPIO chardev). noop_llseek() is primarily meant for
devices that can not support seek, but where there might be a user that
depends on the seek() operation succeeding. For newly added devices that
can not support seek operations it is recommended to use no_llseek(), which
will return an error. For more information see commit 6038f373a3dc
("llseek: automatically add .llseek fop").

Unfortunately this was overlooked when the GPIO chardev ABI was introduced.
But it is highly unlikely that since then userspace applications have
appeared that rely on being able to perform non-failing seek operations on
a GPIO chardev file descriptor. So it should be safe to change from
noop_llseel() to no_seek(). Also use nonseekable_open() in the chardev
open() callback to clear the FMODE_SEEK, FMODE_PREAD and FMODE_PWRITE flags
from the file. Neither of these should be set on a file that does not
support seek operations.

Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs")
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpiolib.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -986,7 +986,8 @@ static int gpio_chrdev_open(struct inode
return -ENODEV;
get_device(>dev);
filp->private_data = gdev;
-   return 0;
+
+   return nonseekable_open(inode, filp);
 }
 
 /**
@@ -1011,7 +1012,7 @@ static const struct file_operations gpio
.release = gpio_chrdev_release,
.open = gpio_chrdev_open,
.owner = THIS_MODULE,
-   .llseek = noop_llseek,
+   .llseek = no_llseek,
.unlocked_ioctl = gpio_ioctl,
 #ifdef CONFIG_COMPAT
.compat_ioctl = gpio_ioctl_compat,

[PATCH 4.8 81/96] pNFS: Dont clear the layout stateid if a layout return is outstanding

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Trond Myklebust 

commit 7b650994ab07434ae58a247dc9ac87d2488ca75c upstream.

If we no longer hold any layout segments, we're normally expected to
consider the layout stateid to be invalid. However we cannot assume this
if we're about to, or in the process of sending a layoutreturn.

Fixes: 334a8f37115b ("pNFS: Don't forget the layout stateid if...")
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfs/pnfs.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -364,7 +364,9 @@ pnfs_layout_remove_lseg(struct pnfs_layo
list_del_init(>pls_list);
/* Matched by pnfs_get_layout_hdr in pnfs_layout_insert_lseg */
atomic_dec(>plh_refcount);
-   if (list_empty(>plh_segs)) {
+   if (list_empty(>plh_segs) &&
+   !test_bit(NFS_LAYOUT_RETURN_REQUESTED, >plh_flags) &&
+   !test_bit(NFS_LAYOUT_RETURN, >plh_flags)) {
if (atomic_read(>plh_outstanding) == 0)
set_bit(NFS_LAYOUT_INVALID_STID, >plh_flags);
clear_bit(NFS_LAYOUT_BULK_RECALL, >plh_flags);

[PATCH 4.9 001/116] ssb: Fix error routine when fallback SPROM fails

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Larry Finger 

commit 8052d7245b6089992343c80b38b14dbbd8354651 upstream.

When there is a CRC error in the SPROM read from the device, the code
attempts to handle a fallback SPROM. When this also fails, the driver
returns zero rather than an error code.

Signed-off-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/ssb/pci.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/ssb/pci.c
+++ b/drivers/ssb/pci.c
@@ -909,6 +909,7 @@ static int ssb_pci_sprom_get(struct ssb_
if (err) {
ssb_warn("WARNING: Using fallback SPROM failed 
(err %d)\n",
 err);
+   goto out_free;
} else {
ssb_dbg("Using SPROM revision %d provided by 
platform\n",
sprom->revision);

[PATCH 4.9 022/116] docs: sphinx-extensions: make rstFlatTable work with docutils 0.13

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Dmitry Shachnev 

commit 217e2bfab22e740227df09f22165e834cddd8a3b upstream.

In docutils 0.13, the return type of get_column_widths method of the
Table directive has changed [1], which breaks our flat-table directive
and leads to a TypeError when trying to build the docs [2].

This patch adds support for the new return type, while keeping support
for older docutils versions too.

[1] https://sourceforge.net/p/docutils/patches/120/
[2] https://sourceforge.net/p/docutils/bugs/303/

Signed-off-by: Dmitry Shachnev 
Signed-off-by: Jonathan Corbet 
Signed-off-by: Greg Kroah-Hartman 

---
 Documentation/sphinx/rstFlatTable.py |5 +
 1 file changed, 5 insertions(+)

--- a/Documentation/sphinx/rstFlatTable.py
+++ b/Documentation/sphinx/rstFlatTable.py
@@ -157,6 +157,11 @@ class ListTableBuilder(object):
 def buildTableNode(self):
 
 colwidths= self.directive.get_column_widths(self.max_cols)
+if isinstance(colwidths, tuple):
+# Since docutils 0.13, get_column_widths returns a (widths,
+# colwidths) tuple, where widths is a string (i.e. 'auto').
+# See https://sourceforge.net/p/docutils/patches/120/.
+colwidths = colwidths[1]
 stub_columns = self.directive.options.get('stub-columns', 0)
 header_rows  = self.directive.options.get('header-rows', 0)
 

[PATCH 4.8 81/96] pNFS: Dont clear the layout stateid if a layout return is outstanding

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Trond Myklebust 

commit 7b650994ab07434ae58a247dc9ac87d2488ca75c upstream.

If we no longer hold any layout segments, we're normally expected to
consider the layout stateid to be invalid. However we cannot assume this
if we're about to, or in the process of sending a layoutreturn.

Fixes: 334a8f37115b ("pNFS: Don't forget the layout stateid if...")
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfs/pnfs.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -364,7 +364,9 @@ pnfs_layout_remove_lseg(struct pnfs_layo
list_del_init(>pls_list);
/* Matched by pnfs_get_layout_hdr in pnfs_layout_insert_lseg */
atomic_dec(>plh_refcount);
-   if (list_empty(>plh_segs)) {
+   if (list_empty(>plh_segs) &&
+   !test_bit(NFS_LAYOUT_RETURN_REQUESTED, >plh_flags) &&
+   !test_bit(NFS_LAYOUT_RETURN, >plh_flags)) {
if (atomic_read(>plh_outstanding) == 0)
set_bit(NFS_LAYOUT_INVALID_STID, >plh_flags);
clear_bit(NFS_LAYOUT_BULK_RECALL, >plh_flags);

[PATCH 4.9 001/116] ssb: Fix error routine when fallback SPROM fails

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Larry Finger 

commit 8052d7245b6089992343c80b38b14dbbd8354651 upstream.

When there is a CRC error in the SPROM read from the device, the code
attempts to handle a fallback SPROM. When this also fails, the driver
returns zero rather than an error code.

Signed-off-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/ssb/pci.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/ssb/pci.c
+++ b/drivers/ssb/pci.c
@@ -909,6 +909,7 @@ static int ssb_pci_sprom_get(struct ssb_
if (err) {
ssb_warn("WARNING: Using fallback SPROM failed 
(err %d)\n",
 err);
+   goto out_free;
} else {
ssb_dbg("Using SPROM revision %d provided by 
platform\n",
sprom->revision);

[PATCH 4.9 022/116] docs: sphinx-extensions: make rstFlatTable work with docutils 0.13

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Dmitry Shachnev 

commit 217e2bfab22e740227df09f22165e834cddd8a3b upstream.

In docutils 0.13, the return type of get_column_widths method of the
Table directive has changed [1], which breaks our flat-table directive
and leads to a TypeError when trying to build the docs [2].

This patch adds support for the new return type, while keeping support
for older docutils versions too.

[1] https://sourceforge.net/p/docutils/patches/120/
[2] https://sourceforge.net/p/docutils/bugs/303/

Signed-off-by: Dmitry Shachnev 
Signed-off-by: Jonathan Corbet 
Signed-off-by: Greg Kroah-Hartman 

---
 Documentation/sphinx/rstFlatTable.py |5 +
 1 file changed, 5 insertions(+)

--- a/Documentation/sphinx/rstFlatTable.py
+++ b/Documentation/sphinx/rstFlatTable.py
@@ -157,6 +157,11 @@ class ListTableBuilder(object):
 def buildTableNode(self):
 
 colwidths= self.directive.get_column_widths(self.max_cols)
+if isinstance(colwidths, tuple):
+# Since docutils 0.13, get_column_widths returns a (widths,
+# colwidths) tuple, where widths is a string (i.e. 'auto').
+# See https://sourceforge.net/p/docutils/patches/120/.
+colwidths = colwidths[1]
 stub_columns = self.directive.options.get('stub-columns', 0)
 header_rows  = self.directive.options.get('header-rows', 0)
 

[PATCH 4.8 68/96] IB/rxe: Fix a memory leak in rxe_qp_cleanup()

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Bart Van Assche 

commit e259934d4df7f99f2a5c2c4f074f6a55bd4b1722 upstream.

A socket is associated with every QP by the rxe driver but sock_release()
is never called. Add a call to sock_release() in rxe_qp_cleanup().

Fixes: commit 8700e3e7c48A5 ("Add Soft RoCE driver")
Signed-off-by: Bart Van Assche 
Cc: Moni Shoua 
Cc: Kamal Heib 
Cc: Amir Vadai 
Cc: Haggai Eran 
Reviewed-by: Moni Shoua 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/sw/rxe/rxe_qp.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/infiniband/sw/rxe/rxe_qp.c
+++ b/drivers/infiniband/sw/rxe/rxe_qp.c
@@ -850,4 +850,5 @@ void rxe_qp_cleanup(void *arg)
free_rd_atomic_resources(qp);
 
kernel_sock_shutdown(qp->sk, SHUT_RDWR);
+   sock_release(qp->sk);
 }

[PATCH 4.8 96/96] drm/i915: skip the first 4k of stolen memory on everything >= gen8

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Paulo Zanoni 

commit 6ba0566cf2afcdb17bff882e3a95cbbcb22c4a83 upstream.

BSpec got updated and this workaround is now listed as standard
required programming for all subsequent projects. This is confirmed to
fix Skylake screen flickering issues (probably caused by the fact that
we initialized a ring in the first page of stolen, but I didn't 100%
confirm this theory).

v2: this is the patch that fixes the screen flickering, document it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
Tested-by: Dominik Klementowski 
Signed-off-by: Paulo Zanoni 
Acked-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1481727338-9901-1-git-send-email-paulo.r.zan...@intel.com
(cherry picked from commit d43537610470d8829ebd17cd7842f47176e35ebd)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i915/i915_gem_stolen.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -55,10 +55,9 @@ int i915_gem_stolen_insert_node_in_range
return -ENODEV;
 
/* See the comment at the drm_mm_init() call for more about this check.
-* WaSkipStolenMemoryFirstPage:bdw,chv,kbl (incomplete)
+* WaSkipStolenMemoryFirstPage:bdw+ (incomplete)
 */
-   if (start < 4096 && (IS_GEN8(dev_priv) ||
-IS_KBL_REVID(dev_priv, 0, KBL_REVID_A0)))
+   if (start < 4096 && INTEL_GEN(dev_priv) >= 8)
start = 4096;
 
mutex_lock(_priv->mm.stolen_lock);

[PATCH 4.8 96/96] drm/i915: skip the first 4k of stolen memory on everything >= gen8

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Paulo Zanoni 

commit 6ba0566cf2afcdb17bff882e3a95cbbcb22c4a83 upstream.

BSpec got updated and this workaround is now listed as standard
required programming for all subsequent projects. This is confirmed to
fix Skylake screen flickering issues (probably caused by the fact that
we initialized a ring in the first page of stolen, but I didn't 100%
confirm this theory).

v2: this is the patch that fixes the screen flickering, document it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
Tested-by: Dominik Klementowski 
Signed-off-by: Paulo Zanoni 
Acked-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1481727338-9901-1-git-send-email-paulo.r.zan...@intel.com
(cherry picked from commit d43537610470d8829ebd17cd7842f47176e35ebd)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i915/i915_gem_stolen.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -55,10 +55,9 @@ int i915_gem_stolen_insert_node_in_range
return -ENODEV;
 
/* See the comment at the drm_mm_init() call for more about this check.
-* WaSkipStolenMemoryFirstPage:bdw,chv,kbl (incomplete)
+* WaSkipStolenMemoryFirstPage:bdw+ (incomplete)
 */
-   if (start < 4096 && (IS_GEN8(dev_priv) ||
-IS_KBL_REVID(dev_priv, 0, KBL_REVID_A0)))
+   if (start < 4096 && INTEL_GEN(dev_priv) >= 8)
start = 4096;
 
mutex_lock(_priv->mm.stolen_lock);

[PATCH 4.8 68/96] IB/rxe: Fix a memory leak in rxe_qp_cleanup()

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Bart Van Assche 

commit e259934d4df7f99f2a5c2c4f074f6a55bd4b1722 upstream.

A socket is associated with every QP by the rxe driver but sock_release()
is never called. Add a call to sock_release() in rxe_qp_cleanup().

Fixes: commit 8700e3e7c48A5 ("Add Soft RoCE driver")
Signed-off-by: Bart Van Assche 
Cc: Moni Shoua 
Cc: Kamal Heib 
Cc: Amir Vadai 
Cc: Haggai Eran 
Reviewed-by: Moni Shoua 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/sw/rxe/rxe_qp.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/infiniband/sw/rxe/rxe_qp.c
+++ b/drivers/infiniband/sw/rxe/rxe_qp.c
@@ -850,4 +850,5 @@ void rxe_qp_cleanup(void *arg)
free_rd_atomic_resources(qp);
 
kernel_sock_shutdown(qp->sk, SHUT_RDWR);
+   sock_release(qp->sk);
 }

[PATCH 4.8 32/96] drm/radeon: add additional pci revision to dpm workaround

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Alex Deucher 

commit 8729675c00a8d13cb2094d617d70a4a4da7d83c5 upstream.

New variant.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/si_dpm.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3026,6 +3026,7 @@ static void si_apply_state_adjust_rules(
(rdev->pdev->revision == 0x80) ||
(rdev->pdev->revision == 0x81) ||
(rdev->pdev->revision == 0x83) ||
+   (rdev->pdev->revision == 0x87) ||
(rdev->pdev->device == 0x6604) ||
(rdev->pdev->device == 0x6605)) {
max_sclk = 75000;

[PATCH 4.8 89/96] kconfig/nconf: Fix hang when editing symbol with a long prompt

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

commit 79e51b5c2deea542b3bb8c66e0d502230b017dde upstream.

Currently it is impossible to edit the value of a config symbol with a
prompt longer than (terminal width - 2) characters.  dialog_inputbox()
calculates a negative x-offset for the input window and newwin() fails
as this is invalid.  It also doesn't check for this failure, so it
busy-loops calling wgetch(NULL) which immediately returns -1.

The additions in the offset calculations also don't match the intended
size of the window.

Limit the window size and calculate the offset similarly to
show_scroll_win().

Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)")
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 scripts/kconfig/nconf.gui.c |   15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

--- a/scripts/kconfig/nconf.gui.c
+++ b/scripts/kconfig/nconf.gui.c
@@ -364,12 +364,14 @@ int dialog_inputbox(WINDOW *main_window,
WINDOW *prompt_win;
WINDOW *form_win;
PANEL *panel;
-   int i, x, y;
+   int i, x, y, lines, columns, win_lines, win_cols;
int res = -1;
int cursor_position = strlen(init);
int cursor_form_win;
char *result = *resultp;
 
+   getmaxyx(stdscr, lines, columns);
+
if (strlen(init)+1 > *result_len) {
*result_len = strlen(init)+1;
*resultp = result = realloc(result, *result_len);
@@ -386,14 +388,19 @@ int dialog_inputbox(WINDOW *main_window,
if (title)
prompt_width = max(prompt_width, strlen(title));
 
+   win_lines = min(prompt_lines+6, lines-2);
+   win_cols = min(prompt_width+7, columns-2);
+   prompt_lines = max(win_lines-6, 0);
+   prompt_width = max(win_cols-7, 0);
+
/* place dialog in middle of screen */
-   y = (getmaxy(stdscr)-(prompt_lines+4))/2;
-   x = (getmaxx(stdscr)-(prompt_width+4))/2;
+   y = (lines-win_lines)/2;
+   x = (columns-win_cols)/2;
 
strncpy(result, init, *result_len);
 
/* create the windows */
-   win = newwin(prompt_lines+6, prompt_width+7, y, x);
+   win = newwin(win_lines, win_cols, y, x);
prompt_win = derwin(win, prompt_lines+1, prompt_width, 2, 2);
form_win = derwin(win, 1, prompt_width, prompt_lines+3, 2);
keypad(form_win, TRUE);

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Andy Lutomirski]

On Fri, Jan 6, 2017 at 10:02 AM, Thomas Garnier  wrote:
> On Thu, Jan 5, 2017 at 6:34 PM, Andy Lutomirski  wrote:
>> On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds
>>  wrote:
>>> On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski  wrote:

 Hmm.  I bet that if we preset the accessed bits in all the segments
 then we don't need it to be writable in general.
>>>
>>> I'm not sure that this is architecturally safe.
>>>
>>
>> Hmm.  Last time I looked, I couldn't find *anything* in the SDM
>> explaining what happened if a GDT access resulted in a page fault.  I
>> did discover that Xen intentionally (!) lazily populates and maps LDT
>> pages.  An attempt to access a not-present page results in #PF with
>> the error cod e indicating kernel access even if the access came from
>> user mode.
>>
>> SDM volume 3 7.2.2 says "Pages corresponding to the previous task’s
>> TSS, the current task’s TSS, and the descriptor table entries for
>> each all should be marked as read/write."  But I don't see how a CPU
>> implementation could possibly care what the page table for the TSS
>> descriptor table entries says after LTR is done because the CPU isn't
>> even supposed to *read* that memory.
>>
>> OTOH a valid implementation could easily require that the page table
>> says that the page is writable merely to load a segment, especially in
>> weird cases (IRET?).  That being said, this is all quite easy to test.
>>
>> Also, Thomas, why are you creating a new memory region?  I don't see
>> any benefit to randomizing the GDT address.  How about just putting it
>> in the fixmap?  This  would be NR_CPUS * 4 pages if do my limit=0x
>> idea.  I'm not sure if the fixmap code knows how to handle this much
>> space.
>
> When I looked at the fixmap, you had to define the space you need
> ahead of time and I am not sure there was enough space as you said.

Can you try it and see if anything goes wrong?  Even if something does
go wrong, I think we should fix *that* rather than making the memory
layout more complicated.

[PATCH 4.8 69/96] IB/cma: Fix a race condition in iboe_addr_get_sgid()

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Bart Van Assche 

commit fba332b079029c2f4f7e84c1c1cd8e3867310c90 upstream.

Code that dereferences the struct net_device ip_ptr member must be
protected with an in_dev_get() / in_dev_put() pair. Hence insert
calls to these functions.

Fixes: commit 7b85627b9f02 ("IB/cma: IBoE (RoCE) IP-based GID addressing")
Signed-off-by: Bart Van Assche 
Reviewed-by: Moni Shoua 
Cc: Or Gerlitz 
Cc: Roland Dreier 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 include/rdma/ib_addr.h |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/include/rdma/ib_addr.h
+++ b/include/rdma/ib_addr.h
@@ -205,10 +205,12 @@ static inline void iboe_addr_get_sgid(st
 
dev = dev_get_by_index(_net, dev_addr->bound_dev_if);
if (dev) {
-   ip4 = (struct in_device *)dev->ip_ptr;
-   if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address)
+   ip4 = in_dev_get(dev);
+   if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address) {
ipv6_addr_set_v4mapped(ip4->ifa_list->ifa_address,
   (struct in6_addr *)gid);
+   in_dev_put(ip4);
+   }
dev_put(dev);
}
 }

Re: kmod: add a sanity check on module loading

[Jessica Yu]

+++ Luis R. Rodriguez [06/01/17 21:36 +0100]:

On Tue, Jan 03, 2017 at 10:34:53AM +1030, Rusty Russell wrote:

"Luis R. Rodriguez"  writes:
> Right, out of ~350 request_module() calls (not included try requests)
> only ~46 check the return value. Hence a validation check, and come to
> think of it, *this* was the issue that originally had me believing
> that in some places we might end up in a null deref --if those open
> coded request_module() calls assume the driver is loaded there could
> be many places where a NULL is inevitable.

Yes, assuming success == module loade is simply a bug.  I wrote
try_then_request_module() to attempt to encapsulate the correct logic
into a single place; maybe we need other helpers to cover (most of?) the
remaining cases?


I see...

OK so indeed we have a few possible changes to kernel given the above:

a) Add SmPL rule to nag about incorrect uses of request_module() which
  never check for the return value, and fix 86% of calls (304 call sites)
  which are buggy

b) Add a new API call, perhaps request_module_assert() which would
  BUG_ON() if the requested module didn't load, and change the callers
  which do not check for the return value to this.


It is probably not a good idea to panic/BUG() because a requested
module didn't load. IMO callers should already be accounting for the
fact that request_module() doesn't provide these guarantees. I haven't
looked yet to see if the majority of these callers actually do the the
responsible thing, though.


Make request_module() do the assert and changing all proper callers of
request_module() to a new API call which *does* let you check for the
return value is another option but tasteless.

b) seems to be what you allude to, and while it may seem also of bad taste,
in practice it may be hard to get callers to properly check for the return
value. I actually just favor a) even though its more work.


> Granted, I agree they
> should be fixed, we could add a grammar rule to start nagging at
> driver developers for started, but it does beg the question also of
> what a tightly knit validation for modprobe might look like, and hence
> this patch and now the completed not-yet-posted alias work.

I really think aliases-in-kernel is too heavy a hammer, but a warning
when modprobe "succeeds" and the module still isn't found would be
a Good Thing.


OK -- such a warning can really only happen if we had alias support though.
So one option is to add this and alias parsing support as a debug option.


Hm, I see what you're saying..

To clarify the problem (if anyone was confused, as I was..): we can
verify a module is loaded by using find_module_all() and looking at
its state. However, find_module_all() operates on real module names,
and we can't verify a module has successfully loaded if all we have is
the name of the alias (eg, "fs-*" aliases in get_fs_type), because we
have no alias->real_module_name mappings in the kernel.

However, in Rusty's sample get_fs_type WARN() code, we indirectly
validated request_module()'s work by verifying that the
file_system_type has actually registered, which is what should happen
if a filesystem module successfully loads. So in this case, the caller
(get_fs_type) indirectly checks if the service it requested is now
available, which is what I *thought* callers were supposed to do in
the first place (and we didn't need the help of aliases to do that).
I think the main question we have to answer is, should the burden of
validation be on the callers, or on request_module? I am currently
leaning towards the former, but I'm still thinking.


> Would it be worthy as a kconfig kmod debugging aide for now? I can
> follow up with a semantic patch to nag about checking the return value
> of request_module(), and we can  have 0-day then also complain about
> new invalid uses.

Yeah, a warning about this would be win for sure.


OK will work on such SmPL patch into the next patch series for this patch set.


BTW, I wrote the original "check-for-module-before-loading" in
module-init-tools, but I'm starting to wonder if it was a premature
optimization.  Have you thought about simply removing it and always
trying to load the module?  If it doesn't slow things down, perhaps
simplicity FTW?


I've given this some thought as I tried to blow up request_module() with
the new kmod stress test driver and given the small changes I made -- I'm of the
mind set it should be based on numbers: if a change improves the time it takes
to load modules while also not regressing all the other test cases then we
should go with it. The only issue is we don't yet have enough test cases
to cover the typical distribution setup: load tons of modules, and only
sometimes try to load a few of the same modules.

The early module-init-tools check seems fair gain to me given a bounce back to
the kernel and back to userspace should incur a bit more work than just checking
for a few files on the filesystem. As I noted though, I 

[PATCH 4.8 76/96] i40iw: Use correct src address in memcpy to rdma stats counters

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Shiraz Saleem 

commit 91c42b72f8e8b45961ff05a05009b644e6316ca2 upstream.

hw_stats is a pointer to i40_iw_dev_stats struct in i40iw_get_hw_stats().
Use hw_stats and not _stats in the memcpy to copy the i40iw device stats
data into rdma_hw_stats counters.

Fixes: b40f4757daa1 ("IB/core: Make device counter infrastructure dynamic")

Signed-off-by: Shiraz Saleem 
Signed-off-by: Faisal Latif 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/i40iw/i40iw_verbs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
@@ -2501,7 +2501,7 @@ static int i40iw_get_hw_stats(struct ib_
return -ENOSYS;
}
 
-   memcpy(>value[0], _stats, sizeof(*hw_stats));
+   memcpy(>value[0], hw_stats, sizeof(*hw_stats));
 
return stats->num_counters;
 }

[PATCH 4.8 32/96] drm/radeon: add additional pci revision to dpm workaround

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Alex Deucher 

commit 8729675c00a8d13cb2094d617d70a4a4da7d83c5 upstream.

New variant.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/si_dpm.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3026,6 +3026,7 @@ static void si_apply_state_adjust_rules(
(rdev->pdev->revision == 0x80) ||
(rdev->pdev->revision == 0x81) ||
(rdev->pdev->revision == 0x83) ||
+   (rdev->pdev->revision == 0x87) ||
(rdev->pdev->device == 0x6604) ||
(rdev->pdev->device == 0x6605)) {
max_sclk = 75000;

[PATCH 4.8 89/96] kconfig/nconf: Fix hang when editing symbol with a long prompt

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

commit 79e51b5c2deea542b3bb8c66e0d502230b017dde upstream.

Currently it is impossible to edit the value of a config symbol with a
prompt longer than (terminal width - 2) characters.  dialog_inputbox()
calculates a negative x-offset for the input window and newwin() fails
as this is invalid.  It also doesn't check for this failure, so it
busy-loops calling wgetch(NULL) which immediately returns -1.

The additions in the offset calculations also don't match the intended
size of the window.

Limit the window size and calculate the offset similarly to
show_scroll_win().

Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)")
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 scripts/kconfig/nconf.gui.c |   15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

--- a/scripts/kconfig/nconf.gui.c
+++ b/scripts/kconfig/nconf.gui.c
@@ -364,12 +364,14 @@ int dialog_inputbox(WINDOW *main_window,
WINDOW *prompt_win;
WINDOW *form_win;
PANEL *panel;
-   int i, x, y;
+   int i, x, y, lines, columns, win_lines, win_cols;
int res = -1;
int cursor_position = strlen(init);
int cursor_form_win;
char *result = *resultp;
 
+   getmaxyx(stdscr, lines, columns);
+
if (strlen(init)+1 > *result_len) {
*result_len = strlen(init)+1;
*resultp = result = realloc(result, *result_len);
@@ -386,14 +388,19 @@ int dialog_inputbox(WINDOW *main_window,
if (title)
prompt_width = max(prompt_width, strlen(title));
 
+   win_lines = min(prompt_lines+6, lines-2);
+   win_cols = min(prompt_width+7, columns-2);
+   prompt_lines = max(win_lines-6, 0);
+   prompt_width = max(win_cols-7, 0);
+
/* place dialog in middle of screen */
-   y = (getmaxy(stdscr)-(prompt_lines+4))/2;
-   x = (getmaxx(stdscr)-(prompt_width+4))/2;
+   y = (lines-win_lines)/2;
+   x = (columns-win_cols)/2;
 
strncpy(result, init, *result_len);
 
/* create the windows */
-   win = newwin(prompt_lines+6, prompt_width+7, y, x);
+   win = newwin(win_lines, win_cols, y, x);
prompt_win = derwin(win, prompt_lines+1, prompt_width, 2, 2);
form_win = derwin(win, 1, prompt_width, prompt_lines+3, 2);
keypad(form_win, TRUE);

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Andy Lutomirski]

On Fri, Jan 6, 2017 at 10:02 AM, Thomas Garnier  wrote:
> On Thu, Jan 5, 2017 at 6:34 PM, Andy Lutomirski  wrote:
>> On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds
>>  wrote:
>>> On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski  wrote:

 Hmm.  I bet that if we preset the accessed bits in all the segments
 then we don't need it to be writable in general.
>>>
>>> I'm not sure that this is architecturally safe.
>>>
>>
>> Hmm.  Last time I looked, I couldn't find *anything* in the SDM
>> explaining what happened if a GDT access resulted in a page fault.  I
>> did discover that Xen intentionally (!) lazily populates and maps LDT
>> pages.  An attempt to access a not-present page results in #PF with
>> the error cod e indicating kernel access even if the access came from
>> user mode.
>>
>> SDM volume 3 7.2.2 says "Pages corresponding to the previous task’s
>> TSS, the current task’s TSS, and the descriptor table entries for
>> each all should be marked as read/write."  But I don't see how a CPU
>> implementation could possibly care what the page table for the TSS
>> descriptor table entries says after LTR is done because the CPU isn't
>> even supposed to *read* that memory.
>>
>> OTOH a valid implementation could easily require that the page table
>> says that the page is writable merely to load a segment, especially in
>> weird cases (IRET?).  That being said, this is all quite easy to test.
>>
>> Also, Thomas, why are you creating a new memory region?  I don't see
>> any benefit to randomizing the GDT address.  How about just putting it
>> in the fixmap?  This  would be NR_CPUS * 4 pages if do my limit=0x
>> idea.  I'm not sure if the fixmap code knows how to handle this much
>> space.
>
> When I looked at the fixmap, you had to define the space you need
> ahead of time and I am not sure there was enough space as you said.

Can you try it and see if anything goes wrong?  Even if something does
go wrong, I think we should fix *that* rather than making the memory
layout more complicated.

[PATCH 4.8 69/96] IB/cma: Fix a race condition in iboe_addr_get_sgid()

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Bart Van Assche 

commit fba332b079029c2f4f7e84c1c1cd8e3867310c90 upstream.

Code that dereferences the struct net_device ip_ptr member must be
protected with an in_dev_get() / in_dev_put() pair. Hence insert
calls to these functions.

Fixes: commit 7b85627b9f02 ("IB/cma: IBoE (RoCE) IP-based GID addressing")
Signed-off-by: Bart Van Assche 
Reviewed-by: Moni Shoua 
Cc: Or Gerlitz 
Cc: Roland Dreier 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 include/rdma/ib_addr.h |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/include/rdma/ib_addr.h
+++ b/include/rdma/ib_addr.h
@@ -205,10 +205,12 @@ static inline void iboe_addr_get_sgid(st
 
dev = dev_get_by_index(_net, dev_addr->bound_dev_if);
if (dev) {
-   ip4 = (struct in_device *)dev->ip_ptr;
-   if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address)
+   ip4 = in_dev_get(dev);
+   if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address) {
ipv6_addr_set_v4mapped(ip4->ifa_list->ifa_address,
   (struct in6_addr *)gid);
+   in_dev_put(ip4);
+   }
dev_put(dev);
}
 }

Re: kmod: add a sanity check on module loading

[Jessica Yu]

+++ Luis R. Rodriguez [06/01/17 21:36 +0100]:

On Tue, Jan 03, 2017 at 10:34:53AM +1030, Rusty Russell wrote:

"Luis R. Rodriguez"  writes:
> Right, out of ~350 request_module() calls (not included try requests)
> only ~46 check the return value. Hence a validation check, and come to
> think of it, *this* was the issue that originally had me believing
> that in some places we might end up in a null deref --if those open
> coded request_module() calls assume the driver is loaded there could
> be many places where a NULL is inevitable.

Yes, assuming success == module loade is simply a bug.  I wrote
try_then_request_module() to attempt to encapsulate the correct logic
into a single place; maybe we need other helpers to cover (most of?) the
remaining cases?


I see...

OK so indeed we have a few possible changes to kernel given the above:

a) Add SmPL rule to nag about incorrect uses of request_module() which
  never check for the return value, and fix 86% of calls (304 call sites)
  which are buggy

b) Add a new API call, perhaps request_module_assert() which would
  BUG_ON() if the requested module didn't load, and change the callers
  which do not check for the return value to this.


It is probably not a good idea to panic/BUG() because a requested
module didn't load. IMO callers should already be accounting for the
fact that request_module() doesn't provide these guarantees. I haven't
looked yet to see if the majority of these callers actually do the the
responsible thing, though.


Make request_module() do the assert and changing all proper callers of
request_module() to a new API call which *does* let you check for the
return value is another option but tasteless.

b) seems to be what you allude to, and while it may seem also of bad taste,
in practice it may be hard to get callers to properly check for the return
value. I actually just favor a) even though its more work.


> Granted, I agree they
> should be fixed, we could add a grammar rule to start nagging at
> driver developers for started, but it does beg the question also of
> what a tightly knit validation for modprobe might look like, and hence
> this patch and now the completed not-yet-posted alias work.

I really think aliases-in-kernel is too heavy a hammer, but a warning
when modprobe "succeeds" and the module still isn't found would be
a Good Thing.


OK -- such a warning can really only happen if we had alias support though.
So one option is to add this and alias parsing support as a debug option.


Hm, I see what you're saying..

To clarify the problem (if anyone was confused, as I was..): we can
verify a module is loaded by using find_module_all() and looking at
its state. However, find_module_all() operates on real module names,
and we can't verify a module has successfully loaded if all we have is
the name of the alias (eg, "fs-*" aliases in get_fs_type), because we
have no alias->real_module_name mappings in the kernel.

However, in Rusty's sample get_fs_type WARN() code, we indirectly
validated request_module()'s work by verifying that the
file_system_type has actually registered, which is what should happen
if a filesystem module successfully loads. So in this case, the caller
(get_fs_type) indirectly checks if the service it requested is now
available, which is what I *thought* callers were supposed to do in
the first place (and we didn't need the help of aliases to do that).
I think the main question we have to answer is, should the burden of
validation be on the callers, or on request_module? I am currently
leaning towards the former, but I'm still thinking.


> Would it be worthy as a kconfig kmod debugging aide for now? I can
> follow up with a semantic patch to nag about checking the return value
> of request_module(), and we can  have 0-day then also complain about
> new invalid uses.

Yeah, a warning about this would be win for sure.


OK will work on such SmPL patch into the next patch series for this patch set.


BTW, I wrote the original "check-for-module-before-loading" in
module-init-tools, but I'm starting to wonder if it was a premature
optimization.  Have you thought about simply removing it and always
trying to load the module?  If it doesn't slow things down, perhaps
simplicity FTW?


I've given this some thought as I tried to blow up request_module() with
the new kmod stress test driver and given the small changes I made -- I'm of the
mind set it should be based on numbers: if a change improves the time it takes
to load modules while also not regressing all the other test cases then we
should go with it. The only issue is we don't yet have enough test cases
to cover the typical distribution setup: load tons of modules, and only
sometimes try to load a few of the same modules.

The early module-init-tools check seems fair gain to me given a bounce back to
the kernel and back to userspace should incur a bit more work than just checking
for a few files on the filesystem. As I noted though, I can't prove this for 

[PATCH 4.8 76/96] i40iw: Use correct src address in memcpy to rdma stats counters

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Shiraz Saleem 

commit 91c42b72f8e8b45961ff05a05009b644e6316ca2 upstream.

hw_stats is a pointer to i40_iw_dev_stats struct in i40iw_get_hw_stats().
Use hw_stats and not _stats in the memcpy to copy the i40iw device stats
data into rdma_hw_stats counters.

Fixes: b40f4757daa1 ("IB/core: Make device counter infrastructure dynamic")

Signed-off-by: Shiraz Saleem 
Signed-off-by: Faisal Latif 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/i40iw/i40iw_verbs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
@@ -2501,7 +2501,7 @@ static int i40iw_get_hw_stats(struct ib_
return -ENOSYS;
}
 
-   memcpy(>value[0], _stats, sizeof(*hw_stats));
+   memcpy(>value[0], hw_stats, sizeof(*hw_stats));
 
return stats->num_counters;
 }

[PATCH 4.8 71/96] [media] mn88473: fix chip id check on probe

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Antti Palosaari 

commit d930b5b5bf122a61952cfebabb1e618682a2631a upstream.

A register used to identify chip during probe was overwritten during
firmware download and due to that later probe's for warm chip were
failing. Detect chip from the another register, which is located on
different register bank 2.

Fixes: 7908fad99a6c ("[media] mn88473: finalize driver")

Signed-off-by: Antti Palosaari 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/dvb-frontends/mn88473.c |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

--- a/drivers/media/dvb-frontends/mn88473.c
+++ b/drivers/media/dvb-frontends/mn88473.c
@@ -485,18 +485,6 @@ static int mn88473_probe(struct i2c_clie
goto err_kfree;
}
 
-   /* Check demod answers with correct chip id */
-   ret = regmap_read(dev->regmap[0], 0xff, );
-   if (ret)
-   goto err_regmap_0_regmap_exit;
-
-   dev_dbg(>dev, "chip id=%02x\n", uitmp);
-
-   if (uitmp != 0x03) {
-   ret = -ENODEV;
-   goto err_regmap_0_regmap_exit;
-   }
-
/*
 * Chip has three I2C addresses for different register banks. Used
 * addresses are 0x18, 0x1a and 0x1c. We register two dummy clients,
@@ -533,6 +521,18 @@ static int mn88473_probe(struct i2c_clie
}
i2c_set_clientdata(dev->client[2], dev);
 
+   /* Check demod answers with correct chip id */
+   ret = regmap_read(dev->regmap[2], 0xff, );
+   if (ret)
+   goto err_regmap_2_regmap_exit;
+
+   dev_dbg(>dev, "chip id=%02x\n", uitmp);
+
+   if (uitmp != 0x03) {
+   ret = -ENODEV;
+   goto err_regmap_2_regmap_exit;
+   }
+
/* Sleep because chip is active by default */
ret = regmap_write(dev->regmap[2], 0x05, 0x3e);
if (ret)

[PATCH 4.8 79/96] nfs_write_end(): fix handling of short copies

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Al Viro 

commit c0cf3ef5e0f47e385920450b245d22bead93e7ad upstream.

What matters when deciding if we should make a page uptodate is
not how much we _wanted_ to copy, but how much we actually have
copied.  As it is, on architectures that do not zero tail on
short copy we can leave uninitialized data in page marked uptodate.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfs/file.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -397,7 +397,7 @@ static int nfs_write_end(struct file *fi
 */
if (!PageUptodate(page)) {
unsigned pglen = nfs_page_length(page);
-   unsigned end = offset + len;
+   unsigned end = offset + copied;
 
if (pglen == 0) {
zero_user_segments(page, 0, offset,

[PATCH 4.8 71/96] [media] mn88473: fix chip id check on probe

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Antti Palosaari 

commit d930b5b5bf122a61952cfebabb1e618682a2631a upstream.

A register used to identify chip during probe was overwritten during
firmware download and due to that later probe's for warm chip were
failing. Detect chip from the another register, which is located on
different register bank 2.

Fixes: 7908fad99a6c ("[media] mn88473: finalize driver")

Signed-off-by: Antti Palosaari 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/dvb-frontends/mn88473.c |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

--- a/drivers/media/dvb-frontends/mn88473.c
+++ b/drivers/media/dvb-frontends/mn88473.c
@@ -485,18 +485,6 @@ static int mn88473_probe(struct i2c_clie
goto err_kfree;
}
 
-   /* Check demod answers with correct chip id */
-   ret = regmap_read(dev->regmap[0], 0xff, );
-   if (ret)
-   goto err_regmap_0_regmap_exit;
-
-   dev_dbg(>dev, "chip id=%02x\n", uitmp);
-
-   if (uitmp != 0x03) {
-   ret = -ENODEV;
-   goto err_regmap_0_regmap_exit;
-   }
-
/*
 * Chip has three I2C addresses for different register banks. Used
 * addresses are 0x18, 0x1a and 0x1c. We register two dummy clients,
@@ -533,6 +521,18 @@ static int mn88473_probe(struct i2c_clie
}
i2c_set_clientdata(dev->client[2], dev);
 
+   /* Check demod answers with correct chip id */
+   ret = regmap_read(dev->regmap[2], 0xff, );
+   if (ret)
+   goto err_regmap_2_regmap_exit;
+
+   dev_dbg(>dev, "chip id=%02x\n", uitmp);
+
+   if (uitmp != 0x03) {
+   ret = -ENODEV;
+   goto err_regmap_2_regmap_exit;
+   }
+
/* Sleep because chip is active by default */
ret = regmap_write(dev->regmap[2], 0x05, 0x3e);
if (ret)

[PATCH 4.8 79/96] nfs_write_end(): fix handling of short copies

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Al Viro 

commit c0cf3ef5e0f47e385920450b245d22bead93e7ad upstream.

What matters when deciding if we should make a page uptodate is
not how much we _wanted_ to copy, but how much we actually have
copied.  As it is, on architectures that do not zero tail on
short copy we can leave uninitialized data in page marked uptodate.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfs/file.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -397,7 +397,7 @@ static int nfs_write_end(struct file *fi
 */
if (!PageUptodate(page)) {
unsigned pglen = nfs_page_length(page);
-   unsigned end = offset + len;
+   unsigned end = offset + copied;
 
if (pglen == 0) {
zero_user_segments(page, 0, offset,

[PATCH 4.8 44/96] iscsi-target: Return error if unable to add network portal

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Varun Prakash 

commit 83337e544323a8bd7492994d64af339175ac7107 upstream.

If iscsit_tpg_add_network_portal() fails then
return error code instead of 0 to user space.

If iscsi-target returns 0 then user space keeps
on retrying same command infinitely, targetcli or
echo hangs till command completes with non zero
return value. In some cases it is possible that
add network portal command never completes with
success even after retrying multiple times,
for example - cxgbit_setup_np() always returns
-EINVAL if portal IP does not belong to Chelsio
adapter interface.

Signed-off-by: Varun Prakash 
Signed-off-by: Bart Van Assche 
[ bvanassche: Added "Fixes:" and "Cc: stable" tags ]
Fixes: commit d4b3fa4b0881 ("iscsi-target: Make iscsi_tpg_np driver show/store 
use generic code")
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/target/iscsi/iscsi_target_configfs.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/target/iscsi/iscsi_target_configfs.c
+++ b/drivers/target/iscsi/iscsi_target_configfs.c
@@ -100,8 +100,10 @@ static ssize_t lio_target_np_driver_stor
 
tpg_np_new = iscsit_tpg_add_network_portal(tpg,
>np_sockaddr, tpg_np, type);
-   if (IS_ERR(tpg_np_new))
+   if (IS_ERR(tpg_np_new)) {
+   rc = PTR_ERR(tpg_np_new);
goto out;
+   }
} else {
tpg_np_new = iscsit_tpg_locate_child_np(tpg_np, type);
if (tpg_np_new) {

[PATCH 4.8 44/96] iscsi-target: Return error if unable to add network portal

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Varun Prakash 

commit 83337e544323a8bd7492994d64af339175ac7107 upstream.

If iscsit_tpg_add_network_portal() fails then
return error code instead of 0 to user space.

If iscsi-target returns 0 then user space keeps
on retrying same command infinitely, targetcli or
echo hangs till command completes with non zero
return value. In some cases it is possible that
add network portal command never completes with
success even after retrying multiple times,
for example - cxgbit_setup_np() always returns
-EINVAL if portal IP does not belong to Chelsio
adapter interface.

Signed-off-by: Varun Prakash 
Signed-off-by: Bart Van Assche 
[ bvanassche: Added "Fixes:" and "Cc: stable" tags ]
Fixes: commit d4b3fa4b0881 ("iscsi-target: Make iscsi_tpg_np driver show/store 
use generic code")
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/target/iscsi/iscsi_target_configfs.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/target/iscsi/iscsi_target_configfs.c
+++ b/drivers/target/iscsi/iscsi_target_configfs.c
@@ -100,8 +100,10 @@ static ssize_t lio_target_np_driver_stor
 
tpg_np_new = iscsit_tpg_add_network_portal(tpg,
>np_sockaddr, tpg_np, type);
-   if (IS_ERR(tpg_np_new))
+   if (IS_ERR(tpg_np_new)) {
+   rc = PTR_ERR(tpg_np_new);
goto out;
+   }
} else {
tpg_np_new = iscsit_tpg_locate_child_np(tpg_np, type);
if (tpg_np_new) {

[PATCH 4.8 51/96] s390/vmlogrdr: fix IUCV buffer allocation

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Gerald Schaefer 

commit 5457e03de918f7a3e294eb9d26a608ab8a579976 upstream.

The buffer for iucv_message_receive() needs to be below 2 GB. In
__iucv_message_receive(), the buffer address is casted to an u32, which
would result in either memory corruption or an addressing exception when
using addresses >= 2 GB.

Fix this by using GFP_DMA for the buffer allocation.

Signed-off-by: Gerald Schaefer 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/s390/char/vmlogrdr.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/s390/char/vmlogrdr.c
+++ b/drivers/s390/char/vmlogrdr.c
@@ -870,7 +870,7 @@ static int __init vmlogrdr_init(void)
goto cleanup;
 
for (i=0; i < MAXMINOR; ++i ) {
-   sys_ser[i].buffer = (char *) get_zeroed_page(GFP_KERNEL);
+   sys_ser[i].buffer = (char *) get_zeroed_page(GFP_KERNEL | 
GFP_DMA);
if (!sys_ser[i].buffer) {
rc = -ENOMEM;
break;

[PATCH 4.8 62/96] ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Steven Rostedt (Red Hat) 

commit 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67 upstream.

With new binutils, gcc may get smart with its optimization and change a jmp
from a 5 byte jump to a 2 byte one even though it was jumping to a global
function. But that global function existed within a 2 byte radius, and gcc
was able to optimize it. Unfortunately, that jump was also being modified
when function graph tracing begins. Since ftrace expected that jump to be 5
bytes, but it was only two, it overwrote code after the jump, causing a
crash.

This was fixed for x86_64 with commit 8329e818f149, with the same subject as
this commit, but nothing was done for x86_32.

Fixes: d61f82d06672 ("ftrace: use dynamic patching for updating mcount calls")
Reported-by: Colin Ian King 
Tested-by: Colin Ian King 
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/entry/entry_32.S |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -852,8 +852,8 @@ ftrace_graph_call:
jmp ftrace_stub
 #endif
 
-.globl ftrace_stub
-ftrace_stub:
+/* This is weak to keep gas from relaxing the jumps */
+WEAK(ftrace_stub)
ret
 END(ftrace_caller)
 

[PATCH 4.8 61/96] vsock/virtio: fix src/dst cid format

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Michael S. Tsirkin 

commit f83f12d660d11718d3eed9d979ee03e83aa55544 upstream.

These fields are 64 bit, using le32_to_cpu and friends
on these will not do the right thing.
Fix this up.

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Greg Kroah-Hartman 

---
 net/vmw_vsock/virtio_transport_common.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -606,9 +606,9 @@ static int virtio_transport_reset_no_soc
return 0;
 
pkt = virtio_transport_alloc_pkt(, 0,
-le32_to_cpu(pkt->hdr.dst_cid),
+le64_to_cpu(pkt->hdr.dst_cid),
 le32_to_cpu(pkt->hdr.dst_port),
-le32_to_cpu(pkt->hdr.src_cid),
+le64_to_cpu(pkt->hdr.src_cid),
 le32_to_cpu(pkt->hdr.src_port));
if (!pkt)
return -ENOMEM;
@@ -823,7 +823,7 @@ virtio_transport_send_response(struct vs
struct virtio_vsock_pkt_info info = {
.op = VIRTIO_VSOCK_OP_RESPONSE,
.type = VIRTIO_VSOCK_TYPE_STREAM,
-   .remote_cid = le32_to_cpu(pkt->hdr.src_cid),
+   .remote_cid = le64_to_cpu(pkt->hdr.src_cid),
.remote_port = le32_to_cpu(pkt->hdr.src_port),
.reply = true,
};
@@ -863,9 +863,9 @@ virtio_transport_recv_listen(struct sock
child->sk_state = SS_CONNECTED;
 
vchild = vsock_sk(child);
-   vsock_addr_init(>local_addr, le32_to_cpu(pkt->hdr.dst_cid),
+   vsock_addr_init(>local_addr, le64_to_cpu(pkt->hdr.dst_cid),
le32_to_cpu(pkt->hdr.dst_port));
-   vsock_addr_init(>remote_addr, le32_to_cpu(pkt->hdr.src_cid),
+   vsock_addr_init(>remote_addr, le64_to_cpu(pkt->hdr.src_cid),
le32_to_cpu(pkt->hdr.src_port));
 
vsock_insert_connected(vchild);
@@ -904,9 +904,9 @@ void virtio_transport_recv_pkt(struct vi
struct sock *sk;
bool space_available;
 
-   vsock_addr_init(, le32_to_cpu(pkt->hdr.src_cid),
+   vsock_addr_init(, le64_to_cpu(pkt->hdr.src_cid),
le32_to_cpu(pkt->hdr.src_port));
-   vsock_addr_init(, le32_to_cpu(pkt->hdr.dst_cid),
+   vsock_addr_init(, le64_to_cpu(pkt->hdr.dst_cid),
le32_to_cpu(pkt->hdr.dst_port));
 
trace_virtio_transport_recv_pkt(src.svm_cid, src.svm_port,

[PATCH 4.8 51/96] s390/vmlogrdr: fix IUCV buffer allocation

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Gerald Schaefer 

commit 5457e03de918f7a3e294eb9d26a608ab8a579976 upstream.

The buffer for iucv_message_receive() needs to be below 2 GB. In
__iucv_message_receive(), the buffer address is casted to an u32, which
would result in either memory corruption or an addressing exception when
using addresses >= 2 GB.

Fix this by using GFP_DMA for the buffer allocation.

Signed-off-by: Gerald Schaefer 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/s390/char/vmlogrdr.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/s390/char/vmlogrdr.c
+++ b/drivers/s390/char/vmlogrdr.c
@@ -870,7 +870,7 @@ static int __init vmlogrdr_init(void)
goto cleanup;
 
for (i=0; i < MAXMINOR; ++i ) {
-   sys_ser[i].buffer = (char *) get_zeroed_page(GFP_KERNEL);
+   sys_ser[i].buffer = (char *) get_zeroed_page(GFP_KERNEL | 
GFP_DMA);
if (!sys_ser[i].buffer) {
rc = -ENOMEM;
break;

[PATCH 4.8 62/96] ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Steven Rostedt (Red Hat) 

commit 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67 upstream.

With new binutils, gcc may get smart with its optimization and change a jmp
from a 5 byte jump to a 2 byte one even though it was jumping to a global
function. But that global function existed within a 2 byte radius, and gcc
was able to optimize it. Unfortunately, that jump was also being modified
when function graph tracing begins. Since ftrace expected that jump to be 5
bytes, but it was only two, it overwrote code after the jump, causing a
crash.

This was fixed for x86_64 with commit 8329e818f149, with the same subject as
this commit, but nothing was done for x86_32.

Fixes: d61f82d06672 ("ftrace: use dynamic patching for updating mcount calls")
Reported-by: Colin Ian King 
Tested-by: Colin Ian King 
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/entry/entry_32.S |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -852,8 +852,8 @@ ftrace_graph_call:
jmp ftrace_stub
 #endif
 
-.globl ftrace_stub
-ftrace_stub:
+/* This is weak to keep gas from relaxing the jumps */
+WEAK(ftrace_stub)
ret
 END(ftrace_caller)
 

[PATCH 4.8 61/96] vsock/virtio: fix src/dst cid format

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Michael S. Tsirkin 

commit f83f12d660d11718d3eed9d979ee03e83aa55544 upstream.

These fields are 64 bit, using le32_to_cpu and friends
on these will not do the right thing.
Fix this up.

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Greg Kroah-Hartman 

---
 net/vmw_vsock/virtio_transport_common.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -606,9 +606,9 @@ static int virtio_transport_reset_no_soc
return 0;
 
pkt = virtio_transport_alloc_pkt(, 0,
-le32_to_cpu(pkt->hdr.dst_cid),
+le64_to_cpu(pkt->hdr.dst_cid),
 le32_to_cpu(pkt->hdr.dst_port),
-le32_to_cpu(pkt->hdr.src_cid),
+le64_to_cpu(pkt->hdr.src_cid),
 le32_to_cpu(pkt->hdr.src_port));
if (!pkt)
return -ENOMEM;
@@ -823,7 +823,7 @@ virtio_transport_send_response(struct vs
struct virtio_vsock_pkt_info info = {
.op = VIRTIO_VSOCK_OP_RESPONSE,
.type = VIRTIO_VSOCK_TYPE_STREAM,
-   .remote_cid = le32_to_cpu(pkt->hdr.src_cid),
+   .remote_cid = le64_to_cpu(pkt->hdr.src_cid),
.remote_port = le32_to_cpu(pkt->hdr.src_port),
.reply = true,
};
@@ -863,9 +863,9 @@ virtio_transport_recv_listen(struct sock
child->sk_state = SS_CONNECTED;
 
vchild = vsock_sk(child);
-   vsock_addr_init(>local_addr, le32_to_cpu(pkt->hdr.dst_cid),
+   vsock_addr_init(>local_addr, le64_to_cpu(pkt->hdr.dst_cid),
le32_to_cpu(pkt->hdr.dst_port));
-   vsock_addr_init(>remote_addr, le32_to_cpu(pkt->hdr.src_cid),
+   vsock_addr_init(>remote_addr, le64_to_cpu(pkt->hdr.src_cid),
le32_to_cpu(pkt->hdr.src_port));
 
vsock_insert_connected(vchild);
@@ -904,9 +904,9 @@ void virtio_transport_recv_pkt(struct vi
struct sock *sk;
bool space_available;
 
-   vsock_addr_init(, le32_to_cpu(pkt->hdr.src_cid),
+   vsock_addr_init(, le64_to_cpu(pkt->hdr.src_cid),
le32_to_cpu(pkt->hdr.src_port));
-   vsock_addr_init(, le32_to_cpu(pkt->hdr.dst_cid),
+   vsock_addr_init(, le64_to_cpu(pkt->hdr.dst_cid),
le32_to_cpu(pkt->hdr.dst_port));
 
trace_virtio_transport_recv_pkt(src.svm_cid, src.svm_port,

[PATCH 4.8 56/96] scsi: aacraid: remove wildcard for series 9 controllers

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Kevin Barnett 

commit ae2aae2421983f6f68eb7c4692624bc43ea50712 upstream.

Controllers with this PCI ID never shipped outside of
PMCS/Microsemi. Remove the ID from the aacraid driver. smartpqi is the
correct driver for these controllers.

[mkp: patch description]

Reviewed-by: Scott Teel 
Signed-off-by: Kevin Barnett 
Signed-off-by: Don Brace 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/aacraid/linit.c |2 --
 1 file changed, 2 deletions(-)

--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -160,7 +160,6 @@ static const struct pci_device_id aac_pc
{ 0x9005, 0x028b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 62 }, /* Adaptec PMC 
Series 6 (Tupelo) */
{ 0x9005, 0x028c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 63 }, /* Adaptec PMC 
Series 7 (Denali) */
{ 0x9005, 0x028d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 64 }, /* Adaptec PMC 
Series 8 */
-   { 0x9005, 0x028f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 65 }, /* Adaptec PMC 
Series 9 */
{ 0,}
 };
 MODULE_DEVICE_TABLE(pci, aac_pci_tbl);
@@ -239,7 +238,6 @@ static struct aac_driver_ident aac_drive
{ aac_src_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC }, /* Adaptec PMC Series 6 (Tupelo) */
{ aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC }, /* Adaptec PMC Series 7 (Denali) */
{ aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC }, /* Adaptec PMC Series 8 */
-   { aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC } /* Adaptec PMC Series 9 */
 };
 
 /**

[PATCH 4.8 64/96] fgraph: Handle a case where a tracer ignores set_graph_notrace

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Steven Rostedt (Red Hat) 

commit 794de08a16cf1fc1bf785dc48f66d36218cf6d88 upstream.

Both the wakeup and irqsoff tracers can use the function graph tracer when
the display-graph option is set. The problem is that they ignore the notrace
file, and record the entry of functions that would be ignored by the
function_graph tracer. This causes the trace->depth to be recorded into the
ring buffer. The set_graph_notrace uses a trick by adding a large negative
number to the trace->depth when a graph function is to be ignored.

On trace output, the graph function uses the depth to record a stack of
functions. But since the depth is negative, it accesses the array with a
negative number and causes an out of bounds access that can cause a kernel
oops or corrupt data.

Have the print functions handle cases where a tracer still records functions
even when they are in set_graph_notrace.

Also add warnings if the depth is below zero before accessing the array.

Note, the function graph logic will still prevent the return of these
functions from being recorded, which means that they will be left hanging
without a return. For example:

   # echo '*spin*' > set_graph_notrace
   # echo 1 > options/display-graph
   # echo wakeup > current_tracer
   # cat trace
   [...]
  _raw_spin_lock() {
preempt_count_add() {
do_raw_spin_lock() {
  update_rq_clock();

Where it should look like:

  _raw_spin_lock() {
preempt_count_add();
do_raw_spin_lock();
  }
  update_rq_clock();

Cc: Namhyung Kim 
Fixes: 29ad23b00474 ("ftrace: Add set_graph_notrace filter")
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/trace/trace_functions_graph.c |   17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -780,6 +780,10 @@ print_graph_entry_leaf(struct trace_iter
 
cpu_data = per_cpu_ptr(data->cpu_data, cpu);
 
+   /* If a graph tracer ignored set_graph_notrace */
+   if (call->depth < -1)
+   call->depth += FTRACE_NOTRACE_DEPTH;
+
/*
 * Comments display at + 1 to depth. Since
 * this is a leaf function, keep the comments
@@ -788,7 +792,8 @@ print_graph_entry_leaf(struct trace_iter
cpu_data->depth = call->depth - 1;
 
/* No need to keep this function around for this depth */
-   if (call->depth < FTRACE_RETFUNC_DEPTH)
+   if (call->depth < FTRACE_RETFUNC_DEPTH &&
+   !WARN_ON_ONCE(call->depth < 0))
cpu_data->enter_funcs[call->depth] = 0;
}
 
@@ -818,11 +823,16 @@ print_graph_entry_nested(struct trace_it
struct fgraph_cpu_data *cpu_data;
int cpu = iter->cpu;
 
+   /* If a graph tracer ignored set_graph_notrace */
+   if (call->depth < -1)
+   call->depth += FTRACE_NOTRACE_DEPTH;
+
cpu_data = per_cpu_ptr(data->cpu_data, cpu);
cpu_data->depth = call->depth;
 
/* Save this function pointer to see if the exit matches */
-   if (call->depth < FTRACE_RETFUNC_DEPTH)
+   if (call->depth < FTRACE_RETFUNC_DEPTH &&
+   !WARN_ON_ONCE(call->depth < 0))
cpu_data->enter_funcs[call->depth] = call->func;
}
 
@@ -1052,7 +1062,8 @@ print_graph_return(struct ftrace_graph_r
 */
cpu_data->depth = trace->depth - 1;
 
-   if (trace->depth < FTRACE_RETFUNC_DEPTH) {
+   if (trace->depth < FTRACE_RETFUNC_DEPTH &&
+   !WARN_ON_ONCE(trace->depth < 0)) {
if (cpu_data->enter_funcs[trace->depth] != trace->func)
func_match = 0;
cpu_data->enter_funcs[trace->depth] = 0;

[PATCH 4.8 35/96] drm/amdgpu: fix init save/restore list in gfx_v8.0

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Rex Zhu 

commit 202e0b227b906cb80a2791f21216a55d9468d61b upstream.

set valid data to mmRLC_SRM_INDEX_CNTL_ADDRx/DATAx.

Signed-off-by: Rex Zhu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -3798,8 +3798,12 @@ static int gfx_v8_0_init_save_restore_li
temp = mmRLC_SRM_INDEX_CNTL_ADDR_0;
data = mmRLC_SRM_INDEX_CNTL_DATA_0;
for (i = 0; i < sizeof(unique_indices) / sizeof(int); i++) {
-   amdgpu_mm_wreg(adev, temp + i, unique_indices[i] & 0x3, 
false);
-   amdgpu_mm_wreg(adev, data + i, unique_indices[i] >> 20, false);
+   if (unique_indices[i] != 0) {
+   amdgpu_mm_wreg(adev, temp + i,
+   unique_indices[i] & 0x3, false);
+   amdgpu_mm_wreg(adev, data + i,
+   unique_indices[i] >> 20, false);
+   }
}
kfree(register_list_format);
 

[PATCH 4.8 54/96] sc16is7xx: Drop bogus use of IRQF_ONESHOT

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Josh Cartwright 

commit 04da73803c05dc1150ccc31cbf93e8cd56679c09 upstream.

The use of IRQF_ONESHOT when registering an interrupt handler with
request_irq() is non-sensical.

Not only that, it also prevents the handler from being threaded when it
otherwise should be w/ IRQ_FORCED_THREADING is enabled.  This causes the
following deadlock observed by Sean Nyekjaer on -rt:

Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[..]
   rt_spin_lock_slowlock from queue_kthread_work
   queue_kthread_work from sc16is7xx_irq
   sc16is7xx_irq [sc16is7xx] from handle_irq_event_percpu
   handle_irq_event_percpu from handle_irq_event
   handle_irq_event from handle_level_irq
   handle_level_irq from generic_handle_irq
   generic_handle_irq from mxc_gpio_irq_handler
   mxc_gpio_irq_handler from mx3_gpio_irq_handler
   mx3_gpio_irq_handler from generic_handle_irq
   generic_handle_irq from __handle_domain_irq
   __handle_domain_irq from gic_handle_irq
   gic_handle_irq from __irq_svc
   __irq_svc from rt_spin_unlock
   rt_spin_unlock from kthread_worker_fn
   kthread_worker_fn from kthread
   kthread from ret_from_fork

Fixes: 9e6f4ca3e567 ("sc16is7xx: use kthread_worker for tx_work and irq")
Reported-by: Sean Nyekjaer 
Signed-off-by: Josh Cartwright 
Cc: linux-rt-us...@vger.kernel.org
Cc: Jakub Kicinski 
Cc: linux-ser...@vger.kernel.org
Cc: Sebastian Andrzej Siewior 
Signed-off-by: Julia Cartwright 
Acked-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/tty/serial/sc16is7xx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1240,7 +1240,7 @@ static int sc16is7xx_probe(struct device
 
/* Setup interrupt */
ret = devm_request_irq(dev, irq, sc16is7xx_irq,
-  IRQF_ONESHOT | flags, dev_name(dev), s);
+  flags, dev_name(dev), s);
if (!ret)
return 0;
 

[PATCH 4.8 64/96] fgraph: Handle a case where a tracer ignores set_graph_notrace

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Steven Rostedt (Red Hat) 

commit 794de08a16cf1fc1bf785dc48f66d36218cf6d88 upstream.

Both the wakeup and irqsoff tracers can use the function graph tracer when
the display-graph option is set. The problem is that they ignore the notrace
file, and record the entry of functions that would be ignored by the
function_graph tracer. This causes the trace->depth to be recorded into the
ring buffer. The set_graph_notrace uses a trick by adding a large negative
number to the trace->depth when a graph function is to be ignored.

On trace output, the graph function uses the depth to record a stack of
functions. But since the depth is negative, it accesses the array with a
negative number and causes an out of bounds access that can cause a kernel
oops or corrupt data.

Have the print functions handle cases where a tracer still records functions
even when they are in set_graph_notrace.

Also add warnings if the depth is below zero before accessing the array.

Note, the function graph logic will still prevent the return of these
functions from being recorded, which means that they will be left hanging
without a return. For example:

   # echo '*spin*' > set_graph_notrace
   # echo 1 > options/display-graph
   # echo wakeup > current_tracer
   # cat trace
   [...]
  _raw_spin_lock() {
preempt_count_add() {
do_raw_spin_lock() {
  update_rq_clock();

Where it should look like:

  _raw_spin_lock() {
preempt_count_add();
do_raw_spin_lock();
  }
  update_rq_clock();

Cc: Namhyung Kim 
Fixes: 29ad23b00474 ("ftrace: Add set_graph_notrace filter")
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/trace/trace_functions_graph.c |   17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -780,6 +780,10 @@ print_graph_entry_leaf(struct trace_iter
 
cpu_data = per_cpu_ptr(data->cpu_data, cpu);
 
+   /* If a graph tracer ignored set_graph_notrace */
+   if (call->depth < -1)
+   call->depth += FTRACE_NOTRACE_DEPTH;
+
/*
 * Comments display at + 1 to depth. Since
 * this is a leaf function, keep the comments
@@ -788,7 +792,8 @@ print_graph_entry_leaf(struct trace_iter
cpu_data->depth = call->depth - 1;
 
/* No need to keep this function around for this depth */
-   if (call->depth < FTRACE_RETFUNC_DEPTH)
+   if (call->depth < FTRACE_RETFUNC_DEPTH &&
+   !WARN_ON_ONCE(call->depth < 0))
cpu_data->enter_funcs[call->depth] = 0;
}
 
@@ -818,11 +823,16 @@ print_graph_entry_nested(struct trace_it
struct fgraph_cpu_data *cpu_data;
int cpu = iter->cpu;
 
+   /* If a graph tracer ignored set_graph_notrace */
+   if (call->depth < -1)
+   call->depth += FTRACE_NOTRACE_DEPTH;
+
cpu_data = per_cpu_ptr(data->cpu_data, cpu);
cpu_data->depth = call->depth;
 
/* Save this function pointer to see if the exit matches */
-   if (call->depth < FTRACE_RETFUNC_DEPTH)
+   if (call->depth < FTRACE_RETFUNC_DEPTH &&
+   !WARN_ON_ONCE(call->depth < 0))
cpu_data->enter_funcs[call->depth] = call->func;
}
 
@@ -1052,7 +1062,8 @@ print_graph_return(struct ftrace_graph_r
 */
cpu_data->depth = trace->depth - 1;
 
-   if (trace->depth < FTRACE_RETFUNC_DEPTH) {
+   if (trace->depth < FTRACE_RETFUNC_DEPTH &&
+   !WARN_ON_ONCE(trace->depth < 0)) {
if (cpu_data->enter_funcs[trace->depth] != trace->func)
func_match = 0;
cpu_data->enter_funcs[trace->depth] = 0;

[PATCH 4.8 35/96] drm/amdgpu: fix init save/restore list in gfx_v8.0

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Rex Zhu 

commit 202e0b227b906cb80a2791f21216a55d9468d61b upstream.

set valid data to mmRLC_SRM_INDEX_CNTL_ADDRx/DATAx.

Signed-off-by: Rex Zhu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -3798,8 +3798,12 @@ static int gfx_v8_0_init_save_restore_li
temp = mmRLC_SRM_INDEX_CNTL_ADDR_0;
data = mmRLC_SRM_INDEX_CNTL_DATA_0;
for (i = 0; i < sizeof(unique_indices) / sizeof(int); i++) {
-   amdgpu_mm_wreg(adev, temp + i, unique_indices[i] & 0x3, 
false);
-   amdgpu_mm_wreg(adev, data + i, unique_indices[i] >> 20, false);
+   if (unique_indices[i] != 0) {
+   amdgpu_mm_wreg(adev, temp + i,
+   unique_indices[i] & 0x3, false);
+   amdgpu_mm_wreg(adev, data + i,
+   unique_indices[i] >> 20, false);
+   }
}
kfree(register_list_format);
 

[PATCH 4.8 54/96] sc16is7xx: Drop bogus use of IRQF_ONESHOT

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Josh Cartwright 

commit 04da73803c05dc1150ccc31cbf93e8cd56679c09 upstream.

The use of IRQF_ONESHOT when registering an interrupt handler with
request_irq() is non-sensical.

Not only that, it also prevents the handler from being threaded when it
otherwise should be w/ IRQ_FORCED_THREADING is enabled.  This causes the
following deadlock observed by Sean Nyekjaer on -rt:

Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[..]
   rt_spin_lock_slowlock from queue_kthread_work
   queue_kthread_work from sc16is7xx_irq
   sc16is7xx_irq [sc16is7xx] from handle_irq_event_percpu
   handle_irq_event_percpu from handle_irq_event
   handle_irq_event from handle_level_irq
   handle_level_irq from generic_handle_irq
   generic_handle_irq from mxc_gpio_irq_handler
   mxc_gpio_irq_handler from mx3_gpio_irq_handler
   mx3_gpio_irq_handler from generic_handle_irq
   generic_handle_irq from __handle_domain_irq
   __handle_domain_irq from gic_handle_irq
   gic_handle_irq from __irq_svc
   __irq_svc from rt_spin_unlock
   rt_spin_unlock from kthread_worker_fn
   kthread_worker_fn from kthread
   kthread from ret_from_fork

Fixes: 9e6f4ca3e567 ("sc16is7xx: use kthread_worker for tx_work and irq")
Reported-by: Sean Nyekjaer 
Signed-off-by: Josh Cartwright 
Cc: linux-rt-us...@vger.kernel.org
Cc: Jakub Kicinski 
Cc: linux-ser...@vger.kernel.org
Cc: Sebastian Andrzej Siewior 
Signed-off-by: Julia Cartwright 
Acked-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/tty/serial/sc16is7xx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1240,7 +1240,7 @@ static int sc16is7xx_probe(struct device
 
/* Setup interrupt */
ret = devm_request_irq(dev, irq, sc16is7xx_irq,
-  IRQF_ONESHOT | flags, dev_name(dev), s);
+  flags, dev_name(dev), s);
if (!ret)
return 0;
 

[PATCH 4.8 56/96] scsi: aacraid: remove wildcard for series 9 controllers

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Kevin Barnett 

commit ae2aae2421983f6f68eb7c4692624bc43ea50712 upstream.

Controllers with this PCI ID never shipped outside of
PMCS/Microsemi. Remove the ID from the aacraid driver. smartpqi is the
correct driver for these controllers.

[mkp: patch description]

Reviewed-by: Scott Teel 
Signed-off-by: Kevin Barnett 
Signed-off-by: Don Brace 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/aacraid/linit.c |2 --
 1 file changed, 2 deletions(-)

--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -160,7 +160,6 @@ static const struct pci_device_id aac_pc
{ 0x9005, 0x028b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 62 }, /* Adaptec PMC 
Series 6 (Tupelo) */
{ 0x9005, 0x028c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 63 }, /* Adaptec PMC 
Series 7 (Denali) */
{ 0x9005, 0x028d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 64 }, /* Adaptec PMC 
Series 8 */
-   { 0x9005, 0x028f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 65 }, /* Adaptec PMC 
Series 9 */
{ 0,}
 };
 MODULE_DEVICE_TABLE(pci, aac_pci_tbl);
@@ -239,7 +238,6 @@ static struct aac_driver_ident aac_drive
{ aac_src_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC }, /* Adaptec PMC Series 6 (Tupelo) */
{ aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC }, /* Adaptec PMC Series 7 (Denali) */
{ aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC }, /* Adaptec PMC Series 8 */
-   { aac_srcv_init, "aacraid", "ADAPTEC ", "RAID", 2, 
AAC_QUIRK_SRC } /* Adaptec PMC Series 9 */
 };
 
 /**

[PATCH 4.8 27/96] drm/nouveau/ttm: wait for bo fence to signal before unmapping vmas

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Skeggs 

commit 10dcab3e7f477bffee88d518aad57d06777cfdf4 upstream.

TTM was changed a while back to allow for pipelining of buffer moves, and
part of this was the removal of waiting for a BO to idle before calling
move(), placing the responsibility on the driver to do this if required.

That's all well and good, except, we make use of move_notify() to handle
mapping/unmapping from the GPU VMM as move() isn't called on all paths.

This commit adds a wait before unmapping from a VMM in move_notify(), to
prevent GPU page faults where a buffer is still being accessed.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/nouveau/nouveau_bo.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1209,6 +1209,7 @@ nouveau_bo_move_ntfy(struct ttm_buffer_o
   nvbo->page_shift != vma->vm->mmu->lpg_shift)) {
nvkm_vm_map(vma, new_mem->mm_node);
} else {
+   WARN_ON(ttm_bo_wait(bo, false, false));
nvkm_vm_unmap(vma);
}
}

[PATCH 4.8 09/96] mmc: sdhci: Fix recovery from tuning timeout

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Adrian Hunter 

commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream.

Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.

Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.

Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.

Signed-off-by: Adrian Hunter 
Tested-by: Dan O'Donovan 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/sdhci.c |   20 
 1 file changed, 20 insertions(+)

--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2074,7 +2074,27 @@ static int sdhci_execute_tuning(struct m
ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
+   sdhci_do_reset(host, SDHCI_RESET_CMD);
+   sdhci_do_reset(host, SDHCI_RESET_DATA);
+
err = -EIO;
+
+   if (cmd.opcode != MMC_SEND_TUNING_BLOCK_HS200)
+   goto out;
+
+   sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
+   sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
+
+   spin_unlock_irqrestore(>lock, flags);
+
+   memset(, 0, sizeof(cmd));
+   cmd.opcode = MMC_STOP_TRANSMISSION;
+   cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
+   cmd.busy_timeout = 50;
+   mmc_wait_for_cmd(mmc, , 0);
+
+   spin_lock_irqsave(>lock, flags);
+
goto out;
}
 

[PATCH 4.8 46/96] scsi: zfcp: do not trace pure benign residual HBA responses at default level

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Steffen Maier 

commit 56d23ed7adf3974f10e91b643bd230e9c65b5f79 upstream.

Since quite a while, Linux issues enough SCSI commands per scsi_device
which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE,
and SAM_STAT_GOOD.  This floods the HBA trace area and we cannot see
other and important HBA trace records long enough.

Therefore, do not trace HBA response errors for pure benign residual
under counts at the default trace level.

This excludes benign residual under count combined with other validity
bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL.  For all those other
cases, we still do want to see both the HBA record and the corresponding
SCSI record by default.

Signed-off-by: Steffen Maier 
Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA 
records.")
Reviewed-by: Benjamin Block 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/s390/scsi/zfcp_dbf.h |   30 --
 drivers/s390/scsi/zfcp_fsf.h |3 ++-
 2 files changed, 30 insertions(+), 3 deletions(-)

--- a/drivers/s390/scsi/zfcp_dbf.h
+++ b/drivers/s390/scsi/zfcp_dbf.h
@@ -2,7 +2,7 @@
  * zfcp device driver
  * debug feature declarations
  *
- * Copyright IBM Corp. 2008, 2015
+ * Copyright IBM Corp. 2008, 2016
  */
 
 #ifndef ZFCP_DBF_H
@@ -283,6 +283,30 @@ struct zfcp_dbf {
struct zfcp_dbf_scsiscsi_buf;
 };
 
+/**
+ * zfcp_dbf_hba_fsf_resp_suppress - true if we should not trace by default
+ * @req: request that has been completed
+ *
+ * Returns true if FCP response with only benign residual under count.
+ */
+static inline
+bool zfcp_dbf_hba_fsf_resp_suppress(struct zfcp_fsf_req *req)
+{
+   struct fsf_qtcb *qtcb = req->qtcb;
+   u32 fsf_stat = qtcb->header.fsf_status;
+   struct fcp_resp *fcp_rsp;
+   u8 rsp_flags, fr_status;
+
+   if (qtcb->prefix.qtcb_type != FSF_IO_COMMAND)
+   return false; /* not an FCP response */
+   fcp_rsp = (struct fcp_resp *)>bottom.io.fcp_rsp;
+   rsp_flags = fcp_rsp->fr_flags;
+   fr_status = fcp_rsp->fr_status;
+   return (fsf_stat == FSF_FCP_RSP_AVAILABLE) &&
+   (rsp_flags == FCP_RESID_UNDER) &&
+   (fr_status == SAM_STAT_GOOD);
+}
+
 static inline
 void zfcp_dbf_hba_fsf_resp(char *tag, int level, struct zfcp_fsf_req *req)
 {
@@ -304,7 +328,9 @@ void zfcp_dbf_hba_fsf_response(struct zf
zfcp_dbf_hba_fsf_resp("fs_perr", 1, req);
 
} else if (qtcb->header.fsf_status != FSF_GOOD) {
-   zfcp_dbf_hba_fsf_resp("fs_ferr", 1, req);
+   zfcp_dbf_hba_fsf_resp("fs_ferr",
+ zfcp_dbf_hba_fsf_resp_suppress(req)
+ ? 5 : 1, req);
 
} else if ((req->fsf_command == FSF_QTCB_OPEN_PORT_WITH_DID) ||
   (req->fsf_command == FSF_QTCB_OPEN_LUN)) {
--- a/drivers/s390/scsi/zfcp_fsf.h
+++ b/drivers/s390/scsi/zfcp_fsf.h
@@ -3,7 +3,7 @@
  *
  * Interface to the FSF support functions.
  *
- * Copyright IBM Corp. 2002, 2015
+ * Copyright IBM Corp. 2002, 2016
  */
 
 #ifndef FSF_H
@@ -78,6 +78,7 @@
 #define FSF_APP_TAG_CHECK_FAILURE  0x0082
 #define FSF_REF_TAG_CHECK_FAILURE  0x0083
 #define FSF_ADAPTER_STATUS_AVAILABLE   0x00AD
+#define FSF_FCP_RSP_AVAILABLE  0x00AF
 #define FSF_UNKNOWN_COMMAND0x00E2
 #define FSF_UNKNOWN_OP_SUBTYPE  0x00E3
 #define FSF_INVALID_COMMAND_OPTION  0x00E5

[PATCH 4.8 46/96] scsi: zfcp: do not trace pure benign residual HBA responses at default level

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Steffen Maier 

commit 56d23ed7adf3974f10e91b643bd230e9c65b5f79 upstream.

Since quite a while, Linux issues enough SCSI commands per scsi_device
which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE,
and SAM_STAT_GOOD.  This floods the HBA trace area and we cannot see
other and important HBA trace records long enough.

Therefore, do not trace HBA response errors for pure benign residual
under counts at the default trace level.

This excludes benign residual under count combined with other validity
bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL.  For all those other
cases, we still do want to see both the HBA record and the corresponding
SCSI record by default.

Signed-off-by: Steffen Maier 
Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA 
records.")
Reviewed-by: Benjamin Block 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/s390/scsi/zfcp_dbf.h |   30 --
 drivers/s390/scsi/zfcp_fsf.h |3 ++-
 2 files changed, 30 insertions(+), 3 deletions(-)

--- a/drivers/s390/scsi/zfcp_dbf.h
+++ b/drivers/s390/scsi/zfcp_dbf.h
@@ -2,7 +2,7 @@
  * zfcp device driver
  * debug feature declarations
  *
- * Copyright IBM Corp. 2008, 2015
+ * Copyright IBM Corp. 2008, 2016
  */
 
 #ifndef ZFCP_DBF_H
@@ -283,6 +283,30 @@ struct zfcp_dbf {
struct zfcp_dbf_scsiscsi_buf;
 };
 
+/**
+ * zfcp_dbf_hba_fsf_resp_suppress - true if we should not trace by default
+ * @req: request that has been completed
+ *
+ * Returns true if FCP response with only benign residual under count.
+ */
+static inline
+bool zfcp_dbf_hba_fsf_resp_suppress(struct zfcp_fsf_req *req)
+{
+   struct fsf_qtcb *qtcb = req->qtcb;
+   u32 fsf_stat = qtcb->header.fsf_status;
+   struct fcp_resp *fcp_rsp;
+   u8 rsp_flags, fr_status;
+
+   if (qtcb->prefix.qtcb_type != FSF_IO_COMMAND)
+   return false; /* not an FCP response */
+   fcp_rsp = (struct fcp_resp *)>bottom.io.fcp_rsp;
+   rsp_flags = fcp_rsp->fr_flags;
+   fr_status = fcp_rsp->fr_status;
+   return (fsf_stat == FSF_FCP_RSP_AVAILABLE) &&
+   (rsp_flags == FCP_RESID_UNDER) &&
+   (fr_status == SAM_STAT_GOOD);
+}
+
 static inline
 void zfcp_dbf_hba_fsf_resp(char *tag, int level, struct zfcp_fsf_req *req)
 {
@@ -304,7 +328,9 @@ void zfcp_dbf_hba_fsf_response(struct zf
zfcp_dbf_hba_fsf_resp("fs_perr", 1, req);
 
} else if (qtcb->header.fsf_status != FSF_GOOD) {
-   zfcp_dbf_hba_fsf_resp("fs_ferr", 1, req);
+   zfcp_dbf_hba_fsf_resp("fs_ferr",
+ zfcp_dbf_hba_fsf_resp_suppress(req)
+ ? 5 : 1, req);
 
} else if ((req->fsf_command == FSF_QTCB_OPEN_PORT_WITH_DID) ||
   (req->fsf_command == FSF_QTCB_OPEN_LUN)) {
--- a/drivers/s390/scsi/zfcp_fsf.h
+++ b/drivers/s390/scsi/zfcp_fsf.h
@@ -3,7 +3,7 @@
  *
  * Interface to the FSF support functions.
  *
- * Copyright IBM Corp. 2002, 2015
+ * Copyright IBM Corp. 2002, 2016
  */
 
 #ifndef FSF_H
@@ -78,6 +78,7 @@
 #define FSF_APP_TAG_CHECK_FAILURE  0x0082
 #define FSF_REF_TAG_CHECK_FAILURE  0x0083
 #define FSF_ADAPTER_STATUS_AVAILABLE   0x00AD
+#define FSF_FCP_RSP_AVAILABLE  0x00AF
 #define FSF_UNKNOWN_COMMAND0x00E2
 #define FSF_UNKNOWN_OP_SUBTYPE  0x00E3
 #define FSF_INVALID_COMMAND_OPTION  0x00E5

[PATCH 4.8 27/96] drm/nouveau/ttm: wait for bo fence to signal before unmapping vmas

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Skeggs 

commit 10dcab3e7f477bffee88d518aad57d06777cfdf4 upstream.

TTM was changed a while back to allow for pipelining of buffer moves, and
part of this was the removal of waiting for a BO to idle before calling
move(), placing the responsibility on the driver to do this if required.

That's all well and good, except, we make use of move_notify() to handle
mapping/unmapping from the GPU VMM as move() isn't called on all paths.

This commit adds a wait before unmapping from a VMM in move_notify(), to
prevent GPU page faults where a buffer is still being accessed.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/nouveau/nouveau_bo.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1209,6 +1209,7 @@ nouveau_bo_move_ntfy(struct ttm_buffer_o
   nvbo->page_shift != vma->vm->mmu->lpg_shift)) {
nvkm_vm_map(vma, new_mem->mm_node);
} else {
+   WARN_ON(ttm_bo_wait(bo, false, false));
nvkm_vm_unmap(vma);
}
}

[PATCH 4.8 09/96] mmc: sdhci: Fix recovery from tuning timeout

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Adrian Hunter 

commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream.

Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.

Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.

Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.

Signed-off-by: Adrian Hunter 
Tested-by: Dan O'Donovan 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/sdhci.c |   20 
 1 file changed, 20 insertions(+)

--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2074,7 +2074,27 @@ static int sdhci_execute_tuning(struct m
ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
+   sdhci_do_reset(host, SDHCI_RESET_CMD);
+   sdhci_do_reset(host, SDHCI_RESET_DATA);
+
err = -EIO;
+
+   if (cmd.opcode != MMC_SEND_TUNING_BLOCK_HS200)
+   goto out;
+
+   sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
+   sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
+
+   spin_unlock_irqrestore(>lock, flags);
+
+   memset(, 0, sizeof(cmd));
+   cmd.opcode = MMC_STOP_TRANSMISSION;
+   cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
+   cmd.busy_timeout = 50;
+   mmc_wait_for_cmd(mmc, , 0);
+
+   spin_lock_irqsave(>lock, flags);
+
goto out;
}
 

[PATCH 4.8 28/96] drm/nouveau/i2c/gk110b,gm10x: use the correct implementation

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Skeggs 

commit 5b3800a6b763874e4a23702fb9628d3bd3315ce9 upstream.

DPAUX registers moved on Kepler, these chipsets were still using the
Fermi implementation for some reason.

This fixes detection of hotplug/sink IRQs on DP connectors.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -1851,7 +1851,7 @@ nvf1_chipset = {
.fb = gk104_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
-   .i2c = gf119_i2c_new,
+   .i2c = gk104_i2c_new,
.ibus = gk104_ibus_new,
.iccsense = gf100_iccsense_new,
.imem = nv50_instmem_new,
@@ -1965,7 +1965,7 @@ nv117_chipset = {
.fb = gm107_fb_new,
.fuse = gm107_fuse_new,
.gpio = gk104_gpio_new,
-   .i2c = gf119_i2c_new,
+   .i2c = gk104_i2c_new,
.ibus = gk104_ibus_new,
.iccsense = gf100_iccsense_new,
.imem = nv50_instmem_new,
@@ -1999,7 +1999,7 @@ nv118_chipset = {
.fb = gm107_fb_new,
.fuse = gm107_fuse_new,
.gpio = gk104_gpio_new,
-   .i2c = gf119_i2c_new,
+   .i2c = gk104_i2c_new,
.ibus = gk104_ibus_new,
.iccsense = gf100_iccsense_new,
.imem = nv50_instmem_new,

[PATCH 4.8 28/96] drm/nouveau/i2c/gk110b,gm10x: use the correct implementation

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Skeggs 

commit 5b3800a6b763874e4a23702fb9628d3bd3315ce9 upstream.

DPAUX registers moved on Kepler, these chipsets were still using the
Fermi implementation for some reason.

This fixes detection of hotplug/sink IRQs on DP connectors.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -1851,7 +1851,7 @@ nvf1_chipset = {
.fb = gk104_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
-   .i2c = gf119_i2c_new,
+   .i2c = gk104_i2c_new,
.ibus = gk104_ibus_new,
.iccsense = gf100_iccsense_new,
.imem = nv50_instmem_new,
@@ -1965,7 +1965,7 @@ nv117_chipset = {
.fb = gm107_fb_new,
.fuse = gm107_fuse_new,
.gpio = gk104_gpio_new,
-   .i2c = gf119_i2c_new,
+   .i2c = gk104_i2c_new,
.ibus = gk104_ibus_new,
.iccsense = gf100_iccsense_new,
.imem = nv50_instmem_new,
@@ -1999,7 +1999,7 @@ nv118_chipset = {
.fb = gm107_fb_new,
.fuse = gm107_fuse_new,
.gpio = gk104_gpio_new,
-   .i2c = gf119_i2c_new,
+   .i2c = gk104_i2c_new,
.ibus = gk104_ibus_new,
.iccsense = gf100_iccsense_new,
.imem = nv50_instmem_new,