This is a note to let you know that I've just added the patch titled
drm/amd/powerplay/smu7: allow mclk switching with no displays
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:
drm-amd-powerplay-smu7-allow-mclk-switching-with-no-displays.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 51954e17914aaadf18d97b21c2a2cee16fa29513 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Tue, 13 Feb 2018 14:26:54 -0500
Subject: drm/amd/powerplay/smu7: allow mclk switching with no displays
From: Alex Deucher <alexander.deucher(a)amd.com>
commit 51954e17914aaadf18d97b21c2a2cee16fa29513 upstream.
If there are no displays attached, there is no reason to disable
mclk switching.
Fixes mclks getting set to high when there are no displays attached.
Reviewed-by: Eric Huang <JinhuiEric.Huang(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -2788,10 +2788,13 @@ static int smu7_apply_state_adjust_rules
PHM_PlatformCaps_DisableMclkSwitchingForFrameLock);
- disable_mclk_switching = ((1 < info.display_count) ||
- disable_mclk_switching_for_frame_lock ||
- smu7_vblank_too_short(hwmgr, mode_info.vblank_time_us) ||
- (mode_info.refresh_rate > 120));
+ if (info.display_count == 0)
+ disable_mclk_switching = false;
+ else
+ disable_mclk_switching = ((1 < info.display_count) ||
+ disable_mclk_switching_for_frame_lock ||
+ smu7_vblank_too_short(hwmgr, mode_info.vblank_time_us) ||
+ (mode_info.refresh_rate > 120));
sclk = smu7_ps->performance_levels[0].engine_clock;
mclk = smu7_ps->performance_levels[0].memory_clock;
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.14/drm-amdgpu-notify-sbios-device-ready-before-send-request.patch
queue-4.14/workqueue-allow-retrieval-of-current-task-s-work-struct.patch
queue-4.14/drm-amd-powerplay-vega10-allow-mclk-switching-with-no-displays.patch
queue-4.14/drm-radeon-fix-kv-harvesting.patch
queue-4.14/drm-radeon-fix-deadlock-on-runtime-suspend.patch
queue-4.14/drm-amdgpu-correct-max-uvd-handles.patch
queue-4.14/drm-amd-powerplay-smu7-allow-mclk-switching-with-no-displays.patch
queue-4.14/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch
queue-4.14/drm-amd-powerplay-fix-power-over-limit-on-fiji.patch
queue-4.14/drm-allow-determining-if-current-task-is-output-poll-worker.patch
queue-4.14/drm-amdgpu-used-cached-pcie-gen-info-for-si-v2.patch
queue-4.14/revert-drm-radeon-pm-autoswitch-power-state-when-in-balanced-mode.patch
queue-4.14/drm-amdgpu-fix-kv-harvesting.patch
queue-4.14/drm-amdgpu-always-save-uvd-vcpu_bo-in-vm-mode.patch
queue-4.14/drm-radeon-insist-on-32-bit-dma-for-cedar-on-ppc64-ppc64le.patch
This is a note to let you know that I've just added the patch titled
drm/amd/powerplay: fix power over limit on Fiji
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:
drm-amd-powerplay-fix-power-over-limit-on-fiji.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 a0aaa03062be252aacad60a776f3374dd53e3f98 Mon Sep 17 00:00:00 2001
From: Eric Huang <JinHuiEric.Huang(a)amd.com>
Date: Mon, 26 Feb 2018 17:36:19 -0500
Subject: drm/amd/powerplay: fix power over limit on Fiji
From: Eric Huang <JinHuiEric.Huang(a)amd.com>
commit a0aaa03062be252aacad60a776f3374dd53e3f98 upstream.
power containment disabled only on Fiji and compute
power profile. It violates PCIe spec and may cause power
supply failed. Enabling it will fix the issue, even the
fix will drop performance of some compute tests.
Signed-off-by: Eric Huang <JinHuiEric.Huang(a)amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 7 -------
1 file changed, 7 deletions(-)
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -4579,13 +4579,6 @@ static int smu7_set_power_profile_state(
int tmp_result, result = 0;
uint32_t sclk_mask = 0, mclk_mask = 0;
- if (hwmgr->chip_id == CHIP_FIJI) {
- if (request->type == AMD_PP_GFX_PROFILE)
- smu7_enable_power_containment(hwmgr);
- else if (request->type == AMD_PP_COMPUTE_PROFILE)
- smu7_disable_power_containment(hwmgr);
- }
-
if (hwmgr->dpm_level != AMD_DPM_FORCED_LEVEL_AUTO)
return -EINVAL;
Patches currently in stable-queue which might be from JinHuiEric.Huang(a)amd.com are
queue-4.14/drm-amd-powerplay-fix-power-over-limit-on-fiji.patch
This is a note to let you know that I've just added the patch titled
drm: Allow determining if current task is output poll worker
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:
drm-allow-determining-if-current-task-is-output-poll-worker.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 25c058ccaf2ebbc3e250ec1e199e161f91fe27d4 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Wed, 14 Feb 2018 06:41:25 +0100
Subject: drm: Allow determining if current task is output poll worker
From: Lukas Wunner <lukas(a)wunner.de>
commit 25c058ccaf2ebbc3e250ec1e199e161f91fe27d4 upstream.
Introduce a helper to determine if the current task is an output poll
worker.
This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for the output poll worker
to finish and the worker in turn calls a ->detect callback which waits
for runtime suspend to finish. The ->detect callback is invoked from
multiple call sites and waiting for runtime suspend to finish is the
correct thing to do except if it's executing in the context of the
worker.
v2: Expand kerneldoc to specifically mention deadlock between
output poll worker and autosuspend worker as use case. (Lyude)
Cc: Dave Airlie <airlied(a)redhat.com>
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Alex Deucher <alexander.deucher(a)amd.com>
Reviewed-by: Lyude Paul <lyude(a)redhat.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/3549ce32e7f1467102e70d3e9cbf7…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_probe_helper.c | 20 ++++++++++++++++++++
include/drm/drm_crtc_helper.h | 1 +
2 files changed, 21 insertions(+)
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -672,6 +672,26 @@ out:
}
/**
+ * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
+ *
+ * Determine if %current task is an output poll worker. This can be used
+ * to select distinct code paths for output polling versus other contexts.
+ *
+ * One use case is to avoid a deadlock between the output poll worker and
+ * the autosuspend worker wherein the latter waits for polling to finish
+ * upon calling drm_kms_helper_poll_disable(), while the former waits for
+ * runtime suspend to finish upon calling pm_runtime_get_sync() in a
+ * connector ->detect hook.
+ */
+bool drm_kms_helper_is_poll_worker(void)
+{
+ struct work_struct *work = current_work();
+
+ return work && work->func == output_poll_execute;
+}
+EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
+
+/**
* drm_kms_helper_poll_disable - disable output polling
* @dev: drm_device
*
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct
void drm_kms_helper_poll_disable(struct drm_device *dev);
void drm_kms_helper_poll_enable(struct drm_device *dev);
+bool drm_kms_helper_is_poll_worker(void);
#endif
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.14/workqueue-allow-retrieval-of-current-task-s-work-struct.patch
queue-4.14/drm-radeon-fix-deadlock-on-runtime-suspend.patch
queue-4.14/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch
queue-4.14/drm-allow-determining-if-current-task-is-output-poll-worker.patch
queue-4.14/drm-nouveau-fix-deadlock-on-runtime-suspend.patch
This is a note to let you know that I've just added the patch titled
Documentation/sphinx: Fix Directive import error
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:
documentation-sphinx-fix-directive-import-error.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 ff690eeed804f112242f9a0614eafdf559f9276a Mon Sep 17 00:00:00 2001
From: Matthew Wilcox <mawilcox(a)microsoft.com>
Date: Fri, 2 Mar 2018 10:40:14 -0800
Subject: Documentation/sphinx: Fix Directive import error
From: Matthew Wilcox <mawilcox(a)microsoft.com>
commit ff690eeed804f112242f9a0614eafdf559f9276a upstream.
Sphinx 1.7 removed sphinx.util.compat.Directive so people
who have upgraded cannot build the documentation. Switch to
docutils.parsers.rst.Directive which has been available since
docutils 0.5 released in 2009.
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694
Co-developed-by: Takashi Iwai <tiwai(a)suse.de>
Acked-by: Jani Nikula <jani.nikula(a)intel.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Matthew Wilcox <mawilcox(a)microsoft.com>
Signed-off-by: Jonathan Corbet <corbet(a)lwn.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/sphinx/kerneldoc.py | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/Documentation/sphinx/kerneldoc.py
+++ b/Documentation/sphinx/kerneldoc.py
@@ -36,8 +36,7 @@ import glob
from docutils import nodes, statemachine
from docutils.statemachine import ViewList
-from docutils.parsers.rst import directives
-from sphinx.util.compat import Directive
+from docutils.parsers.rst import directives, Directive
from sphinx.ext.autodoc import AutodocReporter
__version__ = '1.0'
Patches currently in stable-queue which might be from mawilcox(a)microsoft.com are
queue-4.14/documentation-sphinx-fix-directive-import-error.patch
This is a note to let you know that I've just added the patch titled
dm bufio: avoid false-positive Wmaybe-uninitialized warning
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:
dm-bufio-avoid-false-positive-wmaybe-uninitialized-warning.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 590347e4000356f55eb10b03ced2686bd74dab40 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 22 Feb 2018 16:56:16 +0100
Subject: dm bufio: avoid false-positive Wmaybe-uninitialized warning
From: Arnd Bergmann <arnd(a)arndb.de>
commit 590347e4000356f55eb10b03ced2686bd74dab40 upstream.
gcc-6.3 and earlier show a new warning after a seemingly unrelated
change to the arm64 PAGE_KERNEL definition:
In file included from drivers/md/dm-bufio.c:14:0:
drivers/md/dm-bufio.c: In function 'alloc_buffer':
include/linux/sched/mm.h:182:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized]
current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flags;
^
The same warning happened earlier on linux-3.18 for MIPS and I did a
workaround for that, but now it's come back.
gcc-7 and newer are apparently smart enough to figure this out, and
other architectures don't show it, so the best I could come up with is
to rework the caller slightly in a way that makes it obvious enough to
all arm64 compilers what is happening here.
Fixes: 41acec624087 ("arm64: kpti: Make use of nG dependent on arm64_kernel_unmapped_at_el0()")
Link: https://patchwork.kernel.org/patch/9692829/
Cc: stable(a)vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
[snitzer: moved declarations inside conditional, altered vmalloc return]
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/dm-bufio.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -386,9 +386,6 @@ static void __cache_size_refresh(void)
static void *alloc_buffer_data(struct dm_bufio_client *c, gfp_t gfp_mask,
enum data_mode *data_mode)
{
- unsigned noio_flag;
- void *ptr;
-
if (c->block_size <= DM_BUFIO_BLOCK_SIZE_SLAB_LIMIT) {
*data_mode = DATA_MODE_SLAB;
return kmem_cache_alloc(DM_BUFIO_CACHE(c), gfp_mask);
@@ -412,16 +409,15 @@ static void *alloc_buffer_data(struct dm
* all allocations done by this process (including pagetables) are done
* as if GFP_NOIO was specified.
*/
+ if (gfp_mask & __GFP_NORETRY) {
+ unsigned noio_flag = memalloc_noio_save();
+ void *ptr = __vmalloc(c->block_size, gfp_mask, PAGE_KERNEL);
- if (gfp_mask & __GFP_NORETRY)
- noio_flag = memalloc_noio_save();
-
- ptr = __vmalloc(c->block_size, gfp_mask, PAGE_KERNEL);
-
- if (gfp_mask & __GFP_NORETRY)
memalloc_noio_restore(noio_flag);
+ return ptr;
+ }
- return ptr;
+ return __vmalloc(c->block_size, gfp_mask, PAGE_KERNEL);
}
/*
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/dm-bufio-avoid-false-positive-wmaybe-uninitialized-warning.patch
This is a note to let you know that I've just added the patch titled
bug: use %pB in BUG and stack protector failure
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:
bug-use-pb-in-bug-and-stack-protector-failure.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 0862ca422b79cb5aa70823ee0f07f6b468f86070 Mon Sep 17 00:00:00 2001
From: Kees Cook <keescook(a)chromium.org>
Date: Fri, 9 Mar 2018 15:50:59 -0800
Subject: bug: use %pB in BUG and stack protector failure
From: Kees Cook <keescook(a)chromium.org>
commit 0862ca422b79cb5aa70823ee0f07f6b468f86070 upstream.
The BUG and stack protector reports were still using a raw %p. This
changes it to %pB for more meaningful output.
Link: http://lkml.kernel.org/r/20180301225704.GA34198@beast
Fixes: ad67b74d2469 ("printk: hash addresses printed with %p")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Richard Weinberger <richard.weinberger(a)gmail.com>,
Cc: <stable(a)vger.kernel.org>
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>
---
kernel/panic.c | 2 +-
lib/bug.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -595,7 +595,7 @@ EXPORT_SYMBOL(warn_slowpath_null);
*/
__visible void __stack_chk_fail(void)
{
- panic("stack-protector: Kernel stack is corrupted in: %p\n",
+ panic("stack-protector: Kernel stack is corrupted in: %pB\n",
__builtin_return_address(0));
}
EXPORT_SYMBOL(__stack_chk_fail);
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -191,7 +191,7 @@ enum bug_trap_type report_bug(unsigned l
if (file)
pr_crit("kernel BUG at %s:%u!\n", file, line);
else
- pr_crit("Kernel BUG at %p [verbose debug info unavailable]\n",
+ pr_crit("Kernel BUG at %pB [verbose debug info unavailable]\n",
(void *)bugaddr);
return BUG_TRAP_TYPE_BUG;
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.14/bug-use-pb-in-bug-and-stack-protector-failure.patch
queue-4.14/lib-bug.c-exclude-non-bug-warn-exceptions-from-report_bug.patch
This is a note to let you know that I've just added the patch titled
bcache: don't attach backing with duplicate UUID
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:
bcache-don-t-attach-backing-with-duplicate-uuid.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 86755b7a96faed57f910f9e6b8061e019ac1ec08 Mon Sep 17 00:00:00 2001
From: Michael Lyle <mlyle(a)lyle.org>
Date: Mon, 5 Mar 2018 13:41:55 -0800
Subject: bcache: don't attach backing with duplicate UUID
From: Michael Lyle <mlyle(a)lyle.org>
commit 86755b7a96faed57f910f9e6b8061e019ac1ec08 upstream.
This can happen e.g. during disk cloning.
This is an incomplete fix: it does not catch duplicate UUIDs earlier
when things are still unattached. It does not unregister the device.
Further changes to cope better with this are planned but conflict with
Coly's ongoing improvements to handling device errors. In the meantime,
one can manually stop the device after this has happened.
Attempts to attach a duplicate device result in:
[ 136.372404] loop: module loaded
[ 136.424461] bcache: register_bdev() registered backing device loop0
[ 136.424464] bcache: bch_cached_dev_attach() Tried to attach loop0 but duplicate UUID already attached
My test procedure is:
dd if=/dev/sdb1 of=imgfile bs=1024 count=262144
losetup -f imgfile
Signed-off-by: Michael Lyle <mlyle(a)lyle.org>
Reviewed-by: Tang Junhui <tang.junhui(a)zte.com.cn>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bcache/super.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -938,6 +938,7 @@ int bch_cached_dev_attach(struct cached_
uint32_t rtime = cpu_to_le32(get_seconds());
struct uuid_entry *u;
char buf[BDEVNAME_SIZE];
+ struct cached_dev *exist_dc, *t;
bdevname(dc->bdev, buf);
@@ -961,6 +962,16 @@ int bch_cached_dev_attach(struct cached_
return -EINVAL;
}
+ /* Check whether already attached */
+ list_for_each_entry_safe(exist_dc, t, &c->cached_devs, list) {
+ if (!memcmp(dc->sb.uuid, exist_dc->sb.uuid, 16)) {
+ pr_err("Tried to attach %s but duplicate UUID already attached",
+ buf);
+
+ return -EINVAL;
+ }
+ }
+
u = uuid_find(c, dc->sb.uuid);
if (u &&
Patches currently in stable-queue which might be from mlyle(a)lyle.org are
queue-4.14/bcache-fix-crashes-in-duplicate-cache-device-register.patch
queue-4.14/bcache-don-t-attach-backing-with-duplicate-uuid.patch
This is a note to let you know that I've just added the patch titled
arm64: mm: fix thinko in non-global page table attribute check
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:
arm64-mm-fix-thinko-in-non-global-page-table-attribute-check.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 753e8abc36b2c966caea075db0c845563c8a19bf Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Fri, 23 Feb 2018 18:04:48 +0000
Subject: arm64: mm: fix thinko in non-global page table attribute check
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
commit 753e8abc36b2c966caea075db0c845563c8a19bf upstream.
The routine pgattr_change_is_safe() was extended in commit 4e6020565596
("arm64: mm: Permit transitioning from Global to Non-Global without BBM")
to permit changing the nG attribute from not set to set, but did so in a
way that inadvertently disallows such changes if other permitted attribute
changes take place at the same time. So update the code to take this into
account.
Fixes: 4e6020565596 ("arm64: mm: Permit transitioning from Global to ...")
Cc: <stable(a)vger.kernel.org> # 4.14.x-
Acked-by: Mark Rutland <mark.rutland(a)arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier(a)arm.com>
Acked-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/mmu.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -107,7 +107,7 @@ static bool pgattr_change_is_safe(u64 ol
* The following mapping attributes may be updated in live
* kernel mappings without the need for break-before-make.
*/
- static const pteval_t mask = PTE_PXN | PTE_RDONLY | PTE_WRITE;
+ static const pteval_t mask = PTE_PXN | PTE_RDONLY | PTE_WRITE | PTE_NG;
/* creating or taking down mappings is always safe */
if (old == 0 || new == 0)
@@ -117,9 +117,9 @@ static bool pgattr_change_is_safe(u64 ol
if ((old | new) & PTE_CONT)
return false;
- /* Transitioning from Global to Non-Global is safe */
- if (((old ^ new) == PTE_NG) && (new & PTE_NG))
- return true;
+ /* Transitioning from Non-Global to Global is unsafe */
+ if (old & ~new & PTE_NG)
+ return false;
return ((old ^ new) & ~mask) == 0;
}
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.14/arm64-mm-fix-thinko-in-non-global-page-table-attribute-check.patch