This is a note to let you know that I've just added the patch titled
drm/hisilicon: Ensure LDI regs are properly configured.
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-hisilicon-ensure-ldi-regs-are-properly-configured.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a2f042430784d86eb2b7a6d2a869f552da30edba Mon Sep 17 00:00:00 2001
From: Peter Griffin <peter.griffin(a)linaro.org>
Date: Tue, 15 Aug 2017 15:14:25 +0100
Subject: drm/hisilicon: Ensure LDI regs are properly configured.
From: Peter Griffin <peter.griffin(a)linaro.org>
commit a2f042430784d86eb2b7a6d2a869f552da30edba upstream.
This patch fixes the following soft lockup:
BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
On weston idle-timeout the IP is powered down and reset
asserted. On weston resume we get a massive vblank
IRQ storm due to the LDI registers having lost some state.
This state loss is caused by ade_crtc_atomic_begin() not
calling ade_ldi_set_mode(). With this patch applied
resuming from Weston idle-timeout works well.
Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org>
Tested-by: John Stultz <john.stultz(a)linaro.org>
Reviewed-by: Xinliang Liu <xinliang.liu(a)linaro.org>
Signed-off-by: Xinliang Liu <xinliang.liu(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -521,9 +521,12 @@ static void ade_crtc_atomic_begin(struct
{
struct ade_crtc *acrtc = to_ade_crtc(crtc);
struct ade_hw_ctx *ctx = acrtc->ctx;
+ struct drm_display_mode *mode = &crtc->state->mode;
+ struct drm_display_mode *adj_mode = &crtc->state->adjusted_mode;
if (!ctx->power_on)
(void)ade_power_up(ctx);
+ ade_ldi_set_mode(acrtc, mode, adj_mode);
}
static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
Patches currently in stable-queue which might be from peter.griffin(a)linaro.org are
queue-4.9/drm-hisilicon-ensure-ldi-regs-are-properly-configured.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 78aa02c713fcf19e9bc8511ab61a5fd6c877cc01 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Sat, 30 Sep 2017 11:14:13 +0300
Subject: drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 78aa02c713fcf19e9bc8511ab61a5fd6c877cc01 upstream.
After commit ea09729c9302 ("drm/amdgpu: rework page directory filling
v2") then it becomes a lot harder to verify that "r" is initialized. My
static checker complains and so I've reviewed the code. It does look
like it might be buggy... Anyway, it doesn't hurt to set "r" to zero
at the start.
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -744,7 +744,7 @@ error_free:
int amdgpu_vm_update_page_directory(struct amdgpu_device *adev,
struct amdgpu_vm *vm)
{
- int r;
+ int r = 0;
r = amdgpu_vm_update_pd_or_shadow(adev, vm, true);
if (r)
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 40a9960b046290939b56ce8e51f365258f27f264 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Sat, 30 Sep 2017 11:13:28 +0300
Subject: drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 40a9960b046290939b56ce8e51f365258f27f264 upstream.
We shifted some code around in commit 9cca0b8e5df0 ("drm/amdgpu: move
amdgpu_cs_sysvm_access_required into find_mapping") and now my static
checker complains that "r" might not be initialized at the end of the
function. I've reviewed the code, and that seems possible, but it's
also possible I may have missed something.
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -648,7 +648,7 @@ int amdgpu_vce_ring_parse_cs(struct amdg
uint32_t allocated = 0;
uint32_t tmp, handle = 0;
uint32_t *size = &tmp;
- int i, r, idx = 0;
+ int i, r = 0, idx = 0;
r = amdgpu_cs_sysvm_access_required(p);
if (r)
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch
This is a note to let you know that I've just added the patch titled
drm/amd/pp: fix typecast error in powerplay.
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amd-pp-fix-typecast-error-in-powerplay.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 8d8258bdab735d9f3c4b78e091ecfbb2b2b1f2ca Mon Sep 17 00:00:00 2001
From: Rex Zhu <Rex.Zhu(a)amd.com>
Date: Fri, 17 Nov 2017 16:41:16 +0800
Subject: drm/amd/pp: fix typecast error in powerplay.
From: Rex Zhu <Rex.Zhu(a)amd.com>
commit 8d8258bdab735d9f3c4b78e091ecfbb2b2b1f2ca upstream.
resulted in unexpected data truncation
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
@@ -850,9 +850,9 @@ static int init_over_drive_limits(
const ATOM_Tonga_POWERPLAYTABLE *powerplay_table)
{
hwmgr->platform_descriptor.overdriveLimit.engineClock =
- le16_to_cpu(powerplay_table->ulMaxODEngineClock);
+ le32_to_cpu(powerplay_table->ulMaxODEngineClock);
hwmgr->platform_descriptor.overdriveLimit.memoryClock =
- le16_to_cpu(powerplay_table->ulMaxODMemoryClock);
+ le32_to_cpu(powerplay_table->ulMaxODMemoryClock);
hwmgr->platform_descriptor.minOverdriveVDDC = 0;
hwmgr->platform_descriptor.maxOverdriveVDDC = 0;
Patches currently in stable-queue which might be from Rex.Zhu(a)amd.com are
queue-4.9/drm-amd-pp-fix-typecast-error-in-powerplay.patch
This is a note to let you know that I've just added the patch titled
NFS: revalidate "." etc correctly on "open".
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfs-revalidate-.-etc-correctly-on-open.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b688741cb06695312f18b730653d6611e1bad28d Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb(a)suse.com>
Date: Fri, 25 Aug 2017 17:34:41 +1000
Subject: NFS: revalidate "." etc correctly on "open".
From: NeilBrown <neilb(a)suse.com>
commit b688741cb06695312f18b730653d6611e1bad28d upstream.
For correct close-to-open semantics, NFS must validate
the change attribute of a directory (or file) on open.
Since commit ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a
d_weak_revalidate dentry op"), open() of "." or a path ending ".." is
not revalidated reliably (except when that direct is a mount point).
Prior to that commit, "." was revalidated using nfs_lookup_revalidate()
which checks the LOOKUP_OPEN flag and forces revalidation if the flag is
set.
Since that commit, nfs_weak_revalidate() is used for NFSv3 (which
ignores the flags) and nothing is used for NFSv4.
This is fixed by using nfs_lookup_verify_inode() in
nfs_weak_revalidate(). This does the revalidation exactly when needed.
Also, add a definition of .d_weak_revalidate for NFSv4.
The incorrect behavior is easily demonstrated by running "echo *" in
some non-mountpoint NFS directory while watching network traffic.
Without this patch, "echo *" sometimes doesn't produce any traffic.
With the patch it always does.
Fixes: ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op")
cc: stable(a)vger.kernel.org (3.9+)
Signed-off-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/dir.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1260,7 +1260,7 @@ static int nfs_weak_revalidate(struct de
return 0;
}
- error = nfs_revalidate_inode(NFS_SERVER(inode), inode);
+ error = nfs_lookup_verify_inode(inode, flags);
dfprintk(LOOKUPCACHE, "NFS: %s: inode %lu is %s\n",
__func__, inode->i_ino, error ? "invalid" : "valid");
return !error;
@@ -1420,6 +1420,7 @@ static int nfs4_lookup_revalidate(struct
const struct dentry_operations nfs4_dentry_operations = {
.d_revalidate = nfs4_lookup_revalidate,
+ .d_weak_revalidate = nfs_weak_revalidate,
.d_delete = nfs_dentry_delete,
.d_iput = nfs_dentry_iput,
.d_automount = nfs_d_automount,
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-4.4/nfs-revalidate-.-etc-correctly-on-open.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: Fix writing mtdoops to nand flash.
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mtd-nand-fix-writing-mtdoops-to-nand-flash.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 30863e38ebeb500a31cecee8096fb5002677dd9b Mon Sep 17 00:00:00 2001
From: Brent Taylor <motobud(a)gmail.com>
Date: Mon, 30 Oct 2017 22:32:45 -0500
Subject: mtd: nand: Fix writing mtdoops to nand flash.
From: Brent Taylor <motobud(a)gmail.com>
commit 30863e38ebeb500a31cecee8096fb5002677dd9b upstream.
When mtdoops calls mtd_panic_write(), it eventually calls
panic_nand_write() in nand_base.c. In order to properly wait for the
nand chip to be ready in panic_nand_wait(), the chip must first be
selected.
When using the atmel nand flash controller, a panic would occur due to
a NULL pointer exception.
Fixes: 2af7c6539931 ("mtd: Add panic_write for NAND flashes")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Brent Taylor <motobud(a)gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/nand_base.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2663,15 +2663,18 @@ static int panic_nand_write(struct mtd_i
size_t *retlen, const uint8_t *buf)
{
struct nand_chip *chip = mtd->priv;
+ int chipnr = (int)(to >> chip->chip_shift);
struct mtd_oob_ops ops;
int ret;
- /* Wait for the device to get ready */
- panic_nand_wait(mtd, chip, 400);
-
/* Grab the device */
panic_nand_get_device(chip, mtd, FL_WRITING);
+ chip->select_chip(mtd, chipnr);
+
+ /* Wait for the device to get ready */
+ panic_nand_wait(mtd, chip, 400);
+
memset(&ops, 0, sizeof(ops));
ops.len = len;
ops.datbuf = (uint8_t *)buf;
Patches currently in stable-queue which might be from motobud(a)gmail.com are
queue-4.4/mtd-nand-fix-writing-mtdoops-to-nand-flash.patch
This is a note to let you know that I've just added the patch titled
md: forbid a RAID5 from having both a bitmap and a journal.
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
md-forbid-a-raid5-from-having-both-a-bitmap-and-a-journal.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 230b55fa8d64007339319539f8f8e68114d08529 Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb(a)suse.com>
Date: Tue, 17 Oct 2017 14:24:09 +1100
Subject: md: forbid a RAID5 from having both a bitmap and a journal.
From: NeilBrown <neilb(a)suse.com>
commit 230b55fa8d64007339319539f8f8e68114d08529 upstream.
Having both a bitmap and a journal is pointless.
Attempting to do so can corrupt the bitmap if the journal
replay happens before the bitmap is initialized.
Rather than try to avoid this corruption, simply
refuse to allow arrays with both a bitmap and a journal.
So:
- if raid5_run sees both are present, fail.
- if adding a bitmap finds a journal is present, fail
- if adding a journal finds a bitmap is present, fail.
Signed-off-by: NeilBrown <neilb(a)suse.com>
Tested-by: Joshua Kinard <kumba(a)gentoo.org>
Acked-by: Joshua Kinard <kumba(a)gentoo.org>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bitmap.c | 6 ++++++
drivers/md/md.c | 2 +-
drivers/md/raid5.c | 7 +++++++
3 files changed, 14 insertions(+), 1 deletion(-)
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -1816,6 +1816,12 @@ struct bitmap *bitmap_create(struct mdde
BUG_ON(file && mddev->bitmap_info.offset);
+ if (test_bit(MD_HAS_JOURNAL, &mddev->flags)) {
+ pr_notice("md/raid:%s: array with journal cannot have bitmap\n",
+ mdname(mddev));
+ return ERR_PTR(-EBUSY);
+ }
+
bitmap = kzalloc(sizeof(*bitmap), GFP_KERNEL);
if (!bitmap)
return ERR_PTR(-ENOMEM);
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -6362,7 +6362,7 @@ static int add_new_disk(struct mddev *md
break;
}
}
- if (has_journal) {
+ if (has_journal || mddev->bitmap) {
export_rdev(rdev);
return -EBUSY;
}
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -7156,6 +7156,13 @@ static int raid5_run(struct mddev *mddev
min_offset_diff = diff;
}
+ if ((test_bit(MD_HAS_JOURNAL, &mddev->flags) || journal_dev) &&
+ (mddev->bitmap_info.offset || mddev->bitmap_info.file)) {
+ pr_notice("md/raid:%s: array cannot have both journal and bitmap\n",
+ mdname(mddev));
+ return -EINVAL;
+ }
+
if (mddev->reshape_position != MaxSector) {
/* Check that we can continue the reshape.
* Difficulties arise if the stripe we would write to
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-4.14/autofs-revert-autofs-fix-at_no_automount-not-being-honored.patch
queue-4.14/md-forbid-a-raid5-from-having-both-a-bitmap-and-a-journal.patch
queue-4.14/autofs-revert-autofs-take-more-care-to-not-update-last_used-on-path-walk.patch
This is a note to let you know that I've just added the patch titled
include/linux/compiler-clang.h: handle randomizable anonymous structs
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
include-linux-compiler-clang.h-handle-randomizable-anonymous-structs.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4ca59b14e588f873795a11cdc77a25c686a29d23 Mon Sep 17 00:00:00 2001
From: Sandipan Das <sandipan(a)linux.vnet.ibm.com>
Date: Fri, 17 Nov 2017 15:27:28 -0800
Subject: include/linux/compiler-clang.h: handle randomizable anonymous structs
From: Sandipan Das <sandipan(a)linux.vnet.ibm.com>
commit 4ca59b14e588f873795a11cdc77a25c686a29d23 upstream.
The GCC randomize layout plugin can randomize the member offsets of
sensitive kernel data structures. To use this feature, certain
annotations and members are added to the structures which affect the
member offsets even if this plugin is not used.
All of these structures are completely randomized, except for task_struct
which leaves out some of its members. All the other members are wrapped
within an anonymous struct with the __randomize_layout attribute. This is
done using the randomized_struct_fields_start and
randomized_struct_fields_end defines.
When the plugin is disabled, the behaviour of this attribute can vary
based on the GCC version. For GCC 5.1+, this attribute maps to
__designated_init otherwise it is just an empty define but the anonymous
structure is still present. For other compilers, both
randomized_struct_fields_start and randomized_struct_fields_end default
to empty defines meaning the anonymous structure is not introduced at
all.
So, if a module compiled with Clang, such as a BPF program, needs to
access task_struct fields such as pid and comm, the offsets of these
members as recognized by Clang are different from those recognized by
modules compiled with GCC. If GCC 4.6+ is used to build the kernel,
this can be solved by introducing appropriate defines for Clang so that
the anonymous structure is seen when determining the offsets for the
members.
Link: http://lkml.kernel.org/r/20171109064645.25581-1-sandipan@linux.vnet.ibm.com
Signed-off-by: Sandipan Das <sandipan(a)linux.vnet.ibm.com>
Cc: David Rientjes <rientjes(a)google.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Kate Stewart <kstewart(a)linuxfoundation.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com>
Cc: Alexei Starovoitov <ast(a)fb.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/compiler-clang.h | 3 +++
1 file changed, 3 insertions(+)
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -16,3 +16,6 @@
* with any version that can compile the kernel
*/
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
+
+#define randomized_struct_fields_start struct {
+#define randomized_struct_fields_end };
Patches currently in stable-queue which might be from sandipan(a)linux.vnet.ibm.com are
queue-4.14/include-linux-compiler-clang.h-handle-randomizable-anonymous-structs.patch