This is a note to let you know that I've just added the patch titled
drm/amdgpu: add new device to use atpx quirk
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-add-new-device-to-use-atpx-quirk.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 6e59de2048eb375a9bfcd39461ef841cd2a78962 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Thu, 8 Feb 2018 17:46:01 +0800
Subject: drm/amdgpu: add new device to use atpx quirk
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 6e59de2048eb375a9bfcd39461ef841cd2a78962 upstream.
The affected system (0x0813) is pretty similar to another one (0x0812),
it also needs to use ATPX power control.
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.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/amdgpu/amdgpu_atpx_handler.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
@@ -568,6 +568,7 @@ static const struct amdgpu_px_quirk amdg
/* HG _PR3 doesn't seem to work on this A+A weston board */
{ 0x1002, 0x6900, 0x1002, 0x0124, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX },
+ { 0x1002, 0x6900, 0x1028, 0x0813, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0, 0, 0, 0, 0 },
};
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.9/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
queue-4.9/drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Add dpm quirk for Jet PRO (v2)
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-add-dpm-quirk-for-jet-pro-v2.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 f2e5262f75ecb40a6e56554e156a292ab9e1d1b7 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Tue, 21 Nov 2017 12:10:57 -0500
Subject: drm/amdgpu: Add dpm quirk for Jet PRO (v2)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Alex Deucher <alexander.deucher(a)amd.com>
commit f2e5262f75ecb40a6e56554e156a292ab9e1d1b7 upstream.
Fixes stability issues.
v2: clamp sclk to 600 Mhz
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103370
Acked-by: Christian König <christian.koenig(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/amdgpu/si_dpm.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -3507,6 +3507,11 @@ static void si_apply_state_adjust_rules(
max_sclk = 75000;
max_mclk = 80000;
}
+ if ((adev->pdev->revision == 0xC3) ||
+ (adev->pdev->device == 0x6665)) {
+ max_sclk = 60000;
+ max_mclk = 80000;
+ }
} else if (adev->asic_type == CHIP_OLAND) {
if ((adev->pdev->revision == 0xC7) ||
(adev->pdev->revision == 0x80) ||
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.9/drm-amdgpu-add-new-device-to-use-atpx-quirk.patch
queue-4.9/drm-amdgpu-add-dpm-quirk-for-jet-pro-v2.patch
queue-4.9/drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch
queue-4.9/drm-amdgpu-add-atpx-quirk-handling-v2.patch
This is a note to let you know that I've just added the patch titled
cfg80211: fix cfg80211_beacon_dup
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:
cfg80211-fix-cfg80211_beacon_dup.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 bee92d06157fc39d5d7836a061c7d41289a55797 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Fri, 2 Feb 2018 16:31:23 +0100
Subject: cfg80211: fix cfg80211_beacon_dup
From: Arnd Bergmann <arnd(a)arndb.de>
commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.
gcc-8 warns about some obviously incorrect code:
net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
>From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.
Cc: stable(a)vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2792,7 +2792,7 @@ cfg80211_beacon_dup(struct cfg80211_beac
}
if (beacon->probe_resp_len) {
new_beacon->probe_resp_len = beacon->probe_resp_len;
- beacon->probe_resp = pos;
+ new_beacon->probe_resp = pos;
memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);
pos += beacon->probe_resp_len;
}
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.9/cfg80211-fix-cfg80211_beacon_dup.patch
queue-4.9/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
arm64: Disable unhandled signal log messages by default
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:
arm64-disable-unhandled-signal-log-messages-by-default.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 5ee39a71fd89ab7240c5339d04161c44a8e03269 Mon Sep 17 00:00:00 2001
From: Michael Weiser <michael.weiser(a)gmx.de>
Date: Thu, 1 Feb 2018 23:13:38 +0100
Subject: arm64: Disable unhandled signal log messages by default
From: Michael Weiser <michael.weiser(a)gmx.de>
commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream.
aarch64 unhandled signal kernel messages are very verbose, suggesting
them to be more of a debugging aid:
sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
0x92000046, in sigsegv[400000+71000]
CPU: 1 PID: 33 Comm: sigsegv Tainted: G W 4.15.0-rc3+ #3
Hardware name: linux,dummy-virt (DT)
pstate: 60000000 (nZCv daif -PAN -UAO)
pc : 0x4003f4
lr : 0x4006bc
sp : 0000fffffe94a060
x29: 0000fffffe94a070 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 00000000004001b0
x23: 0000000000486ac8 x22: 00000000004001c8
x21: 0000000000000000 x20: 0000000000400be8
x19: 0000000000400b30 x18: 0000000000484728
x17: 000000000865ffc8 x16: 000000000000270f
x15: 00000000000000b0 x14: 0000000000000002
x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0008000020008008
x9 : 000000000000000f x8 : ffffffffffffffff
x7 : 0004000000000000 x6 : ffffffffffffffff
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
x1 : 000000000000000a x0 : 0000000000000000
Disable them by default, so they can be enabled using
/proc/sys/debug/exception-trace.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Michael Weiser <michael.weiser(a)gmx.de>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -50,7 +50,7 @@ static const char *handler[]= {
"Error"
};
-int show_unhandled_signals = 1;
+int show_unhandled_signals = 0;
/*
* Dump out the contents of some kernel memory nicely...
Patches currently in stable-queue which might be from michael.weiser(a)gmx.de are
queue-4.9/arm64-disable-unhandled-signal-log-messages-by-default.patch
This is a note to let you know that I've just added the patch titled
Add delay-init quirk for Corsair K70 RGB keyboards
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:
add-delay-init-quirk-for-corsair-k70-rgb-keyboards.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 7a1646d922577b5b48c0d222e03831141664bb59 Mon Sep 17 00:00:00 2001
From: Jack Stocker <jackstocker.93(a)gmail.com>
Date: Thu, 15 Feb 2018 18:24:10 +0000
Subject: Add delay-init quirk for Corsair K70 RGB keyboards
From: Jack Stocker <jackstocker.93(a)gmail.com>
commit 7a1646d922577b5b48c0d222e03831141664bb59 upstream.
Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.
Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
Signed-off-by: Jack Stocker <jackstocker.93(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -225,6 +225,9 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x1a0a, 0x0200), .driver_info =
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+ /* Corsair K70 RGB */
+ { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
Patches currently in stable-queue which might be from jackstocker.93(a)gmail.com are
queue-4.9/add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d61a5c1063515e855bedb1b81e20e50b0ac3541e Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sun, 11 Feb 2018 10:38:28 +0100
Subject: [PATCH] drm/nouveau: Fix deadlock on runtime suspend
nouveau's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.
The output poll worker meanwhile calls pm_runtime_get_sync() in
nouveau_connector_detect() which waits for the ongoing suspend to finish,
causing a deadlock.
Fix by not acquiring a runtime PM ref if nouveau_connector_detect() is
called in the output poll worker's context. This is safe because
the poll worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.
Other contexts calling nouveau_connector_detect() do require a runtime
PM ref, these comprise:
status_store() drm sysfs interface
->fill_modes drm callback
drm_fb_helper_probe_connector_modes()
drm_mode_getconnector()
nouveau_connector_hotplug()
nouveau_display_hpd_work()
nv17_tv_set_property()
Stack trace for posterity:
INFO: task kworker/0:1:58 blocked for more than 120 seconds.
Workqueue: events output_poll_execute [drm_kms_helper]
Call Trace:
schedule+0x28/0x80
rpm_resume+0x107/0x6e0
__pm_runtime_resume+0x47/0x70
nouveau_connector_detect+0x7e/0x4a0 [nouveau]
nouveau_connector_detect_lvds+0x132/0x180 [nouveau]
drm_helper_probe_detect_ctx+0x85/0xd0 [drm_kms_helper]
output_poll_execute+0x11e/0x1c0 [drm_kms_helper]
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
INFO: task kworker/0:2:252 blocked for more than 120 seconds.
Workqueue: pm pm_runtime_work
Call Trace:
schedule+0x28/0x80
schedule_timeout+0x1e3/0x370
wait_for_completion+0x123/0x190
flush_work+0x142/0x1c0
nouveau_pmops_runtime_suspend+0x7e/0xd0 [nouveau]
pci_pm_runtime_suspend+0x5c/0x180
vga_switcheroo_runtime_suspend+0x1e/0xa0
__rpm_callback+0xc1/0x200
rpm_callback+0x1f/0x70
rpm_suspend+0x13c/0x640
pm_runtime_work+0x6e/0x90
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
Bugzilla: https://bugs.archlinux.org/task/53497
Bugzilla: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870523
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388#c33
Fixes: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)")
Cc: stable(a)vger.kernel.org # v3.12+: 27d4ee03078a: workqueue: Allow retrieval of current task's work struct
Cc: stable(a)vger.kernel.org # v3.12+: 25c058ccaf2e: drm: Allow determining if current task is output poll worker
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Dave Airlie <airlied(a)redhat.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/b7d2cbb609a80f59ccabfdf479b9d…
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 69d6e61a01ec..6ed9cb053dfa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -570,9 +570,15 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
nv_connector->edid = NULL;
}
- ret = pm_runtime_get_sync(connector->dev->dev);
- if (ret < 0 && ret != -EACCES)
- return conn_status;
+ /* Outputs are only polled while runtime active, so acquiring a
+ * runtime PM ref here is unnecessary (and would deadlock upon
+ * runtime suspend because it waits for polling to finish).
+ */
+ if (!drm_kms_helper_is_poll_worker()) {
+ ret = pm_runtime_get_sync(connector->dev->dev);
+ if (ret < 0 && ret != -EACCES)
+ return conn_status;
+ }
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
@@ -647,8 +653,10 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
out:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return conn_status;
}
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d61a5c1063515e855bedb1b81e20e50b0ac3541e Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sun, 11 Feb 2018 10:38:28 +0100
Subject: [PATCH] drm/nouveau: Fix deadlock on runtime suspend
nouveau's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.
The output poll worker meanwhile calls pm_runtime_get_sync() in
nouveau_connector_detect() which waits for the ongoing suspend to finish,
causing a deadlock.
Fix by not acquiring a runtime PM ref if nouveau_connector_detect() is
called in the output poll worker's context. This is safe because
the poll worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.
Other contexts calling nouveau_connector_detect() do require a runtime
PM ref, these comprise:
status_store() drm sysfs interface
->fill_modes drm callback
drm_fb_helper_probe_connector_modes()
drm_mode_getconnector()
nouveau_connector_hotplug()
nouveau_display_hpd_work()
nv17_tv_set_property()
Stack trace for posterity:
INFO: task kworker/0:1:58 blocked for more than 120 seconds.
Workqueue: events output_poll_execute [drm_kms_helper]
Call Trace:
schedule+0x28/0x80
rpm_resume+0x107/0x6e0
__pm_runtime_resume+0x47/0x70
nouveau_connector_detect+0x7e/0x4a0 [nouveau]
nouveau_connector_detect_lvds+0x132/0x180 [nouveau]
drm_helper_probe_detect_ctx+0x85/0xd0 [drm_kms_helper]
output_poll_execute+0x11e/0x1c0 [drm_kms_helper]
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
INFO: task kworker/0:2:252 blocked for more than 120 seconds.
Workqueue: pm pm_runtime_work
Call Trace:
schedule+0x28/0x80
schedule_timeout+0x1e3/0x370
wait_for_completion+0x123/0x190
flush_work+0x142/0x1c0
nouveau_pmops_runtime_suspend+0x7e/0xd0 [nouveau]
pci_pm_runtime_suspend+0x5c/0x180
vga_switcheroo_runtime_suspend+0x1e/0xa0
__rpm_callback+0xc1/0x200
rpm_callback+0x1f/0x70
rpm_suspend+0x13c/0x640
pm_runtime_work+0x6e/0x90
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
Bugzilla: https://bugs.archlinux.org/task/53497
Bugzilla: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870523
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388#c33
Fixes: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)")
Cc: stable(a)vger.kernel.org # v3.12+: 27d4ee03078a: workqueue: Allow retrieval of current task's work struct
Cc: stable(a)vger.kernel.org # v3.12+: 25c058ccaf2e: drm: Allow determining if current task is output poll worker
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Dave Airlie <airlied(a)redhat.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/b7d2cbb609a80f59ccabfdf479b9d…
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 69d6e61a01ec..6ed9cb053dfa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -570,9 +570,15 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
nv_connector->edid = NULL;
}
- ret = pm_runtime_get_sync(connector->dev->dev);
- if (ret < 0 && ret != -EACCES)
- return conn_status;
+ /* Outputs are only polled while runtime active, so acquiring a
+ * runtime PM ref here is unnecessary (and would deadlock upon
+ * runtime suspend because it waits for polling to finish).
+ */
+ if (!drm_kms_helper_is_poll_worker()) {
+ ret = pm_runtime_get_sync(connector->dev->dev);
+ if (ret < 0 && ret != -EACCES)
+ return conn_status;
+ }
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
@@ -647,8 +653,10 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
out:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return conn_status;
}
This is a note to let you know that I've just added the patch titled
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
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:
x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.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 85c615eb52222bc5fab6c7190d146bc59fac289e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 20 Feb 2018 21:58:21 +0100
Subject: x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
From: Arnd Bergmann <arnd(a)arndb.de>
commit 85c615eb52222bc5fab6c7190d146bc59fac289e upstream.
GCC-8 shows a warning for the x86 oprofile code that copies per-CPU
data from CPU 0 to all other CPUs, which when building a non-SMP
kernel turns into a memcpy() with identical source and destination
pointers:
arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
memcpy(per_cpu(cpu_msrs, cpu).multiplex,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
per_cpu(cpu_msrs, 0).multiplex,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(struct op_msr) * model->num_virt_counters);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
I have analyzed a number of such warnings now: some are valid and the
GCC warning is welcome. Others turned out to be false-positives, and
GCC was changed to not warn about those any more. This is a corner case
that is a false-positive but the GCC developers feel it's better to keep
warning about it.
In this case, it seems best to work around it by telling GCC
a little more clearly that this code path is never hit with
an IS_ENABLED() configuration check.
Cc:stable as we also want old kernels to build cleanly with GCC-8.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Jessica Yu <jeyu(a)kernel.org>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Martin Sebor <msebor(a)gcc.gnu.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Robert Richter <rric(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: oprofile-list(a)lists.sf.net
Cc: stable(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/oprofile/nmi_int.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -471,7 +471,7 @@ static int nmi_setup(void)
goto fail;
for_each_possible_cpu(cpu) {
- if (!cpu)
+ if (!IS_ENABLED(CONFIG_SMP) || !cpu)
continue;
memcpy(per_cpu(cpu_msrs, cpu).counters,
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.4/cfg80211-fix-cfg80211_beacon_dup.patch
This is a note to let you know that I've just added the patch titled
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
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:
usb-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.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 17aa31f13cad25daa19d3f923323f552e87bc874 Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Mon, 5 Feb 2018 17:12:35 +0900
Subject: usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
commit 17aa31f13cad25daa19d3f923323f552e87bc874 upstream.
This fixes an issue that a gadget driver (usb_f_fs) is possible to
stop rx transactions after the usb-dmac is used because the following
functions missed to set/check the "running" flag.
- usbhsf_dma_prepare_pop_with_usb_dmac()
- usbhsf_dma_pop_done_with_usb_dmac()
So, if next transaction uses pio, the usbhsf_prepare_pop() can not
start the transaction because the "running" flag is 0.
Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
Cc: <stable(a)vger.kernel.org> # v3.19+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/renesas_usbhs/fifo.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -999,6 +999,10 @@ static int usbhsf_dma_prepare_pop_with_u
if ((uintptr_t)pkt->buf & (USBHS_USB_DMAC_XFER_SIZE - 1))
goto usbhsf_pio_prepare_pop;
+ /* return at this time if the pipe is running */
+ if (usbhs_pipe_is_running(pipe))
+ return 0;
+
usbhs_pipe_config_change_bfre(pipe, 1);
ret = usbhsf_fifo_select(pipe, fifo, 0);
@@ -1189,6 +1193,7 @@ static int usbhsf_dma_pop_done_with_usb_
usbhsf_fifo_clear(pipe, fifo);
pkt->actual = usbhs_dma_calc_received_size(pkt, chan, rcv_len);
+ usbhs_pipe_running(pipe, 0);
usbhsf_dma_stop(pipe, fifo);
usbhsf_dma_unmap(pkt);
usbhsf_fifo_unselect(pipe, pipe->fifo);
Patches currently in stable-queue which might be from yoshihiro.shimoda.uh(a)renesas.com are
queue-4.4/usb-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch
This is a note to let you know that I've just added the patch titled
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
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:
usb-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.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 46408ea558df13b110e0866b99624384a33bdeba Mon Sep 17 00:00:00 2001
From: AMAN DEEP <aman.deep(a)samsung.com>
Date: Thu, 8 Feb 2018 11:55:01 +0800
Subject: usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
From: AMAN DEEP <aman.deep(a)samsung.com>
commit 46408ea558df13b110e0866b99624384a33bdeba upstream.
There is a race condition between finish_unlinks->finish_urb() function
and usb_kill_urb() in ohci controller case. The finish_urb calls
spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call,
then if during this time, usb_kill_urb is called for another endpoint,
then new ed will be added to ed_rm_list at beginning for unlink, and
ed_rm_list will point to newly added.
When finish_urb() is completed in finish_unlinks() and ed->td_list
becomes empty as in below code (in finish_unlinks() function):
if (list_empty(&ed->td_list)) {
*last = ed->ed_next;
ed->ed_next = NULL;
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
*last = ed->ed_next;
ed->ed_next = NULL;
ed_schedule(ohci, ed);
}
The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next
and previously added ed by usb_kill_urb will be left unreferenced by
ed_rm_list. This causes usb_kill_urb() hang forever waiting for
finish_unlink to remove added ed from ed_rm_list.
The main reason for hang in this race condtion is addition and removal
of ed from ed_rm_list in the beginning during usb_kill_urb and later
last* is modified in finish_unlinks().
As suggested by Alan Stern, the solution for proper handling of
ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing
any URBs. Then at the end, we can add ed back to the list if necessary.
This properly handle the updated ohci->ed_rm_list in usb_kill_urb().
Fixes: 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies")
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
CC: <stable(a)vger.kernel.org>
Signed-off-by: Aman Deep <aman.deep(a)samsung.com>
Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ohci-q.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -1018,6 +1018,8 @@ skip_ed:
* have modified this list. normally it's just prepending
* entries (which we'd ignore), but paranoia won't hurt.
*/
+ *last = ed->ed_next;
+ ed->ed_next = NULL;
modified = 0;
/* unlink urbs as requested, but rescan the list after
@@ -1076,21 +1078,22 @@ rescan_this:
goto rescan_this;
/*
- * If no TDs are queued, take ED off the ed_rm_list.
+ * If no TDs are queued, ED is now idle.
* Otherwise, if the HC is running, reschedule.
- * If not, leave it on the list for further dequeues.
+ * If the HC isn't running, add ED back to the
+ * start of the list for later processing.
*/
if (list_empty(&ed->td_list)) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed->state = ED_IDLE;
list_del(&ed->in_use_list);
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed_schedule(ohci, ed);
} else {
- last = &ed->ed_next;
+ ed->ed_next = ohci->ed_rm_list;
+ ohci->ed_rm_list = ed;
+ /* Don't loop on the same ED */
+ if (last == &ohci->ed_rm_list)
+ last = &ed->ed_next;
}
if (modified)
Patches currently in stable-queue which might be from aman.deep(a)samsung.com are
queue-4.4/usb-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch
This is a note to let you know that I've just added the patch titled
usb: ldusb: add PIDs for new CASSY devices supported by this driver
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:
usb-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.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 52ad2bd8918158266fc88a05f95429b56b6a33c5 Mon Sep 17 00:00:00 2001
From: Karsten Koop <kkoop(a)ld-didactic.de>
Date: Fri, 9 Feb 2018 09:12:06 +0000
Subject: usb: ldusb: add PIDs for new CASSY devices supported by this driver
From: Karsten Koop <kkoop(a)ld-didactic.de>
commit 52ad2bd8918158266fc88a05f95429b56b6a33c5 upstream.
This patch adds support for new CASSY devices to the ldusb driver. The
PIDs are also added to the ignore list in hid-quirks.
Signed-off-by: Karsten Koop <kkoop(a)ld-didactic.de>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
drivers/hid/hid-ids.h | 3 +++
drivers/usb/misc/ldusb.c | 6 ++++++
3 files changed, 12 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2386,6 +2386,9 @@ static const struct hid_device_id hid_ig
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -570,6 +570,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043
#define USB_DEVICE_ID_LD_JWM 0x1080
#define USB_DEVICE_ID_LD_DMMP 0x1081
#define USB_DEVICE_ID_LD_UMIP 0x1090
--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -46,6 +46,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033 /* USB Product ID of Micro-CASSY Time (reserved) */
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035 /* USB Product ID of Micro-CASSY Temperature */
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038 /* USB Product ID of Micro-CASSY pH */
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040 /* USB Product ID of Power Analyser CASSY */
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042 /* USB Product ID of Converter Controller CASSY */
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043 /* USB Product ID of Machine Test CASSY */
#define USB_DEVICE_ID_LD_JWM 0x1080 /* USB Product ID of Joule and Wattmeter */
#define USB_DEVICE_ID_LD_DMMP 0x1081 /* USB Product ID of Digital Multimeter P (reserved) */
#define USB_DEVICE_ID_LD_UMIP 0x1090 /* USB Product ID of UMI P */
@@ -88,6 +91,9 @@ static const struct usb_device_id ld_usb
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
Patches currently in stable-queue which might be from kkoop(a)ld-didactic.de are
queue-4.4/usb-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Process all descriptors during bind
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:
usb-gadget-f_fs-process-all-descriptors-during-bind.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 6cf439e0d37463e42784271179c8a308fd7493c6 Mon Sep 17 00:00:00 2001
From: Jack Pham <jackp(a)codeaurora.org>
Date: Wed, 24 Jan 2018 00:11:53 -0800
Subject: usb: gadget: f_fs: Process all descriptors during bind
From: Jack Pham <jackp(a)codeaurora.org>
commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable(a)vger.kernel.org
Co-Developed-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Jack Pham <jackp(a)codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2756,10 +2756,8 @@ static int _ffs_func_bind(struct usb_con
struct ffs_data *ffs = func->ffs;
const int full = !!func->ffs->fs_descs_count;
- const int high = gadget_is_dualspeed(func->gadget) &&
- func->ffs->hs_descs_count;
- const int super = gadget_is_superspeed(func->gadget) &&
- func->ffs->ss_descs_count;
+ const int high = !!func->ffs->hs_descs_count;
+ const int super = !!func->ffs->ss_descs_count;
int fs_len, hs_len, ss_len, ret, i;
struct ffs_ep *eps_ptr;
Patches currently in stable-queue which might be from jackp(a)codeaurora.org are
queue-4.4/usb-gadget-f_fs-process-all-descriptors-during-bind.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: Set maxpacket size for ep0 IN
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:
usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.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 6180026341e852a250e1f97ebdcf71684a3c81b9 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:05 -0800
Subject: usb: dwc3: gadget: Set maxpacket size for ep0 IN
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.
There are 2 control endpoint structures for DWC3. However, the driver
only updates the OUT direction control endpoint structure during
ConnectDone event. DWC3 driver needs to update the endpoint max packet
size for control IN endpoint as well. If the max packet size is not
properly set, then the driver will incorrectly calculate the data
transfer size and fail to send ZLP for HS/FS 3-stage control read
transfer.
The fix is simply to update the max packet size for the ep0 IN direction
during ConnectDone event.
Cc: stable(a)vger.kernel.org
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2393,6 +2393,8 @@ static void dwc3_gadget_conndone_interru
break;
}
+ dwc->eps[1]->endpoint.maxpacket = dwc->gadget.ep0->maxpacket;
+
/* Enable USB2 LPM Capability */
if ((dwc->revision > DWC3_REVISION_194A)
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-4.4/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
This is a note to let you know that I've just added the patch titled
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
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:
scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.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 c39813652700f3df552b6557530f1e5f782dbe2f Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Date: Tue, 23 Jan 2018 20:11:32 -0600
Subject: scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.
The fcp_rsp_info structure as defined in the FC spec has an initial 3
bytes reserved field. The ibmvfc driver mistakenly defined this field as
4 bytes resulting in the rsp_code field being defined in what should be
the start of the second reserved field and thus always being reported as
zero by the driver.
Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a
single place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be
done in a followup patch.
Cc: <stable(a)vger.kernel.org>
Reported-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/ibmvscsi/ibmvfc.h
+++ b/drivers/scsi/ibmvscsi/ibmvfc.h
@@ -366,7 +366,7 @@ enum ibmvfc_fcp_rsp_info_codes {
};
struct ibmvfc_fcp_rsp_info {
- __be16 reserved;
+ u8 reserved[3];
u8 rsp_code;
u8 reserved2[4];
}__attribute__((packed, aligned (2)));
Patches currently in stable-queue which might be from tyreld(a)linux.vnet.ibm.com are
queue-4.4/scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
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:
irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.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 21ec30c0ef5234fb1039cc7c7737d885bf875a9e Mon Sep 17 00:00:00 2001
From: Shanker Donthineni <shankerd(a)codeaurora.org>
Date: Wed, 31 Jan 2018 18:03:42 -0600
Subject: irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
From: Shanker Donthineni <shankerd(a)codeaurora.org>
commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream.
A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient
for observability of memory accesses that occur before ICC_SGI1R_EL1
writes.
A DSB instruction ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.
Cc: stable(a)vger.kernel.org
Acked-by: Will Deacon <will.deacon(a)arm.com>,
Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -604,7 +604,7 @@ static void gic_raise_softirq(const stru
* Ensure that stores to Normal memory are visible to the
* other CPUs before issuing the IPI.
*/
- smp_wmb();
+ wmb();
for_each_cpu(cpu, mask) {
unsigned long cluster_id = cpu_logical_map(cpu) & ~0xffUL;
Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are
queue-4.4/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
This is a note to let you know that I've just added the patch titled
iio: buffer: check if a buffer has been set up when poll is called
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:
iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.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 4cd140bda6494543f1c1b0ccceceaa44b676eef6 Mon Sep 17 00:00:00 2001
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Date: Thu, 15 Feb 2018 15:02:53 +0100
Subject: iio: buffer: check if a buffer has been set up when poll is called
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream.
If no iio buffer has been set up and poll is called return 0.
Without this check there will be a null pointer dereference when
calling poll on a iio driver without an iio buffer.
Cc: stable(a)vger.kernel.org
Signed-off-by: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/industrialio-buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -174,7 +174,7 @@ unsigned int iio_buffer_poll(struct file
struct iio_dev *indio_dev = filp->private_data;
struct iio_buffer *rb = indio_dev->buffer;
- if (!indio_dev->info)
+ if (!indio_dev->info || rb == NULL)
return 0;
poll_wait(filp, &rb->pollq, wait);
Patches currently in stable-queue which might be from stefan.windfeldt(a)axis.com are
queue-4.4/iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch
This is a note to let you know that I've just added the patch titled
iio: adis_lib: Initialize trigger before requesting interrupt
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:
iio-adis_lib-initialize-trigger-before-requesting-interrupt.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 f027e0b3a774e10302207e91d304bbf99e3a8b36 Mon Sep 17 00:00:00 2001
From: Lars-Peter Clausen <lars(a)metafoo.de>
Date: Wed, 14 Feb 2018 15:43:00 +0100
Subject: iio: adis_lib: Initialize trigger before requesting interrupt
From: Lars-Peter Clausen <lars(a)metafoo.de>
commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream.
The adis_probe_trigger() creates a new IIO trigger and requests an
interrupt associated with the trigger. The interrupt uses the generic
iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
Currently the driver initializes some fields of the trigger structure after
the interrupt has been requested. But an interrupt can fire as soon as it
has been requested. This opens up a race condition.
iio_trigger_generic_data_rdy_poll() will access the trigger data structure
and dereference the ops field. If the ops field is not yet initialized this
will result in a NULL pointer deref.
It is not expected that the device generates an interrupt at this point, so
typically this issue did not surface unless e.g. due to a hardware
misconfiguration (wrong interrupt number, wrong polarity, etc.).
But some newer devices from the ADIS family start to generate periodic
interrupts in their power-on reset configuration and unfortunately the
interrupt can not be masked in the device. This makes the race condition
much more visible and the following crash has been observed occasionally
when booting a system using the ADIS16460.
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c0004000
[00000008] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
Hardware name: Xilinx Zynq Platform
task: ef04f640 task.stack: ef050000
PC is at iio_trigger_notify_done+0x30/0x68
LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
pc : [<c042d868>] lr : [<c042d924>] psr: 60000193
sp : ef051bb8 ip : 00000000 fp : ef106400
r10: c081d80a r9 : ef3bfa00 r8 : 00000087
r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 18c5387d Table: 0000404a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xef050210)
[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
To fix this make sure that the trigger is fully initialized before
requesting the interrupt.
Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library")
Reported-by: Robin Getz <Robin.Getz(a)analog.com>
Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/imu/adis_trigger.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/iio/imu/adis_trigger.c
+++ b/drivers/iio/imu/adis_trigger.c
@@ -47,6 +47,10 @@ int adis_probe_trigger(struct adis *adis
if (adis->trig == NULL)
return -ENOMEM;
+ adis->trig->dev.parent = &adis->spi->dev;
+ adis->trig->ops = &adis_trigger_ops;
+ iio_trigger_set_drvdata(adis->trig, adis);
+
ret = request_irq(adis->spi->irq,
&iio_trigger_generic_data_rdy_poll,
IRQF_TRIGGER_RISING,
@@ -55,9 +59,6 @@ int adis_probe_trigger(struct adis *adis
if (ret)
goto error_free_trig;
- adis->trig->dev.parent = &adis->spi->dev;
- adis->trig->ops = &adis_trigger_ops;
- iio_trigger_set_drvdata(adis->trig, adis);
ret = iio_trigger_register(adis->trig);
indio_dev->trig = iio_trigger_get(adis->trig);
Patches currently in stable-queue which might be from lars(a)metafoo.de are
queue-4.4/iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch
This is a note to let you know that I've just added the patch titled
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
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:
drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.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 06998a756a3865817b87a129a7e5d5bb66dc1ec3 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Sun, 18 Feb 2018 16:53:59 +0800
Subject: drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 06998a756a3865817b87a129a7e5d5bb66dc1ec3 upstream.
Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display
AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support
6bpc instead of 8 bpc.
Hence, use 6 bpc quirk for this panel.
Fixes: 196f954e2509 ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"")
BugLink: https://bugs.launchpad.net/bugs/1749420
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de(a)gmail.com>
Cc: <stable(a)vger.kernel.org> # v4.8+
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180218085359.7817-1-kai.hen…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -106,6 +106,9 @@ static struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
+ /* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
+ { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.4/drm-edid-add-6-bpc-quirk-for-cpt-panel-in-asus-ux303la.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
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:
drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.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 458d876eb869d5a88b53074c6c271b8b9adc0f07 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Mon, 22 Jan 2018 23:13:32 -0500
Subject: drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
From: Alex Deucher <alexander.deucher(a)amd.com>
commit 458d876eb869d5a88b53074c6c271b8b9adc0f07 upstream.
We only support vga_switcheroo and runtime pm on PX/HG systems
so forcing runpm to 1 doesn't do anything useful anyway.
Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so
that the cleanup path is correct as well. This mirrors what
radeon does as well.
v2: rework the patch originally sent by Lukas (Alex)
Acked-by: Lukas Wunner <lukas(a)wunner.de>
Reported-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de> (v1)
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1467,8 +1467,6 @@ int amdgpu_device_init(struct amdgpu_dev
* ignore it */
vga_client_register(adev->pdev, adev, NULL, amdgpu_vga_set_decode);
- if (amdgpu_runtime_pm == 1)
- runtime = true;
if (amdgpu_device_is_px(ddev))
runtime = true;
vga_switcheroo_register_client(adev->pdev, &amdgpu_switcheroo_ops, runtime);
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.4/drm-amdgpu-avoid-leaking-pm-domain-on-driver-unbind-v2.patch
This is a note to let you know that I've just added the patch titled
cfg80211: fix cfg80211_beacon_dup
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:
cfg80211-fix-cfg80211_beacon_dup.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 bee92d06157fc39d5d7836a061c7d41289a55797 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Fri, 2 Feb 2018 16:31:23 +0100
Subject: cfg80211: fix cfg80211_beacon_dup
From: Arnd Bergmann <arnd(a)arndb.de>
commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.
gcc-8 warns about some obviously incorrect code:
net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
>From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.
Cc: stable(a)vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2877,7 +2877,7 @@ cfg80211_beacon_dup(struct cfg80211_beac
}
if (beacon->probe_resp_len) {
new_beacon->probe_resp_len = beacon->probe_resp_len;
- beacon->probe_resp = pos;
+ new_beacon->probe_resp = pos;
memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);
pos += beacon->probe_resp_len;
}
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.4/cfg80211-fix-cfg80211_beacon_dup.patch
This is a note to let you know that I've just added the patch titled
arm64: Disable unhandled signal log messages by default
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:
arm64-disable-unhandled-signal-log-messages-by-default.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 5ee39a71fd89ab7240c5339d04161c44a8e03269 Mon Sep 17 00:00:00 2001
From: Michael Weiser <michael.weiser(a)gmx.de>
Date: Thu, 1 Feb 2018 23:13:38 +0100
Subject: arm64: Disable unhandled signal log messages by default
From: Michael Weiser <michael.weiser(a)gmx.de>
commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream.
aarch64 unhandled signal kernel messages are very verbose, suggesting
them to be more of a debugging aid:
sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
0x92000046, in sigsegv[400000+71000]
CPU: 1 PID: 33 Comm: sigsegv Tainted: G W 4.15.0-rc3+ #3
Hardware name: linux,dummy-virt (DT)
pstate: 60000000 (nZCv daif -PAN -UAO)
pc : 0x4003f4
lr : 0x4006bc
sp : 0000fffffe94a060
x29: 0000fffffe94a070 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 00000000004001b0
x23: 0000000000486ac8 x22: 00000000004001c8
x21: 0000000000000000 x20: 0000000000400be8
x19: 0000000000400b30 x18: 0000000000484728
x17: 000000000865ffc8 x16: 000000000000270f
x15: 00000000000000b0 x14: 0000000000000002
x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0008000020008008
x9 : 000000000000000f x8 : ffffffffffffffff
x7 : 0004000000000000 x6 : ffffffffffffffff
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
x1 : 000000000000000a x0 : 0000000000000000
Disable them by default, so they can be enabled using
/proc/sys/debug/exception-trace.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Michael Weiser <michael.weiser(a)gmx.de>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -49,7 +49,7 @@ static const char *handler[]= {
"Error"
};
-int show_unhandled_signals = 1;
+int show_unhandled_signals = 0;
/*
* Dump out the contents of some memory nicely...
Patches currently in stable-queue which might be from michael.weiser(a)gmx.de are
queue-4.4/arm64-disable-unhandled-signal-log-messages-by-default.patch
This is a note to let you know that I've just added the patch titled
Add delay-init quirk for Corsair K70 RGB keyboards
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:
add-delay-init-quirk-for-corsair-k70-rgb-keyboards.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 7a1646d922577b5b48c0d222e03831141664bb59 Mon Sep 17 00:00:00 2001
From: Jack Stocker <jackstocker.93(a)gmail.com>
Date: Thu, 15 Feb 2018 18:24:10 +0000
Subject: Add delay-init quirk for Corsair K70 RGB keyboards
From: Jack Stocker <jackstocker.93(a)gmail.com>
commit 7a1646d922577b5b48c0d222e03831141664bb59 upstream.
Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.
Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
Signed-off-by: Jack Stocker <jackstocker.93(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -225,6 +225,9 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x1a0a, 0x0200), .driver_info =
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+ /* Corsair K70 RGB */
+ { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
Patches currently in stable-queue which might be from jackstocker.93(a)gmail.com are
queue-4.4/add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch
This is a note to let you know that I've just added the patch titled
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
to the 3.18-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:
x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
and it can be found in the queue-3.18 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 85c615eb52222bc5fab6c7190d146bc59fac289e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 20 Feb 2018 21:58:21 +0100
Subject: x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
From: Arnd Bergmann <arnd(a)arndb.de>
commit 85c615eb52222bc5fab6c7190d146bc59fac289e upstream.
GCC-8 shows a warning for the x86 oprofile code that copies per-CPU
data from CPU 0 to all other CPUs, which when building a non-SMP
kernel turns into a memcpy() with identical source and destination
pointers:
arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
memcpy(per_cpu(cpu_msrs, cpu).multiplex,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
per_cpu(cpu_msrs, 0).multiplex,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(struct op_msr) * model->num_virt_counters);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
I have analyzed a number of such warnings now: some are valid and the
GCC warning is welcome. Others turned out to be false-positives, and
GCC was changed to not warn about those any more. This is a corner case
that is a false-positive but the GCC developers feel it's better to keep
warning about it.
In this case, it seems best to work around it by telling GCC
a little more clearly that this code path is never hit with
an IS_ENABLED() configuration check.
Cc:stable as we also want old kernels to build cleanly with GCC-8.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Jessica Yu <jeyu(a)kernel.org>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Martin Sebor <msebor(a)gcc.gnu.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Robert Richter <rric(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: oprofile-list(a)lists.sf.net
Cc: stable(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/oprofile/nmi_int.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -471,7 +471,7 @@ static int nmi_setup(void)
goto fail;
for_each_possible_cpu(cpu) {
- if (!cpu)
+ if (!IS_ENABLED(CONFIG_SMP) || !cpu)
continue;
memcpy(per_cpu(cpu_msrs, cpu).counters,
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-3.18/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-3.18/cfg80211-fix-cfg80211_beacon_dup.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Process all descriptors during bind
to the 3.18-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:
usb-gadget-f_fs-process-all-descriptors-during-bind.patch
and it can be found in the queue-3.18 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 6cf439e0d37463e42784271179c8a308fd7493c6 Mon Sep 17 00:00:00 2001
From: Jack Pham <jackp(a)codeaurora.org>
Date: Wed, 24 Jan 2018 00:11:53 -0800
Subject: usb: gadget: f_fs: Process all descriptors during bind
From: Jack Pham <jackp(a)codeaurora.org>
commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable(a)vger.kernel.org
Co-Developed-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Jack Pham <jackp(a)codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2727,10 +2727,8 @@ static int _ffs_func_bind(struct usb_con
struct ffs_data *ffs = func->ffs;
const int full = !!func->ffs->fs_descs_count;
- const int high = gadget_is_dualspeed(func->gadget) &&
- func->ffs->hs_descs_count;
- const int super = gadget_is_superspeed(func->gadget) &&
- func->ffs->ss_descs_count;
+ const int high = !!func->ffs->hs_descs_count;
+ const int super = !!func->ffs->ss_descs_count;
int fs_len, hs_len, ss_len, ret, i;
Patches currently in stable-queue which might be from jackp(a)codeaurora.org are
queue-3.18/usb-gadget-f_fs-process-all-descriptors-during-bind.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: Set maxpacket size for ep0 IN
to the 3.18-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:
usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
and it can be found in the queue-3.18 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 6180026341e852a250e1f97ebdcf71684a3c81b9 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:05 -0800
Subject: usb: dwc3: gadget: Set maxpacket size for ep0 IN
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.
There are 2 control endpoint structures for DWC3. However, the driver
only updates the OUT direction control endpoint structure during
ConnectDone event. DWC3 driver needs to update the endpoint max packet
size for control IN endpoint as well. If the max packet size is not
properly set, then the driver will incorrectly calculate the data
transfer size and fail to send ZLP for HS/FS 3-stage control read
transfer.
The fix is simply to update the max packet size for the ep0 IN direction
during ConnectDone event.
Cc: stable(a)vger.kernel.org
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2345,6 +2345,8 @@ static void dwc3_gadget_conndone_interru
break;
}
+ dwc->eps[1]->endpoint.maxpacket = dwc->gadget.ep0->maxpacket;
+
/* Enable USB2 LPM Capability */
if ((dwc->revision > DWC3_REVISION_194A)
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-3.18/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
This is a note to let you know that I've just added the patch titled
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
to the 3.18-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:
scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
and it can be found in the queue-3.18 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 c39813652700f3df552b6557530f1e5f782dbe2f Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Date: Tue, 23 Jan 2018 20:11:32 -0600
Subject: scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.
The fcp_rsp_info structure as defined in the FC spec has an initial 3
bytes reserved field. The ibmvfc driver mistakenly defined this field as
4 bytes resulting in the rsp_code field being defined in what should be
the start of the second reserved field and thus always being reported as
zero by the driver.
Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a
single place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be
done in a followup patch.
Cc: <stable(a)vger.kernel.org>
Reported-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/ibmvscsi/ibmvfc.h
+++ b/drivers/scsi/ibmvscsi/ibmvfc.h
@@ -366,7 +366,7 @@ enum ibmvfc_fcp_rsp_info_codes {
};
struct ibmvfc_fcp_rsp_info {
- __be16 reserved;
+ u8 reserved[3];
u8 rsp_code;
u8 reserved2[4];
}__attribute__((packed, aligned (2)));
Patches currently in stable-queue which might be from tyreld(a)linux.vnet.ibm.com are
queue-3.18/scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
to the 3.18-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:
irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
and it can be found in the queue-3.18 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 21ec30c0ef5234fb1039cc7c7737d885bf875a9e Mon Sep 17 00:00:00 2001
From: Shanker Donthineni <shankerd(a)codeaurora.org>
Date: Wed, 31 Jan 2018 18:03:42 -0600
Subject: irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
From: Shanker Donthineni <shankerd(a)codeaurora.org>
commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream.
A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient
for observability of memory accesses that occur before ICC_SGI1R_EL1
writes.
A DSB instruction ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.
Cc: stable(a)vger.kernel.org
Acked-by: Will Deacon <will.deacon(a)arm.com>,
Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -503,7 +503,7 @@ static void gic_raise_softirq(const stru
* Ensure that stores to Normal memory are visible to the
* other CPUs before issuing the IPI.
*/
- smp_wmb();
+ wmb();
for_each_cpu_mask(cpu, *mask) {
u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are
queue-3.18/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
This is a note to let you know that I've just added the patch titled
iio: buffer: check if a buffer has been set up when poll is called
to the 3.18-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:
iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch
and it can be found in the queue-3.18 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 4cd140bda6494543f1c1b0ccceceaa44b676eef6 Mon Sep 17 00:00:00 2001
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Date: Thu, 15 Feb 2018 15:02:53 +0100
Subject: iio: buffer: check if a buffer has been set up when poll is called
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream.
If no iio buffer has been set up and poll is called return 0.
Without this check there will be a null pointer dereference when
calling poll on a iio driver without an iio buffer.
Cc: stable(a)vger.kernel.org
Signed-off-by: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/industrialio-buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -92,7 +92,7 @@ unsigned int iio_buffer_poll(struct file
struct iio_dev *indio_dev = filp->private_data;
struct iio_buffer *rb = indio_dev->buffer;
- if (!indio_dev->info)
+ if (!indio_dev->info || rb == NULL)
return 0;
poll_wait(filp, &rb->pollq, wait);
Patches currently in stable-queue which might be from stefan.windfeldt(a)axis.com are
queue-3.18/iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch
This is a note to let you know that I've just added the patch titled
iio: adis_lib: Initialize trigger before requesting interrupt
to the 3.18-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:
iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch
and it can be found in the queue-3.18 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 f027e0b3a774e10302207e91d304bbf99e3a8b36 Mon Sep 17 00:00:00 2001
From: Lars-Peter Clausen <lars(a)metafoo.de>
Date: Wed, 14 Feb 2018 15:43:00 +0100
Subject: iio: adis_lib: Initialize trigger before requesting interrupt
From: Lars-Peter Clausen <lars(a)metafoo.de>
commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream.
The adis_probe_trigger() creates a new IIO trigger and requests an
interrupt associated with the trigger. The interrupt uses the generic
iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
Currently the driver initializes some fields of the trigger structure after
the interrupt has been requested. But an interrupt can fire as soon as it
has been requested. This opens up a race condition.
iio_trigger_generic_data_rdy_poll() will access the trigger data structure
and dereference the ops field. If the ops field is not yet initialized this
will result in a NULL pointer deref.
It is not expected that the device generates an interrupt at this point, so
typically this issue did not surface unless e.g. due to a hardware
misconfiguration (wrong interrupt number, wrong polarity, etc.).
But some newer devices from the ADIS family start to generate periodic
interrupts in their power-on reset configuration and unfortunately the
interrupt can not be masked in the device. This makes the race condition
much more visible and the following crash has been observed occasionally
when booting a system using the ADIS16460.
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c0004000
[00000008] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
Hardware name: Xilinx Zynq Platform
task: ef04f640 task.stack: ef050000
PC is at iio_trigger_notify_done+0x30/0x68
LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
pc : [<c042d868>] lr : [<c042d924>] psr: 60000193
sp : ef051bb8 ip : 00000000 fp : ef106400
r10: c081d80a r9 : ef3bfa00 r8 : 00000087
r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 18c5387d Table: 0000404a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xef050210)
[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
To fix this make sure that the trigger is fully initialized before
requesting the interrupt.
Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library")
Reported-by: Robin Getz <Robin.Getz(a)analog.com>
Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/imu/adis_trigger.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/iio/imu/adis_trigger.c
+++ b/drivers/iio/imu/adis_trigger.c
@@ -47,6 +47,10 @@ int adis_probe_trigger(struct adis *adis
if (adis->trig == NULL)
return -ENOMEM;
+ adis->trig->dev.parent = &adis->spi->dev;
+ adis->trig->ops = &adis_trigger_ops;
+ iio_trigger_set_drvdata(adis->trig, adis);
+
ret = request_irq(adis->spi->irq,
&iio_trigger_generic_data_rdy_poll,
IRQF_TRIGGER_RISING,
@@ -55,9 +59,6 @@ int adis_probe_trigger(struct adis *adis
if (ret)
goto error_free_trig;
- adis->trig->dev.parent = &adis->spi->dev;
- adis->trig->ops = &adis_trigger_ops;
- iio_trigger_set_drvdata(adis->trig, adis);
ret = iio_trigger_register(adis->trig);
indio_dev->trig = iio_trigger_get(adis->trig);
Patches currently in stable-queue which might be from lars(a)metafoo.de are
queue-3.18/iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch
This is a note to let you know that I've just added the patch titled
cfg80211: fix cfg80211_beacon_dup
to the 3.18-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:
cfg80211-fix-cfg80211_beacon_dup.patch
and it can be found in the queue-3.18 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 bee92d06157fc39d5d7836a061c7d41289a55797 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Fri, 2 Feb 2018 16:31:23 +0100
Subject: cfg80211: fix cfg80211_beacon_dup
From: Arnd Bergmann <arnd(a)arndb.de>
commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.
gcc-8 warns about some obviously incorrect code:
net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
>From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.
Cc: stable(a)vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2769,7 +2769,7 @@ cfg80211_beacon_dup(struct cfg80211_beac
}
if (beacon->probe_resp_len) {
new_beacon->probe_resp_len = beacon->probe_resp_len;
- beacon->probe_resp = pos;
+ new_beacon->probe_resp = pos;
memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);
pos += beacon->probe_resp_len;
}
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-3.18/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-3.18/cfg80211-fix-cfg80211_beacon_dup.patch
This is a note to let you know that I've just added the patch titled
arm64: Disable unhandled signal log messages by default
to the 3.18-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-disable-unhandled-signal-log-messages-by-default.patch
and it can be found in the queue-3.18 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 5ee39a71fd89ab7240c5339d04161c44a8e03269 Mon Sep 17 00:00:00 2001
From: Michael Weiser <michael.weiser(a)gmx.de>
Date: Thu, 1 Feb 2018 23:13:38 +0100
Subject: arm64: Disable unhandled signal log messages by default
From: Michael Weiser <michael.weiser(a)gmx.de>
commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream.
aarch64 unhandled signal kernel messages are very verbose, suggesting
them to be more of a debugging aid:
sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
0x92000046, in sigsegv[400000+71000]
CPU: 1 PID: 33 Comm: sigsegv Tainted: G W 4.15.0-rc3+ #3
Hardware name: linux,dummy-virt (DT)
pstate: 60000000 (nZCv daif -PAN -UAO)
pc : 0x4003f4
lr : 0x4006bc
sp : 0000fffffe94a060
x29: 0000fffffe94a070 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 00000000004001b0
x23: 0000000000486ac8 x22: 00000000004001c8
x21: 0000000000000000 x20: 0000000000400be8
x19: 0000000000400b30 x18: 0000000000484728
x17: 000000000865ffc8 x16: 000000000000270f
x15: 00000000000000b0 x14: 0000000000000002
x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0008000020008008
x9 : 000000000000000f x8 : ffffffffffffffff
x7 : 0004000000000000 x6 : ffffffffffffffff
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
x1 : 000000000000000a x0 : 0000000000000000
Disable them by default, so they can be enabled using
/proc/sys/debug/exception-trace.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Michael Weiser <michael.weiser(a)gmx.de>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -45,7 +45,7 @@ static const char *handler[]= {
"Error"
};
-int show_unhandled_signals = 1;
+int show_unhandled_signals = 0;
/*
* Dump out the contents of some memory nicely...
Patches currently in stable-queue which might be from michael.weiser(a)gmx.de are
queue-3.18/arm64-disable-unhandled-signal-log-messages-by-default.patch
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5ba4fa35d3d6a60fa5b669b319e2a95d5e0b6e7a Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Wed, 17 Jan 2018 09:07:29 -0500
Subject: [PATCH] drm/amdgpu: only check for ECC on Vega10
RV doesn't support it.
Reviewed-by: Junwei Zhang <Jerry.Zhang(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index eb8b1bb66389..2719937e09d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -634,14 +634,16 @@ static int gmc_v9_0_late_init(void *handle)
for(i = 0; i < AMDGPU_MAX_VMHUBS; ++i)
BUG_ON(vm_inv_eng[i] > 16);
- r = gmc_v9_0_ecc_available(adev);
- if (r == 1) {
- DRM_INFO("ECC is active.\n");
- } else if (r == 0) {
- DRM_INFO("ECC is not present.\n");
- } else {
- DRM_ERROR("gmc_v9_0_ecc_available() failed. r: %d\n", r);
- return r;
+ if (adev->asic_type == CHIP_VEGA10) {
+ r = gmc_v9_0_ecc_available(adev);
+ if (r == 1) {
+ DRM_INFO("ECC is active.\n");
+ } else if (r == 0) {
+ DRM_INFO("ECC is not present.\n");
+ } else {
+ DRM_ERROR("gmc_v9_0_ecc_available() failed. r: %d\n", r);
+ return r;
+ }
}
return amdgpu_irq_get(adev, &adev->mc.vm_fault, 0);
Changes since v2 [1]:
* Fix yet more compile breakage in the FS_DAX=n and DEV_DAX=y case.
(0day robot)
[1]: https://lists.01.org/pipermail/linux-nvdimm/2018-February/014046.html
---
The vfio interface, like RDMA, wants to setup long term (indefinite)
pins of the pages backing an address range so that a guest or userspace
driver can perform DMA to the with physical address. Given that this
pinning may lead to filesystem operations deadlocking in the
filesystem-dax case, the pinning request needs to be rejected.
The longer term fix for vfio, RDMA, and any other long term pin user, is
to provide a 'pin with lease' mechanism. Similar to the leases that are
hold for pNFS RDMA layouts, this userspace lease gives the kernel a way
to notify userspace that the block layout of the file is changing and
the kernel is revoking access to pinned pages.
---
Dan Williams (6):
dax: fix vma_is_fsdax() helper
dax: fix dax_mapping() definition in the FS_DAX=n + DEV_DAX=y case
xfs, dax: introduce IS_FSDAX()
dax: fix S_DAX definition
dax: short circuit vma_is_fsdax() in the CONFIG_FS_DAX=n case
vfio: disable filesystem-dax page pinning
drivers/vfio/vfio_iommu_type1.c | 18 +++++++++++++++---
fs/xfs/xfs_file.c | 14 +++++++-------
fs/xfs/xfs_ioctl.c | 4 ++--
fs/xfs/xfs_iomap.c | 6 +++---
fs/xfs/xfs_reflink.c | 2 +-
include/linux/dax.h | 9 ++++++---
include/linux/fs.h | 8 ++++++--
7 files changed, 40 insertions(+), 21 deletions(-)
The patch below does not apply to the 4.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5ba4fa35d3d6a60fa5b669b319e2a95d5e0b6e7a Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Wed, 17 Jan 2018 09:07:29 -0500
Subject: [PATCH] drm/amdgpu: only check for ECC on Vega10
RV doesn't support it.
Reviewed-by: Junwei Zhang <Jerry.Zhang(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index eb8b1bb66389..2719937e09d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -634,14 +634,16 @@ static int gmc_v9_0_late_init(void *handle)
for(i = 0; i < AMDGPU_MAX_VMHUBS; ++i)
BUG_ON(vm_inv_eng[i] > 16);
- r = gmc_v9_0_ecc_available(adev);
- if (r == 1) {
- DRM_INFO("ECC is active.\n");
- } else if (r == 0) {
- DRM_INFO("ECC is not present.\n");
- } else {
- DRM_ERROR("gmc_v9_0_ecc_available() failed. r: %d\n", r);
- return r;
+ if (adev->asic_type == CHIP_VEGA10) {
+ r = gmc_v9_0_ecc_available(adev);
+ if (r == 1) {
+ DRM_INFO("ECC is active.\n");
+ } else if (r == 0) {
+ DRM_INFO("ECC is not present.\n");
+ } else {
+ DRM_ERROR("gmc_v9_0_ecc_available() failed. r: %d\n", r);
+ return r;
+ }
}
return amdgpu_irq_get(adev, &adev->mc.vm_fault, 0);
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 4c63abb203db9cf23c746dcbcc64883e08977776 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig(a)amd.com>
Date: Tue, 16 Jan 2018 11:00:12 +0100
Subject: [PATCH] drm/amdgpu: fix typo in amdgpu_vce_validate_bo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Otherwise buffer placement is very restrictive and might fail.
Fixes: "drm/amdgpu: fix VCE buffer placement restrictions v2"
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Reported-by: Deng, Emily <Emily.Deng(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 55a726a322e3..d274ae535530 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -585,8 +585,8 @@ static int amdgpu_vce_validate_bo(struct amdgpu_cs_parser *p, uint32_t ib_idx,
for (i = 0; i < bo->placement.num_placement; ++i) {
bo->placements[i].fpfn = max(bo->placements[i].fpfn, fpfn);
- bo->placements[i].lpfn = bo->placements[i].fpfn ?
- min(bo->placements[i].fpfn, lpfn) : lpfn;
+ bo->placements[i].lpfn = bo->placements[i].lpfn ?
+ min(bo->placements[i].lpfn, lpfn) : lpfn;
}
return ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
}
The patch below does not apply to the 4.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 4c63abb203db9cf23c746dcbcc64883e08977776 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig(a)amd.com>
Date: Tue, 16 Jan 2018 11:00:12 +0100
Subject: [PATCH] drm/amdgpu: fix typo in amdgpu_vce_validate_bo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Otherwise buffer placement is very restrictive and might fail.
Fixes: "drm/amdgpu: fix VCE buffer placement restrictions v2"
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Reported-by: Deng, Emily <Emily.Deng(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 55a726a322e3..d274ae535530 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -585,8 +585,8 @@ static int amdgpu_vce_validate_bo(struct amdgpu_cs_parser *p, uint32_t ib_idx,
for (i = 0; i < bo->placement.num_placement; ++i) {
bo->placements[i].fpfn = max(bo->placements[i].fpfn, fpfn);
- bo->placements[i].lpfn = bo->placements[i].fpfn ?
- min(bo->placements[i].fpfn, lpfn) : lpfn;
+ bo->placements[i].lpfn = bo->placements[i].lpfn ?
+ min(bo->placements[i].lpfn, lpfn) : lpfn;
}
return ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
}
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 57ad33a307bf85cafda3a77c03a555c9f9ee4139 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Tue, 19 Dec 2017 09:52:31 -0500
Subject: [PATCH] drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on
tonga/fiji
We only support SR-IOV on tonga/fiji. Don't check this register
on other VI parts.
Fixes: 048765ad5af7c89 (amdgpu: fix asic initialization for virtualized environments (v2))
Reviewed-by: Xiangliang Yu <Xiangliang.Yu(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index d9bb26322850..c59b37365e4d 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -449,14 +449,19 @@ static bool vi_read_bios_from_rom(struct amdgpu_device *adev,
static void vi_detect_hw_virtualization(struct amdgpu_device *adev)
{
- uint32_t reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
- /* bit0: 0 means pf and 1 means vf */
- /* bit31: 0 means disable IOV and 1 means enable */
- if (reg & 1)
- adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
-
- if (reg & 0x80000000)
- adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
+ uint32_t reg = 0;
+
+ if (adev->asic_type == CHIP_TONGA ||
+ adev->asic_type == CHIP_FIJI) {
+ reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
+ /* bit0: 0 means pf and 1 means vf */
+ /* bit31: 0 means disable IOV and 1 means enable */
+ if (reg & 1)
+ adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
+
+ if (reg & 0x80000000)
+ adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
+ }
if (reg == 0) {
if (is_virtual_machine()) /* passthrough mode exclus sr-iov mode */
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 54f809cfbd6b4a43959039f5d33596ed3297ce16 Mon Sep 17 00:00:00 2001
From: "Leo (Sunpeng) Li" <sunpeng.li(a)amd.com>
Date: Wed, 17 Jan 2018 12:51:08 +0100
Subject: [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking
commits
During a non-blocking commit, it is possible to return before the
commit_tail work is queued (-ERESTARTSYS, for example).
Since a reference on the crtc commit object is obtained for the pending
vblank event when preparing the commit, the above situation will leave
us with an extra reference.
Therefore, if the commit_tail worker has not consumed the event at the
end of a commit, release it's reference.
Changes since v1:
- Also check for state->event->base.completion being set, to
handle the case where stall_checks() fails in setup_crtc_commit().
Changes since v2:
- Add a flag to drm_crtc_commit, to prevent dereferencing a freed event.
i915 may unreference the state in a worker.
Fixes: 24835e442f28 ("drm: reference count event->completion")
Cc: <stable(a)vger.kernel.org> # v4.11+
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li(a)amd.com>
Acked-by: Harry Wentland <harry.wentland(a)amd.com> #v1
Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180117115108.29608-1-maarte…
Reviewed-by: Sean Paul <seanpaul(a)chromium.org>
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index b16f1d69a0bb..e8c249361d7e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1778,6 +1778,8 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
new_crtc_state->event->base.completion = &commit->flip_done;
new_crtc_state->event->base.completion_release = release_crtc_commit;
drm_crtc_commit_get(commit);
+
+ commit->abort_completion = true;
}
for_each_oldnew_connector_in_state(state, conn, old_conn_state, new_conn_state, i) {
@@ -3327,8 +3329,21 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
{
if (state->commit) {
+ /*
+ * In the event that a non-blocking commit returns
+ * -ERESTARTSYS before the commit_tail work is queued, we will
+ * have an extra reference to the commit object. Release it, if
+ * the event has not been consumed by the worker.
+ *
+ * state->event may be freed, so we can't directly look at
+ * state->event->base.completion.
+ */
+ if (state->event && state->commit->abort_completion)
+ drm_crtc_commit_put(state->commit);
+
kfree(state->commit->event);
state->commit->event = NULL;
+
drm_crtc_commit_put(state->commit);
}
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 5afd6e364fb6..c63b0b48e884 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -134,6 +134,15 @@ struct drm_crtc_commit {
* &drm_pending_vblank_event pointer to clean up private events.
*/
struct drm_pending_vblank_event *event;
+
+ /**
+ * @abort_completion:
+ *
+ * A flag that's set after drm_atomic_helper_setup_commit takes a second
+ * reference for the completion of $drm_crtc_state.event. It's used by
+ * the free code to remove the second reference if commit fails.
+ */
+ bool abort_completion;
};
struct __drm_planes_state {
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 98112041bcca164676367e261c8c1073ef70cb51 Mon Sep 17 00:00:00 2001
From: Roger Quadros <rogerq(a)ti.com>
Date: Mon, 12 Feb 2018 15:30:08 +0200
Subject: [PATCH] usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init
during suspend/resume
In order for ULPI PHYs to work, dwc3_phy_setup() and dwc3_ulpi_init()
must be doene before dwc3_core_get_phy().
commit 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
broke this.
The other issue is that dwc3_core_get_phy() and dwc3_ulpi_init() should
be called only once during the life cycle of the driver. However,
as dwc3_core_init() is called during system suspend/resume it will
result in multiple calls to dwc3_core_get_phy() and dwc3_ulpi_init()
which is wrong.
Fix this by moving dwc3_ulpi_init() out of dwc3_phy_setup()
into dwc3_core_ulpi_init(). Use a flag 'ulpi_ready' to ensure that
dwc3_core_ulpi_init() is called only once from dwc3_core_init().
Use another flag 'phys_ready' to call dwc3_core_get_phy() only once from
dwc3_core_init().
Fixes: 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
Fixes: f54edb539c11 ("usb: dwc3: core: initialize ULPI before trying to get the PHY")
Cc: linux-stable <stable(a)vger.kernel.org> # >= v4.13
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 59511f2cd3ac..f1d838a4acd6 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -486,6 +486,22 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
}
+static int dwc3_core_ulpi_init(struct dwc3 *dwc)
+{
+ int intf;
+ int ret = 0;
+
+ intf = DWC3_GHWPARAMS3_HSPHY_IFC(dwc->hwparams.hwparams3);
+
+ if (intf == DWC3_GHWPARAMS3_HSPHY_IFC_ULPI ||
+ (intf == DWC3_GHWPARAMS3_HSPHY_IFC_UTMI_ULPI &&
+ dwc->hsphy_interface &&
+ !strncmp(dwc->hsphy_interface, "ulpi", 4)))
+ ret = dwc3_ulpi_init(dwc);
+
+ return ret;
+}
+
/**
* dwc3_phy_setup - Configure USB PHY Interface of DWC3 Core
* @dwc: Pointer to our controller context structure
@@ -497,7 +513,6 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
static int dwc3_phy_setup(struct dwc3 *dwc)
{
u32 reg;
- int ret;
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
@@ -568,9 +583,6 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
}
/* FALLTHROUGH */
case DWC3_GHWPARAMS3_HSPHY_IFC_ULPI:
- ret = dwc3_ulpi_init(dwc);
- if (ret)
- return ret;
/* FALLTHROUGH */
default:
break;
@@ -727,6 +739,7 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc)
}
static int dwc3_core_get_phy(struct dwc3 *dwc);
+static int dwc3_core_ulpi_init(struct dwc3 *dwc);
/**
* dwc3_core_init - Low-level initialization of DWC3 Core
@@ -758,17 +771,27 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc->maximum_speed = USB_SPEED_HIGH;
}
- ret = dwc3_core_get_phy(dwc);
+ ret = dwc3_phy_setup(dwc);
if (ret)
goto err0;
- ret = dwc3_core_soft_reset(dwc);
- if (ret)
- goto err0;
+ if (!dwc->ulpi_ready) {
+ ret = dwc3_core_ulpi_init(dwc);
+ if (ret)
+ goto err0;
+ dwc->ulpi_ready = true;
+ }
- ret = dwc3_phy_setup(dwc);
+ if (!dwc->phys_ready) {
+ ret = dwc3_core_get_phy(dwc);
+ if (ret)
+ goto err0a;
+ dwc->phys_ready = true;
+ }
+
+ ret = dwc3_core_soft_reset(dwc);
if (ret)
- goto err0;
+ goto err0a;
dwc3_core_setup_global_control(dwc);
dwc3_core_num_eps(dwc);
@@ -841,6 +864,9 @@ err1:
phy_exit(dwc->usb2_generic_phy);
phy_exit(dwc->usb3_generic_phy);
+err0a:
+ dwc3_ulpi_exit(dwc);
+
err0:
return ret;
}
@@ -1235,7 +1261,6 @@ err4:
err3:
dwc3_free_event_buffers(dwc);
- dwc3_ulpi_exit(dwc);
err2:
pm_runtime_allow(&pdev->dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 185b9603fd98..860d2bc184d1 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -797,7 +797,9 @@ struct dwc3_scratchpad_array {
* @usb3_phy: pointer to USB3 PHY
* @usb2_generic_phy: pointer to USB2 PHY
* @usb3_generic_phy: pointer to USB3 PHY
+ * @phys_ready: flag to indicate that PHYs are ready
* @ulpi: pointer to ulpi interface
+ * @ulpi_ready: flag to indicate that ULPI is initialized
* @u2sel: parameter from Set SEL request.
* @u2pel: parameter from Set SEL request.
* @u1sel: parameter from Set SEL request.
@@ -895,7 +897,10 @@ struct dwc3 {
struct phy *usb2_generic_phy;
struct phy *usb3_generic_phy;
+ bool phys_ready;
+
struct ulpi *ulpi;
+ bool ulpi_ready;
void __iomem *regs;
size_t regs_size;
The patch below does not apply to the 4.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 98112041bcca164676367e261c8c1073ef70cb51 Mon Sep 17 00:00:00 2001
From: Roger Quadros <rogerq(a)ti.com>
Date: Mon, 12 Feb 2018 15:30:08 +0200
Subject: [PATCH] usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init
during suspend/resume
In order for ULPI PHYs to work, dwc3_phy_setup() and dwc3_ulpi_init()
must be doene before dwc3_core_get_phy().
commit 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
broke this.
The other issue is that dwc3_core_get_phy() and dwc3_ulpi_init() should
be called only once during the life cycle of the driver. However,
as dwc3_core_init() is called during system suspend/resume it will
result in multiple calls to dwc3_core_get_phy() and dwc3_ulpi_init()
which is wrong.
Fix this by moving dwc3_ulpi_init() out of dwc3_phy_setup()
into dwc3_core_ulpi_init(). Use a flag 'ulpi_ready' to ensure that
dwc3_core_ulpi_init() is called only once from dwc3_core_init().
Use another flag 'phys_ready' to call dwc3_core_get_phy() only once from
dwc3_core_init().
Fixes: 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before initializing phys")
Fixes: f54edb539c11 ("usb: dwc3: core: initialize ULPI before trying to get the PHY")
Cc: linux-stable <stable(a)vger.kernel.org> # >= v4.13
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 59511f2cd3ac..f1d838a4acd6 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -486,6 +486,22 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
}
+static int dwc3_core_ulpi_init(struct dwc3 *dwc)
+{
+ int intf;
+ int ret = 0;
+
+ intf = DWC3_GHWPARAMS3_HSPHY_IFC(dwc->hwparams.hwparams3);
+
+ if (intf == DWC3_GHWPARAMS3_HSPHY_IFC_ULPI ||
+ (intf == DWC3_GHWPARAMS3_HSPHY_IFC_UTMI_ULPI &&
+ dwc->hsphy_interface &&
+ !strncmp(dwc->hsphy_interface, "ulpi", 4)))
+ ret = dwc3_ulpi_init(dwc);
+
+ return ret;
+}
+
/**
* dwc3_phy_setup - Configure USB PHY Interface of DWC3 Core
* @dwc: Pointer to our controller context structure
@@ -497,7 +513,6 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
static int dwc3_phy_setup(struct dwc3 *dwc)
{
u32 reg;
- int ret;
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
@@ -568,9 +583,6 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
}
/* FALLTHROUGH */
case DWC3_GHWPARAMS3_HSPHY_IFC_ULPI:
- ret = dwc3_ulpi_init(dwc);
- if (ret)
- return ret;
/* FALLTHROUGH */
default:
break;
@@ -727,6 +739,7 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc)
}
static int dwc3_core_get_phy(struct dwc3 *dwc);
+static int dwc3_core_ulpi_init(struct dwc3 *dwc);
/**
* dwc3_core_init - Low-level initialization of DWC3 Core
@@ -758,17 +771,27 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc->maximum_speed = USB_SPEED_HIGH;
}
- ret = dwc3_core_get_phy(dwc);
+ ret = dwc3_phy_setup(dwc);
if (ret)
goto err0;
- ret = dwc3_core_soft_reset(dwc);
- if (ret)
- goto err0;
+ if (!dwc->ulpi_ready) {
+ ret = dwc3_core_ulpi_init(dwc);
+ if (ret)
+ goto err0;
+ dwc->ulpi_ready = true;
+ }
- ret = dwc3_phy_setup(dwc);
+ if (!dwc->phys_ready) {
+ ret = dwc3_core_get_phy(dwc);
+ if (ret)
+ goto err0a;
+ dwc->phys_ready = true;
+ }
+
+ ret = dwc3_core_soft_reset(dwc);
if (ret)
- goto err0;
+ goto err0a;
dwc3_core_setup_global_control(dwc);
dwc3_core_num_eps(dwc);
@@ -841,6 +864,9 @@ err1:
phy_exit(dwc->usb2_generic_phy);
phy_exit(dwc->usb3_generic_phy);
+err0a:
+ dwc3_ulpi_exit(dwc);
+
err0:
return ret;
}
@@ -1235,7 +1261,6 @@ err4:
err3:
dwc3_free_event_buffers(dwc);
- dwc3_ulpi_exit(dwc);
err2:
pm_runtime_allow(&pdev->dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 185b9603fd98..860d2bc184d1 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -797,7 +797,9 @@ struct dwc3_scratchpad_array {
* @usb3_phy: pointer to USB3 PHY
* @usb2_generic_phy: pointer to USB2 PHY
* @usb3_generic_phy: pointer to USB3 PHY
+ * @phys_ready: flag to indicate that PHYs are ready
* @ulpi: pointer to ulpi interface
+ * @ulpi_ready: flag to indicate that ULPI is initialized
* @u2sel: parameter from Set SEL request.
* @u2pel: parameter from Set SEL request.
* @u1sel: parameter from Set SEL request.
@@ -895,7 +897,10 @@ struct dwc3 {
struct phy *usb2_generic_phy;
struct phy *usb3_generic_phy;
+ bool phys_ready;
+
struct ulpi *ulpi;
+ bool ulpi_ready;
void __iomem *regs;
size_t regs_size;
The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:27 -0800
Subject: [PATCH] usb: dwc3: ep0: Reset TRB counter for ep0 IN
DWC3 tracks TRB counter for each ep0 direction separately. In control
read transfer completion handler, the driver needs to reset the TRB
enqueue counter for ep0 IN direction. Currently the driver only resets
the TRB counter for control OUT endpoint. Check for the data direction
and properly reset the TRB counter from correct control endpoint.
Cc: stable(a)vger.kernel.org
Fixes: c2da2ff00606 ("usb: dwc3: ep0: don't use ep0in for transfers")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 9c2e4a17918e..18be31d5743a 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -854,7 +854,12 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
trb++;
trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
trace_dwc3_complete_trb(ep0, trb);
- ep0->trb_enqueue = 0;
+
+ if (r->direction)
+ dwc->eps[1]->trb_enqueue = 0;
+ else
+ dwc->eps[0]->trb_enqueue = 0;
+
dwc->ep0_bounced = false;
}
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:27 -0800
Subject: [PATCH] usb: dwc3: ep0: Reset TRB counter for ep0 IN
DWC3 tracks TRB counter for each ep0 direction separately. In control
read transfer completion handler, the driver needs to reset the TRB
enqueue counter for ep0 IN direction. Currently the driver only resets
the TRB counter for control OUT endpoint. Check for the data direction
and properly reset the TRB counter from correct control endpoint.
Cc: stable(a)vger.kernel.org
Fixes: c2da2ff00606 ("usb: dwc3: ep0: don't use ep0in for transfers")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 9c2e4a17918e..18be31d5743a 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -854,7 +854,12 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
trb++;
trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
trace_dwc3_complete_trb(ep0, trb);
- ep0->trb_enqueue = 0;
+
+ if (r->direction)
+ dwc->eps[1]->trb_enqueue = 0;
+ else
+ dwc->eps[0]->trb_enqueue = 0;
+
dwc->ep0_bounced = false;
}
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:27 -0800
Subject: [PATCH] usb: dwc3: ep0: Reset TRB counter for ep0 IN
DWC3 tracks TRB counter for each ep0 direction separately. In control
read transfer completion handler, the driver needs to reset the TRB
enqueue counter for ep0 IN direction. Currently the driver only resets
the TRB counter for control OUT endpoint. Check for the data direction
and properly reset the TRB counter from correct control endpoint.
Cc: stable(a)vger.kernel.org
Fixes: c2da2ff00606 ("usb: dwc3: ep0: don't use ep0in for transfers")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 9c2e4a17918e..18be31d5743a 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -854,7 +854,12 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
trb++;
trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
trace_dwc3_complete_trb(ep0, trb);
- ep0->trb_enqueue = 0;
+
+ if (r->direction)
+ dwc->eps[1]->trb_enqueue = 0;
+ else
+ dwc->eps[0]->trb_enqueue = 0;
+
dwc->ep0_bounced = false;
}
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From a06f818a70de21b4b3b4186816094208fc7accf9 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon(a)arm.com>
Date: Mon, 19 Feb 2018 16:46:57 +0000
Subject: [PATCH] arm64: __show_regs: Only resolve kernel symbols when running
at EL1
__show_regs pretty prints PC and LR by attempting to map them to kernel
function names to improve the utility of crash reports. Unfortunately,
this mapping is applied even when the pt_regs corresponds to user mode,
resulting in a KASLR oracle.
Avoid this issue by only looking up the function symbols when the register
state indicates that we're actually running at EL1.
Cc: <stable(a)vger.kernel.org>
Reported-by: NCSC Security <security(a)ncsc.gov.uk>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index ad8aeb098b31..c0da6efe5465 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -220,8 +220,15 @@ void __show_regs(struct pt_regs *regs)
show_regs_print_info(KERN_DEFAULT);
print_pstate(regs);
- printk("pc : %pS\n", (void *)regs->pc);
- printk("lr : %pS\n", (void *)lr);
+
+ if (!user_mode(regs)) {
+ printk("pc : %pS\n", (void *)regs->pc);
+ printk("lr : %pS\n", (void *)lr);
+ } else {
+ printk("pc : %016llx\n", regs->pc);
+ printk("lr : %016llx\n", lr);
+ }
+
printk("sp : %016llx\n", sp);
i = top_reg;
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From a06f818a70de21b4b3b4186816094208fc7accf9 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon(a)arm.com>
Date: Mon, 19 Feb 2018 16:46:57 +0000
Subject: [PATCH] arm64: __show_regs: Only resolve kernel symbols when running
at EL1
__show_regs pretty prints PC and LR by attempting to map them to kernel
function names to improve the utility of crash reports. Unfortunately,
this mapping is applied even when the pt_regs corresponds to user mode,
resulting in a KASLR oracle.
Avoid this issue by only looking up the function symbols when the register
state indicates that we're actually running at EL1.
Cc: <stable(a)vger.kernel.org>
Reported-by: NCSC Security <security(a)ncsc.gov.uk>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index ad8aeb098b31..c0da6efe5465 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -220,8 +220,15 @@ void __show_regs(struct pt_regs *regs)
show_regs_print_info(KERN_DEFAULT);
print_pstate(regs);
- printk("pc : %pS\n", (void *)regs->pc);
- printk("lr : %pS\n", (void *)lr);
+
+ if (!user_mode(regs)) {
+ printk("pc : %pS\n", (void *)regs->pc);
+ printk("lr : %pS\n", (void *)lr);
+ } else {
+ printk("pc : %016llx\n", regs->pc);
+ printk("lr : %016llx\n", lr);
+ }
+
printk("sp : %016llx\n", sp);
i = top_reg;
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From a06f818a70de21b4b3b4186816094208fc7accf9 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon(a)arm.com>
Date: Mon, 19 Feb 2018 16:46:57 +0000
Subject: [PATCH] arm64: __show_regs: Only resolve kernel symbols when running
at EL1
__show_regs pretty prints PC and LR by attempting to map them to kernel
function names to improve the utility of crash reports. Unfortunately,
this mapping is applied even when the pt_regs corresponds to user mode,
resulting in a KASLR oracle.
Avoid this issue by only looking up the function symbols when the register
state indicates that we're actually running at EL1.
Cc: <stable(a)vger.kernel.org>
Reported-by: NCSC Security <security(a)ncsc.gov.uk>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index ad8aeb098b31..c0da6efe5465 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -220,8 +220,15 @@ void __show_regs(struct pt_regs *regs)
show_regs_print_info(KERN_DEFAULT);
print_pstate(regs);
- printk("pc : %pS\n", (void *)regs->pc);
- printk("lr : %pS\n", (void *)lr);
+
+ if (!user_mode(regs)) {
+ printk("pc : %pS\n", (void *)regs->pc);
+ printk("lr : %pS\n", (void *)lr);
+ } else {
+ printk("pc : %016llx\n", regs->pc);
+ printk("lr : %016llx\n", lr);
+ }
+
printk("sp : %016llx\n", sp);
i = top_reg;
Commit e864f39569f4 "fs: add RWF_DSYNC aand RWF_SYNC" added additional
way for direct IO to become synchronous and thus trigger fsync from the
IO completion handler. Then commit 9830f4be159b "fs: Use RWF_* flags for
AIO operations" allowed these flags to be set for AIO as well. However
that commit forgot to update the condition checking whether the IO
completion handling should be defered to a workqueue and thus AIO DIO
with RWF_[D]SYNC set will call fsync() from IRQ context resulting in
sleep in atomic.
Fix the problem by checking directly iocb flags (the same way as it is
done in dio_complete()) instead of checking all conditions that could
lead to IO being synchronous.
CC: Christoph Hellwig <hch(a)lst.de>
CC: Goldwyn Rodrigues <rgoldwyn(a)suse.com>
CC: stable(a)vger.kernel.org
Reported-by: Mark Rutland <mark.rutland(a)arm.com>
Tested-by: Mark Rutland <mark.rutland(a)arm.com>
Fixes: 9830f4be159b29399d107bffb99e0132bc5aedd4
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
fs/direct-io.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/direct-io.c b/fs/direct-io.c
index a0ca9e48e993..1357ef563893 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -1274,8 +1274,7 @@ do_blockdev_direct_IO(struct kiocb *iocb, struct inode *inode,
*/
if (dio->is_async && iov_iter_rw(iter) == WRITE) {
retval = 0;
- if ((iocb->ki_filp->f_flags & O_DSYNC) ||
- IS_SYNC(iocb->ki_filp->f_mapping->host))
+ if (iocb->ki_flags & IOCB_DSYNC)
retval = dio_set_defer_completion(dio);
else if (!dio->inode->i_sb->s_dio_done_wq) {
/*
--
2.13.6
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 4b34968e77ad09628cfb3c4a7daf2adc2cefc6e8 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 22 Feb 2018 14:38:34 +0000
Subject: [PATCH] X.509: fix NULL dereference when restricting key with
unsupported_sig
The asymmetric key type allows an X.509 certificate to be added even if
its signature's hash algorithm is not available in the crypto API. In
that case 'payload.data[asym_auth]' will be NULL. But the key
restriction code failed to check for this case before trying to use the
signature, resulting in a NULL pointer dereference in
key_or_keyring_common() or in restrict_link_by_signature().
Fix this by returning -ENOPKG when the signature is unsupported.
Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled and
keyctl has support for the 'restrict_keyring' command:
keyctl new_session
keyctl restrict_keyring @s asymmetric builtin_trusted
openssl req -new -sha512 -x509 -batch -nodes -outform der \
| keyctl padd asymmetric desc @s
Fixes: a511e1af8b12 ("KEYS: Move the point of trust determination to __key_link()")
Cc: <stable(a)vger.kernel.org> # v4.7+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
diff --git a/crypto/asymmetric_keys/restrict.c b/crypto/asymmetric_keys/restrict.c
index 86fb68508952..7c93c7728454 100644
--- a/crypto/asymmetric_keys/restrict.c
+++ b/crypto/asymmetric_keys/restrict.c
@@ -67,8 +67,9 @@ __setup("ca_keys=", ca_keys_setup);
*
* Returns 0 if the new certificate was accepted, -ENOKEY if we couldn't find a
* matching parent certificate in the trusted list, -EKEYREJECTED if the
- * signature check fails or the key is blacklisted and some other error if
- * there is a matching certificate but the signature check cannot be performed.
+ * signature check fails or the key is blacklisted, -ENOPKG if the signature
+ * uses unsupported crypto, or some other error if there is a matching
+ * certificate but the signature check cannot be performed.
*/
int restrict_link_by_signature(struct key *dest_keyring,
const struct key_type *type,
@@ -88,6 +89,8 @@ int restrict_link_by_signature(struct key *dest_keyring,
return -EOPNOTSUPP;
sig = payload->data[asym_auth];
+ if (!sig)
+ return -ENOPKG;
if (!sig->auth_ids[0] && !sig->auth_ids[1])
return -ENOKEY;
@@ -139,6 +142,8 @@ static int key_or_keyring_common(struct key *dest_keyring,
return -EOPNOTSUPP;
sig = payload->data[asym_auth];
+ if (!sig)
+ return -ENOPKG;
if (!sig->auth_ids[0] && !sig->auth_ids[1])
return -ENOKEY;
@@ -222,9 +227,9 @@ static int key_or_keyring_common(struct key *dest_keyring,
*
* Returns 0 if the new certificate was accepted, -ENOKEY if we
* couldn't find a matching parent certificate in the trusted list,
- * -EKEYREJECTED if the signature check fails, and some other error if
- * there is a matching certificate but the signature check cannot be
- * performed.
+ * -EKEYREJECTED if the signature check fails, -ENOPKG if the signature uses
+ * unsupported crypto, or some other error if there is a matching certificate
+ * but the signature check cannot be performed.
*/
int restrict_link_by_key_or_keyring(struct key *dest_keyring,
const struct key_type *type,
@@ -249,9 +254,9 @@ int restrict_link_by_key_or_keyring(struct key *dest_keyring,
*
* Returns 0 if the new certificate was accepted, -ENOKEY if we
* couldn't find a matching parent certificate in the trusted list,
- * -EKEYREJECTED if the signature check fails, and some other error if
- * there is a matching certificate but the signature check cannot be
- * performed.
+ * -EKEYREJECTED if the signature check fails, -ENOPKG if the signature uses
+ * unsupported crypto, or some other error if there is a matching certificate
+ * but the signature check cannot be performed.
*/
int restrict_link_by_key_or_keyring_chain(struct key *dest_keyring,
const struct key_type *type,
This is a note to let you know that I've just added the patch titled
arm64: mm: don't write garbage into TTBR1_EL1 register
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:
arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.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 ard.biesheuvel(a)linaro.org Mon Feb 26 13:53:22 2018
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Fri, 23 Feb 2018 18:29:02 +0000
Subject: arm64: mm: don't write garbage into TTBR1_EL1 register
To: linux-arm-kernel(a)lists.infradead.org
Cc: catalin.marinas(a)arm.com, will.deacon(a)arm.com, marc.zyngier(a)arm.com, mark.rutland(a)arm.com, nicolas.dechesne(a)linaro.org, gregkh(a)linuxfoundation.org, Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Message-ID: <20180223182902.24873-1-ard.biesheuvel(a)linaro.org>
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Stable backport commit 173358a49173 ("arm64: kpti: Add ->enable callback
to remap swapper using nG mappings") of upstream commit f992b4dfd58b did
not survive the backporting process unscathed, and ends up writing garbage
into the TTBR1_EL1 register, rather than pointing it to the zero page to
disable translations. Fix that.
Cc: <stable(a)vger.kernel.org> #v4.14
Reported-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Acked-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/proc.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 08572f95bd8a..2b473ddeb7a3 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -155,7 +155,7 @@ ENDPROC(cpu_do_switch_mm)
.macro __idmap_cpu_set_reserved_ttbr1, tmp1, tmp2
adrp \tmp1, empty_zero_page
- msr ttbr1_el1, \tmp2
+ msr ttbr1_el1, \tmp1
isb
tlbi vmalle1
dsb nsh
--
2.11.0
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.4/arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: vivid: check if the cec_adapter is valid
Author: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Mon Feb 12 06:45:32 2018 -0500
If CEC is not enabled for the vivid driver, then the adap pointer is NULL
and 'adap->phys_addr' will fail.
Cc: <stable(a)vger.kernel.org> # for v4.12 and up
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/platform/vivid/vivid-vid-common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
---
diff --git a/drivers/media/platform/vivid/vivid-vid-common.c b/drivers/media/platform/vivid/vivid-vid-common.c
index cc67f403a808..e5914be0e12d 100644
--- a/drivers/media/platform/vivid/vivid-vid-common.c
+++ b/drivers/media/platform/vivid/vivid-vid-common.c
@@ -862,7 +862,8 @@ int vidioc_g_edid(struct file *file, void *_fh,
return -EINVAL;
if (edid->start_block + edid->blocks > dev->edid_blocks)
edid->blocks = dev->edid_blocks - edid->start_block;
- cec_set_edid_phys_addr(dev->edid, dev->edid_blocks * 128, adap->phys_addr);
+ if (adap)
+ cec_set_edid_phys_addr(dev->edid, dev->edid_blocks * 128, adap->phys_addr);
memcpy(edid->edid, dev->edid + edid->start_block * 128, edid->blocks * 128);
return 0;
}
This is a note to let you know that I've just added the patch titled
PCI: keystone: Fix interrupt-controller-node lookup
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:
pci-keystone-fix-interrupt-controller-node-lookup.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 eac56aa3bc8af3d9b9850345d0f2da9d83529134 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Fri, 17 Nov 2017 14:38:31 +0100
Subject: PCI: keystone: Fix interrupt-controller-node lookup
From: Johan Hovold <johan(a)kernel.org>
commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.
Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.
To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.
Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable <stable(a)vger.kernel.org> # 3.18
Acked-by: Murali Karicheri <m-karicheri2(a)ti.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
[lorenzo.pieralisi(a)arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
[johan: backport to 4.4]
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-keystone.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -179,14 +179,16 @@ static int ks_pcie_get_irq_controller_in
}
/* interrupt controller is in a child node */
- *np_temp = of_find_node_by_name(np_pcie, controller);
+ *np_temp = of_get_child_by_name(np_pcie, controller);
if (!(*np_temp)) {
dev_err(dev, "Node for %s is absent\n", controller);
goto out;
}
temp = of_irq_count(*np_temp);
- if (!temp)
+ if (!temp) {
+ of_node_put(*np_temp);
goto out;
+ }
if (temp > max_host_irqs)
dev_warn(dev, "Too many %s interrupts defined %u\n",
(legacy ? "legacy" : "MSI"), temp);
@@ -200,6 +202,9 @@ static int ks_pcie_get_irq_controller_in
if (!host_irqs[temp])
break;
}
+
+ of_node_put(*np_temp);
+
if (temp) {
*num_irqs = temp;
ret = 0;
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.4/pci-keystone-fix-interrupt-controller-node-lookup.patch
This is a note to let you know that I've just added the patch titled
ip_tunnel: fix preempt warning in ip tunnel creation/updating
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:
ip_tunnel-fix-preempt-warning-in-ip-tunnel-creation-updating.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 f27337e16f2d0e52a8d05ea599ed13cd266ac291 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 28 Apr 2016 11:04:51 +0200
Subject: ip_tunnel: fix preempt warning in ip tunnel creation/updating
From: Paolo Abeni <pabeni(a)redhat.com>
commit f27337e16f2d0e52a8d05ea599ed13cd266ac291 upstream.
After the commit e09acddf873b ("ip_tunnel: replace dst_cache with generic
implementation"), a preemption debug warning is triggered on ip4
tunnels updating; the dst cache helper needs to be invoked in unpreemptible
context.
We don't need to load the cache on tunnel update, so this commit fixes
the warning replacing the load with a dst cache reset, which is
preempt safe.
Fixes: e09acddf873b ("ip_tunnel: replace dst_cache with generic implementation")
Reported-by: Eric Dumazet <eric.dumazet(a)gmail.com>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Acked-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_tunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -327,12 +327,12 @@ static int ip_tunnel_bind_dev(struct net
if (!IS_ERR(rt)) {
tdev = rt->dst.dev;
- dst_cache_set_ip4(&tunnel->dst_cache, &rt->dst,
- fl4.saddr);
ip_rt_put(rt);
}
if (dev->type != ARPHRD_ETHER)
dev->flags |= IFF_POINTOPOINT;
+
+ dst_cache_reset(&tunnel->dst_cache);
}
if (!tdev && tunnel->parms.link)
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.4/ip_tunnel-fix-preempt-warning-in-ip-tunnel-creation-updating.patch
queue-4.4/ip_tunnel-replace-dst_cache-with-generic-implementation.patch
queue-4.4/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: vb2: core: Finish buffers at the end of the stream
Author: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Date: Fri Feb 2 05:08:59 2018 -0500
If buffers were prepared or queued and the buffers were released without
starting the queue, the finish mem op (corresponding to the prepare mem
op) was never called to the buffers.
Before commit a136f59c0a1f there was no need to do this as in such a case
the prepare mem op had not been called yet. Address the problem by
explicitly calling finish mem op when the queue is stopped if the buffer
is in either prepared or queued state.
Fixes: a136f59c0a1f ("[media] vb2: Move buffer cache synchronisation to prepare from queue")
Cc: stable(a)vger.kernel.org # for v4.13 and up
Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Tested-by: Devin Heitmueller <dheitmueller(a)kernellabs.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/common/videobuf2/videobuf2-core.c | 9 +++++++++
1 file changed, 9 insertions(+)
---
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
index debe35fc66b4..d3f7bb33a54d 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1696,6 +1696,15 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
for (i = 0; i < q->num_buffers; ++i) {
struct vb2_buffer *vb = q->bufs[i];
+ if (vb->state == VB2_BUF_STATE_PREPARED ||
+ vb->state == VB2_BUF_STATE_QUEUED) {
+ unsigned int plane;
+
+ for (plane = 0; plane < vb->num_planes; ++plane)
+ call_void_memop(vb, finish,
+ vb->planes[plane].mem_priv);
+ }
+
if (vb->state != VB2_BUF_STATE_DEQUEUED) {
vb->state = VB2_BUF_STATE_PREPARED;
call_void_vb_qop(vb, buf_finish, vb);
This is a note to let you know that I've just added the patch titled
MIPS: boot: Define __ASSEMBLY__ for its.S build
to the 4.15-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:
mips-boot-define-__assembly__-for-its.s-build.patch
and it can be found in the queue-4.15 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 0f9da844d87796ac31b04e81ee95e155e9043132 Mon Sep 17 00:00:00 2001
From: Kees Cook <keescook(a)chromium.org>
Date: Thu, 22 Feb 2018 16:59:26 -0800
Subject: MIPS: boot: Define __ASSEMBLY__ for its.S build
From: Kees Cook <keescook(a)chromium.org>
commit 0f9da844d87796ac31b04e81ee95e155e9043132 upstream.
The MIPS %.its.S compiler command did not define __ASSEMBLY__, which meant
when compiler_types.h was added to kconfig.h, unexpected things appeared
(e.g. struct declarations) which should not have been present. As done in
the general %.S compiler command, __ASSEMBLY__ is now included here too.
The failure was:
Error: arch/mips/boot/vmlinux.gz.its:201.1-2 syntax error
FATAL ERROR: Unable to parse input tree
/usr/bin/mkimage: Can't read arch/mips/boot/vmlinux.gz.itb.tmp: Invalid argument
/usr/bin/mkimage Can't add hashes to FIT blob
Reported-by: kbuild test robot <lkp(a)intel.com>
Fixes: 28128c61e08e ("kconfig.h: Include compiler types to avoid missed struct attributes")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/boot/Makefile | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/boot/Makefile
+++ b/arch/mips/boot/Makefile
@@ -126,6 +126,7 @@ $(obj)/vmlinux.its.S: $(addprefix $(srct
quiet_cmd_cpp_its_S = ITS $@
cmd_cpp_its_S = $(CPP) $(cpp_flags) -P -C -o $@ $< \
+ -D__ASSEMBLY__ \
-DKERNEL_NAME="\"Linux $(KERNELRELEASE)\"" \
-DVMLINUX_BINARY="\"$(3)\"" \
-DVMLINUX_COMPRESSION="\"$(2)\"" \
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.15/mips-boot-define-__assembly__-for-its.s-build.patch
queue-4.15/kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch
This is a note to let you know that I've just added the patch titled
kconfig.h: Include compiler types to avoid missed struct attributes
to the 4.15-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:
kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch
and it can be found in the queue-4.15 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 28128c61e08eaeced9cc8ec0e6b5d677b5b94690 Mon Sep 17 00:00:00 2001
From: Kees Cook <keescook(a)chromium.org>
Date: Thu, 22 Feb 2018 09:41:40 -0800
Subject: kconfig.h: Include compiler types to avoid missed struct attributes
From: Kees Cook <keescook(a)chromium.org>
commit 28128c61e08eaeced9cc8ec0e6b5d677b5b94690 upstream.
The header files for some structures could get included in such a way
that struct attributes (specifically __randomize_layout from path.h) would
be parsed as variable names instead of attributes. This could lead to
some instances of a structure being unrandomized, causing nasty GPFs, etc.
This patch makes sure the compiler_types.h header is included in
kconfig.h so that we've always got types and struct attributes defined,
since kconfig.h is included from the compiler command line.
Reported-by: Patrick McLean <chutzpah(a)gentoo.org>
Root-caused-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Tested-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Fixes: 3859a271a003 ("randstruct: Mark various structs for randomization")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/kconfig.h | 3 +++
1 file changed, 3 insertions(+)
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -64,4 +64,7 @@
*/
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
+/* Make sure we always have all types and struct attributes defined. */
+#include <linux/compiler_types.h>
+
#endif /* __LINUX_KCONFIG_H */
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.15/mips-boot-define-__assembly__-for-its.s-build.patch
queue-4.15/kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch
This is a note to let you know that I've just added the patch titled
arm64: mm: don't write garbage into TTBR1_EL1 register
to the 4.15-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-don-t-write-garbage-into-ttbr1_el1-register.patch
and it can be found in the queue-4.15 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 ard.biesheuvel(a)linaro.org Mon Feb 26 13:53:22 2018
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Fri, 23 Feb 2018 18:29:02 +0000
Subject: arm64: mm: don't write garbage into TTBR1_EL1 register
To: linux-arm-kernel(a)lists.infradead.org
Cc: catalin.marinas(a)arm.com, will.deacon(a)arm.com, marc.zyngier(a)arm.com, mark.rutland(a)arm.com, nicolas.dechesne(a)linaro.org, gregkh(a)linuxfoundation.org, Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Message-ID: <20180223182902.24873-1-ard.biesheuvel(a)linaro.org>
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Stable backport commit 173358a49173 ("arm64: kpti: Add ->enable callback
to remap swapper using nG mappings") of upstream commit f992b4dfd58b did
not survive the backporting process unscathed, and ends up writing garbage
into the TTBR1_EL1 register, rather than pointing it to the zero page to
disable translations. Fix that.
Cc: <stable(a)vger.kernel.org> #v4.14
Reported-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Acked-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/proc.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -155,7 +155,7 @@ ENDPROC(cpu_do_switch_mm)
.macro __idmap_cpu_set_reserved_ttbr1, tmp1, tmp2
adrp \tmp1, empty_zero_page
- msr ttbr1_el1, \tmp2
+ msr ttbr1_el1, \tmp1
isb
tlbi vmalle1
dsb nsh
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.15/arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch
This is a note to let you know that I've just added the patch titled
MIPS: boot: Define __ASSEMBLY__ for its.S build
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:
mips-boot-define-__assembly__-for-its.s-build.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 0f9da844d87796ac31b04e81ee95e155e9043132 Mon Sep 17 00:00:00 2001
From: Kees Cook <keescook(a)chromium.org>
Date: Thu, 22 Feb 2018 16:59:26 -0800
Subject: MIPS: boot: Define __ASSEMBLY__ for its.S build
From: Kees Cook <keescook(a)chromium.org>
commit 0f9da844d87796ac31b04e81ee95e155e9043132 upstream.
The MIPS %.its.S compiler command did not define __ASSEMBLY__, which meant
when compiler_types.h was added to kconfig.h, unexpected things appeared
(e.g. struct declarations) which should not have been present. As done in
the general %.S compiler command, __ASSEMBLY__ is now included here too.
The failure was:
Error: arch/mips/boot/vmlinux.gz.its:201.1-2 syntax error
FATAL ERROR: Unable to parse input tree
/usr/bin/mkimage: Can't read arch/mips/boot/vmlinux.gz.itb.tmp: Invalid argument
/usr/bin/mkimage Can't add hashes to FIT blob
Reported-by: kbuild test robot <lkp(a)intel.com>
Fixes: 28128c61e08e ("kconfig.h: Include compiler types to avoid missed struct attributes")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/boot/Makefile | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/boot/Makefile
+++ b/arch/mips/boot/Makefile
@@ -126,6 +126,7 @@ $(obj)/vmlinux.its.S: $(addprefix $(srct
quiet_cmd_cpp_its_S = ITS $@
cmd_cpp_its_S = $(CPP) $(cpp_flags) -P -C -o $@ $< \
+ -D__ASSEMBLY__ \
-DKERNEL_NAME="\"Linux $(KERNELRELEASE)\"" \
-DVMLINUX_BINARY="\"$(3)\"" \
-DVMLINUX_COMPRESSION="\"$(2)\"" \
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.14/mips-boot-define-__assembly__-for-its.s-build.patch
queue-4.14/kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch
This is a note to let you know that I've just added the patch titled
kconfig.h: Include compiler types to avoid missed struct attributes
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:
kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.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 28128c61e08eaeced9cc8ec0e6b5d677b5b94690 Mon Sep 17 00:00:00 2001
From: Kees Cook <keescook(a)chromium.org>
Date: Thu, 22 Feb 2018 09:41:40 -0800
Subject: kconfig.h: Include compiler types to avoid missed struct attributes
From: Kees Cook <keescook(a)chromium.org>
commit 28128c61e08eaeced9cc8ec0e6b5d677b5b94690 upstream.
The header files for some structures could get included in such a way
that struct attributes (specifically __randomize_layout from path.h) would
be parsed as variable names instead of attributes. This could lead to
some instances of a structure being unrandomized, causing nasty GPFs, etc.
This patch makes sure the compiler_types.h header is included in
kconfig.h so that we've always got types and struct attributes defined,
since kconfig.h is included from the compiler command line.
Reported-by: Patrick McLean <chutzpah(a)gentoo.org>
Root-caused-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Tested-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Fixes: 3859a271a003 ("randstruct: Mark various structs for randomization")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/kconfig.h | 3 +++
1 file changed, 3 insertions(+)
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -64,4 +64,7 @@
*/
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
+/* Make sure we always have all types and struct attributes defined. */
+#include <linux/compiler_types.h>
+
#endif /* __LINUX_KCONFIG_H */
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.14/mips-boot-define-__assembly__-for-its.s-build.patch
queue-4.14/kconfig.h-include-compiler-types-to-avoid-missed-struct-attributes.patch
This is a note to let you know that I've just added the patch titled
arm64: mm: don't write garbage into TTBR1_EL1 register
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-don-t-write-garbage-into-ttbr1_el1-register.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 ard.biesheuvel(a)linaro.org Mon Feb 26 13:53:22 2018
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Fri, 23 Feb 2018 18:29:02 +0000
Subject: arm64: mm: don't write garbage into TTBR1_EL1 register
To: linux-arm-kernel(a)lists.infradead.org
Cc: catalin.marinas(a)arm.com, will.deacon(a)arm.com, marc.zyngier(a)arm.com, mark.rutland(a)arm.com, nicolas.dechesne(a)linaro.org, gregkh(a)linuxfoundation.org, Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Message-ID: <20180223182902.24873-1-ard.biesheuvel(a)linaro.org>
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Stable backport commit 173358a49173 ("arm64: kpti: Add ->enable callback
to remap swapper using nG mappings") of upstream commit f992b4dfd58b did
not survive the backporting process unscathed, and ends up writing garbage
into the TTBR1_EL1 register, rather than pointing it to the zero page to
disable translations. Fix that.
Cc: <stable(a)vger.kernel.org> #v4.14
Reported-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Acked-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/proc.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -155,7 +155,7 @@ ENDPROC(cpu_do_switch_mm)
.macro __idmap_cpu_set_reserved_ttbr1, tmp1, tmp2
adrp \tmp1, empty_zero_page
- msr ttbr1_el1, \tmp2
+ msr ttbr1_el1, \tmp1
isb
tlbi vmalle1
dsb nsh
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.14/arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch
This is a note to let you know that I've just added the patch titled
PCI: keystone: Fix interrupt-controller-node lookup
to the 3.18-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:
pci-keystone-fix-interrupt-controller-node-lookup.patch
and it can be found in the queue-3.18 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 eac56aa3bc8af3d9b9850345d0f2da9d83529134 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Fri, 17 Nov 2017 14:38:31 +0100
Subject: PCI: keystone: Fix interrupt-controller-node lookup
From: Johan Hovold <johan(a)kernel.org>
commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.
Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.
To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.
Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable <stable(a)vger.kernel.org> # 3.18
Acked-by: Murali Karicheri <m-karicheri2(a)ti.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
[lorenzo.pieralisi(a)arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
[johan: backport to 4.4]
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-keystone.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -179,14 +179,16 @@ static int ks_pcie_get_irq_controller_in
}
/* interrupt controller is in a child node */
- *np_temp = of_find_node_by_name(np_pcie, controller);
+ *np_temp = of_get_child_by_name(np_pcie, controller);
if (!(*np_temp)) {
dev_err(dev, "Node for %s is absent\n", controller);
goto out;
}
temp = of_irq_count(*np_temp);
- if (!temp)
+ if (!temp) {
+ of_node_put(*np_temp);
goto out;
+ }
if (temp > max_host_irqs)
dev_warn(dev, "Too many %s interrupts defined %u\n",
(legacy ? "legacy" : "MSI"), temp);
@@ -200,6 +202,9 @@ static int ks_pcie_get_irq_controller_in
if (host_irqs[temp] < 0)
break;
}
+
+ of_node_put(*np_temp);
+
if (temp) {
*num_irqs = temp;
ret = 0;
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-3.18/pci-keystone-fix-interrupt-controller-node-lookup.patch
commit 28128c61e08eaeced9cc8ec0e6b5d677b5b94690 upstream.
The header files for some structures could get included in such a way
that struct attributes (specifically __randomize_layout from path.h) would
be parsed as variable names instead of attributes. This could lead to
some instances of a structure being unrandomized, causing nasty GPFs, etc.
This patch makes sure the compiler_types.h header is included in path.h.
Reported-by: Patrick McLean <chutzpah(a)gentoo.org>
Root-caused-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Tested-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Fixes: 3859a271a003 ("randstruct: Mark various structs for randomization")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
[kees: Adjusted to just path.h for -stable, as this is a smaller change]
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
This is a much more narrow fix for the issue. I adjusted the commit subject
and body, but still reference the "full" upstream commit. Is this the best
way to handle this?
---
include/linux/path.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/path.h b/include/linux/path.h
index 81e65a5be7ce..74a59d190a3c 100644
--- a/include/linux/path.h
+++ b/include/linux/path.h
@@ -2,6 +2,8 @@
#ifndef _LINUX_PATH_H
#define _LINUX_PATH_H
+#include <linux/compiler_types.h>
+
struct dentry;
struct vfsmount;
--
2.7.4
--
Kees Cook
Pixel Security
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: usbtv: prevent double free in error case
Author: Oliver Neukum <oneukum(a)suse.com>
Date: Mon Jan 8 09:21:07 2018 -0500
Quoting the original report:
It looks like there is a double-free vulnerability in Linux usbtv driver
on an error path of usbtv_probe function. When audio registration fails,
usbtv_video_free function ends up freeing usbtv data structure, which
gets freed the second time under usbtv_video_fail label.
usbtv_audio_fail:
usbtv_video_free(usbtv); =>
v4l2_device_put(&usbtv->v4l2_dev);
=> v4l2_device_put
=> kref_put
=> v4l2_device_release
=> usbtv_release (CALLBACK)
=> kfree(usbtv) (1st time)
usbtv_video_fail:
usb_set_intfdata(intf, NULL);
usb_put_dev(usbtv->udev);
kfree(usbtv); (2nd time)
So, as we have refcounting, use it
Reported-by: Yavuz, Tuba <tuba(a)ece.ufl.edu>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
CC: stable(a)vger.kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/usb/usbtv/usbtv-core.c | 2 ++
1 file changed, 2 insertions(+)
---
diff --git a/drivers/media/usb/usbtv/usbtv-core.c b/drivers/media/usb/usbtv/usbtv-core.c
index 127f8a0c098b..0c2e628e8723 100644
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -112,6 +112,8 @@ static int usbtv_probe(struct usb_interface *intf,
return 0;
usbtv_audio_fail:
+ /* we must not free at this point */
+ usb_get_dev(usbtv->udev);
usbtv_video_free(usbtv);
usbtv_video_fail:
The patch
ASoC: sun4i-i2s: Fix RX slot number of SUN8I
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 5a3386790a172cf738194e1574f631cd43c6140a Mon Sep 17 00:00:00 2001
From: Yong Deng <yong.deng(a)magewell.com>
Date: Mon, 26 Feb 2018 10:43:52 +0800
Subject: [PATCH] ASoC: sun4i-i2s: Fix RX slot number of SUN8I
I2S's RX slot number of SUN8I should be shifted 4 bit to left.
Fixes: 7d2993811a1e ("ASoC: sun4i-i2s: Add support for H3")
Signed-off-by: Yong Deng <yong.deng(a)magewell.com>
Reviewed-by: Chen-Yu Tsai <wens(a)csie.org>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/sunxi/sun4i-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index dca1143c1150..a4aa931ebfae 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -104,7 +104,7 @@
#define SUN8I_I2S_CHAN_CFG_REG 0x30
#define SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM_MASK GENMASK(6, 4)
-#define SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM(chan) (chan - 1)
+#define SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM(chan) ((chan - 1) << 4)
#define SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK GENMASK(2, 0)
#define SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM(chan) (chan - 1)
--
2.16.1
commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.
Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.
To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.
Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable <stable(a)vger.kernel.org> # 3.18
Acked-by: Murali Karicheri <m-karicheri2(a)ti.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
[lorenzo.pieralisi(a)arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
[johan: backport to 4.4]
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/pci/host/pci-keystone.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c
index 0aa81bd3de12..fb682e8af74d 100644
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -179,14 +179,16 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie,
}
/* interrupt controller is in a child node */
- *np_temp = of_find_node_by_name(np_pcie, controller);
+ *np_temp = of_get_child_by_name(np_pcie, controller);
if (!(*np_temp)) {
dev_err(dev, "Node for %s is absent\n", controller);
goto out;
}
temp = of_irq_count(*np_temp);
- if (!temp)
+ if (!temp) {
+ of_node_put(*np_temp);
goto out;
+ }
if (temp > max_host_irqs)
dev_warn(dev, "Too many %s interrupts defined %u\n",
(legacy ? "legacy" : "MSI"), temp);
@@ -200,6 +202,9 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie,
if (!host_irqs[temp])
break;
}
+
+ of_node_put(*np_temp);
+
if (temp) {
*num_irqs = temp;
ret = 0;
--
2.16.2
Changes since v1 [1]:
* Fix the detection of device-dax file instances in vma_is_fsdax().
(Haozhong, Gerd)
* Fix compile breakage in the FS_DAX=n and DEV_DAX=y case. (0day robot)
[1]: https://lists.01.org/pipermail/linux-nvdimm/2018-February/014046.html
---
The vfio interface, like RDMA, wants to setup long term (indefinite)
pins of the pages backing an address range so that a guest or userspace
driver can perform DMA to the with physical address. Given that this
pinning may lead to filesystem operations deadlocking in the
filesystem-dax case, the pinning request needs to be rejected.
The longer term fix for vfio, RDMA, and any other long term pin user, is
to provide a 'pin with lease' mechanism. Similar to the leases that are
hold for pNFS RDMA layouts, this userspace lease gives the kernel a way
to notify userspace that the block layout of the file is changing and
the kernel is revoking access to pinned pages.
---
Dan Williams (5):
dax: fix vma_is_fsdax() helper
dax: fix dax_mapping() definition in the FS_DAX=n + DEV_DAX=y case
dax: fix S_DAX definition
dax: short circuit vma_is_fsdax() in the CONFIG_FS_DAX=n case
vfio: disable filesystem-dax page pinning
drivers/vfio/vfio_iommu_type1.c | 18 +++++++++++++++---
include/linux/dax.h | 9 ++++++---
include/linux/fs.h | 6 ++++--
3 files changed, 25 insertions(+), 8 deletions(-)
The backport of commit aa8a5e0062ac ("powerpc/64s: Add support for RFI
flush of L1-D cache"), incorrectly placed the new RFI flush code
inside an existing #ifdef CONFIG_HARDLOCKUP_DETECTOR block.
This has the obvious effect of requiring HARDLOCKUP_DETECTOR to be
enabled in order for RFI flush to be enabled, which is a bug.
Fix it by moving the #endif up to where it belongs.
Fixes: c3892946315e ("powerpc/64s: Add support for RFI flush of L1-D cache")
Reported-by: Bernhard Kaindl <bernhard.kaindl(a)thalesgroup.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
---
arch/powerpc/kernel/setup_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index df4a87eb8da4..9eb469bed22b 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -835,6 +835,7 @@ static int __init disable_hardlockup_detector(void)
return 0;
}
early_initcall(disable_hardlockup_detector);
+#endif
#ifdef CONFIG_PPC_BOOK3S_64
static enum l1d_flush_type enabled_flush_types;
@@ -973,4 +974,3 @@ ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, cha
return sprintf(buf, "Vulnerable\n");
}
#endif /* CONFIG_PPC_BOOK3S_64 */
-#endif
--
2.14.1
This is a note to let you know that I've just added the patch titled
netfilter: drop outermost socket lock in getsockopt()
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:
netfilter-drop-outermost-socket-lock-in-getsockopt.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 01ea306f2ac2baff98d472da719193e738759d93 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 8 Feb 2018 12:19:00 +0100
Subject: netfilter: drop outermost socket lock in getsockopt()
From: Paolo Abeni <pabeni(a)redhat.com>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <lucien.xin(a)gmail.com>
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d(a)syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 7 +------
net/ipv6/ipv6_sockglue.c | 10 ++--------
2 files changed, 3 insertions(+), 14 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1552,10 +1552,7 @@ int ip_getsockopt(struct sock *sk, int l
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
return err;
@@ -1587,9 +1584,7 @@ int compat_ip_getsockopt(struct sock *sk
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
- release_sock(sk);
if (err >= 0)
err = put_user(len, optlen);
return err;
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1343,10 +1343,7 @@ int ipv6_getsockopt(struct sock *sk, int
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET6, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
@@ -1385,10 +1382,7 @@ int compat_ipv6_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = compat_nf_getsockopt(sk, PF_INET6,
- optname, optval, &len);
- release_sock(sk);
+ err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.9/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
This is a note to let you know that I've just added the patch titled
netfilter: drop outermost socket lock in getsockopt()
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:
netfilter-drop-outermost-socket-lock-in-getsockopt.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 01ea306f2ac2baff98d472da719193e738759d93 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 8 Feb 2018 12:19:00 +0100
Subject: netfilter: drop outermost socket lock in getsockopt()
From: Paolo Abeni <pabeni(a)redhat.com>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <lucien.xin(a)gmail.com>
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d(a)syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 7 +------
net/ipv6/ipv6_sockglue.c | 10 ++--------
2 files changed, 3 insertions(+), 14 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1527,10 +1527,7 @@ int ip_getsockopt(struct sock *sk, int l
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
return err;
@@ -1562,9 +1559,7 @@ int compat_ip_getsockopt(struct sock *sk
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
- release_sock(sk);
if (err >= 0)
err = put_user(len, optlen);
return err;
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1340,10 +1340,7 @@ int ipv6_getsockopt(struct sock *sk, int
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET6, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
@@ -1382,10 +1379,7 @@ int compat_ipv6_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = compat_nf_getsockopt(sk, PF_INET6,
- optname, optval, &len);
- release_sock(sk);
+ err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.4/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
This is a note to let you know that I've just added the patch titled
netfilter: drop outermost socket lock in getsockopt()
to the 4.15-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:
netfilter-drop-outermost-socket-lock-in-getsockopt.patch
and it can be found in the queue-4.15 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 01ea306f2ac2baff98d472da719193e738759d93 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 8 Feb 2018 12:19:00 +0100
Subject: netfilter: drop outermost socket lock in getsockopt()
From: Paolo Abeni <pabeni(a)redhat.com>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <lucien.xin(a)gmail.com>
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d(a)syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 7 +------
net/ipv6/ipv6_sockglue.c | 10 ++--------
2 files changed, 3 insertions(+), 14 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1563,10 +1563,7 @@ int ip_getsockopt(struct sock *sk, int l
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
return err;
@@ -1598,9 +1595,7 @@ int compat_ip_getsockopt(struct sock *sk
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
- release_sock(sk);
if (err >= 0)
err = put_user(len, optlen);
return err;
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1367,10 +1367,7 @@ int ipv6_getsockopt(struct sock *sk, int
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET6, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
@@ -1409,10 +1406,7 @@ int compat_ipv6_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = compat_nf_getsockopt(sk, PF_INET6,
- optname, optval, &len);
- release_sock(sk);
+ err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.15/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
This is a note to let you know that I've just added the patch titled
netfilter: drop outermost socket lock in getsockopt()
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:
netfilter-drop-outermost-socket-lock-in-getsockopt.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 01ea306f2ac2baff98d472da719193e738759d93 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 8 Feb 2018 12:19:00 +0100
Subject: netfilter: drop outermost socket lock in getsockopt()
From: Paolo Abeni <pabeni(a)redhat.com>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <lucien.xin(a)gmail.com>
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d(a)syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 7 +------
net/ipv6/ipv6_sockglue.c | 10 ++--------
2 files changed, 3 insertions(+), 14 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1563,10 +1563,7 @@ int ip_getsockopt(struct sock *sk, int l
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
return err;
@@ -1598,9 +1595,7 @@ int compat_ip_getsockopt(struct sock *sk
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
- release_sock(sk);
if (err >= 0)
err = put_user(len, optlen);
return err;
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1355,10 +1355,7 @@ int ipv6_getsockopt(struct sock *sk, int
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET6, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
@@ -1397,10 +1394,7 @@ int compat_ipv6_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = compat_nf_getsockopt(sk, PF_INET6,
- optname, optval, &len);
- release_sock(sk);
+ err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.14/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
This is a note to let you know that I've just added the patch titled
netfilter: drop outermost socket lock in getsockopt()
to the 3.18-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:
netfilter-drop-outermost-socket-lock-in-getsockopt.patch
and it can be found in the queue-3.18 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 01ea306f2ac2baff98d472da719193e738759d93 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu, 8 Feb 2018 12:19:00 +0100
Subject: netfilter: drop outermost socket lock in getsockopt()
From: Paolo Abeni <pabeni(a)redhat.com>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <lucien.xin(a)gmail.com>
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Reported-by: syzbot+ddde1c7b7ff7442d7f2d(a)syzkaller.appspotmail.com
Suggested-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 7 +------
net/ipv6/ipv6_sockglue.c | 10 ++--------
2 files changed, 3 insertions(+), 14 deletions(-)
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1375,10 +1375,7 @@ int ip_getsockopt(struct sock *sk, int l
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
return err;
@@ -1410,9 +1407,7 @@ int compat_ip_getsockopt(struct sock *sk
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
err = compat_nf_getsockopt(sk, PF_INET, optname, optval, &len);
- release_sock(sk);
if (err >= 0)
err = put_user(len, optlen);
return err;
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1314,10 +1314,7 @@ int ipv6_getsockopt(struct sock *sk, int
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = nf_getsockopt(sk, PF_INET6, optname, optval,
- &len);
- release_sock(sk);
+ err = nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
@@ -1356,10 +1353,7 @@ int compat_ipv6_getsockopt(struct sock *
if (get_user(len, optlen))
return -EFAULT;
- lock_sock(sk);
- err = compat_nf_getsockopt(sk, PF_INET6,
- optname, optval, &len);
- release_sock(sk);
+ err = compat_nf_getsockopt(sk, PF_INET6, optname, optval, &len);
if (err >= 0)
err = put_user(len, optlen);
}
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-3.18/netfilter-drop-outermost-socket-lock-in-getsockopt.patch
From: Jack Wang <jinpu.wang(a)profitbricks.com>
Hi Greg,
I notice there are some stable bugfix missing on stable-4.4, so I did
backport from 4.9, most of them are simple cherry-pick, some need to
adjust context a bit, I did some regression tests/ltp/kvm-unit-tests,
looks fine, there are still some patches to port, not sure if worth the
effort.
Note: patches base on 4.4.117
Thanks,
Jack Wang
Andi Kleen (1):
module/retpoline: Warn about missing retpoline in module
Borislav Petkov (2):
x86/nospec: Fix header guards names
x86/bugs: Drop one "mitigation" from dmesg
Colin Ian King (1):
x86/spectre: Fix spelling mistake: "vunerable"-> "vulnerable"
Dan Williams (9):
array_index_nospec: Sanitize speculative array de-references
x86: Implement array_index_mask_nospec
x86: Introduce barrier_nospec
x86/get_user: Use pointer masking to limit speculation
x86/syscall: Sanitize syscall table de-references under speculation
vfs, fdtable: Prevent bounds-check bypass via speculative execution
nl80211: Sanitize array index in parse_txq_params
x86/spectre: Report get_user mitigation for spectre_v1
x86/kvm: Update spectre-v1 mitigation
Darren Kenny (1):
x86/speculation: Fix typo IBRS_ATT, which should be IBRS_ALL
David Hildenbrand (2):
KVM: nVMX: kmap() can't fail
KVM: nVMX: vmx_complete_nested_posted_interrupt() can't fail
David Woodhouse (1):
x86/retpoline: Avoid retpolines for built-in __init functions
Dou Liyang (1):
x86/spectre: Check CONFIG_RETPOLINE in command line parser
Jan Dakinevich (2):
KVM: VMX: clean up declaration of VPID/EPT invalidation types
KVM: nVMX: invvpid handling improvements
Jim Mattson (1):
kvm: nVMX: Fix kernel panics induced by illegal INVEPT/INVVPID types
Josh Poimboeuf (1):
x86/paravirt: Remove 'noreplace-paravirt' cmdline option
KarimAllah Ahmed (1):
x86/spectre: Simplify spectre_v2 command line parsing
Mark Rutland (1):
Documentation: Document array_index_nospec
Peter Zijlstra (2):
KVM: x86: Make indirect calls in emulator speculation safe
KVM: VMX: Make indirect call speculation safe
Thomas Gleixner (1):
x86/cpu/bugs: Make retpoline module warning conditional
Waiman Long (1):
x86/retpoline: Remove the esp/rsp thunk
Wanpeng Li (1):
KVM: async_pf: Fix #DF due to inject "Page not Present" and "Page
Ready" exceptions simultaneously
Documentation/kernel-parameters.txt | 2 -
Documentation/speculation.txt | 90 +++++++++++++++++++++++++
arch/x86/entry/common.c | 2 +
arch/x86/include/asm/asm-prototypes.h | 1 -
arch/x86/include/asm/barrier.h | 28 ++++++++
arch/x86/include/asm/msr.h | 3 +-
arch/x86/include/asm/nospec-branch.h | 8 +--
arch/x86/include/asm/vmx.h | 5 +-
arch/x86/kernel/alternative.c | 14 ----
arch/x86/kernel/cpu/bugs.c | 122 ++++++++++++++++++++++++----------
arch/x86/kvm/emulate.c | 9 +--
arch/x86/kvm/vmx.c | 83 +++++++++++------------
arch/x86/kvm/x86.c | 34 +++++++---
arch/x86/lib/getuser.S | 10 +++
arch/x86/lib/retpoline.S | 1 -
include/linux/fdtable.h | 5 +-
include/linux/init.h | 9 ++-
include/linux/module.h | 9 +++
include/linux/nospec.h | 72 ++++++++++++++++++++
kernel/module.c | 11 +++
net/wireless/nl80211.c | 9 ++-
scripts/mod/modpost.c | 9 +++
22 files changed, 417 insertions(+), 119 deletions(-)
create mode 100644 Documentation/speculation.txt
create mode 100644 include/linux/nospec.h
--
2.7.4
This is the start of the stable review cycle for the 4.15.6 release.
There are 45 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 Feb 25 17:06:43 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.6-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.15.6-rc1
Michal Hocko <mhocko(a)suse.com>
vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
Tomas Winkler <tomas.winkler(a)intel.com>
mei: me: add cannon point device ids for 4th device
Alexander Usyskin <alexander.usyskin(a)intel.com>
mei: me: add cannon point device ids
Kamil Konieczny <k.konieczny(a)partner.samsung.com>
crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
Shuah Khan <shuah(a)kernel.org>
usbip: keep usbip_device sockfd state in sync with tcp_socket
Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
xhci: fix xhci debugfs errors in xhci_stop
Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
xhci: xhci debugfs device nodes weren't removed after device plugged out
Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
xhci: Fix xhci debugfs devices node disappearance after hibernation
Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
xhci: Fix NULL pointer in xhci debugfs
Alexandru Ardelean <alexandru.ardelean(a)analog.com>
staging: iio: ad5933: switch buffer mode to software
Alexandru Ardelean <alexandru.ardelean(a)analog.com>
staging: iio: adc: ad7192: fix external frequency setting
Arnd Bergmann <arnd(a)arndb.de>
staging: fsl-mc: fix build testing on x86
Todd Kjos <tkjos(a)android.com>
binder: replace "%p" with "%pK"
Eric Biggers <ebiggers(a)google.com>
binder: check for binder_thread allocation failure in binder_poll()
Ben Hutchings <ben(a)decadent.org.uk>
staging: android: ashmem: Fix a race condition in pin ioctls
Martijn Coenen <maco(a)android.com>
ANDROID: binder: synchronize_rcu() when using POLLFREE.
Todd Kjos <tkjos(a)android.com>
ANDROID: binder: remove WARN() for redundant txn error
Paolo Abeni <pabeni(a)redhat.com>
dn_getsockoptdecnet: move nf_{get/set}sockopt outside sock lock
Arnd Bergmann <arnd(a)arndb.de>
arm64: dts: add #cooling-cells to CPU nodes
Arnd Bergmann <arnd(a)arndb.de>
ARM: 8743/1: bL_switcher: add MODULE_LICENSE tag
Arnd Bergmann <arnd(a)arndb.de>
video: fbdev/mmp: add MODULE_LICENSE
Arnd Bergmann <arnd(a)arndb.de>
ASoC: ux500: add MODULE_LICENSE tag
Jesse Chan <jc(a)linux.com>
soc: qcom: rmtfs_mem: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Eric Dumazet <edumazet(a)google.com>
net_sched: gen_estimator: fix lockdep splat
Willem de Bruijn <willemb(a)google.com>
net: avoid skb_warn_bad_offload on IS_ERR
Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete
Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
rds: tcp: correctly sequence cleanup on netns deletion.
Cong Wang <xiyou.wangcong(a)gmail.com>
netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
Cong Wang <xiyou.wangcong(a)gmail.com>
netfilter: xt_cgroup: initialize info->priv in cgroup_mt_check_v1()
Paolo Abeni <pabeni(a)redhat.com>
netfilter: on sockopt() acquire sock lock only in the required scope
Dmitry Vyukov <dvyukov(a)google.com>
netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
Eric Dumazet <edumazet(a)google.com>
netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
Dmitry Vyukov <dvyukov(a)google.com>
netfilter: x_tables: fix int overflow in xt_alloc_table_info()
Dmitry Vyukov <dvyukov(a)google.com>
kcov: detect double association with a single task
Wanpeng Li <wanpeng.li(a)hotmail.com>
KVM: x86: fix escape of guest dr6 to the host
Douglas Gilbert <dgilbert(a)interlog.com>
blk_rq_map_user_iov: fix error override
Laura Abbott <labbott(a)redhat.com>
staging: android: ion: Switch from WARN to pr_warn
Laura Abbott <labbott(a)redhat.com>
staging: android: ion: Add __GFP_NOWARN for system contig heap
Eric Biggers <ebiggers(a)google.com>
crypto: x86/twofish-3way - Fix %rbp usage
Andrey Konovalov <andreyknvl(a)google.com>
media: pvrusb2: properly check endpoint types
Paul Moore <paul(a)paul-moore.com>
selinux: skip bounded transition processing if the policy isn't loaded
Paul Moore <paul(a)paul-moore.com>
selinux: ensure the context is NUL terminated in security_context_to_sid_core()
Jason Wang <jasowang(a)redhat.com>
ptr_ring: try vmalloc() when kmalloc() fails
Jason Wang <jasowang(a)redhat.com>
ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE
Eric Dumazet <edumazet(a)google.com>
tun: fix tun_napi_alloc_frags() frag allocator
-------------
Diffstat:
Makefile | 4 +-
arch/arm/common/bL_switcher_dummy_if.c | 4 +
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +
arch/x86/crypto/twofish-x86_64-asm_64-3way.S | 112 +++++++++++++-----------
arch/x86/kvm/x86.c | 6 ++
block/blk-map.c | 4 +-
drivers/android/binder.c | 29 ++++--
drivers/crypto/s5p-sss.c | 12 ++-
drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 12 +++
drivers/misc/mei/hw-me-regs.h | 5 ++
drivers/misc/mei/pci-me.c | 5 ++
drivers/net/tun.c | 16 ++--
drivers/soc/qcom/rmtfs_mem.c | 4 +
drivers/staging/android/ashmem.c | 19 ++--
drivers/staging/android/ion/ion-ioctl.c | 4 +-
drivers/staging/android/ion/ion_system_heap.c | 2 +-
drivers/staging/fsl-mc/bus/Kconfig | 2 +-
drivers/staging/iio/adc/ad7192.c | 27 ++++--
drivers/staging/iio/impedance-analyzer/ad5933.c | 4 +-
drivers/usb/host/xhci-debugfs.c | 4 +-
drivers/usb/host/xhci.c | 10 +--
drivers/usb/usbip/stub_dev.c | 3 +
drivers/usb/usbip/vhci_hcd.c | 2 +
drivers/video/fbdev/mmp/core.c | 5 ++
include/linux/ptr_ring.h | 15 ++--
kernel/kcov.c | 4 +-
mm/vmalloc.c | 10 ++-
net/core/dev.c | 2 +-
net/core/gen_estimator.c | 4 +
net/decnet/af_decnet.c | 62 +++++++------
net/ipv4/ip_sockglue.c | 14 +--
net/ipv4/netfilter/ipt_CLUSTERIP.c | 16 +++-
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 6 +-
net/ipv6/ipv6_sockglue.c | 17 ++--
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 18 ++--
net/netfilter/x_tables.c | 9 +-
net/netfilter/xt_RATEEST.c | 22 +++--
net/netfilter/xt_cgroup.c | 1 +
net/rds/connection.c | 3 +-
net/rds/rds.h | 6 +-
net/rds/tcp.c | 13 ++-
net/rds/tcp.h | 1 +
security/selinux/ss/services.c | 21 ++---
sound/soc/ux500/mop500.c | 4 +
sound/soc/ux500/ux500_pcm.c | 5 ++
45 files changed, 348 insertions(+), 202 deletions(-)
In commit c713fb071edc ("rtlwifi: rtl8821ae: Fix connection lost problem
correctly") a problem in rtl8821ae that caused loss of signal was fixed.
That same problem has now been reported for rtl8723be. Accordingly,
the ASPM L1 latency has been increased from 0 to 7 to fix the instability.
Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net>
Cc: Stable <stable(a)vger.kernel.org>
---
Kalle,
This patch should be sent to 4.16.
Thanks,
Larry
---
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index f9ccd13c79f9..e7bbbc95cdb1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -1125,7 +1125,8 @@ static void _rtl8723be_enable_aspm_back_door(struct ieee80211_hw *hw)
/* Configuration Space offset 0x70f BIT7 is used to control L0S */
tmp8 = _rtl8723be_dbi_read(rtlpriv, 0x70f);
- _rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7));
+ _rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7) |
+ ASPM_L1_LATENCY << 3);
/* Configuration Space offset 0x719 Bit3 is for L1
* BIT4 is for clock request
--
2.16.2
On Sat, Feb 24, 2018 at 11:41:01AM +0000, Harsh Shandilya wrote:
> On Sat 24 Feb, 2018, 12:01 AM Greg Kroah-Hartman, <
> gregkh(a)linuxfoundation.org> wrote:
>
> > This is the start of the stable review cycle for the 3.18.96 release.
> > There are 58 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 Feb 25 17:01:41 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.96-rc…
> > or in the git tree and branch at:
> > git://
> > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > linux-3.18.y
> > and the diffstat can be found below.
> >
>
> Clean merge into the msm-3.18 CAF tree, no regressions noticed on the
> OnePlus 3T. Thanks for the update :)
Great, thanks for testing and letting me know.
greg k-h
This is the start of the stable review cycle for the 3.18.96 release.
There are 58 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 Feb 25 17:01:41 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.96-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 3.18.96-rc1
Kamil Konieczny <k.konieczny(a)partner.samsung.com>
crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
Wanpeng Li <wanpeng.li(a)hotmail.com>
KVM: async_pf: Fix #DF due to inject "Page not Present" and "Page Ready" exceptions simultaneously
Jia-Ju Bai <baijiaju1990(a)163.com>
hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close
Jan Beulich <JBeulich(a)suse.com>
xen: XEN_ACPI_PROCESSOR is Dom0-only
Karol Herbst <kherbst(a)redhat.com>
x86/mm/kmmio: Fix mmiotrace for page unaligned addresses
Dave Young <dyoung(a)redhat.com>
mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep
Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
dmaengine: jz4740: disable/unprepare clk if probe fails
Steffen Klassert <steffen.klassert(a)secunet.com>
xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies.
Takuo Koguchi <takuo.koguchi(a)gmail.com>
spi: sun4i: disable clocks in the remove function
Eric Biggers <ebiggers3(a)gmail.com>
509: fix printing uninitialized stack memory when OID is empty
Nikolay Borisov <nborisov(a)suse.com>
btrfs: Fix possible off-by-one in btrfs_search_path_in_tree
Nogah Frankel <nogahf(a)mellanox.com>
net_sched: red: Avoid illegal values
Nogah Frankel <nogahf(a)mellanox.com>
net_sched: red: Avoid devision by zero
Zumeng Chen <zumeng.chen(a)gmail.com>
gianfar: fix a flooded alignment reports because of padding issue.
Stefan Haberland <sth(a)linux.vnet.ibm.com>
s390/dasd: prevent prefix I/O error
Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com>
powerpc/perf: Fix oops when grouping different pmu events
Greg Ungerer <gerg(a)linux-m68k.org>
m68k: add missing SOFTIRQENTRY_TEXT linker section
Will Deacon <will.deacon(a)arm.com>
scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none
Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
media: s5k6aa: describe some function parameters
Satheesh Rajendran <sathnaga(a)linux.vnet.ibm.com>
perf bench numa: Fixup discontiguous/sparse numa nodes
Jiri Olsa <jolsa(a)kernel.org>
perf top: Fix window dimensions change handling
Peter Ujfalusi <peter.ujfalusi(a)ti.com>
ARM: dts: am4372: Correct the interrupts_properties of McASP
Keerthy <j-keerthy(a)ti.com>
ARM: AM33xx: PRM: Remove am33xx_pwrdm_read_prev_pwrst function
Randy Dunlap <rdunlap(a)infradead.org>
usb: build drivers/usb/common/ when USB_SUPPORT is set
Shuah Khan <shuahkh(a)osg.samsung.com>
usbip: keep usbip_device sockfd state in sync with tcp_socket
Paolo Abeni <pabeni(a)redhat.com>
dn_getsockoptdecnet: move nf_{get/set}sockopt outside sock lock
Arnd Bergmann <arnd(a)arndb.de>
video: fbdev/mmp: add MODULE_LICENSE
Arnd Bergmann <arnd(a)arndb.de>
ASoC: ux500: add MODULE_LICENSE tag
Paul Moore <paul(a)paul-moore.com>
selinux: ensure the context is NUL terminated in security_context_to_sid_core()
David Howells <dhowells(a)redhat.com>
Provide a function to create a NUL-terminated string from unterminated data
Willem de Bruijn <willemb(a)google.com>
net: avoid skb_warn_bad_offload on IS_ERR
Cong Wang <xiyou.wangcong(a)gmail.com>
netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
Paolo Abeni <pabeni(a)redhat.com>
netfilter: on sockopt() acquire sock lock only in the required scope
Dmitry Vyukov <dvyukov(a)google.com>
netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
Eric Dumazet <edumazet(a)google.com>
netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
Dmitry Vyukov <dvyukov(a)google.com>
netfilter: x_tables: fix int overflow in xt_alloc_table_info()
Laura Abbott <labbott(a)redhat.com>
staging: android: ion: Add __GFP_NOWARN for system contig heap
Eric Biggers <ebiggers(a)google.com>
crypto: x86/twofish-3way - Fix %rbp usage
Paul Moore <paul(a)paul-moore.com>
selinux: skip bounded transition processing if the policy isn't loaded
Cong Wang <xiyou.wangcong(a)gmail.com>
xfrm: check id proto in validate_tmpl()
Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
mm,vmscan: Make unregister_shrinker() no-op if register_shrinker() failed.
Arnd Bergmann <arnd(a)arndb.de>
media: r820t: fix r820t_write_reg for KASAN
Arnd Bergmann <arnd(a)arndb.de>
ARM: dts: s5pv210: add interrupt-parent for ohci
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix racy pool initializations
Liu Bo <bo.li.liu(a)oracle.com>
Btrfs: fix crash due to not cleaning up tree log block's dirty bits
Liu Bo <bo.li.liu(a)oracle.com>
Btrfs: fix deadlock in run_delalloc_nocow
Nicolas Pitre <nicolas.pitre(a)linaro.org>
console/dummy: leave .con_font_get set to NULL
Johan Hovold <johan(a)kernel.org>
video: fbdev: atmel_lcdfb: fix display-timings lookup
Ernesto A. Fernández <ernesto.mnd.fernandez(a)gmail.com>
ext4: correct documentation for grpid mount option
Zhouyi Zhou <zhouzhouyi(a)gmail.com>
ext4: save error to disk in __ext4_grp_locked_error()
Julia Lawall <Julia.Lawall(a)lip6.fr>
drm/radeon: adjust tested variable
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix regression by incorrect ioctl_mutex usages
Viresh Kumar <viresh.kumar(a)linaro.org>
arm: spear13xx: Fix spics gpio controller's warning
Viresh Kumar <viresh.kumar(a)linaro.org>
arm: spear13xx: Fix dmas cells
Viresh Kumar <viresh.kumar(a)linaro.org>
arm: spear600: Add missing interrupt-parent of rtc
Eugene Syromiatnikov <esyr(a)redhat.com>
s390: fix handling of -1 in set{,fs}[gu]id16 syscalls
Bjorn Andersson <bjorn.andersson(a)linaro.org>
PM / devfreq: Propagate error from devfreq_add_device()
Jack Morgenstein <jackm(a)dev.mellanox.co.il>
IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports
-------------
Diffstat:
Documentation/devicetree/bindings/dma/snps-dma.txt | 2 +-
Documentation/filesystems/ext4.txt | 2 +-
Makefile | 4 +-
arch/arm/boot/dts/am4372.dtsi | 6 +-
arch/arm/boot/dts/s5pv210.dtsi | 1 +
arch/arm/boot/dts/spear1310-evb.dts | 2 +-
arch/arm/boot/dts/spear1340.dtsi | 4 +-
arch/arm/boot/dts/spear13xx.dtsi | 6 +-
arch/arm/boot/dts/spear600.dtsi | 1 +
arch/arm/mach-omap2/prm33xx.c | 12 ---
arch/m68k/kernel/vmlinux-nommu.lds | 2 +
arch/m68k/kernel/vmlinux-std.lds | 2 +
arch/m68k/kernel/vmlinux-sun3.lds | 2 +
arch/powerpc/perf/core-book3s.c | 4 +-
arch/s390/kernel/compat_linux.c | 8 +-
arch/x86/crypto/twofish-x86_64-asm_64-3way.S | 112 +++++++++++----------
arch/x86/kvm/x86.c | 34 +++++--
arch/x86/mm/ioremap.c | 4 +-
arch/x86/mm/kmmio.c | 12 ++-
drivers/Makefile | 1 +
drivers/crypto/s5p-sss.c | 13 ++-
drivers/devfreq/devfreq.c | 2 +-
drivers/dma/dma-jz4740.c | 4 +-
drivers/gpu/drm/radeon/radeon_uvd.c | 2 +-
drivers/infiniband/hw/mlx4/main.c | 13 +--
drivers/media/i2c/s5k6aa.c | 5 +
drivers/media/tuners/r820t.c | 13 ++-
drivers/net/ethernet/freescale/gianfar.c | 6 +-
drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +
drivers/net/hippi/rrunner.c | 2 +-
drivers/s390/block/dasd_eckd.c | 16 +--
drivers/spi/spi-sun4i.c | 2 +-
drivers/staging/android/ion/ion_system_heap.c | 2 +-
drivers/usb/usbip/stub_dev.c | 3 +
drivers/usb/usbip/vhci_hcd.c | 2 +
drivers/video/console/dummycon.c | 1 -
drivers/video/fbdev/atmel_lcdfb.c | 8 +-
drivers/video/fbdev/mmp/core.c | 5 +
drivers/xen/Kconfig | 2 +-
fs/btrfs/inode.c | 5 +-
fs/btrfs/ioctl.c | 2 +-
fs/btrfs/tree-log.c | 9 ++
fs/ext4/super.c | 1 +
include/linux/string.h | 1 +
include/net/red.h | 13 ++-
lib/oid_registry.c | 8 +-
mm/early_ioremap.c | 2 +-
mm/util.c | 24 +++++
mm/vmscan.c | 3 +
net/core/dev.c | 2 +-
net/decnet/af_decnet.c | 62 ++++++------
net/ipv4/ip_sockglue.c | 14 +--
net/ipv4/netfilter/ipt_CLUSTERIP.c | 16 ++-
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 6 +-
net/ipv6/ipv6_sockglue.c | 17 +---
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 18 ++--
net/netfilter/x_tables.c | 10 +-
net/netfilter/xt_RATEEST.c | 22 +++-
net/sched/sch_choke.c | 3 +
net/sched/sch_gred.c | 3 +
net/sched/sch_red.c | 2 +
net/sched/sch_sfq.c | 3 +
net/xfrm/xfrm_user.c | 24 +++++
scripts/kernel-doc | 2 +-
security/selinux/ss/services.c | 21 ++--
sound/core/seq/seq_clientmgr.c | 23 +++--
sound/soc/ux500/mop500.c | 4 +
sound/soc/ux500/ux500_pcm.c | 5 +
tools/perf/bench/numa.c | 56 ++++++++++-
tools/perf/builtin-top.c | 15 ++-
70 files changed, 485 insertions(+), 236 deletions(-)
This is a note to let you know that I've just added the patch titled
net: dst_cache_per_cpu_dst_set() can be static
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:
net-dst_cache_per_cpu_dst_set-can-be-static.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 b73f96fcb49ec90c2f837719893e7b25fcdf08d8 Mon Sep 17 00:00:00 2001
From: Wu Fengguang <fengguang.wu(a)intel.com>
Date: Fri, 18 Mar 2016 23:27:28 +0800
Subject: net: dst_cache_per_cpu_dst_set() can be static
From: Wu Fengguang <fengguang.wu(a)intel.com>
commit b73f96fcb49ec90c2f837719893e7b25fcdf08d8 upstream.
Signed-off-by: Fengguang Wu <fengguang.wu(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/dst_cache.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/net/core/dst_cache.c
+++ b/net/core/dst_cache.c
@@ -28,8 +28,8 @@ struct dst_cache_pcpu {
};
};
-void dst_cache_per_cpu_dst_set(struct dst_cache_pcpu *dst_cache,
- struct dst_entry *dst, u32 cookie)
+static void dst_cache_per_cpu_dst_set(struct dst_cache_pcpu *dst_cache,
+ struct dst_entry *dst, u32 cookie)
{
dst_release(dst_cache->dst);
if (dst)
@@ -39,8 +39,8 @@ void dst_cache_per_cpu_dst_set(struct ds
dst_cache->dst = dst;
}
-struct dst_entry *dst_cache_per_cpu_get(struct dst_cache *dst_cache,
- struct dst_cache_pcpu *idst)
+static struct dst_entry *dst_cache_per_cpu_get(struct dst_cache *dst_cache,
+ struct dst_cache_pcpu *idst)
{
struct dst_entry *dst;
Patches currently in stable-queue which might be from fengguang.wu(a)intel.com are
queue-4.4/net-dst_cache_per_cpu_dst_set-can-be-static.patch
queue-4.4/video-use-bool-instead-int-pointer-for-get_opt_bool-argument.patch
queue-4.4/staging-wilc1000-fix-kbuild-test-robot-error.patch
queue-4.4/serial-8250_mid-fix-broken-dma-dependency.patch
Guests on new hypersiors might set KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT
bit when enabling async_PF, but this bit is reserved on old hypervisors,
which results in a failure upon migration.
To avoid breaking different cases, we are checking for CPUID feature bit
before enabling the feature and nothing else.
Fixes: 52a5c155cf79 ("KVM: async_pf: Let guest support delivery of async_pf from guest mode")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
---
v2:
* added documentation [Paolo]
* retained compatibility recent kernels [Paolo]
---
Documentation/virtual/kvm/cpuid.txt | 4 ++++
Documentation/virtual/kvm/msr.txt | 3 ++-
arch/x86/include/uapi/asm/kvm_para.h | 1 +
arch/x86/kernel/kvm.c | 8 ++++----
arch/x86/kvm/cpuid.c | 3 ++-
5 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
index dcab6dc11e3b..87a7506f31c2 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -58,6 +58,10 @@ KVM_FEATURE_PV_TLB_FLUSH || 9 || guest checks this feature bit
|| || before enabling paravirtualized
|| || tlb flush.
------------------------------------------------------------------------------
+KVM_FEATURE_ASYNC_PF_VMEXIT || 10 || paravirtualized async PF VM exit
+ || || can be enabled by setting bit 2
+ || || when writing to msr 0x4b564d02
+------------------------------------------------------------------------------
KVM_FEATURE_CLOCKSOURCE_STABLE_BIT || 24 || host will warn if no guest-side
|| || per-cpu warps are expected in
|| || kvmclock.
diff --git a/Documentation/virtual/kvm/msr.txt b/Documentation/virtual/kvm/msr.txt
index 1ebecc115dc6..f3f0d57ced8e 100644
--- a/Documentation/virtual/kvm/msr.txt
+++ b/Documentation/virtual/kvm/msr.txt
@@ -170,7 +170,8 @@ MSR_KVM_ASYNC_PF_EN: 0x4b564d02
when asynchronous page faults are enabled on the vcpu 0 when
disabled. Bit 1 is 1 if asynchronous page faults can be injected
when vcpu is in cpl == 0. Bit 2 is 1 if asynchronous page faults
- are delivered to L1 as #PF vmexits.
+ are delivered to L1 as #PF vmexits. Bit 2 can be set only if
+ KVM_FEATURE_ASYNC_PF_VMEXIT is present in CPUID.
First 4 byte of 64 byte memory location will be written to by
the hypervisor at the time of asynchronous page fault (APF)
diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h
index 7a2ade4aa235..6cfa9c8cb7d6 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -26,6 +26,7 @@
#define KVM_FEATURE_PV_EOI 6
#define KVM_FEATURE_PV_UNHALT 7
#define KVM_FEATURE_PV_TLB_FLUSH 9
+#define KVM_FEATURE_ASYNC_PF_VMEXIT 10
/* The last 8 bits are used to indicate how to interpret the flags field
* in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 4e37d1a851a6..971babe964d2 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -341,10 +341,10 @@ static void kvm_guest_cpu_init(void)
#endif
pa |= KVM_ASYNC_PF_ENABLED;
- /* Async page fault support for L1 hypervisor is optional */
- if (wrmsr_safe(MSR_KVM_ASYNC_PF_EN,
- (pa | KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT) & 0xffffffff, pa >> 32) < 0)
- wrmsrl(MSR_KVM_ASYNC_PF_EN, pa);
+ if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF_VMEXIT))
+ pa |= KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT;
+
+ wrmsrl(MSR_KVM_ASYNC_PF_EN, pa);
__this_cpu_write(apf_reason.enabled, 1);
printk(KERN_INFO"KVM setup async PF for cpu %d\n",
smp_processor_id());
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 20e491b94f44..7fc04a176c57 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -604,7 +604,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
(1 << KVM_FEATURE_PV_EOI) |
(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
(1 << KVM_FEATURE_PV_UNHALT) |
- (1 << KVM_FEATURE_PV_TLB_FLUSH);
+ (1 << KVM_FEATURE_PV_TLB_FLUSH) |
+ (1 << KVM_FEATURE_ASYNC_PF_VMEXIT);
if (sched_info_on())
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
--
2.15.1