This is a note to let you know that I've just added the patch titled
media: davinci: vpif_capture: add NULL check on devm_kzalloc return value
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:
media-davinci-vpif_capture-add-null-check-on-devm_kzalloc-return-value.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
Date: Wed, 22 Nov 2017 22:34:44 -0500
Subject: media: davinci: vpif_capture: add NULL check on devm_kzalloc return value
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
[ Upstream commit 5a18c2434f8bfc8bc2fb0f8af3e44f7408d63e4f ]
Check return value from call to devm_kzalloc() in order to prevent
a NULL pointer dereference.
This issue was detected with the help of Coccinelle.
Fixes: 4a5f8ae50b66 ("[media] davinci: vpif_capture: get subdevs from DT when available")
Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/davinci/vpif_capture.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1550,6 +1550,8 @@ vpif_capture_get_pdata(struct platform_d
sizeof(*chan->inputs) *
VPIF_CAPTURE_NUM_CHANNELS,
GFP_KERNEL);
+ if (!chan->inputs)
+ return NULL;
chan->input_count++;
chan->inputs[i].input.type = V4L2_INPUT_TYPE_CAMERA;
Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are
queue-4.15/media-davinci-vpif_capture-add-null-check-on-devm_kzalloc-return-value.patch
This is a note to let you know that I've just added the patch titled
media: cpia2: Fix a couple off by one bugs
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:
media-cpia2-fix-a-couple-off-by-one-bugs.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Thu, 9 Nov 2017 16:28:14 -0500
Subject: media: cpia2: Fix a couple off by one bugs
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit d5ac225c7d64c9c3ef821239edc035634e594ec9 ]
The cam->buffers[] array has cam->num_frames elements so the > needs to
be changed to >= to avoid going beyond the end of the array. The
->buffers[] array is allocated in cpia2_allocate_buffers() if you want
to confirm.
Fixes: ab33d5071de7 ("V4L/DVB (3376): Add cpia2 camera support")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/usb/cpia2/cpia2_v4l.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -808,7 +808,7 @@ static int cpia2_querybuf(struct file *f
struct camera_data *cam = video_drvdata(file);
if(buf->type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
- buf->index > cam->num_frames)
+ buf->index >= cam->num_frames)
return -EINVAL;
buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
@@ -859,7 +859,7 @@ static int cpia2_qbuf(struct file *file,
if(buf->type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
buf->memory != V4L2_MEMORY_MMAP ||
- buf->index > cam->num_frames)
+ buf->index >= cam->num_frames)
return -EINVAL;
DBG("QBUF #%d\n", buf->index);
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.15/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.15/crypto-chelsio-fix-an-error-code-in-chcr_hash_dma_map.patch
queue-4.15/drm-panel-rpi-touchscreen-propagate-errors-in-rpi_touchscreen_i2c_read.patch
queue-4.15/bnxt_en-uninitialized-variable-in-bnxt_tc_parse_actions.patch
queue-4.15/power-supply-sbs-message-double-left-shift-bug-in-sbsm_select.patch
queue-4.15/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED
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:
mac80211_hwsim-enforce-ps_manual_poll-to-be-set-after-ps_enabled.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Adiel Aloni <adiel.aloni(a)intel.com>
Date: Fri, 1 Dec 2017 13:50:53 +0200
Subject: mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED
From: Adiel Aloni <adiel.aloni(a)intel.com>
[ Upstream commit e16ea4bb516bc21ea2202f2107718b29218bea59 ]
Enforce using PS_MANUAL_POLL in ps hwsim debugfs to trigger a poll,
only if PS_ENABLED was set before.
This is required due to commit c9491367b759 ("mac80211: always update the
PM state of a peer on MGMT / DATA frames") that enforces the ap to
check only mgmt/data frames ps bit, and then update station's power save
accordingly.
When sending only ps-poll (control frame) the ap will not be aware that
the station entered power save.
Setting ps enable before triggering ps_poll, will send NDP with PM bit
enabled first.
Signed-off-by: Adiel Aloni <adiel.aloni(a)intel.com>
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/mac80211_hwsim.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -729,16 +729,21 @@ static int hwsim_fops_ps_write(void *dat
val != PS_MANUAL_POLL)
return -EINVAL;
- old_ps = data->ps;
- data->ps = val;
-
- local_bh_disable();
if (val == PS_MANUAL_POLL) {
+ if (data->ps != PS_ENABLED)
+ return -EINVAL;
+ local_bh_disable();
ieee80211_iterate_active_interfaces_atomic(
data->hw, IEEE80211_IFACE_ITER_NORMAL,
hwsim_send_ps_poll, data);
- data->ps_poll_pending = true;
- } else if (old_ps == PS_DISABLED && val != PS_DISABLED) {
+ local_bh_enable();
+ return 0;
+ }
+ old_ps = data->ps;
+ data->ps = val;
+
+ local_bh_disable();
+ if (old_ps == PS_DISABLED && val != PS_DISABLED) {
ieee80211_iterate_active_interfaces_atomic(
data->hw, IEEE80211_IFACE_ITER_NORMAL,
hwsim_send_nullfunc_ps, data);
Patches currently in stable-queue which might be from adiel.aloni(a)intel.com are
queue-4.15/mac80211_hwsim-enforce-ps_manual_poll-to-be-set-after-ps_enabled.patch
This is a note to let you know that I've just added the patch titled
mac80211: remove BUG() when interface type is invalid
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:
mac80211-remove-bug-when-interface-type-is-invalid.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Luca Coelho <luciano.coelho(a)intel.com>
Date: Sun, 29 Oct 2017 11:51:10 +0200
Subject: mac80211: remove BUG() when interface type is invalid
From: Luca Coelho <luciano.coelho(a)intel.com>
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never happen, but if there is
something wrong with the code, it will not be caught until the bug
happens when an interface is being set up. Calling BUG() is too
extreme for this and a WARN_ON() would be better used instead. Change
that.
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/iface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1474,7 +1474,7 @@ static void ieee80211_setup_sdata(struct
break;
case NL80211_IFTYPE_UNSPECIFIED:
case NUM_NL80211_IFTYPES:
- BUG();
+ WARN_ON(1);
break;
}
Patches currently in stable-queue which might be from luciano.coelho(a)intel.com are
queue-4.15/mac80211-remove-bug-when-interface-type-is-invalid.patch
queue-4.15/mac80211_hwsim-enforce-ps_manual_poll-to-be-set-after-ps_enabled.patch
queue-4.15/iwlwifi-mvm-rs-don-t-override-the-rate-history-in-the-search-cycle.patch
queue-4.15/iwlwifi-mvm-avoid-dumping-assert-log-when-device-is-stopped.patch
This is a note to let you know that I've just added the patch titled
locking/locktorture: Fix num reader/writer corner cases
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:
locking-locktorture-fix-num-reader-writer-corner-cases.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Davidlohr Bueso <dave(a)stgolabs.net>
Date: Mon, 15 May 2017 02:07:23 -0700
Subject: locking/locktorture: Fix num reader/writer corner cases
From: Davidlohr Bueso <dave(a)stgolabs.net>
[ Upstream commit 2ce77d16db4240dd2e422fc0a5c26d3e2ec03446 ]
Things can explode for locktorture if the user does combinations
of nwriters_stress=0 nreaders_stress=0. Fix this by not assuming
we always want to torture writer threads.
Reported-by: Jeremy Linton <jeremy.linton(a)arm.com>
Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de>
Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Reviewed-by: Jeremy Linton <jeremy.linton(a)arm.com>
Tested-by: Jeremy Linton <jeremy.linton(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/locking/locktorture.c | 76 ++++++++++++++++++++++++-------------------
1 file changed, 44 insertions(+), 32 deletions(-)
--- a/kernel/locking/locktorture.c
+++ b/kernel/locking/locktorture.c
@@ -715,8 +715,7 @@ static void __torture_print_stats(char *
{
bool fail = 0;
int i, n_stress;
- long max = 0;
- long min = statp[0].n_lock_acquired;
+ long max = 0, min = statp ? statp[0].n_lock_acquired : 0;
long long sum = 0;
n_stress = write ? cxt.nrealwriters_stress : cxt.nrealreaders_stress;
@@ -823,7 +822,7 @@ static void lock_torture_cleanup(void)
* such, only perform the underlying torture-specific cleanups,
* and avoid anything related to locktorture.
*/
- if (!cxt.lwsa)
+ if (!cxt.lwsa && !cxt.lrsa)
goto end;
if (writer_tasks) {
@@ -898,6 +897,13 @@ static int __init lock_torture_init(void
firsterr = -EINVAL;
goto unwind;
}
+
+ if (nwriters_stress == 0 && nreaders_stress == 0) {
+ pr_alert("lock-torture: must run at least one locking thread\n");
+ firsterr = -EINVAL;
+ goto unwind;
+ }
+
if (cxt.cur_ops->init)
cxt.cur_ops->init();
@@ -921,17 +927,19 @@ static int __init lock_torture_init(void
#endif
/* Initialize the statistics so that each run gets its own numbers. */
+ if (nwriters_stress) {
+ lock_is_write_held = 0;
+ cxt.lwsa = kmalloc(sizeof(*cxt.lwsa) * cxt.nrealwriters_stress, GFP_KERNEL);
+ if (cxt.lwsa == NULL) {
+ VERBOSE_TOROUT_STRING("cxt.lwsa: Out of memory");
+ firsterr = -ENOMEM;
+ goto unwind;
+ }
- lock_is_write_held = 0;
- cxt.lwsa = kmalloc(sizeof(*cxt.lwsa) * cxt.nrealwriters_stress, GFP_KERNEL);
- if (cxt.lwsa == NULL) {
- VERBOSE_TOROUT_STRING("cxt.lwsa: Out of memory");
- firsterr = -ENOMEM;
- goto unwind;
- }
- for (i = 0; i < cxt.nrealwriters_stress; i++) {
- cxt.lwsa[i].n_lock_fail = 0;
- cxt.lwsa[i].n_lock_acquired = 0;
+ for (i = 0; i < cxt.nrealwriters_stress; i++) {
+ cxt.lwsa[i].n_lock_fail = 0;
+ cxt.lwsa[i].n_lock_acquired = 0;
+ }
}
if (cxt.cur_ops->readlock) {
@@ -948,19 +956,21 @@ static int __init lock_torture_init(void
cxt.nrealreaders_stress = cxt.nrealwriters_stress;
}
- lock_is_read_held = 0;
- cxt.lrsa = kmalloc(sizeof(*cxt.lrsa) * cxt.nrealreaders_stress, GFP_KERNEL);
- if (cxt.lrsa == NULL) {
- VERBOSE_TOROUT_STRING("cxt.lrsa: Out of memory");
- firsterr = -ENOMEM;
- kfree(cxt.lwsa);
- cxt.lwsa = NULL;
- goto unwind;
- }
-
- for (i = 0; i < cxt.nrealreaders_stress; i++) {
- cxt.lrsa[i].n_lock_fail = 0;
- cxt.lrsa[i].n_lock_acquired = 0;
+ if (nreaders_stress) {
+ lock_is_read_held = 0;
+ cxt.lrsa = kmalloc(sizeof(*cxt.lrsa) * cxt.nrealreaders_stress, GFP_KERNEL);
+ if (cxt.lrsa == NULL) {
+ VERBOSE_TOROUT_STRING("cxt.lrsa: Out of memory");
+ firsterr = -ENOMEM;
+ kfree(cxt.lwsa);
+ cxt.lwsa = NULL;
+ goto unwind;
+ }
+
+ for (i = 0; i < cxt.nrealreaders_stress; i++) {
+ cxt.lrsa[i].n_lock_fail = 0;
+ cxt.lrsa[i].n_lock_acquired = 0;
+ }
}
}
@@ -990,12 +1000,14 @@ static int __init lock_torture_init(void
goto unwind;
}
- writer_tasks = kzalloc(cxt.nrealwriters_stress * sizeof(writer_tasks[0]),
- GFP_KERNEL);
- if (writer_tasks == NULL) {
- VERBOSE_TOROUT_ERRSTRING("writer_tasks: Out of memory");
- firsterr = -ENOMEM;
- goto unwind;
+ if (nwriters_stress) {
+ writer_tasks = kzalloc(cxt.nrealwriters_stress * sizeof(writer_tasks[0]),
+ GFP_KERNEL);
+ if (writer_tasks == NULL) {
+ VERBOSE_TOROUT_ERRSTRING("writer_tasks: Out of memory");
+ firsterr = -ENOMEM;
+ goto unwind;
+ }
}
if (cxt.cur_ops->readlock) {
Patches currently in stable-queue which might be from dave(a)stgolabs.net are
queue-4.15/locking-locktorture-fix-num-reader-writer-corner-cases.patch
This is a note to let you know that I've just added the patch titled
leds: pm8058: Silence pointer to integer size warning
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:
leds-pm8058-silence-pointer-to-integer-size-warning.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Date: Thu, 30 Nov 2017 21:16:56 -0800
Subject: leds: pm8058: Silence pointer to integer size warning
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
[ Upstream commit 8f52df50d9366f770a894d14ef724e5e04574e98 ]
The pointer returned by of_device_get_match_data() doesn't have the same
size as u32 on 64-bit architectures, causing a compile warning when
compile-testing the driver on such platform.
Cast the return value of of_device_get_match_data() to unsigned long and
then to u32 to silence this warning.
Fixes: 7f866986e705 ("leds: add PM8058 LEDs driver")
Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org>
Acked-by: Pavel Machek <pavel(a)ucw.cz>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/leds/leds-pm8058.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/leds/leds-pm8058.c
+++ b/drivers/leds/leds-pm8058.c
@@ -106,7 +106,7 @@ static int pm8058_led_probe(struct platf
if (!led)
return -ENOMEM;
- led->ledtype = (u32)of_device_get_match_data(&pdev->dev);
+ led->ledtype = (u32)(unsigned long)of_device_get_match_data(&pdev->dev);
map = dev_get_regmap(pdev->dev.parent, NULL);
if (!map) {
Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are
queue-4.15/leds-pm8058-silence-pointer-to-integer-size-warning.patch
This is a note to let you know that I've just added the patch titled
KVM: X86: Restart the guest when insn_len is zero and SEV is enabled
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:
kvm-x86-restart-the-guest-when-insn_len-is-zero-and-sev-is-enabled.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Brijesh Singh <brijesh.singh(a)amd.com>
Date: Mon, 4 Dec 2017 10:57:40 -0600
Subject: KVM: X86: Restart the guest when insn_len is zero and SEV is enabled
From: Brijesh Singh <brijesh.singh(a)amd.com>
[ Upstream commit 00b10fe1046c4b2232097a7ffaa9238c7e479388 ]
On AMD platforms, under certain conditions insn_len may be zero on #NPF.
This can happen if a guest gets a page-fault on data access but the HW
table walker is not able to read the instruction page (e.g instruction
page is not present in memory).
Typically, when insn_len is zero, x86_emulate_instruction() walks the
guest page table and fetches the instruction bytes from guest memory.
When SEV is enabled, the guest memory is encrypted with guest-specific
key hence hypervisor will not able to fetch the instruction bytes.
In those cases we simply restart the guest.
I have encountered this issue when running kernbench inside the guest.
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: "Radim Krčmář" <rkrcmar(a)redhat.com>
Cc: Joerg Roedel <joro(a)8bytes.org>
Cc: Borislav Petkov <bp(a)suse.de>
Cc: Tom Lendacky <thomas.lendacky(a)amd.com>
Cc: x86(a)kernel.org
Cc: kvm(a)vger.kernel.org
Cc: linux-kernel(a)vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/mmu.c | 10 ++++++++++
arch/x86/kvm/svm.c | 6 ++++--
2 files changed, 14 insertions(+), 2 deletions(-)
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4951,6 +4951,16 @@ int kvm_mmu_page_fault(struct kvm_vcpu *
if (mmio_info_in_cache(vcpu, cr2, direct))
emulation_type = 0;
emulate:
+ /*
+ * On AMD platforms, under certain conditions insn_len may be zero on #NPF.
+ * This can happen if a guest gets a page-fault on data access but the HW
+ * table walker is not able to read the instruction page (e.g instruction
+ * page is not present in memory). In those cases we simply restart the
+ * guest.
+ */
+ if (unlikely(insn && !insn_len))
+ return 1;
+
er = x86_emulate_instruction(vcpu, cr2, emulation_type, insn, insn_len);
switch (er) {
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2178,7 +2178,8 @@ static int pf_interception(struct vcpu_s
u64 error_code = svm->vmcb->control.exit_info_1;
return kvm_handle_page_fault(&svm->vcpu, error_code, fault_address,
- svm->vmcb->control.insn_bytes,
+ static_cpu_has(X86_FEATURE_DECODEASSISTS) ?
+ svm->vmcb->control.insn_bytes : NULL,
svm->vmcb->control.insn_len);
}
@@ -2189,7 +2190,8 @@ static int npf_interception(struct vcpu_
trace_kvm_page_fault(fault_address, error_code);
return kvm_mmu_page_fault(&svm->vcpu, fault_address, error_code,
- svm->vmcb->control.insn_bytes,
+ static_cpu_has(X86_FEATURE_DECODEASSISTS) ?
+ svm->vmcb->control.insn_bytes : NULL,
svm->vmcb->control.insn_len);
}
Patches currently in stable-queue which might be from brijesh.singh(a)amd.com are
queue-4.15/kvm-x86-restart-the-guest-when-insn_len-is-zero-and-sev-is-enabled.patch
This is a note to let you know that I've just added the patch titled
KVM: PPC: Book3S HV: Fix typo in kvmppc_hv_get_dirty_log_radix()
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:
kvm-ppc-book3s-hv-fix-typo-in-kvmppc_hv_get_dirty_log_radix.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Paul Mackerras <paulus(a)ozlabs.org>
Date: Fri, 10 Nov 2017 16:43:35 +1100
Subject: KVM: PPC: Book3S HV: Fix typo in kvmppc_hv_get_dirty_log_radix()
From: Paul Mackerras <paulus(a)ozlabs.org>
[ Upstream commit 117647ff936e2d9684cc881d87c0291f46669c20 ]
This fixes a typo where the intent was to assign to 'j' in order to
skip some number of bits in the dirty bitmap for a guest. The effect
of the typo is benign since it means we just iterate through all the
bits rather than skipping bits which we know will be zero. This issue
was found by Coverity.
Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -573,7 +573,7 @@ long kvmppc_hv_get_dirty_log_radix(struc
j = i + 1;
if (npages) {
set_dirty_bits(map, i, npages);
- i = j + npages;
+ j = i + npages;
}
}
return 0;
Patches currently in stable-queue which might be from paulus(a)ozlabs.org are
queue-4.15/kvm-ppc-book3s-hv-avoid-shifts-by-negative-amounts.patch
queue-4.15/kvm-ppc-book3s-hv-fix-typo-in-kvmppc_hv_get_dirty_log_radix.patch
This is a note to let you know that I've just added the patch titled
KVM: PPC: Book3S HV: Avoid shifts by negative amounts
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:
kvm-ppc-book3s-hv-avoid-shifts-by-negative-amounts.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 foo@baz Fri Mar 16 15:10:48 CET 2018
From: Paul Mackerras <paulus(a)ozlabs.org>
Date: Fri, 10 Nov 2017 16:40:24 +1100
Subject: KVM: PPC: Book3S HV: Avoid shifts by negative amounts
From: Paul Mackerras <paulus(a)ozlabs.org>
[ Upstream commit cda2eaa35948893d70145490d5d6ded546fc3bc6 ]
The kvmppc_hpte_page_shifts function decodes the actual and base page
sizes for a HPTE, returning -1 if it doesn't recognize the page size
encoding. This then gets used as a shift amount in various places,
which is undefined behaviour. This was reported by Coverity.
In fact this should never occur, since we should only get HPTEs in the
HPT which have a recognized page size encoding. The only place where
this might not be true is in the call to kvmppc_actual_pgsz() near the
beginning of kvmppc_do_h_enter(), where we are validating the HPTE
value passed in from the guest.
So to fix this and eliminate the undefined behaviour, we make
kvmppc_hpte_page_shifts return 0 for unrecognized page size encodings,
and make kvmppc_actual_pgsz() detect that case and return 0 for the
page size, which will then cause kvmppc_do_h_enter() to return an
error and refuse to insert any HPTE with an unrecognized page size
encoding.
To ensure that we don't get undefined behaviour in compute_tlbie_rb(),
we take the 4k page size path for any unrecognized page size encoding.
This should never be hit in practice because it is only used on HPTE
values which have previously been checked for having a recognized
page size encoding.
Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/include/asm/kvm_book3s_64.h | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h b/arch/powerpc/include/asm/kvm_book3s_64.h
index 735cfa35298a..998f7b7aaa9e 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -122,13 +122,13 @@ static inline int kvmppc_hpte_page_shifts(unsigned long h, unsigned long l)
lphi = (l >> 16) & 0xf;
switch ((l >> 12) & 0xf) {
case 0:
- return !lphi ? 24 : -1; /* 16MB */
+ return !lphi ? 24 : 0; /* 16MB */
break;
case 1:
return 16; /* 64kB */
break;
case 3:
- return !lphi ? 34 : -1; /* 16GB */
+ return !lphi ? 34 : 0; /* 16GB */
break;
case 7:
return (16 << 8) + 12; /* 64kB in 4kB */
@@ -140,7 +140,7 @@ static inline int kvmppc_hpte_page_shifts(unsigned long h, unsigned long l)
return (24 << 8) + 12; /* 16MB in 4kB */
break;
}
- return -1;
+ return 0;
}
static inline int kvmppc_hpte_base_page_shift(unsigned long h, unsigned long l)
@@ -159,7 +159,11 @@ static inline int kvmppc_hpte_actual_page_shift(unsigned long h, unsigned long l
static inline unsigned long kvmppc_actual_pgsz(unsigned long v, unsigned long r)
{
- return 1ul << kvmppc_hpte_actual_page_shift(v, r);
+ int shift = kvmppc_hpte_actual_page_shift(v, r);
+
+ if (shift)
+ return 1ul << shift;
+ return 0;
}
static inline int kvmppc_pgsize_lp_encoding(int base_shift, int actual_shift)
@@ -232,7 +236,7 @@ static inline unsigned long compute_tlbie_rb(unsigned long v, unsigned long r,
va_low ^= v >> (SID_SHIFT_1T - 16);
va_low &= 0x7ff;
- if (b_pgshift == 12) {
+ if (b_pgshift <= 12) {
if (a_pgshift > 12) {
sllp = (a_pgshift == 16) ? 5 : 4;
rb |= sllp << 5; /* AP field */
--
2.16.2
Patches currently in stable-queue which might be from paulus(a)ozlabs.org are
queue-4.15/kvm-ppc-book3s-hv-avoid-shifts-by-negative-amounts.patch
queue-4.15/kvm-ppc-book3s-hv-fix-typo-in-kvmppc_hv_get_dirty_log_radix.patch
This is a note to let you know that I've just added the patch titled
iwlwifi: mvm: rs: don't override the rate history in the search cycle
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:
iwlwifi-mvm-rs-don-t-override-the-rate-history-in-the-search-cycle.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
Date: Thu, 19 Oct 2017 21:36:04 +0300
Subject: iwlwifi: mvm: rs: don't override the rate history in the search cycle
From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
[ Upstream commit 992172e3aec19e5b0ea5b757ba40a146b9282d1e ]
When we are in a search cycle, we try different combinations
of parameters. Those combinations are called 'columns'.
When we switch to a new column, we first need to check if
this column has a suitable rate, if not, we can't try it.
This means we must not erase the statistics we gathered
for the previous column until we are sure that we are
indeed switching column.
The code that tries to switch to a new column first sets
a whole bunch of things for the new column, and only then
checks that we can find suitable rates in that column.
While doing that, the code mistakenly erased the rate
statistics. This code was right until
struct iwl_scale_tbl_info grew up for TPC.
Fix this to make sure we don't erase the rate statistics
until we are sure that we can indeed switch to the new
column.
Note that this bug is really harmless since it causes a
change in the behavior only when we can't find any rate
in the new column which should really not happen. In the
case we do find a suitable we reset the rate statistics
a few lines later anyway.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -1877,12 +1877,10 @@ static int rs_switch_to_column(struct iw
struct rs_rate *rate = &search_tbl->rate;
const struct rs_tx_column *column = &rs_tx_columns[col_id];
const struct rs_tx_column *curr_column = &rs_tx_columns[tbl->column];
- u32 sz = (sizeof(struct iwl_scale_tbl_info) -
- (sizeof(struct iwl_rate_scale_data) * IWL_RATE_COUNT));
unsigned long rate_mask = 0;
u32 rate_idx = 0;
- memcpy(search_tbl, tbl, sz);
+ memcpy(search_tbl, tbl, offsetof(struct iwl_scale_tbl_info, win));
rate->sgi = column->sgi;
rate->ant = column->ant;
Patches currently in stable-queue which might be from emmanuel.grumbach(a)intel.com are
queue-4.15/iwlwifi-mvm-rs-don-t-override-the-rate-history-in-the-search-cycle.patch
This is a note to let you know that I've just added the patch titled
iwlwifi: mvm: avoid dumping assert log when device is stopped
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:
iwlwifi-mvm-avoid-dumping-assert-log-when-device-is-stopped.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Sara Sharon <sara.sharon(a)intel.com>
Date: Mon, 20 Nov 2017 18:02:05 +0200
Subject: iwlwifi: mvm: avoid dumping assert log when device is stopped
From: Sara Sharon <sara.sharon(a)intel.com>
[ Upstream commit 6362ab721ef5c4ecfa01f53ad4137d3d984f0c6c ]
We might erroneously get to error dumping code when the
device is already stopped.
In that case the driver will detect a defective value and will try to
reset the HW, assuming it is only a bus issue. The driver than
proceeds with the dumping.
The result has two side effects:
1. The device won't be stopped again, since the transport status is
already stopped, so the device remains powered on while it actually
should be stopped.
2. The dump in that case is completely garbaged and useless.
Detect and avoid this. It will also make debugging such issues
easier.
Signed-off-by: Sara Sharon <sara.sharon(a)intel.com>
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
@@ -595,6 +595,12 @@ static void iwl_mvm_dump_lmac_error_log(
void iwl_mvm_dump_nic_error_log(struct iwl_mvm *mvm)
{
+ if (!test_bit(STATUS_DEVICE_ENABLED, &mvm->trans->status)) {
+ IWL_ERR(mvm,
+ "DEVICE_ENABLED bit is not set. Aborting dump.\n");
+ return;
+ }
+
iwl_mvm_dump_lmac_error_log(mvm, mvm->error_event_table[0]);
if (mvm->error_event_table[1])
Patches currently in stable-queue which might be from sara.sharon(a)intel.com are
queue-4.15/iwlwifi-mvm-avoid-dumping-assert-log-when-device-is-stopped.patch
This is a note to let you know that I've just added the patch titled
ipvlan: add L2 check for packets arriving via virtual devices
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:
ipvlan-add-l2-check-for-packets-arriving-via-virtual-devices.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Mahesh Bandewar <maheshb(a)google.com>
Date: Thu, 7 Dec 2017 15:15:43 -0800
Subject: ipvlan: add L2 check for packets arriving via virtual devices
From: Mahesh Bandewar <maheshb(a)google.com>
[ Upstream commit 92ff42645028fa6f9b8aa767718457b9264316b4 ]
Packets that don't have dest mac as the mac of the master device should
not be entertained by the IPvlan rx-handler. This is mostly true as the
packet path mostly takes care of that, except when the master device is
a virtual device. As demonstrated in the following case -
ip netns add ns1
ip link add ve1 type veth peer name ve2
ip link add link ve2 name iv1 type ipvlan mode l2
ip link set dev iv1 netns ns1
ip link set ve1 up
ip link set ve2 up
ip -n ns1 link set iv1 up
ip addr add 192.168.10.1/24 dev ve1
ip -n ns1 addr 192.168.10.2/24 dev iv1
ping -c2 192.168.10.2
<Works!>
ip neigh show dev ve1
ip neigh show 192.168.10.2 lladdr <random> dev ve1
ping -c2 192.168.10.2
<Still works! Wrong!!>
This patch adds that missing check in the IPvlan rx-handler.
Reported-by: Amit Sikka <amit.sikka(a)ericsson.com>
Signed-off-by: Mahesh Bandewar <maheshb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ipvlan/ipvlan_core.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -322,6 +322,10 @@ static int ipvlan_rcv_frame(struct ipvl_
if (dev_forward_skb(ipvlan->dev, skb) == NET_RX_SUCCESS)
success = true;
} else {
+ if (!ether_addr_equal_64bits(eth_hdr(skb)->h_dest,
+ ipvlan->phy_dev->dev_addr))
+ skb->pkt_type = PACKET_OTHERHOST;
+
ret = RX_HANDLER_ANOTHER;
success = true;
}
Patches currently in stable-queue which might be from maheshb(a)google.com are
queue-4.15/ipvlan-add-l2-check-for-packets-arriving-via-virtual-devices.patch
This is a note to let you know that I've just added the patch titled
ima: relax requiring a file signature for new files with zero length
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:
ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Date: Wed, 8 Nov 2017 07:38:28 -0500
Subject: ima: relax requiring a file signature for new files with zero length
From: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
[ Upstream commit b7e27bc1d42e8e0cc58b602b529c25cd0071b336 ]
Custom policies can require file signatures based on LSM labels. These
files are normally created and only afterwards labeled, requiring them
to be signed.
Instead of requiring file signatures based on LSM labels, entire
filesystems could require file signatures. In this case, we need the
ability of writing new files without requiring file signatures.
The definition of a "new" file was originally defined as any file with
a length of zero. Subsequent patches redefined a "new" file to be based
on the FILE_CREATE open flag. By combining the open flag with a file
size of zero, this patch relaxes the file signature requirement.
Fixes: 1ac202e978e1 ima: accept previously set IMA_NEW_FILE
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_appraise.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -223,7 +223,8 @@ int ima_appraise_measurement(enum ima_ho
if (opened & FILE_CREATED)
iint->flags |= IMA_NEW_FILE;
if ((iint->flags & IMA_NEW_FILE) &&
- !(iint->flags & IMA_DIGSIG_REQUIRED))
+ (!(iint->flags & IMA_DIGSIG_REQUIRED) ||
+ (inode->i_size == 0)))
status = INTEGRITY_PASS;
goto out;
}
Patches currently in stable-queue which might be from zohar(a)linux.vnet.ibm.com are
queue-4.15/ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch
This is a note to let you know that I've just added the patch titled
iio: health: max30102: Add power enable parameter to get_temp function
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:
iio-health-max30102-add-power-enable-parameter-to-get_temp-function.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Peter Meerwald-Stadler <pmeerw(a)pmeerw.net>
Date: Fri, 27 Oct 2017 21:45:38 +0200
Subject: iio: health: max30102: Add power enable parameter to get_temp function
From: Peter Meerwald-Stadler <pmeerw(a)pmeerw.net>
[ Upstream commit a9c47abbdd71dceeaf1b923e5ce10e700e036905 ]
Chip must not be in shutdown for reading temperature, so briefly leave
shutdown if buffer is not already running
Signed-off-by: Peter Meerwald-Stadler <pmeerw(a)pmeerw.net>
Acked-by: Matt Ranostay <matt.ranostay(a)konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/health/max30102.c | 36 +++++++++++++++++++++++-------------
1 file changed, 23 insertions(+), 13 deletions(-)
--- a/drivers/iio/health/max30102.c
+++ b/drivers/iio/health/max30102.c
@@ -329,20 +329,31 @@ static int max30102_read_temp(struct max
return 0;
}
-static int max30102_get_temp(struct max30102_data *data, int *val)
+static int max30102_get_temp(struct max30102_data *data, int *val, bool en)
{
int ret;
+ if (en) {
+ ret = max30102_set_powermode(data, true);
+ if (ret)
+ return ret;
+ }
+
/* start acquisition */
ret = regmap_update_bits(data->regmap, MAX30102_REG_TEMP_CONFIG,
MAX30102_REG_TEMP_CONFIG_TEMP_EN,
MAX30102_REG_TEMP_CONFIG_TEMP_EN);
if (ret)
- return ret;
+ goto out;
msleep(35);
+ ret = max30102_read_temp(data, val);
+
+out:
+ if (en)
+ max30102_set_powermode(data, false);
- return max30102_read_temp(data, val);
+ return ret;
}
static int max30102_read_raw(struct iio_dev *indio_dev,
@@ -355,20 +366,19 @@ static int max30102_read_raw(struct iio_
switch (mask) {
case IIO_CHAN_INFO_RAW:
/*
- * Temperature reading can only be acquired while engine
- * is running
+ * Temperature reading can only be acquired when not in
+ * shutdown; leave shutdown briefly when buffer not running
*/
mutex_lock(&indio_dev->mlock);
-
if (!iio_buffer_enabled(indio_dev))
- ret = -EBUSY;
- else {
- ret = max30102_get_temp(data, val);
- if (!ret)
- ret = IIO_VAL_INT;
- }
-
+ ret = max30102_get_temp(data, val, true);
+ else
+ ret = max30102_get_temp(data, val, false);
mutex_unlock(&indio_dev->mlock);
+ if (ret)
+ return ret;
+
+ ret = IIO_VAL_INT;
break;
case IIO_CHAN_INFO_SCALE:
*val = 1000; /* 62.5 */
Patches currently in stable-queue which might be from pmeerw(a)pmeerw.net are
queue-4.15/iio-health-max30102-add-power-enable-parameter-to-get_temp-function.patch
This is a note to let you know that I've just added the patch titled
IB/mlx5: revisit -Wmaybe-uninitialized warning
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:
ib-mlx5-revisit-wmaybe-uninitialized-warning.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Mon, 11 Dec 2017 12:45:44 +0100
Subject: IB/mlx5: revisit -Wmaybe-uninitialized warning
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 1b19b95169cd52fe82cd442fec0b279fe25cc838 ]
A warning that I thought I had fixed before occasionally comes
back in rare randconfig builds (I found 7 instances in the last
100000 builds, originally it was much more frequent):
drivers/infiniband/hw/mlx5/mr.c: In function 'mlx5_ib_reg_user_mr':
drivers/infiniband/hw/mlx5/mr.c:1229:5: error: 'order' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (order <= mr_cache_max_order(dev)) {
^
drivers/infiniband/hw/mlx5/mr.c:1247:8: error: 'ncont' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/infiniband/hw/mlx5/mr.c:1247:8: error: 'page_shift' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/infiniband/hw/mlx5/mr.c:1260:2: error: 'npages' may be used uninitialized in this function [-Werror=maybe-uninitialized]
I've looked at all those findings again and noticed that they are all
with CONFIG_INFINIBAND_USER_MEM=n, which means ib_umem_get() returns
an error unconditionally and we never initialize or use those variables.
This triggers a condition in gcc iff mr_umem_get() is partially but not
entirely inlined, which in turn depends on the exact combination of
optimization settings. This is a known problem with gcc, with no
easy solution in the compiler, so this adds another workaround that
should be more reliable than my previous attempt.
Returning an error from mlx5_ib_reg_user_mr() earlier means that we
can completely bypass the logic that caused the warning, the compiler
can now see that the variable is never accessed.
Fixes: 14ab8896f5d9 ("IB/mlx5: avoid bogus -Wmaybe-uninitialized warning")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx5/mr.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1206,6 +1206,9 @@ struct ib_mr *mlx5_ib_reg_user_mr(struct
int err;
bool use_umr = true;
+ if (!IS_ENABLED(CONFIG_INFINIBAND_USER_MEM))
+ return ERR_PTR(-EINVAL);
+
mlx5_ib_dbg(dev, "start 0x%llx, virt_addr 0x%llx, length 0x%llx, access_flags 0x%x\n",
start, virt_addr, length, access_flags);
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.15/ib-mlx5-revisit-wmaybe-uninitialized-warning.patch
queue-4.15/drm-vblank-fix-vblank-timestamp-debugs.patch
queue-4.15/earlycon-add-reg-offset-to-physical-address-before-mapping.patch
This is a note to let you know that I've just added the patch titled
HID: multitouch: Only look at non touch fields in first packet of a frame
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:
hid-multitouch-only-look-at-non-touch-fields-in-first-packet-of-a-frame.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 foo@baz Fri Mar 16 15:10:48 CET 2018
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 22 Nov 2017 12:57:09 +0100
Subject: HID: multitouch: Only look at non touch fields in first packet of a frame
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit 55746d28d66860bccaae20a67b55b9d5db7c14af ]
Devices in "single finger hybrid mode" will send one report per finger,
on some devices only the first report of such a multi-packet frame will
contain a value for BTN_LEFT, in subsequent reports (if multiple fingers
are down) the value is always 0, causing hid-mt to report BTN_LEFT going
1 - 0 - 1 - 0 when pressing a clickpad and putting down a second finger.
This happens for example on USB 0603:0002 mt touchpads.
This commit fixes this by only reporting non touch fields for the first
packet of a (possibly) multi-packet frame.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-multitouch.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 65ea23be9677..397592959238 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -778,9 +778,11 @@ static int mt_touch_event(struct hid_device *hid, struct hid_field *field,
}
static void mt_process_mt_event(struct hid_device *hid, struct hid_field *field,
- struct hid_usage *usage, __s32 value)
+ struct hid_usage *usage, __s32 value,
+ bool first_packet)
{
struct mt_device *td = hid_get_drvdata(hid);
+ __s32 cls = td->mtclass.name;
__s32 quirks = td->mtclass.quirks;
struct input_dev *input = field->hidinput->input;
@@ -837,6 +839,15 @@ static void mt_process_mt_event(struct hid_device *hid, struct hid_field *field,
break;
default:
+ /*
+ * For Win8 PTP touchpads we should only look at
+ * non finger/touch events in the first_packet of
+ * a (possible) multi-packet frame.
+ */
+ if ((cls == MT_CLS_WIN_8 || cls == MT_CLS_WIN_8_DUAL) &&
+ !first_packet)
+ return;
+
if (usage->type)
input_event(input, usage->type, usage->code,
value);
@@ -856,6 +867,7 @@ static void mt_touch_report(struct hid_device *hid, struct hid_report *report)
{
struct mt_device *td = hid_get_drvdata(hid);
struct hid_field *field;
+ bool first_packet;
unsigned count;
int r, n;
@@ -874,6 +886,7 @@ static void mt_touch_report(struct hid_device *hid, struct hid_report *report)
td->num_expected = value;
}
+ first_packet = td->num_received == 0;
for (r = 0; r < report->maxfield; r++) {
field = report->field[r];
count = field->report_count;
@@ -883,7 +896,7 @@ static void mt_touch_report(struct hid_device *hid, struct hid_report *report)
for (n = 0; n < count; n++)
mt_process_mt_event(hid, field, &field->usage[n],
- field->value[n]);
+ field->value[n], first_packet);
}
if (td->num_received >= td->num_expected)
--
2.16.2
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.15/asoc-rt5651-fix-regcache-sync-errors-on-resume.patch
queue-4.15/uas-fix-comparison-for-error-code.patch
queue-4.15/hid-multitouch-only-look-at-non-touch-fields-in-first-packet-of-a-frame.patch
This is a note to let you know that I've just added the patch titled
HID: elo: clear BTN_LEFT mapping
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:
hid-elo-clear-btn_left-mapping.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Jiri Kosina <jkosina(a)suse.cz>
Date: Wed, 22 Nov 2017 11:19:51 +0100
Subject: HID: elo: clear BTN_LEFT mapping
From: Jiri Kosina <jkosina(a)suse.cz>
[ Upstream commit 9abd04af951e5734c9d5cfee9b49790844b734cf ]
ELO devices have one Button usage in GenDesk field, which makes hid-input map
it to BTN_LEFT; that confuses userspace, which then considers the device to be
a mouse/touchpad instead of touchscreen.
Fix that by unmapping BTN_LEFT and keeping only BTN_TOUCH in place.
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-elo.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/hid/hid-elo.c
+++ b/drivers/hid/hid-elo.c
@@ -42,6 +42,12 @@ static int elo_input_configured(struct h
{
struct input_dev *input = hidinput->input;
+ /*
+ * ELO devices have one Button usage in GenDesk field, which makes
+ * hid-input map it to BTN_LEFT; that confuses userspace, which then
+ * considers the device to be a mouse/touchpad instead of touchscreen.
+ */
+ clear_bit(BTN_LEFT, input->keybit);
set_bit(BTN_TOUCH, input->keybit);
set_bit(ABS_PRESSURE, input->absbit);
input_set_abs_params(input, ABS_PRESSURE, 0, 256, 0, 0);
Patches currently in stable-queue which might be from jkosina(a)suse.cz are
queue-4.15/hid-elo-clear-btn_left-mapping.patch
queue-4.15/hid-multitouch-only-look-at-non-touch-fields-in-first-packet-of-a-frame.patch
This is a note to let you know that I've just added the patch titled
gpiolib: don't allow OPEN_DRAIN & OPEN_SOURCE flags simultaneously
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:
gpiolib-don-t-allow-open_drain-open_source-flags-simultaneously.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Bartosz Golaszewski <brgl(a)bgdev.pl>
Date: Wed, 15 Nov 2017 16:47:43 +0100
Subject: gpiolib: don't allow OPEN_DRAIN & OPEN_SOURCE flags simultaneously
From: Bartosz Golaszewski <brgl(a)bgdev.pl>
[ Upstream commit 588fc3bceaf81bbd62e18af6f7bd475e01c2b7e8 ]
Do not allow OPEN_SOURCE & OPEN_DRAIN flags in a single request. If
the hardware actually supports enabling both at the same time the
electrical result would be disastrous.
Suggested-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl(a)bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -460,6 +460,15 @@ static int linehandle_create(struct gpio
if (lflags & ~GPIOHANDLE_REQUEST_VALID_FLAGS)
return -EINVAL;
+ /*
+ * Do not allow OPEN_SOURCE & OPEN_DRAIN flags in a single request. If
+ * the hardware actually supports enabling both at the same time the
+ * electrical result would be disastrous.
+ */
+ if ((lflags & GPIOHANDLE_REQUEST_OPEN_DRAIN) &&
+ (lflags & GPIOHANDLE_REQUEST_OPEN_SOURCE))
+ return -EINVAL;
+
/* OPEN_DRAIN and OPEN_SOURCE flags only make sense for output mode. */
if (!(lflags & GPIOHANDLE_REQUEST_OUTPUT) &&
((lflags & GPIOHANDLE_REQUEST_OPEN_DRAIN) ||
Patches currently in stable-queue which might be from brgl(a)bgdev.pl are
queue-4.15/gpiolib-don-t-allow-open_drain-open_source-flags-simultaneously.patch
This is a note to let you know that I've just added the patch titled
Fix misannotated out-of-line _copy_to_user()
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:
fix-misannotated-out-of-line-_copy_to_user.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
Date: Sat, 9 Dec 2017 17:24:24 +0100
Subject: Fix misannotated out-of-line _copy_to_user()
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
[ Upstream commit a0e94598e6b6c0d1df6a5fa14eb7c767ca817a20 ]
Destination is a kernel pointer and source - a userland one
in _copy_from_user(); _copy_to_user() is the other way round.
Fixes: d597580d37377 ("generic ...copy_..._user primitives")
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/usercopy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/usercopy.c
+++ b/lib/usercopy.c
@@ -20,7 +20,7 @@ EXPORT_SYMBOL(_copy_from_user);
#endif
#ifndef INLINE_COPY_TO_USER
-unsigned long _copy_to_user(void *to, const void __user *from, unsigned long n)
+unsigned long _copy_to_user(void __user *to, const void *from, unsigned long n)
{
might_fault();
if (likely(access_ok(VERIFY_WRITE, to, n))) {
Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are
queue-4.15/fix-misannotated-out-of-line-_copy_to_user.patch
This is a note to let you know that I've just added the patch titled
dt-bindings: serial: Add common rs485 binding for RTS polarity
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:
dt-bindings-serial-add-common-rs485-binding-for-rts-polarity.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Lukas Wunner <lukas(a)wunner.de>
Date: Fri, 24 Nov 2017 23:26:40 +0100
Subject: dt-bindings: serial: Add common rs485 binding for RTS polarity
From: Lukas Wunner <lukas(a)wunner.de>
[ Upstream commit 6abe9ea8a5a5904d935b8a482117a7fd9b25f09e ]
rs485 allows for robust half-duplex serial communication. It is often
implemented by attaching an rs485 transceiver to a UART. The UART's
RTS line is wired to the transceiver's Transmit Enable pin and
determines whether the transceiver is sending or receiving.
Examples for such transceivers are Maxim MAX13451E and TI SN65HVD1781A:
https://datasheets.maximintegrated.com/en/ds/MAX13450E-MAX13451E.pdfhttp://www.ti.com/lit/ds/symlink/sn65hvd1781a-q1.pdf
In the devicetree, the transceiver itself is not represented, only the
UART is. A few rs485-specific dt-bindings already exist and these go
into the UART's device node.
This commit adds a binding to set the RTS polarity. Most (if not all)
transceivers require the Transmit Enable pin be driven high for sending,
but in some cases boards may negate the pin and RTS must then be driven
low. Consequently the polarity defaults to active high but can be
inverted with the newly added "rs485-rts-active-low" binding.
Document this binding in rs485.txt and in the two drivers fsl-imx-uart
and fsl-lpuart that are about to be amended with support for it.
Curiously, the omap_serial driver defaults to active low and already
supports an "rs485-rts-active-high" binding to invert the polarity.
This is left unchanged to retain compatibility, but the binding is
herewith documented.
Cc: Mark Jackson <mpfj(a)newflow.co.uk>
Cc: Michał Oleszczyk <oleszczyk.m(a)gmail.com>
Cc: Rafael Gago Castano <rgc(a)hms.se>
Cc: Sascha Hauer <s.hauer(a)pengutronix.de>
Acked-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | 3 ++-
Documentation/devicetree/bindings/serial/fsl-lpuart.txt | 3 ++-
Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
Documentation/devicetree/bindings/serial/rs485.txt | 1 +
4 files changed, 6 insertions(+), 2 deletions(-)
--- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
@@ -9,7 +9,8 @@ Optional properties:
- fsl,irda-mode : Indicate the uart supports irda mode
- fsl,dte-mode : Indicate the uart works in DTE mode. The uart works
in DCE mode by default.
-- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt
+- rs485-rts-delay, rs485-rts-active-low, rs485-rx-during-tx,
+ linux,rs485-enabled-at-boot-time: see rs485.txt
Please check Documentation/devicetree/bindings/serial/serial.txt
for the complete list of generic properties.
--- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
@@ -16,7 +16,8 @@ Required properties:
Optional properties:
- dmas: A list of two dma specifiers, one for each entry in dma-names.
- dma-names: should contain "tx" and "rx".
-- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt
+- rs485-rts-delay, rs485-rts-active-low, rs485-rx-during-tx,
+ linux,rs485-enabled-at-boot-time: see rs485.txt
Note: Optional properties for DMA support. Write them both or both not.
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -20,6 +20,7 @@ Optional properties:
node and a DMA channel number.
- dma-names : "rx" for receive channel, "tx" for transmit channel.
- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt
+- rs485-rts-active-high: drive RTS high when sending (default is low).
Example:
--- a/Documentation/devicetree/bindings/serial/rs485.txt
+++ b/Documentation/devicetree/bindings/serial/rs485.txt
@@ -12,6 +12,7 @@ Optional properties:
* b is the delay between end of data sent and rts signal in milliseconds
it corresponds to the delay after sending data and actual release of the line.
If this property is not specified, <0 0> is assumed.
+- rs485-rts-active-low: drive RTS low when sending (default is high).
- linux,rs485-enabled-at-boot-time: empty property telling to enable the rs485
feature at boot time. It can be disabled later with proper ioctl.
- rs485-rx-during-tx: empty property that enables the receiving of data even
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.15/dt-bindings-serial-add-common-rs485-binding-for-rts-polarity.patch
This is a note to let you know that I've just added the patch titled
drm/vblank: Fix vblank timestamp debugs
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:
drm-vblank-fix-vblank-timestamp-debugs.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com>
Date: Mon, 13 Nov 2017 17:02:10 +0200
Subject: drm/vblank: Fix vblank timestamp debugs
From: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com>
[ Upstream commit bcbec31ce500fe036f75a19bca5c73bfa6dd420b ]
We're currently calling ktime_to_timespec64() on stack garbage
hence the debug output for vblank timestamps also contains garbage.
Let's assing something to the ktime_t first before we go converting
it to a timespec.
While at it micro-optimize the ktime_to_timespec64() calls away
when vblank debugging isn't enabled.
Fixes: 67680d3c0464 ("drm: vblank: use ktime_t instead of timeval")
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: Keith Packard <keithp(a)keithp.com>
Cc: Sean Paul <seanpaul(a)chromium.org>
Cc: Dave Airlie <airlied(a)redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113150210.11311-1-ville.…
Acked-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_vblank.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -663,14 +663,16 @@ bool drm_calc_vbltimestamp_from_scanoutp
delta_ns = div_s64(1000000LL * (vpos * mode->crtc_htotal + hpos),
mode->crtc_clock);
- /* save this only for debugging purposes */
- ts_etime = ktime_to_timespec64(etime);
- ts_vblank_time = ktime_to_timespec64(*vblank_time);
/* Subtract time delta from raw timestamp to get final
* vblank_time timestamp for end of vblank.
*/
- etime = ktime_sub_ns(etime, delta_ns);
- *vblank_time = etime;
+ *vblank_time = ktime_sub_ns(etime, delta_ns);
+
+ if ((drm_debug & DRM_UT_VBL) == 0)
+ return true;
+
+ ts_etime = ktime_to_timespec64(etime);
+ ts_vblank_time = ktime_to_timespec64(*vblank_time);
DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %lld.%06ld -> %lld.%06ld [e %d us, %d rep]\n",
pipe, hpos, vpos,
Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are
queue-4.15/drm-vblank-fix-vblank-timestamp-debugs.patch
queue-4.15/video-hdmi-allow-empty-hdmi-infoframes.patch
queue-4.15/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch
This is a note to let you know that I've just added the patch titled
drm/sun4i: Fix format mask in DE2 driver
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:
drm-sun4i-fix-format-mask-in-de2-driver.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Jernej Skrabec <jernej.skrabec(a)siol.net>
Date: Fri, 1 Dec 2017 07:05:24 +0100
Subject: drm/sun4i: Fix format mask in DE2 driver
From: Jernej Skrabec <jernej.skrabec(a)siol.net>
[ Upstream commit a2407f4bd1f3001d6b46f6d32eb1cc98a60f5a43 ]
Format mask is one bit too short. Fix it.
Fixes: 9d75b8c0b999 (drm/sun4i: add support for Allwinner DE2 mixers)
Signed-off-by: Jernej Skrabec <jernej.skrabec(a)siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171201060550.10392-2-jernej…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/sun4i/sun8i_mixer.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -80,7 +80,7 @@
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN BIT(0)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK GENMASK(2, 1)
-#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK GENMASK(11, 8)
+#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK GENMASK(12, 8)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK GENMASK(31, 24)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF (1 << 1)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_ARGB8888 (0 << 8)
Patches currently in stable-queue which might be from jernej.skrabec(a)siol.net are
queue-4.15/drm-sun4i-fix-format-mask-in-de2-driver.patch
This is a note to let you know that I've just added the patch titled
drm/panel: rpi-touchscreen: propagate errors in rpi_touchscreen_i2c_read()
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:
drm-panel-rpi-touchscreen-propagate-errors-in-rpi_touchscreen_i2c_read.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 foo@baz Fri Mar 16 15:10:48 CET 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Fri, 20 Oct 2017 03:28:45 +0300
Subject: drm/panel: rpi-touchscreen: propagate errors in rpi_touchscreen_i2c_read()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 85b4587f8e94143bafb8b6a4003a5187b9a8753d ]
There is one caller which checks whether rpi_touchscreen_i2c_read()
returns negative error codes. Currently it can't because negative
error codes are truncated to u8, but that's easy to fix if we change the
type to int.
Fixes: 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7" Touchscreen.")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Eric Anholt <eric(a)anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20171020002845.kar2wg7gqxg7tz…
Reviewed-by: Eric Anholt <eric(a)anholt.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 890fd6ff397c..d964d454e4ae 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -221,7 +221,7 @@ static struct rpi_touchscreen *panel_to_ts(struct drm_panel *panel)
return container_of(panel, struct rpi_touchscreen, base);
}
-static u8 rpi_touchscreen_i2c_read(struct rpi_touchscreen *ts, u8 reg)
+static int rpi_touchscreen_i2c_read(struct rpi_touchscreen *ts, u8 reg)
{
return i2c_smbus_read_byte_data(ts->i2c, reg);
}
--
2.16.2
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.15/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.15/crypto-chelsio-fix-an-error-code-in-chcr_hash_dma_map.patch
queue-4.15/drm-panel-rpi-touchscreen-propagate-errors-in-rpi_touchscreen_i2c_read.patch
queue-4.15/bnxt_en-uninitialized-variable-in-bnxt_tc_parse_actions.patch
queue-4.15/power-supply-sbs-message-double-left-shift-bug-in-sbsm_select.patch
queue-4.15/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
drm/etnaviv: make THERMAL selectable
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:
drm-etnaviv-make-thermal-selectable.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Philipp Zabel <p.zabel(a)pengutronix.de>
Date: Fri, 1 Dec 2017 16:00:41 +0100
Subject: drm/etnaviv: make THERMAL selectable
From: Philipp Zabel <p.zabel(a)pengutronix.de>
[ Upstream commit 49b82c389d2a40eaef1355aaa35868b367aec9d1 ]
The etnaviv driver causes a link failure if it is built-in but THERMAL
is built as a module:
drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind':
etnaviv_gpu.c:(.text+0x4c4): undefined reference to `thermal_of_cooling_device_register'
etnaviv_gpu.c:(.text+0x600): undefined reference to `thermal_cooling_device_unregister'
drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_unbind':
etnaviv_gpu.c:(.text+0x2aac): undefined reference to `thermal_cooling_device_unregister'
Adding a Kconfig dependency on THERMAL || !THERMAL to avoid this causes
a dependency loop on x86_64:
drivers/gpu/drm/tve200/Kconfig:1:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/tve200/Kconfig:1: symbol DRM_TVE200 depends on CMA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
mm/Kconfig:489: symbol CMA is selected by DRM_ETNAVIV
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/etnaviv/Kconfig:2: symbol DRM_ETNAVIV depends on THERMAL
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/thermal/Kconfig:5: symbol THERMAL is selected by ACPI_VIDEO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/acpi/Kconfig:189: symbol ACPI_VIDEO is selected by BACKLIGHT_CLASS_DEVICE
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/backlight/Kconfig:158: symbol BACKLIGHT_CLASS_DEVICE is selected by DRM_PARADE_PS8622
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/bridge/Kconfig:62: symbol DRM_PARADE_PS8622 depends on DRM_BRIDGE
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_TVE200
To work around this, add a new option DRM_ETNAVIV_THERMAL to optionally
enable thermal throttling support and make DRM_ETNAVIV select THERMAL
at the same time.
Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de>
Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/etnaviv/Kconfig | 9 +++++++++
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 8 +++++---
2 files changed, 14 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -6,6 +6,7 @@ config DRM_ETNAVIV
depends on MMU
select SHMEM
select SYNC_FILE
+ select THERMAL if DRM_ETNAVIV_THERMAL
select TMPFS
select WANT_DEV_COREDUMP
select CMA if HAVE_DMA_CONTIGUOUS
@@ -13,6 +14,14 @@ config DRM_ETNAVIV
help
DRM driver for Vivante GPUs.
+config DRM_ETNAVIV_THERMAL
+ bool "enable ETNAVIV thermal throttling"
+ depends on DRM_ETNAVIV
+ default y
+ help
+ Compile in support for thermal throttling.
+ Say Y unless you want to risk burning your SoC.
+
config DRM_ETNAVIV_REGISTER_LOGGING
bool "enable ETNAVIV register logging"
depends on DRM_ETNAVIV
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1738,7 +1738,7 @@ static int etnaviv_gpu_bind(struct devic
struct etnaviv_gpu *gpu = dev_get_drvdata(dev);
int ret;
- if (IS_ENABLED(CONFIG_THERMAL)) {
+ if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL)) {
gpu->cooling = thermal_of_cooling_device_register(dev->of_node,
(char *)dev_name(dev), gpu, &cooling_ops);
if (IS_ERR(gpu->cooling))
@@ -1751,7 +1751,8 @@ static int etnaviv_gpu_bind(struct devic
ret = etnaviv_gpu_clk_enable(gpu);
#endif
if (ret < 0) {
- thermal_cooling_device_unregister(gpu->cooling);
+ if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL))
+ thermal_cooling_device_unregister(gpu->cooling);
return ret;
}
@@ -1808,7 +1809,8 @@ static void etnaviv_gpu_unbind(struct de
gpu->drm = NULL;
- thermal_cooling_device_unregister(gpu->cooling);
+ if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL))
+ thermal_cooling_device_unregister(gpu->cooling);
gpu->cooling = NULL;
}
Patches currently in stable-queue which might be from p.zabel(a)pengutronix.de are
queue-4.15/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch
queue-4.15/drm-etnaviv-make-thermal-selectable.patch
This is a note to let you know that I've just added the patch titled
drm/edid: set ELD connector type in drm_edid_to_eld()
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:
drm-edid-set-eld-connector-type-in-drm_edid_to_eld.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Jani Nikula <jani.nikula(a)intel.com>
Date: Wed, 1 Nov 2017 16:20:58 +0200
Subject: drm/edid: set ELD connector type in drm_edid_to_eld()
From: Jani Nikula <jani.nikula(a)intel.com>
[ Upstream commit 1d1c36650752b7fb81cee515a9bba4131cac4b7c ]
Since drm_edid_to_eld() knows the connector type, we can set the type in
ELD while at it. Most connectors this gets called on are not DP
encoders, and with the HDMI type being 0, this does not change behaviour
for non-DP.
For i915 having this in place earlier would have saved a considerable
amount of debugging that lead to the fix 2d8f63297b9f ("drm/i915: always
update ELD connector type after get modes"). I don't see other drivers,
even the ones calling drm_edid_to_eld() on DP connectors, setting the
connector type in ELD.
Cc: Alex Deucher <alexander.deucher(a)amd.com>
Cc: Christian König <christian.koenig(a)amd.com>
Cc: Archit Taneja <architt(a)codeaurora.org>
Cc: Andrzej Hajda <a.hajda(a)samsung.com>
Cc: Russell King <linux(a)armlinux.org.uk>
Cc: CK Hu <ck.hu(a)mediatek.com>
Cc: Philipp Zabel <p.zabel(a)pengutronix.de>
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Mark Yao <mark.yao(a)rock-chips.com>
Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
Cc: Vincent Abriou <vincent.abriou(a)st.com>
Cc: Thierry Reding <thierry.reding(a)gmail.com>
Cc: Eric Anholt <eric(a)anholt.net>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Acked-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d527b31619528c477c2c136f25cdf…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3843,8 +3843,7 @@ EXPORT_SYMBOL(drm_edid_get_monitor_name)
* @edid: EDID to parse
*
* Fill the ELD (EDID-Like Data) buffer for passing to the audio driver. The
- * Conn_Type, HDCP and Port_ID ELD fields are left for the graphics driver to
- * fill in.
+ * HDCP and Port_ID ELD fields are left for the graphics driver to fill in.
*/
void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
{
@@ -3925,6 +3924,12 @@ void drm_edid_to_eld(struct drm_connecto
}
eld[5] |= total_sad_count << 4;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP)
+ eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_DP;
+ else
+ eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_HDMI;
+
eld[DRM_ELD_BASELINE_ELD_LEN] =
DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
Patches currently in stable-queue which might be from jani.nikula(a)intel.com are
queue-4.15/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch
This is a note to let you know that I've just added the patch titled
drm/amdkfd: Fix memory leaks in kfd topology
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:
drm-amdkfd-fix-memory-leaks-in-kfd-topology.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Yong Zhao <yong.zhao(a)amd.com>
Date: Fri, 8 Dec 2017 23:08:48 -0500
Subject: drm/amdkfd: Fix memory leaks in kfd topology
From: Yong Zhao <yong.zhao(a)amd.com>
[ Upstream commit 5108d768408abc80e4e8d99f5b406a73cb04056b ]
Kobject created using kobject_create_and_add() can be freed using
kobject_put() when there is no referenece any more. However,
kobject memory allocated with kzalloc() has to set up a release
callback in order to free it when the counter decreases to 0.
Otherwise it causes memory leak.
Signed-off-by: Yong Zhao <yong.zhao(a)amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com>
Reviewed-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -501,11 +501,17 @@ static ssize_t sysprops_show(struct kobj
return ret;
}
+static void kfd_topology_kobj_release(struct kobject *kobj)
+{
+ kfree(kobj);
+}
+
static const struct sysfs_ops sysprops_ops = {
.show = sysprops_show,
};
static struct kobj_type sysprops_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &sysprops_ops,
};
@@ -541,6 +547,7 @@ static const struct sysfs_ops iolink_ops
};
static struct kobj_type iolink_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &iolink_ops,
};
@@ -568,6 +575,7 @@ static const struct sysfs_ops mem_ops =
};
static struct kobj_type mem_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &mem_ops,
};
@@ -607,6 +615,7 @@ static const struct sysfs_ops cache_ops
};
static struct kobj_type cache_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &cache_ops,
};
@@ -729,6 +738,7 @@ static const struct sysfs_ops node_ops =
};
static struct kobj_type node_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &node_ops,
};
Patches currently in stable-queue which might be from yong.zhao(a)amd.com are
queue-4.15/drm-amdkfd-fix-memory-leaks-in-kfd-topology.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu:fix virtual dce bug
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:
drm-amdgpu-fix-virtual-dce-bug.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Monk Liu <Monk.Liu(a)amd.com>
Date: Wed, 15 Nov 2017 17:10:13 +0800
Subject: drm/amdgpu:fix virtual dce bug
From: Monk Liu <Monk.Liu(a)amd.com>
[ Upstream commit 129d65c18ecfb249aceb540c31fdaf79bd5a11ff ]
this fix the issue that access memory after freed
after driver unloaded.
Signed-off-by: Monk Liu <Monk.Liu(a)amd.com>
Acked-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
@@ -437,6 +437,8 @@ static int dce_virtual_sw_fini(void *han
drm_kms_helper_poll_fini(adev->ddev);
drm_mode_config_cleanup(adev->ddev);
+ /* clear crtcs pointer to avoid dce irq finish routine access freed data */
+ memset(adev->mode_info.crtcs, 0, sizeof(adev->mode_info.crtcs[0]) * AMDGPU_MAX_CRTCS);
adev->mode_info.mode_config_initialized = false;
return 0;
}
@@ -723,7 +725,7 @@ static void dce_virtual_set_crtc_vblank_
int crtc,
enum amdgpu_interrupt_state state)
{
- if (crtc >= adev->mode_info.num_crtc) {
+ if (crtc >= adev->mode_info.num_crtc || !adev->mode_info.crtcs[crtc]) {
DRM_DEBUG("invalid crtc %d\n", crtc);
return;
}
Patches currently in stable-queue which might be from Monk.Liu(a)amd.com are
queue-4.15/drm-amdgpu-fix-random-missing-of-flr-notify.patch
queue-4.15/drm-amdgpu-fix-virtual-dce-bug.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu:fix random missing of FLR NOTIFY
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:
drm-amdgpu-fix-random-missing-of-flr-notify.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Monk Liu <Monk.Liu(a)amd.com>
Date: Tue, 24 Oct 2017 15:10:11 +0800
Subject: drm/amdgpu:fix random missing of FLR NOTIFY
From: Monk Liu <Monk.Liu(a)amd.com>
[ Upstream commit 34a4d2bf06b3ab92024b8e26d6049411369d1f1a ]
Signed-off-by: Monk Liu <Monk.Liu(a)amd.com>
Acked-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
@@ -282,9 +282,17 @@ static int xgpu_ai_mailbox_rcv_irq(struc
/* see what event we get */
r = xgpu_ai_mailbox_rcv_msg(adev, IDH_FLR_NOTIFICATION);
- /* only handle FLR_NOTIFY now */
- if (!r)
- schedule_work(&adev->virt.flr_work);
+ /* sometimes the interrupt is delayed to inject to VM, so under such case
+ * the IDH_FLR_NOTIFICATION is overwritten by VF FLR from GIM side, thus
+ * above recieve message could be failed, we should schedule the flr_work
+ * anyway
+ */
+ if (r) {
+ DRM_ERROR("FLR_NOTIFICATION is missed\n");
+ xgpu_ai_mailbox_send_ack(adev);
+ }
+
+ schedule_work(&adev->virt.flr_work);
}
return 0;
Patches currently in stable-queue which might be from Monk.Liu(a)amd.com are
queue-4.15/drm-amdgpu-fix-random-missing-of-flr-notify.patch
queue-4.15/drm-amdgpu-fix-virtual-dce-bug.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: fix get_max_engine_clock_in_mhz
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:
drm-amdgpu-fix-get_max_engine_clock_in_mhz.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Felix Kuehling <Felix.Kuehling(a)amd.com>
Date: Mon, 27 Nov 2017 18:29:43 -0500
Subject: drm/amdgpu: fix get_max_engine_clock_in_mhz
From: Felix Kuehling <Felix.Kuehling(a)amd.com>
[ Upstream commit a9efcc19161e20623c285fac967a32842972cebe ]
Use proper powerplay function. This fixes OpenCL initialization
problems.
Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com>
Acked-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -265,6 +265,9 @@ uint32_t get_max_engine_clock_in_mhz(str
{
struct amdgpu_device *adev = (struct amdgpu_device *)kgd;
- /* The sclk is in quantas of 10kHz */
- return adev->pm.dpm.dyn_state.max_clock_voltage_on_ac.sclk / 100;
+ /* the sclk is in quantas of 10kHz */
+ if (amdgpu_sriov_vf(adev))
+ return adev->clock.default_sclk / 100;
+
+ return amdgpu_dpm_get_sclk(adev, false) / 100;
}
Patches currently in stable-queue which might be from Felix.Kuehling(a)amd.com are
queue-4.15/drm-amdgpu-fix-get_max_engine_clock_in_mhz.patch
queue-4.15/drm-amdkfd-fix-memory-leaks-in-kfd-topology.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: fix amdgpu_sync_resv v2
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:
drm-amdgpu-fix-amdgpu_sync_resv-v2.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: "Christian König" <christian.koenig(a)amd.com>
Date: Fri, 24 Nov 2017 11:41:52 +0100
Subject: drm/amdgpu: fix amdgpu_sync_resv v2
From: "Christian König" <christian.koenig(a)amd.com>
[ Upstream commit d4b7648d6d1774f961f3f6a758d9b009f1f34f05 ]
Fixes a bug introduced by AMDGPU_GEM_CREATE_EXPLICIT_SYNC. We still need
to wait for pipelined moves in the shared fences list.
v2: fix typo
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Reviewed-by: Andres Rodriguez <andresx7(a)gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
@@ -191,9 +191,6 @@ int amdgpu_sync_resv(struct amdgpu_devic
f = reservation_object_get_excl(resv);
r = amdgpu_sync_fence(adev, sync, f);
- if (explicit_sync)
- return r;
-
flist = reservation_object_get_list(resv);
if (!flist || r)
return r;
@@ -212,11 +209,11 @@ int amdgpu_sync_resv(struct amdgpu_devic
(fence_owner == AMDGPU_FENCE_OWNER_VM)))
continue;
- /* Ignore fence from the same owner as
+ /* Ignore fence from the same owner and explicit one as
* long as it isn't undefined.
*/
if (owner != AMDGPU_FENCE_OWNER_UNDEFINED &&
- fence_owner == owner)
+ (fence_owner == owner || explicit_sync))
continue;
}
Patches currently in stable-queue which might be from christian.koenig(a)amd.com are
queue-4.15/drm-amdgpu-fix-random-missing-of-flr-notify.patch
queue-4.15/drm-amdgpu-fix-amdgpu_sync_resv-v2.patch
queue-4.15/dma-buf-fence-fix-lock-inversion-within-dma-fence-array.patch
queue-4.15/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch
This is a note to let you know that I've just added the patch titled
dmaengine: qcom_hidma: check pending interrupts
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:
dmaengine-qcom_hidma-check-pending-interrupts.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Sinan Kaya <okaya(a)codeaurora.org>
Date: Tue, 14 Nov 2017 09:55:01 -0500
Subject: dmaengine: qcom_hidma: check pending interrupts
From: Sinan Kaya <okaya(a)codeaurora.org>
[ Upstream commit 38680bc6b1e3592bc9e18adc1d6e259667df27ce ]
Driver is missing the interrupts if two requests are queued up at the same
time as the interrupt handler is servicing a request that was just
delivered.
The ISR clears the interrupt at the end but it could be clearing the
interrupt for an outstanding event. Therefore, second interrupt never
arrives.
Clear the interrupt first and then check for completions.
Also, make sure that request start and interrupt clear do not overlap in
time by using a spinlock.
Signed-off-by: Sinan Kaya <okaya(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/qcom/hidma_ll.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -393,6 +393,8 @@ static int hidma_ll_reset(struct hidma_l
*/
static void hidma_ll_int_handler_internal(struct hidma_lldev *lldev, int cause)
{
+ unsigned long irqflags;
+
if (cause & HIDMA_ERR_INT_MASK) {
dev_err(lldev->dev, "error 0x%x, disabling...\n",
cause);
@@ -410,6 +412,10 @@ static void hidma_ll_int_handler_interna
return;
}
+ spin_lock_irqsave(&lldev->lock, irqflags);
+ writel_relaxed(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+ spin_unlock_irqrestore(&lldev->lock, irqflags);
+
/*
* Fine tuned for this HW...
*
@@ -421,9 +427,6 @@ static void hidma_ll_int_handler_interna
* Try to consume as many EVREs as possible.
*/
hidma_handle_tre_completion(lldev);
-
- /* We consumed TREs or there are pending TREs or EVREs. */
- writel_relaxed(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
}
irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
Patches currently in stable-queue which might be from okaya(a)codeaurora.org are
queue-4.15/dmaengine-qcom_hidma-check-pending-interrupts.patch
This is a note to let you know that I've just added the patch titled
dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free
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:
dmaengine-bcm2835-dma-use-vchan_terminate_vdesc-instead-of-desc_free.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Tue, 14 Nov 2017 16:32:07 +0200
Subject: dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit de92436ac40ffe9933230aa503e24dbb5ede9201 ]
To avoid race with vchan_complete, use the race free way to terminate
running transfer.
Implement the device_synchronize callback to make sure that the terminated
descriptor is freed.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Acked-by: Eric Anholt <eric(a)anholt.net>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/bcm2835-dma.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -812,7 +812,7 @@ static int bcm2835_dma_terminate_all(str
* c->desc is NULL and exit.)
*/
if (c->desc) {
- bcm2835_dma_desc_free(&c->desc->vd);
+ vchan_terminate_vdesc(&c->desc->vd);
c->desc = NULL;
bcm2835_dma_abort(c->chan_base);
@@ -836,6 +836,13 @@ static int bcm2835_dma_terminate_all(str
return 0;
}
+static void bcm2835_dma_synchronize(struct dma_chan *chan)
+{
+ struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
+
+ vchan_synchronize(&c->vc);
+}
+
static int bcm2835_dma_chan_init(struct bcm2835_dmadev *d, int chan_id,
int irq, unsigned int irq_flags)
{
@@ -942,6 +949,7 @@ static int bcm2835_dma_probe(struct plat
od->ddev.device_prep_dma_memcpy = bcm2835_dma_prep_dma_memcpy;
od->ddev.device_config = bcm2835_dma_slave_config;
od->ddev.device_terminate_all = bcm2835_dma_terminate_all;
+ od->ddev.device_synchronize = bcm2835_dma_synchronize;
od->ddev.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
od->ddev.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
od->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV) |
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.15/dmaengine-bcm2835-dma-use-vchan_terminate_vdesc-instead-of-desc_free.patch
queue-4.15/dmaengine-amba-pl08x-use-vchan_terminate_vdesc-instead-of-desc_free.patch
This is a note to let you know that I've just added the patch titled
dmaengine: amba-pl08x: Use vchan_terminate_vdesc() instead of desc_free
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:
dmaengine-amba-pl08x-use-vchan_terminate_vdesc-instead-of-desc_free.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Tue, 14 Nov 2017 16:32:09 +0200
Subject: dmaengine: amba-pl08x: Use vchan_terminate_vdesc() instead of desc_free
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit 47d71bc75d072ce25c1063aa629e55e1cfb961b2 ]
To avoid race with vchan_complete, use the race free way to terminate
running transfer.
Implement the device_synchronize callback to make sure that the terminated
descriptor is freed.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/amba-pl08x.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2182,7 +2182,7 @@ static int pl08x_terminate_all(struct dm
}
/* Dequeue jobs and free LLIs */
if (plchan->at) {
- pl08x_desc_free(&plchan->at->vd);
+ vchan_terminate_vdesc(&plchan->at->vd);
plchan->at = NULL;
}
/* Dequeue jobs not yet fired as well */
@@ -2193,6 +2193,13 @@ static int pl08x_terminate_all(struct dm
return 0;
}
+static void pl08x_synchronize(struct dma_chan *chan)
+{
+ struct pl08x_dma_chan *plchan = to_pl08x_chan(chan);
+
+ vchan_synchronize(&plchan->vc);
+}
+
static int pl08x_pause(struct dma_chan *chan)
{
struct pl08x_dma_chan *plchan = to_pl08x_chan(chan);
@@ -2773,6 +2780,7 @@ static int pl08x_probe(struct amba_devic
pl08x->memcpy.device_pause = pl08x_pause;
pl08x->memcpy.device_resume = pl08x_resume;
pl08x->memcpy.device_terminate_all = pl08x_terminate_all;
+ pl08x->memcpy.device_synchronize = pl08x_synchronize;
pl08x->memcpy.src_addr_widths = PL80X_DMA_BUSWIDTHS;
pl08x->memcpy.dst_addr_widths = PL80X_DMA_BUSWIDTHS;
pl08x->memcpy.directions = BIT(DMA_MEM_TO_MEM);
@@ -2802,6 +2810,7 @@ static int pl08x_probe(struct amba_devic
pl08x->slave.device_pause = pl08x_pause;
pl08x->slave.device_resume = pl08x_resume;
pl08x->slave.device_terminate_all = pl08x_terminate_all;
+ pl08x->slave.device_synchronize = pl08x_synchronize;
pl08x->slave.src_addr_widths = PL80X_DMA_BUSWIDTHS;
pl08x->slave.dst_addr_widths = PL80X_DMA_BUSWIDTHS;
pl08x->slave.directions =
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.15/dmaengine-bcm2835-dma-use-vchan_terminate_vdesc-instead-of-desc_free.patch
queue-4.15/dmaengine-amba-pl08x-use-vchan_terminate_vdesc-instead-of-desc_free.patch
This is a note to let you know that I've just added the patch titled
dma-buf/fence: Fix lock inversion within dma-fence-array
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:
dma-buf-fence-fix-lock-inversion-within-dma-fence-array.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Tue, 14 Nov 2017 16:27:19 +0000
Subject: dma-buf/fence: Fix lock inversion within dma-fence-array
From: Chris Wilson <chris(a)chris-wilson.co.uk>
[ Upstream commit 03e4e0a9e02cf703da331ff6cfd57d0be9bf5692 ]
Ages ago Rob Clark noted,
"Currently with fence-array, we have a potential deadlock situation. If
we fence_add_callback() on an array-fence, the array-fence's lock is
acquired first, and in it's ->enable_signaling() callback, it will install
cbs on it's array-member fences, so the array-member's lock is acquired
second.
But in the signal path, the array-member's lock is acquired first, and
the array-fence's lock acquired second."
Rob proposed either extensive changes to dma-fence to unnest the
fence-array signaling, or to defer the signaling onto a workqueue. This
is a more refined version of the later, that should keep the latency
of the fence signaling to a minimum by using an irq-work, which is
executed asap.
Reported-by: Rob Clark <robdclark(a)gmail.com>
Suggested-by: Rob Clark <robdclark(a)gmail.com>
References: 1476635975-21981-1-git-send-email-robdclark(a)gmail.com
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Rob Clark <robdclark(a)gmail.com>
Cc: Gustavo Padovan <gustavo.padovan(a)collabora.co.uk>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Cc: Christian König <christian.koenig(a)amd.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114162719.30958-1-chris@…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/Kconfig | 1 +
drivers/dma-buf/dma-fence-array.c | 14 ++++++++++++--
include/linux/dma-fence-array.h | 3 +++
3 files changed, 16 insertions(+), 2 deletions(-)
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -249,6 +249,7 @@ config DMA_SHARED_BUFFER
bool
default n
select ANON_INODES
+ select IRQ_WORK
help
This option enables the framework for buffer-sharing between
multiple drivers. A buffer is associated with a file using driver
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -31,6 +31,14 @@ static const char *dma_fence_array_get_t
return "unbound";
}
+static void irq_dma_fence_array_work(struct irq_work *wrk)
+{
+ struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
+
+ dma_fence_signal(&array->base);
+ dma_fence_put(&array->base);
+}
+
static void dma_fence_array_cb_func(struct dma_fence *f,
struct dma_fence_cb *cb)
{
@@ -39,8 +47,9 @@ static void dma_fence_array_cb_func(stru
struct dma_fence_array *array = array_cb->array;
if (atomic_dec_and_test(&array->num_pending))
- dma_fence_signal(&array->base);
- dma_fence_put(&array->base);
+ irq_work_queue(&array->work);
+ else
+ dma_fence_put(&array->base);
}
static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
@@ -136,6 +145,7 @@ struct dma_fence_array *dma_fence_array_
spin_lock_init(&array->lock);
dma_fence_init(&array->base, &dma_fence_array_ops, &array->lock,
context, seqno);
+ init_irq_work(&array->work, irq_dma_fence_array_work);
array->num_fences = num_fences;
atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -21,6 +21,7 @@
#define __LINUX_DMA_FENCE_ARRAY_H
#include <linux/dma-fence.h>
+#include <linux/irq_work.h>
/**
* struct dma_fence_array_cb - callback helper for fence array
@@ -47,6 +48,8 @@ struct dma_fence_array {
unsigned num_fences;
atomic_t num_pending;
struct dma_fence **fences;
+
+ struct irq_work work;
};
extern const struct dma_fence_ops dma_fence_array_ops;
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.15/dma-buf-fence-fix-lock-inversion-within-dma-fence-array.patch
queue-4.15/agp-intel-flush-all-chipset-writes-after-updating-the-ggtt.patch
This is a note to let you know that I've just added the patch titled
dm raid: fix raid set size revalidation
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:
dm-raid-fix-raid-set-size-revalidation.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Heinz Mauelshagen <heinzm(a)redhat.com>
Date: Sat, 2 Dec 2017 01:03:51 +0100
Subject: dm raid: fix raid set size revalidation
From: Heinz Mauelshagen <heinzm(a)redhat.com>
[ Upstream commit 61e06e2c3ebd986050958513bfa40dceed756f8f ]
The raid set size is being revalidated unconditionally before a
reshaping conversion is started. MD requires the size to only be
reduced in case of a stripe removing (i.e. shrinking) reshape but not
when growing because the raid array has to stay small until after the
growing reshape finishes.
Fix by avoiding the size revalidation in preresume unless a shrinking
reshape is requested.
Signed-off-by: Heinz Mauelshagen <heinzm(a)redhat.com>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/dm-raid.c | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -675,15 +675,11 @@ static struct raid_type *get_raid_type_b
return NULL;
}
-/*
- * Conditionally change bdev capacity of @rs
- * in case of a disk add/remove reshape
- */
-static void rs_set_capacity(struct raid_set *rs)
+/* Adjust rdev sectors */
+static void rs_set_rdev_sectors(struct raid_set *rs)
{
struct mddev *mddev = &rs->md;
struct md_rdev *rdev;
- struct gendisk *gendisk = dm_disk(dm_table_get_md(rs->ti->table));
/*
* raid10 sets rdev->sector to the device size, which
@@ -692,8 +688,16 @@ static void rs_set_capacity(struct raid_
rdev_for_each(rdev, mddev)
if (!test_bit(Journal, &rdev->flags))
rdev->sectors = mddev->dev_sectors;
+}
- set_capacity(gendisk, mddev->array_sectors);
+/*
+ * Change bdev capacity of @rs in case of a disk add/remove reshape
+ */
+static void rs_set_capacity(struct raid_set *rs)
+{
+ struct gendisk *gendisk = dm_disk(dm_table_get_md(rs->ti->table));
+
+ set_capacity(gendisk, rs->md.array_sectors);
revalidate_disk(gendisk);
}
@@ -1674,8 +1678,11 @@ static void do_table_event(struct work_s
struct raid_set *rs = container_of(ws, struct raid_set, md.event_work);
smp_rmb(); /* Make sure we access most actual mddev properties */
- if (!rs_is_reshaping(rs))
+ if (!rs_is_reshaping(rs)) {
+ if (rs_is_raid10(rs))
+ rs_set_rdev_sectors(rs);
rs_set_capacity(rs);
+ }
dm_table_event(rs->ti->table);
}
@@ -3842,11 +3849,10 @@ static int raid_preresume(struct dm_targ
mddev->resync_min = mddev->recovery_cp;
}
- rs_set_capacity(rs);
-
/* Check for any reshape request unless new raid set */
if (test_and_clear_bit(RT_FLAG_RESHAPE_RS, &rs->runtime_flags)) {
/* Initiate a reshape. */
+ rs_set_rdev_sectors(rs);
mddev_lock_nointr(mddev);
r = rs_start_reshape(rs);
mddev_unlock(mddev);
@@ -3875,6 +3881,10 @@ static void raid_resume(struct dm_target
mddev->ro = 0;
mddev->in_sync = 0;
+ /* Only reduce raid set size before running a disk removing reshape. */
+ if (mddev->delta_disks < 0)
+ rs_set_capacity(rs);
+
/*
* Keep the RAID set frozen if reshape/rebuild flags are set.
* The RAID set is unfrozen once the next table load/resume,
Patches currently in stable-queue which might be from heinzm(a)redhat.com are
queue-4.15/dm-raid-fix-raid-set-size-revalidation.patch
This is a note to let you know that I've just added the patch titled
crypto: keywrap - Add missing ULL suffixes for 64-bit constants
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:
crypto-keywrap-add-missing-ull-suffixes-for-64-bit-constants.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Wed, 15 Nov 2017 11:44:28 +0100
Subject: crypto: keywrap - Add missing ULL suffixes for 64-bit constants
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
[ Upstream commit c9683276dd89906ca9b65696d09104d542171421 ]
On 32-bit (e.g. with m68k-linux-gnu-gcc-4.1):
crypto/keywrap.c: In function ‘crypto_kw_decrypt’:
crypto/keywrap.c:191: warning: integer constant is too large for ‘long’ type
crypto/keywrap.c: In function ‘crypto_kw_encrypt’:
crypto/keywrap.c:224: warning: integer constant is too large for ‘long’ type
Fixes: 9e49451d7a15365d ("crypto: keywrap - simplify code")
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Reviewed-by: Stephan Mueller <smueller(a)chronox.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/keywrap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/crypto/keywrap.c
+++ b/crypto/keywrap.c
@@ -188,7 +188,7 @@ static int crypto_kw_decrypt(struct blkc
}
/* Perform authentication check */
- if (block.A != cpu_to_be64(0xa6a6a6a6a6a6a6a6))
+ if (block.A != cpu_to_be64(0xa6a6a6a6a6a6a6a6ULL))
ret = -EBADMSG;
memzero_explicit(&block, sizeof(struct crypto_kw_block));
@@ -221,7 +221,7 @@ static int crypto_kw_encrypt(struct blkc
* Place the predefined IV into block A -- for encrypt, the caller
* does not need to provide an IV, but he needs to fetch the final IV.
*/
- block.A = cpu_to_be64(0xa6a6a6a6a6a6a6a6);
+ block.A = cpu_to_be64(0xa6a6a6a6a6a6a6a6ULL);
/*
* src scatterlist is read-only. dst scatterlist is r/w. During the
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.15/crypto-keywrap-add-missing-ull-suffixes-for-64-bit-constants.patch
This is a note to let you know that I've just added the patch titled
crypto: ecc - Fix NULL pointer deref. on no default_rng
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:
crypto-ecc-fix-null-pointer-deref.-on-no-default_rng.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Pierre <pinaraf(a)pinaraf.info>
Date: Sun, 12 Nov 2017 15:24:32 +0100
Subject: crypto: ecc - Fix NULL pointer deref. on no default_rng
From: Pierre <pinaraf(a)pinaraf.info>
[ Upstream commit 4c0e22c90510308433272d7ba281b1eb4eda8209 ]
If crypto_get_default_rng returns an error, the
function ecc_gen_privkey should return an error.
Instead, it currently tries to use the default_rng
nevertheless, thus creating a kernel panic with a
NULL pointer dereference.
Returning the error directly, as was supposedly
intended when looking at the code, fixes this.
Signed-off-by: Pierre Ducroquet <pinaraf(a)pinaraf.info>
Reviewed-by: PrasannaKumar Muralidharan <prasannatsmkumar(a)gmail.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/ecc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -964,7 +964,7 @@ int ecc_gen_privkey(unsigned int curve_i
* DRBG with a security strength of 256.
*/
if (crypto_get_default_rng())
- err = -EFAULT;
+ return -EFAULT;
err = crypto_rng_get_bytes(crypto_default_rng, (u8 *)priv, nbytes);
crypto_put_default_rng();
Patches currently in stable-queue which might be from pinaraf(a)pinaraf.info are
queue-4.15/crypto-ecc-fix-null-pointer-deref.-on-no-default_rng.patch
This is a note to let you know that I've just added the patch titled
crypto: chelsio - Fix an error code in chcr_hash_dma_map()
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:
crypto-chelsio-fix-an-error-code-in-chcr_hash_dma_map.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Fri, 10 Nov 2017 00:25:43 +0300
Subject: crypto: chelsio - Fix an error code in chcr_hash_dma_map()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 7814f552ff826fefa5e1b24083c7a06a9378e9ef ]
The dma_map_sg() function returns zero on error and positive values on
success. We want to return -ENOMEM on failure here and zero on success.
Fixes: 2f47d5804311 ("crypto: chelsio - Move DMA un/mapping to chcr from lld cxgb4 driver")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/chelsio/chcr_algo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -2414,7 +2414,7 @@ static inline int chcr_hash_dma_map(stru
error = dma_map_sg(dev, req->src, sg_nents(req->src),
DMA_TO_DEVICE);
if (!error)
- return error;
+ return -ENOMEM;
req_ctx->is_sg_map = 1;
return 0;
}
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.15/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.15/crypto-chelsio-fix-an-error-code-in-chcr_hash_dma_map.patch
queue-4.15/drm-panel-rpi-touchscreen-propagate-errors-in-rpi_touchscreen_i2c_read.patch
queue-4.15/bnxt_en-uninitialized-variable-in-bnxt_tc_parse_actions.patch
queue-4.15/power-supply-sbs-message-double-left-shift-bug-in-sbsm_select.patch
queue-4.15/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
crypto: cavium - fix memory leak on info
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:
crypto-cavium-fix-memory-leak-on-info.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Colin Ian King <colin.king(a)canonical.com>
Date: Wed, 15 Nov 2017 12:37:19 +0000
Subject: crypto: cavium - fix memory leak on info
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 87aae50af730a28dc1d8846d86dca5e9aa724a9f ]
The object info is being leaked on an error return path, fix this
by setting ret to -ENOMEM and exiting via the request_cleanup path
that will free info.
Detected by CoverityScan, CID#1408439 ("Resource Leak")
Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
+++ b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
@@ -459,7 +459,8 @@ int process_request(struct cpt_vf *cptvf
info->completion_addr = kzalloc(sizeof(union cpt_res_s), GFP_KERNEL);
if (unlikely(!info->completion_addr)) {
dev_err(&pdev->dev, "Unable to allocate memory for completion_addr\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto request_cleanup;
}
result = (union cpt_res_s *)info->completion_addr;
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.15/usbip-vudc-fix-null-pointer-dereference-on-udc-lock.patch
queue-4.15/crypto-cavium-fix-memory-leak-on-info.patch
queue-4.15/staging-rtl8822be-fix-missing-null-check-on-dev_alloc_skb-return.patch
This is a note to let you know that I've just added the patch titled
crypto: caam/qi - use correct print specifier for size_t
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:
crypto-caam-qi-use-correct-print-specifier-for-size_t.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: "Horia Geantă" <horia.geanta(a)nxp.com>
Date: Tue, 28 Nov 2017 18:48:08 +0200
Subject: crypto: caam/qi - use correct print specifier for size_t
From: "Horia Geantă" <horia.geanta(a)nxp.com>
[ Upstream commit 9db09e3bad65393dc23b0279beb7f3754d77065c ]
Fix below warnings on ARMv7 by using %zu for printing size_t values:
drivers/crypto/caam/caamalg_qi.c: In function aead_edesc_alloc:
drivers/crypto/caam/caamalg_qi.c:417:17: warning: format %lu expects argument of type long unsigned int, but argument 4 has type unsigned int [-Wformat=]
sizeof(struct qm_sg_entry))
^
drivers/crypto/caam/caamalg_qi.c:672:16: note: in expansion of macro CAAM_QI_MAX_AEAD_SG
qm_sg_ents, CAAM_QI_MAX_AEAD_SG);
^
drivers/crypto/caam/caamalg_qi.c: In function ablkcipher_edesc_alloc:
drivers/crypto/caam/caamalg_qi.c:440:17: warning: format %lu expects argument of type long unsigned int, but argument 4 has type unsigned int [-Wformat=]
sizeof(struct qm_sg_entry))
^
drivers/crypto/caam/caamalg_qi.c:909:16: note: in expansion of macro CAAM_QI_MAX_ABLKCIPHER_SG
qm_sg_ents, CAAM_QI_MAX_ABLKCIPHER_SG);
^
drivers/crypto/caam/caamalg_qi.c: In function ablkcipher_giv_edesc_alloc:
drivers/crypto/caam/caamalg_qi.c:440:17: warning: format %lu expects argument of type long unsigned int, but argument 4 has type unsigned int [-Wformat=]
sizeof(struct qm_sg_entry))
^
drivers/crypto/caam/caamalg_qi.c:1062:16: note: in expansion of macro CAAM_QI_MAX_ABLKCIPHER_SG
qm_sg_ents, CAAM_QI_MAX_ABLKCIPHER_SG);
^
Fixes: eb9ba37dc15a ("crypto: caam/qi - handle large number of S/Gs case")
Signed-off-by: Horia Geantă <horia.geanta(a)nxp.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/caam/caamalg_qi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/crypto/caam/caamalg_qi.c
+++ b/drivers/crypto/caam/caamalg_qi.c
@@ -668,7 +668,7 @@ static struct aead_edesc *aead_edesc_all
qm_sg_ents = 1 + !!ivsize + mapped_src_nents +
(mapped_dst_nents > 1 ? mapped_dst_nents : 0);
if (unlikely(qm_sg_ents > CAAM_QI_MAX_AEAD_SG)) {
- dev_err(qidev, "Insufficient S/G entries: %d > %lu\n",
+ dev_err(qidev, "Insufficient S/G entries: %d > %zu\n",
qm_sg_ents, CAAM_QI_MAX_AEAD_SG);
caam_unmap(qidev, req->src, req->dst, src_nents, dst_nents,
iv_dma, ivsize, op_type, 0, 0);
@@ -905,7 +905,7 @@ static struct ablkcipher_edesc *ablkciph
qm_sg_ents += mapped_dst_nents > 1 ? mapped_dst_nents : 0;
if (unlikely(qm_sg_ents > CAAM_QI_MAX_ABLKCIPHER_SG)) {
- dev_err(qidev, "Insufficient S/G entries: %d > %lu\n",
+ dev_err(qidev, "Insufficient S/G entries: %d > %zu\n",
qm_sg_ents, CAAM_QI_MAX_ABLKCIPHER_SG);
caam_unmap(qidev, req->src, req->dst, src_nents, dst_nents,
iv_dma, ivsize, op_type, 0, 0);
@@ -1058,7 +1058,7 @@ static struct ablkcipher_edesc *ablkciph
}
if (unlikely(qm_sg_ents > CAAM_QI_MAX_ABLKCIPHER_SG)) {
- dev_err(qidev, "Insufficient S/G entries: %d > %lu\n",
+ dev_err(qidev, "Insufficient S/G entries: %d > %zu\n",
qm_sg_ents, CAAM_QI_MAX_ABLKCIPHER_SG);
caam_unmap(qidev, req->src, req->dst, src_nents, dst_nents,
iv_dma, ivsize, GIVENCRYPT, 0, 0);
Patches currently in stable-queue which might be from horia.geanta(a)nxp.com are
queue-4.15/crypto-caam-qi-use-correct-print-specifier-for-size_t.patch
This is a note to let you know that I've just added the patch titled
cpufreq: Fix governor module removal race
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:
cpufreq-fix-governor-module-removal-race.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com>
Date: Thu, 23 Nov 2017 14:27:07 +0100
Subject: cpufreq: Fix governor module removal race
From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com>
[ Upstream commit a8b149d32b663c1a4105273295184b78f53d33cf ]
It is possible to remove a cpufreq governor module after
cpufreq_parse_governor() has returned success in
store_scaling_governor() and before cpufreq_set_policy()
acquires a reference to it, because the governor list is
not protected during that period and nothing prevents the
governor from being unregistered then.
Prevent that from happening by acquiring an extra reference
to the governor module temporarily in cpufreq_parse_governor(),
under cpufreq_governor_mutex, and dropping it in
store_scaling_governor(), when cpufreq_set_policy() returns.
Note that the second cpufreq_parse_governor() call site is fine,
because it only cares about the policy member of new_policy.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/cpufreq/cpufreq.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -637,6 +637,8 @@ static int cpufreq_parse_governor(char *
*governor = t;
err = 0;
}
+ if (t && !try_module_get(t->owner))
+ t = NULL;
mutex_unlock(&cpufreq_governor_mutex);
}
@@ -765,6 +767,10 @@ static ssize_t store_scaling_governor(st
return -EINVAL;
ret = cpufreq_set_policy(policy, &new_policy);
+
+ if (new_policy.governor)
+ module_put(new_policy.governor->owner);
+
return ret ? ret : count;
}
Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are
queue-4.15/cpufreq-fix-governor-module-removal-race.patch
This is a note to let you know that I've just added the patch titled
clk: ti: clkctrl: add support for retrying failed init
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:
clk-ti-clkctrl-add-support-for-retrying-failed-init.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Tero Kristo <t-kristo(a)ti.com>
Date: Thu, 12 Oct 2017 10:55:29 +0300
Subject: clk: ti: clkctrl: add support for retrying failed init
From: Tero Kristo <t-kristo(a)ti.com>
[ Upstream commit 729e13bf58e643b9accd2a14c55b555958702fb0 ]
In case the clkctrl node contains assigned-clock-* entries, registering
the provider can fail with -EPROBE_DEFER. In this case, add the
provider to the retry_init clock list so it will be cleaned up later.
Signed-off-by: Tero Kristo <t-kristo(a)ti.com>
Acked-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/ti/clkctrl.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/drivers/clk/ti/clkctrl.c
+++ b/drivers/clk/ti/clkctrl.c
@@ -400,6 +400,12 @@ _ti_clkctrl_setup_subclks(struct omap_cl
}
}
+static void __init _clkctrl_add_provider(void *data,
+ struct device_node *np)
+{
+ of_clk_add_hw_provider(np, _ti_omap4_clkctrl_xlate, data);
+}
+
static void __init _ti_omap4_clkctrl_setup(struct device_node *node)
{
struct omap_clkctrl_provider *provider;
@@ -411,6 +417,7 @@ static void __init _ti_omap4_clkctrl_set
struct omap_clkctrl_clk *clkctrl_clk;
const __be32 *addrp;
u32 addr;
+ int ret;
addrp = of_get_address(node, 0, NULL, NULL);
addr = (u32)of_translate_address(node, addrp);
@@ -485,7 +492,10 @@ static void __init _ti_omap4_clkctrl_set
reg_data++;
}
- of_clk_add_hw_provider(node, _ti_omap4_clkctrl_xlate, provider);
+ ret = of_clk_add_hw_provider(node, _ti_omap4_clkctrl_xlate, provider);
+ if (ret == -EPROBE_DEFER)
+ ti_clk_retry_init(node, provider, _clkctrl_add_provider);
+
return;
cleanup:
Patches currently in stable-queue which might be from t-kristo(a)ti.com are
queue-4.15/clk-ti-clkctrl-add-support-for-retrying-failed-init.patch
This is a note to let you know that I've just added the patch titled
clk: renesas: r8a77970: Add LVDS clock
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:
clk-renesas-r8a77970-add-lvds-clock.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Date: Wed, 6 Dec 2017 00:43:35 +0300
Subject: clk: renesas: r8a77970: Add LVDS clock
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
[ Upstream commit 64082568dd1e05d349a0d9dfda2bdf6ace3f9f6c ]
I seem to have omitted the LVDS clock from the R8A77970 CPG/MSSR support
patch for some reason -- add it back...
Based on the original (and large) patch by Daisuke Matsushita
<daisuke.matsushita.ns(a)hitachi.com>.
Fixes: 8d46e28fb5081b49 ("clk: renesas: cpg-mssr: Add R8A77970 support")
Signed-off-by: Vladimir Barinov <vladimir.barinov(a)cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/renesas/r8a77970-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/clk/renesas/r8a77970-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77970-cpg-mssr.c
@@ -105,6 +105,7 @@ static const struct mssr_mod_clk r8a7797
DEF_MOD("vspd0", 623, R8A77970_CLK_S2D1),
DEF_MOD("csi40", 716, R8A77970_CLK_CSI0),
DEF_MOD("du0", 724, R8A77970_CLK_S2D1),
+ DEF_MOD("lvds", 727, R8A77970_CLK_S2D1),
DEF_MOD("vin3", 808, R8A77970_CLK_S2D1),
DEF_MOD("vin2", 809, R8A77970_CLK_S2D1),
DEF_MOD("vin1", 810, R8A77970_CLK_S2D1),
Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are
queue-4.15/clk-renesas-r8a77970-add-lvds-clock.patch
This is a note to let you know that I've just added the patch titled
clk: qcom: msm8916: fix mnd_width for codec_digcodec
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:
clk-qcom-msm8916-fix-mnd_width-for-codec_digcodec.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org>
Date: Wed, 6 Dec 2017 12:11:38 +0000
Subject: clk: qcom: msm8916: fix mnd_width for codec_digcodec
From: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org>
[ Upstream commit d8e488e8242ecf129eebc440c92d800a99ca109d ]
This patch fixes missing mnd_width for codec_digital clk, this is now set to
8 inline with datasheet.
Fixes: 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/qcom/gcc-msm8916.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/clk/qcom/gcc-msm8916.c
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -1438,6 +1438,7 @@ static const struct freq_tbl ftbl_codec_
static struct clk_rcg2 codec_digcodec_clk_src = {
.cmd_rcgr = 0x1c09c,
+ .mnd_width = 8,
.hid_width = 5,
.parent_map = gcc_xo_gpll1_emclk_sleep_map,
.freq_tbl = ftbl_codec_clk,
Patches currently in stable-queue which might be from srinivas.kandagatla(a)linaro.org are
queue-4.15/clk-qcom-msm8916-fix-mnd_width-for-codec_digcodec.patch
This is a note to let you know that I've just added the patch titled
clk: meson: gxbb: fix wrong clock for SARADC/SANA
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:
clk-meson-gxbb-fix-wrong-clock-for-saradc-sana.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Yixun Lan <yixun.lan(a)amlogic.com>
Date: Tue, 7 Nov 2017 22:12:23 +0800
Subject: clk: meson: gxbb: fix wrong clock for SARADC/SANA
From: Yixun Lan <yixun.lan(a)amlogic.com>
[ Upstream commit 75eccf5ed83250c0aeaeeb76f7288254ac0a87b4 ]
According to the datasheet, in Meson-GXBB/GXL series,
The clock gate bit for SARADC is HHI_GCLK_MPEG2 bit[22],
while clock gate bit for SANA is HHI_GCLK_MPEG0 bit[10].
Test passed at gxl-s905x-p212 board.
The following published datasheets are wrong and should be updated
[1] GXBB v1.1.4
[2] GXL v0.3_20170314
Fixes: 738f66d3211d ("clk: gxbb: add AmLogic GXBB clk controller driver")
Tested-by: Xingyu Chen <xingyu.chen(a)amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan(a)amlogic.com>
Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/meson/gxbb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -1386,7 +1386,7 @@ static MESON_GATE(gxbb_pl301, HHI_GCLK_M
static MESON_GATE(gxbb_periphs, HHI_GCLK_MPEG0, 7);
static MESON_GATE(gxbb_spicc, HHI_GCLK_MPEG0, 8);
static MESON_GATE(gxbb_i2c, HHI_GCLK_MPEG0, 9);
-static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG0, 10);
+static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG0, 10);
static MESON_GATE(gxbb_smart_card, HHI_GCLK_MPEG0, 11);
static MESON_GATE(gxbb_rng0, HHI_GCLK_MPEG0, 12);
static MESON_GATE(gxbb_uart0, HHI_GCLK_MPEG0, 13);
@@ -1437,7 +1437,7 @@ static MESON_GATE(gxbb_usb0_ddr_bridge,
static MESON_GATE(gxbb_mmc_pclk, HHI_GCLK_MPEG2, 11);
static MESON_GATE(gxbb_dvin, HHI_GCLK_MPEG2, 12);
static MESON_GATE(gxbb_uart2, HHI_GCLK_MPEG2, 15);
-static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG2, 22);
+static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG2, 22);
static MESON_GATE(gxbb_vpu_intr, HHI_GCLK_MPEG2, 25);
static MESON_GATE(gxbb_sec_ahb_ahb3_bridge, HHI_GCLK_MPEG2, 26);
static MESON_GATE(gxbb_clk81_a53, HHI_GCLK_MPEG2, 29);
Patches currently in stable-queue which might be from yixun.lan(a)amlogic.com are
queue-4.15/clk-meson-gxbb-fix-wrong-clock-for-saradc-sana.patch
This is a note to let you know that I've just added the patch titled
bpf: fix stack state printing in verifier log
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:
bpf-fix-stack-state-printing-in-verifier-log.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Alexei Starovoitov <ast(a)fb.com>
Date: Thu, 30 Nov 2017 21:31:35 -0800
Subject: bpf: fix stack state printing in verifier log
From: Alexei Starovoitov <ast(a)fb.com>
[ Upstream commit 12a3cc8424fe1237aaeb982dec4f0914ddd22f3e ]
fix incorrect stack state prints in print_verifier_state()
Fixes: 638f5b90d460 ("bpf: reduce verifier memory consumption")
Signed-off-by: Alexei Starovoitov <ast(a)kernel.org>
Acked-by: John Fastabend <john.fastabend(a)gmail.com>
Acked-by: Daniel Borkmann <daniel(a)iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -279,7 +279,7 @@ static void print_verifier_state(struct
for (i = 0; i < state->allocated_stack / BPF_REG_SIZE; i++) {
if (state->stack[i].slot_type[0] == STACK_SPILL)
verbose(env, " fp%d=%s",
- -MAX_BPF_STACK + i * BPF_REG_SIZE,
+ (-i - 1) * BPF_REG_SIZE,
reg_type_str[state->stack[i].spilled_ptr.type]);
}
verbose(env, "\n");
Patches currently in stable-queue which might be from ast(a)fb.com are
queue-4.15/bpf-fix-stack-state-printing-in-verifier-log.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Uninitialized variable in bnxt_tc_parse_actions()
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:
bnxt_en-uninitialized-variable-in-bnxt_tc_parse_actions.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 5 Dec 2017 17:37:52 +0300
Subject: bnxt_en: Uninitialized variable in bnxt_tc_parse_actions()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 92425c40676d498efccae6fecdb8f8e4dcf7e4a4 ]
Smatch warns that:
drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c:160 bnxt_tc_parse_actions()
error: uninitialized symbol 'rc'.
"rc" is either uninitialized or set to zero here so we can just remove
the check.
Fixes: 8c95f773b4a3 ("bnxt_en: add support for Flower based vxlan encap/decap offload")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Acked-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
@@ -148,9 +148,6 @@ static int bnxt_tc_parse_actions(struct
}
}
- if (rc)
- return rc;
-
if (actions->flags & BNXT_TC_ACTION_FLAG_FWD) {
if (actions->flags & BNXT_TC_ACTION_FLAG_TUNNEL_ENCAP) {
/* dst_fid is PF's fid */
@@ -164,7 +161,7 @@ static int bnxt_tc_parse_actions(struct
}
}
- return rc;
+ return 0;
}
#define GET_KEY(flow_cmd, key_type) \
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.15/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.15/crypto-chelsio-fix-an-error-code-in-chcr_hash_dma_map.patch
queue-4.15/drm-panel-rpi-touchscreen-propagate-errors-in-rpi_touchscreen_i2c_read.patch
queue-4.15/bnxt_en-uninitialized-variable-in-bnxt_tc_parse_actions.patch
queue-4.15/power-supply-sbs-message-double-left-shift-bug-in-sbsm_select.patch
queue-4.15/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Don't print "Link speed -1 no longer supported" messages.
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:
bnxt_en-don-t-print-link-speed-1-no-longer-supported-messages.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Michael Chan <michael.chan(a)broadcom.com>
Date: Wed, 6 Dec 2017 17:31:22 -0500
Subject: bnxt_en: Don't print "Link speed -1 no longer supported" messages.
From: Michael Chan <michael.chan(a)broadcom.com>
[ Upstream commit a8168b6cee6e9334dfebb4b9108e8d73794f6088 ]
On some dual port NICs, the 2 ports have to be configured with compatible
link speeds. Under some conditions, a port's configured speed may no
longer be supported. The firmware will send a message to the driver
when this happens.
Improve this logic that prints out the warning by only printing it if
we can determine the link speed that is no longer supported. If the
speed is unknown or it is in autoneg mode, skip the warning message.
Reported-by: Thomas Bogendoerfer <tbogendoerfer(a)suse.de>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Tested-by: Thomas Bogendoerfer <tbogendoerfer(a)suse.de>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -1706,12 +1706,16 @@ static int bnxt_async_event_process(stru
if (BNXT_VF(bp))
goto async_event_process_exit;
- if (data1 & 0x20000) {
+
+ /* print unsupported speed warning in forced speed mode only */
+ if (!(link_info->autoneg & BNXT_AUTONEG_SPEED) &&
+ (data1 & 0x20000)) {
u16 fw_speed = link_info->force_link_speed;
u32 speed = bnxt_fw_to_ethtool_speed(fw_speed);
- netdev_warn(bp->dev, "Link speed %d no longer supported\n",
- speed);
+ if (speed != SPEED_UNKNOWN)
+ netdev_warn(bp->dev, "Link speed %d no longer supported\n",
+ speed);
}
set_bit(BNXT_LINK_SPEED_CHNG_SP_EVENT, &bp->sp_event);
/* fall thru */
Patches currently in stable-queue which might be from michael.chan(a)broadcom.com are
queue-4.15/bnxt_en-don-t-print-link-speed-1-no-longer-supported-messages.patch
queue-4.15/bnxt_en-uninitialized-variable-in-bnxt_tc_parse_actions.patch
This is a note to let you know that I've just added the patch titled
ath10k: update tdls teardown state to target
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:
ath10k-update-tdls-teardown-state-to-target.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Manikanta Pubbisetty <mpubbise(a)qti.qualcomm.com>
Date: Mon, 6 Nov 2017 13:39:31 +0530
Subject: ath10k: update tdls teardown state to target
From: Manikanta Pubbisetty <mpubbise(a)qti.qualcomm.com>
[ Upstream commit 424ea0d174e82365f85c6770225dba098b8f1d5f ]
It is required to update the teardown state of the peer when
a tdls link with that peer is terminated. This information is
useful for the target to perform some cleanups wrt the tdls peer.
Without proper cleanup, target assumes that the peer is connected and
blocks future connection requests, updating the teardown state of the
peer addresses the problem.
Tested this change on QCA9888 with 10.4-3.5.1-00018 fw version.
Signed-off-by: Manikanta Pubbisetty <mpubbise(a)qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6201,6 +6201,16 @@ static int ath10k_sta_state(struct ieee8
"mac vdev %d peer delete %pM sta %pK (sta gone)\n",
arvif->vdev_id, sta->addr, sta);
+ if (sta->tdls) {
+ ret = ath10k_mac_tdls_peer_update(ar, arvif->vdev_id,
+ sta,
+ WMI_TDLS_PEER_STATE_TEARDOWN);
+ if (ret)
+ ath10k_warn(ar, "failed to update tdls peer state for %pM state %d: %i\n",
+ sta->addr,
+ WMI_TDLS_PEER_STATE_TEARDOWN, ret);
+ }
+
ret = ath10k_peer_delete(ar, arvif->vdev_id, sta->addr);
if (ret)
ath10k_warn(ar, "failed to delete peer %pM for vdev %d: %i\n",
Patches currently in stable-queue which might be from mpubbise(a)qti.qualcomm.com are
queue-4.15/ath10k-update-tdls-teardown-state-to-target.patch
This is a note to let you know that I've just added the patch titled
ath10k: fix invalid STS_CAP_OFFSET_MASK
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:
ath10k-fix-invalid-sts_cap_offset_mask.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Ben Greear <greearb(a)candelatech.com>
Date: Sat, 2 Dec 2017 16:50:49 +0200
Subject: ath10k: fix invalid STS_CAP_OFFSET_MASK
From: Ben Greear <greearb(a)candelatech.com>
[ Upstream commit 8cec57f5277ef0e354e37a0bf909dc71bc1f865b ]
The 10.4 firmware defines this as a 3-bit field, as does the
mac80211 stack. The 4th bit is defined as CONF_IMPLICIT_BF
at least in the firmware header I have seen. This patch
fixes the ath10k wmi header to match the firmware.
Signed-off-by: Ben Greear <greearb(a)candelatech.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/wmi.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -5236,7 +5236,8 @@ enum wmi_10_4_vdev_param {
#define WMI_VDEV_PARAM_TXBF_MU_TX_BFER BIT(3)
#define WMI_TXBF_STS_CAP_OFFSET_LSB 4
-#define WMI_TXBF_STS_CAP_OFFSET_MASK 0xf0
+#define WMI_TXBF_STS_CAP_OFFSET_MASK 0x70
+#define WMI_TXBF_CONF_IMPLICIT_BF BIT(7)
#define WMI_BF_SOUND_DIM_OFFSET_LSB 8
#define WMI_BF_SOUND_DIM_OFFSET_MASK 0xf00
Patches currently in stable-queue which might be from greearb(a)candelatech.com are
queue-4.15/ath10k-fix-invalid-sts_cap_offset_mask.patch
This is a note to let you know that I've just added the patch titled
ASoC: nuc900: Fix a loop timeout test
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:
asoc-nuc900-fix-a-loop-timeout-test.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Sat, 9 Dec 2017 14:52:28 +0300
Subject: ASoC: nuc900: Fix a loop timeout test
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 65a12b3aafed5fc59f4ce41b22b752b1729e6701 ]
We should be finishing the loop with timeout set to zero but because
this is a post-op we finish with timeout == -1.
Fixes: 1082e2703a2d ("ASoC: NUC900/audio: add nuc900 audio driver support")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/nuc900/nuc900-ac97.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/soc/nuc900/nuc900-ac97.c
+++ b/sound/soc/nuc900/nuc900-ac97.c
@@ -67,7 +67,7 @@ static unsigned short nuc900_ac97_read(s
/* polling the AC_R_FINISH */
while (!(AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_R_FINISH)
- && timeout--)
+ && --timeout)
mdelay(1);
if (!timeout) {
@@ -121,7 +121,7 @@ static void nuc900_ac97_write(struct snd
/* polling the AC_W_FINISH */
while ((AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_W_FINISH)
- && timeout--)
+ && --timeout)
mdelay(1);
if (!timeout)
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.15/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.15/crypto-chelsio-fix-an-error-code-in-chcr_hash_dma_map.patch
queue-4.15/drm-panel-rpi-touchscreen-propagate-errors-in-rpi_touchscreen_i2c_read.patch
queue-4.15/bnxt_en-uninitialized-variable-in-bnxt_tc_parse_actions.patch
queue-4.15/power-supply-sbs-message-double-left-shift-bug-in-sbsm_select.patch
queue-4.15/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: renesas: salvator-common: Add EthernetAVB PHY reset
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-dts-renesas-salvator-common-add-ethernetavb-phy-reset.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 4 Dec 2017 11:34:51 +0100
Subject: arm64: dts: renesas: salvator-common: Add EthernetAVB PHY reset
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit f5bbcd533a9d1af97b8a0862a421bb8455f1bf6d ]
Describe the GPIO used to reset the Ethernet PHY for EthernetAVB.
This allows the driver to reset the PHY during probe and after system
resume.
This fixes Ethernet operation after resume from s2ram on Salvator-XS,
where the enable pin of the regulator providing PHY power is connected
to PRESETn, and PSCI powers down the SoC during system suspend.
On Salvator-X, the enable pin is always pulled high, but the driver may
still need to reset the PHY if this wasn't done by the bootloader
before.
Inspired by patches in the BSP for the individual Salvator-X/XS boards
by Kazuya Mizuguchi.
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -263,6 +263,7 @@
reg = <0>;
interrupt-parent = <&gpio2>;
interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
};
};
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.15/clk-renesas-r8a77970-add-lvds-clock.patch
queue-4.15/serial-sh-sci-prevent-lockup-on-full-tty-buffers.patch
queue-4.15/pinctrl-sh-pfc-r8a7795-es1-fix-mod_sel1-bit-to-0x3-when-using-stp_isen_1_d.patch
queue-4.15/arm64-dts-renesas-salvator-common-add-ethernetavb-phy-reset.patch
queue-4.15/pinctrl-sh-pfc-r8a7791-add-can_clk-function.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: omap3-n900: Fix the audio CODEC's reset pin
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:
arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: "Andrew F. Davis" <afd(a)ti.com>
Date: Wed, 29 Nov 2017 11:13:59 -0600
Subject: ARM: dts: omap3-n900: Fix the audio CODEC's reset pin
From: "Andrew F. Davis" <afd(a)ti.com>
[ Upstream commit 7be4b5dc7ffa9499ac6ef33a5ffa9ff43f9b7057 ]
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.
Fixes: 14e3e295b2b9 ("ARM: dts: omap3-n900: Add TLV320AIC3X support")
Signed-off-by: Andrew F. Davis <afd(a)ti.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/omap3-n900.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -558,7 +558,7 @@
tlv320aic3x: tlv320aic3x@18 {
compatible = "ti,tlv320aic3x";
reg = <0x18>;
- gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
+ reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
ai3x-gpio-func = <
0 /* AIC3X_GPIO1_FUNC_DISABLED */
5 /* AIC3X_GPIO2_FUNC_DIGITAL_MIC_INPUT */
@@ -575,7 +575,7 @@
tlv320aic3x_aux: tlv320aic3x@19 {
compatible = "ti,tlv320aic3x";
reg = <0x19>;
- gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
+ reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
AVDD-supply = <&vmmc2>;
DRVDD-supply = <&vmmc2>;
Patches currently in stable-queue which might be from afd(a)ti.com are
queue-4.15/arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch
queue-4.15/arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: koelsch: Move cec_clock to root node
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:
arm-dts-koelsch-move-cec_clock-to-root-node.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Simon Horman <horms+renesas(a)verge.net.au>
Date: Thu, 2 Nov 2017 10:18:05 +0100
Subject: ARM: dts: koelsch: Move cec_clock to root node
From: Simon Horman <horms+renesas(a)verge.net.au>
[ Upstream commit d72f4f03854d1225c72d682bf0e01377e7016419 ]
cec-clock is a fixed clock generator that is not controlled by i2c5 and
thus should not be a child of the i2c5 bus node. Rather, it should be
a child of the root node of the DT.
Fixes: 02a5ab18d366 ("ARM: dts: koelsch: Add CEC clock for HDMI transmitter")
Reported-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -278,6 +278,12 @@
};
};
+ cec_clock: cec-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12000000>;
+ };
+
hdmi-out {
compatible = "hdmi-connector";
type = "a";
@@ -640,12 +646,6 @@
};
};
- cec_clock: cec-clock {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <12000000>;
- };
-
hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
Patches currently in stable-queue which might be from horms+renesas(a)verge.net.au are
queue-4.15/arm64-dts-renesas-salvator-common-add-ethernetavb-phy-reset.patch
queue-4.15/usb-host-xhci-rcar-add-support-for-r8a77965.patch
queue-4.15/arm-dts-koelsch-move-cec_clock-to-root-node.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: exynos: Correct Trats2 panel reset line
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:
arm-dts-exynos-correct-trats2-panel-reset-line.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: Simon Shields <simon(a)lineageos.org>
Date: Tue, 21 Nov 2017 22:24:24 +1100
Subject: ARM: dts: exynos: Correct Trats2 panel reset line
From: Simon Shields <simon(a)lineageos.org>
[ Upstream commit 1b377924841df1e13ab5b225be3a83f807a92b52 ]
Trats2 uses gpf2-1 as the panel reset GPIO. gpy4-5 was only used
on early revisions of the board.
Fixes: 420ae8451a22 ("ARM: dts: exynos4412-trats2: add panel node")
Signed-off-by: Simon Shields <simon(a)lineageos.org>
Acked-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/exynos4412-trats2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -454,7 +454,7 @@
reg = <0>;
vdd3-supply = <&lcd_vdd3_reg>;
vci-supply = <&ldo25_reg>;
- reset-gpios = <&gpy4 5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpf2 1 GPIO_ACTIVE_HIGH>;
power-on-delay= <50>;
reset-delay = <100>;
init-delay = <100>;
Patches currently in stable-queue which might be from simon(a)lineageos.org are
queue-4.15/arm-dts-exynos-correct-trats2-panel-reset-line.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin
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:
arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.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 foo@baz Fri Mar 16 15:11:07 CET 2018
From: "Andrew F. Davis" <afd(a)ti.com>
Date: Wed, 29 Nov 2017 11:13:56 -0600
Subject: ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin
From: "Andrew F. Davis" <afd(a)ti.com>
[ Upstream commit e153db03c6b7a035c797bcdf35262586f003ee93 ]
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.
Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board")
Signed-off-by: Andrew F. Davis <afd(a)ti.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/am335x-pepper.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -139,7 +139,7 @@
&audio_codec {
status = "okay";
- gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
AVDD-supply = <&ldo3_reg>;
IOVDD-supply = <&ldo3_reg>;
DRVDD-supply = <&ldo3_reg>;
Patches currently in stable-queue which might be from afd(a)ti.com are
queue-4.15/arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch
queue-4.15/arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch
This is a note to let you know that I've just added the patch titled
agp/intel: Flush all chipset writes after updating the GGTT
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:
agp-intel-flush-all-chipset-writes-after-updating-the-ggtt.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 foo@baz Fri Mar 16 15:11:08 CET 2018
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Fri, 8 Dec 2017 21:46:16 +0000
Subject: agp/intel: Flush all chipset writes after updating the GGTT
From: Chris Wilson <chris(a)chris-wilson.co.uk>
[ Upstream commit 8516673a996870ea0ceb337ee4f83c33c5ec3111 ]
Before accessing the GGTT we must flush the PTE writes and make them
visible to the chipset, or else the indirect access may end up in the
wrong page. In commit 3497971a71d8 ("agp/intel: Flush chipset writes
after updating a single PTE"), we noticed corruption of the uploads for
pwrite and for capturing GPU error states, but it was presumed that the
explicit calls to intel_gtt_chipset_flush() were sufficient for the
execbuffer path. However, we have not been flushing the chipset between
the PTE writes and access via the GTT itself.
For simplicity, do the flush after any PTE update rather than try and
batch the flushes on a just-in-time basis.
References: 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE")
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
Cc: Mika Kuoppala <mika.kuoppala(a)intel.com>
Cc: drm-intel-fixes(a)lists.freedesktop.org
Reviewed-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171208214616.30147-1-chris@…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/agp/intel-gtt.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -872,6 +872,8 @@ void intel_gtt_insert_sg_entries(struct
}
}
wmb();
+ if (intel_private.driver->chipset_flush)
+ intel_private.driver->chipset_flush();
}
EXPORT_SYMBOL(intel_gtt_insert_sg_entries);
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.15/dma-buf-fence-fix-lock-inversion-within-dma-fence-array.patch
queue-4.15/agp-intel-flush-all-chipset-writes-after-updating-the-ggtt.patch
Hi Greg,
Andrew Price has observed that mounting gfs2 filesystems is currently
broken in the 4.15.y kernels. The reason is that commit 'gfs2: Fixes
to "Implement iomap for block_map"' was cherry-picked from mainline in
4.15.5 without adding a commit that that commit depends on. Could you
please fix that by adding the following commit to 4.15.y:
e8b43fe0c1 gfs2: Clean up {lookup,fillup}_metapath
In addition, could you please add the following commit to 4.15.y as well:
3b5da96e45 gfs2: Fixes to "Implement iomap for block_map" (2)
Both commits can be cherry-picked cleanly.
Thanks a lot,
Andreas
This is a note to let you know that I've just added the patch titled
gfs2: Fixes to "Implement iomap for block_map" (2)
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:
gfs2-fixes-to-implement-iomap-for-block_map-2.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 3b5da96e4585a2788da6a07619bda3518d76eb30 Mon Sep 17 00:00:00 2001
From: Andreas Gruenbacher <agruenba(a)redhat.com>
Date: Mon, 5 Mar 2018 06:18:25 -0700
Subject: gfs2: Fixes to "Implement iomap for block_map" (2)
From: Andreas Gruenbacher <agruenba(a)redhat.com>
commit 3b5da96e4585a2788da6a07619bda3518d76eb30 upstream.
It turns out that commit 3229c18c0d6b2 'Fixes to "Implement iomap for
block_map"' introduced another bug in gfs2_iomap_begin that can cause
gfs2_block_map to set bh->b_size of an actual buffer to 0. This can
lead to arbitrary incorrect behavior including crashes or disk
corruption. Revert the incorrect part of that commit.
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
Signed-off-by: Bob Peterson <rpeterso(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/gfs2/bmap.c | 3 ---
1 file changed, 3 deletions(-)
--- a/fs/gfs2/bmap.c
+++ b/fs/gfs2/bmap.c
@@ -811,9 +811,6 @@ do_alloc:
iomap->length = hole_size(inode, lblock, &mp);
else
iomap->length = size - pos;
- } else {
- if (height <= ip->i_height)
- iomap->length = hole_size(inode, lblock, &mp);
}
goto out_release;
}
Patches currently in stable-queue which might be from agruenba(a)redhat.com are
queue-4.15/gfs2-clean-up-lookup-fillup-_metapath.patch
queue-4.15/gfs2-fixes-to-implement-iomap-for-block_map-2.patch
This is a note to let you know that I've just added the patch titled
gfs2: Clean up {lookup,fillup}_metapath
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:
gfs2-clean-up-lookup-fillup-_metapath.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 e8b43fe0c1e035a135be7ca3791d465fcb1b501e Mon Sep 17 00:00:00 2001
From: Andreas Gruenbacher <agruenba(a)redhat.com>
Date: Fri, 8 Dec 2017 17:01:57 +0100
Subject: gfs2: Clean up {lookup,fillup}_metapath
From: Andreas Gruenbacher <agruenba(a)redhat.com>
commit e8b43fe0c1e035a135be7ca3791d465fcb1b501e upstream.
Split out the entire lookup loop from lookup_metapath and
fillup_metapath. Make both functions return the actual height in
mp->mp_aheight, and return 0 on success. Handle lookup errors properly
in trunc_dealloc.
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
Signed-off-by: Bob Peterson <rpeterso(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/gfs2/bmap.c | 74 +++++++++++++++++++++++----------------------------------
1 file changed, 30 insertions(+), 44 deletions(-)
--- a/fs/gfs2/bmap.c
+++ b/fs/gfs2/bmap.c
@@ -305,21 +305,22 @@ static void gfs2_metapath_ra(struct gfs2
}
}
-/**
- * lookup_mp_height - helper function for lookup_metapath
- * @ip: the inode
- * @mp: the metapath
- * @h: the height which needs looking up
- */
-static int lookup_mp_height(struct gfs2_inode *ip, struct metapath *mp, int h)
+static int __fillup_metapath(struct gfs2_inode *ip, struct metapath *mp,
+ unsigned int x, unsigned int h)
{
- __be64 *ptr = metapointer(h, mp);
- u64 dblock = be64_to_cpu(*ptr);
-
- if (!dblock)
- return h + 1;
+ for (; x < h; x++) {
+ __be64 *ptr = metapointer(x, mp);
+ u64 dblock = be64_to_cpu(*ptr);
+ int ret;
- return gfs2_meta_indirect_buffer(ip, h + 1, dblock, &mp->mp_bh[h + 1]);
+ if (!dblock)
+ break;
+ ret = gfs2_meta_indirect_buffer(ip, x + 1, dblock, &mp->mp_bh[x + 1]);
+ if (ret)
+ return ret;
+ }
+ mp->mp_aheight = x + 1;
+ return 0;
}
/**
@@ -336,25 +337,12 @@ static int lookup_mp_height(struct gfs2_
* at which it found the unallocated block. Blocks which are found are
* added to the mp->mp_bh[] list.
*
- * Returns: error or height of metadata tree
+ * Returns: error
*/
static int lookup_metapath(struct gfs2_inode *ip, struct metapath *mp)
{
- unsigned int end_of_metadata = ip->i_height - 1;
- unsigned int x;
- int ret;
-
- for (x = 0; x < end_of_metadata; x++) {
- ret = lookup_mp_height(ip, mp, x);
- if (ret)
- goto out;
- }
-
- ret = ip->i_height;
-out:
- mp->mp_aheight = ret;
- return ret;
+ return __fillup_metapath(ip, mp, 0, ip->i_height - 1);
}
/**
@@ -365,25 +353,21 @@ out:
*
* Similar to lookup_metapath, but does lookups for a range of heights
*
- * Returns: error or height of metadata tree
+ * Returns: error
*/
static int fillup_metapath(struct gfs2_inode *ip, struct metapath *mp, int h)
{
- unsigned int start_h = h - 1;
- int ret;
+ unsigned int x = 0;
if (h) {
/* find the first buffer we need to look up. */
- while (start_h > 0 && mp->mp_bh[start_h] == NULL)
- start_h--;
- for (; start_h < h; start_h++) {
- ret = lookup_mp_height(ip, mp, start_h);
- if (ret)
- return ret;
+ for (x = h - 1; x > 0; x--) {
+ if (mp->mp_bh[x])
+ break;
}
}
- return ip->i_height;
+ return __fillup_metapath(ip, mp, x, h);
}
static inline void release_metapath(struct metapath *mp)
@@ -790,7 +774,7 @@ int gfs2_iomap_begin(struct inode *inode
goto do_alloc;
ret = lookup_metapath(ip, &mp);
- if (ret < 0)
+ if (ret)
goto out_release;
if (mp.mp_aheight != ip->i_height)
@@ -1339,7 +1323,9 @@ static int trunc_dealloc(struct gfs2_ino
mp.mp_bh[0] = dibh;
ret = lookup_metapath(ip, &mp);
- if (ret == ip->i_height)
+ if (ret)
+ goto out_metapath;
+ if (mp.mp_aheight == ip->i_height)
state = DEALLOC_MP_FULL; /* We have a complete metapath */
else
state = DEALLOC_FILL_MP; /* deal with partial metapath */
@@ -1435,16 +1421,16 @@ static int trunc_dealloc(struct gfs2_ino
case DEALLOC_FILL_MP:
/* Fill the buffers out to the current height. */
ret = fillup_metapath(ip, &mp, mp_h);
- if (ret < 0)
+ if (ret)
goto out;
/* If buffers found for the entire strip height */
- if ((ret == ip->i_height) && (mp_h == strip_h)) {
+ if (mp.mp_aheight - 1 == strip_h) {
state = DEALLOC_MP_FULL;
break;
}
- if (ret < ip->i_height) /* We have a partial height */
- mp_h = ret - 1;
+ if (mp.mp_aheight < ip->i_height) /* We have a partial height */
+ mp_h = mp.mp_aheight - 1;
/* If we find a non-null block pointer, crawl a bit
higher up in the metapath and try again, otherwise
Patches currently in stable-queue which might be from agruenba(a)redhat.com are
queue-4.15/gfs2-clean-up-lookup-fillup-_metapath.patch
queue-4.15/gfs2-fixes-to-implement-iomap-for-block_map-2.patch
This is a note to let you know that I've just added the patch titled
USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h
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:
usb-storage-add-jmicron-bridge-152d-2567-to-unusual_devs.h.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 5126a504b63d82785eaece3a9c30c660b313785a Mon Sep 17 00:00:00 2001
From: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
Date: Thu, 1 Mar 2018 19:34:29 +0200
Subject: USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h
From: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
commit 5126a504b63d82785eaece3a9c30c660b313785a upstream.
This USB-SATA controller seems to be similar with JMicron bridge
152d:2566 already on the list. Adding it here fixes "Invalid
field in cdb" errors.
Signed-off-by: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
Cc: stable(a)vger.kernel.org
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/unusual_devs.h | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2137,6 +2137,13 @@ UNUSUAL_DEV( 0x152d, 0x2566, 0x0114, 0x
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA ),
+/* Reported by Teijo Kinnunen <teijo.kinnunen(a)code-q.fi> */
+UNUSUAL_DEV( 0x152d, 0x2567, 0x0117, 0x0117,
+ "JMicron",
+ "USB to ATA/ATAPI Bridge",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA ),
+
/* Reported-by George Cherian <george.cherian(a)cavium.com> */
UNUSUAL_DEV(0x152d, 0x9561, 0x0000, 0x9999,
"JMicron",
Patches currently in stable-queue which might be from teijo.kinnunen(a)code-q.fi are
queue-4.9/usb-storage-add-jmicron-bridge-152d-2567-to-unusual_devs.h.patch
This is a note to let you know that I've just added the patch titled
usbip: vudc: fix null pointer dereference on udc->lock
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:
usbip-vudc-fix-null-pointer-dereference-on-udc-lock.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 df3334c223a033f562645712e832ca4cbb326bbf Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king(a)canonical.com>
Date: Thu, 22 Feb 2018 17:39:17 +0000
Subject: usbip: vudc: fix null pointer dereference on udc->lock
From: Colin Ian King <colin.king(a)canonical.com>
commit df3334c223a033f562645712e832ca4cbb326bbf upstream.
Currently the driver attempts to spin lock on udc->lock before a NULL
pointer check is performed on udc, hence there is a potential null
pointer dereference on udc->lock. Fix this by moving the null check
on udc before the lock occurs.
Fixes: ea6873a45a22 ("usbip: vudc: Add SysFS infrastructure for VUDC")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Reviewed-by: Krzysztof Opasiak <k.opasiak(a)samsung.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/vudc_sysfs.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/usb/usbip/vudc_sysfs.c
+++ b/drivers/usb/usbip/vudc_sysfs.c
@@ -117,10 +117,14 @@ static ssize_t store_sockfd(struct devic
if (rv != 0)
return -EINVAL;
+ if (!udc) {
+ dev_err(dev, "no device");
+ return -ENODEV;
+ }
spin_lock_irqsave(&udc->lock, flags);
/* Don't export what we don't have */
- if (!udc || !udc->driver || !udc->pullup) {
- dev_err(dev, "no device or gadget not bound");
+ if (!udc->driver || !udc->pullup) {
+ dev_err(dev, "gadget not bound");
ret = -ENODEV;
goto unlock;
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.9/mips-ath25-check-for-kzalloc-allocation-failure.patch
queue-4.9/usbip-vudc-fix-null-pointer-dereference-on-udc-lock.patch
queue-4.9/mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.patch
This is a note to let you know that I've just added the patch titled
usb: quirks: add control message delay for 1b1c:1b20
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:
usb-quirks-add-control-message-delay-for-1b1c-1b20.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 cb88a0588717ba6c756cb5972d75766b273a6817 Mon Sep 17 00:00:00 2001
From: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
Date: Tue, 6 Mar 2018 09:38:49 +0100
Subject: usb: quirks: add control message delay for 1b1c:1b20
From: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
commit cb88a0588717ba6c756cb5972d75766b273a6817 upstream.
Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.
Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.
Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):
[ 29.103520] usb 1-8: string descriptor 0 read error: -110
[ 34.363097] usb 1-8: can't set config #1, error -110
Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:
[ 35.400533] usbhid 1-8:1.0: can't add hid device: -110
[ 35.401014] usbhid: probe of 1-8:1.0 failed with error -110
The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.
Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().
The overall boot time seems not to be influenced by these additional
delays, even on fast machines and lightweight distributions.
Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard")
Cc: stable(a)vger.kernel.org
Signed-off-by: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/message.c | 4 ++++
drivers/usb/core/quirks.c | 3 ++-
include/linux/usb/quirks.h | 3 +++
3 files changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -148,6 +148,10 @@ int usb_control_msg(struct usb_device *d
ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout);
+ /* Linger a bit, prior to the next control message. */
+ if (dev->quirks & USB_QUIRK_DELAY_CTRL_MSG)
+ msleep(200);
+
kfree(dr);
return ret;
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -229,7 +229,8 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
/* Corsair Strafe RGB */
- { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+ { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT |
+ USB_QUIRK_DELAY_CTRL_MSG },
/* Corsair K70 LUX */
{ USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT },
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -56,4 +56,7 @@
*/
#define USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL BIT(11)
+/* Device needs a pause after every control message. */
+#define USB_QUIRK_DELAY_CTRL_MSG BIT(13)
+
#endif /* __LINUX_USB_QUIRKS_H */
Patches currently in stable-queue which might be from danilokrummrich(a)dk-develop.de are
queue-4.9/usb-quirks-add-control-message-delay-for-1b1c-1b20.patch
This is a note to let you know that I've just added the patch titled
uas: fix comparison for error code
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:
uas-fix-comparison-for-error-code.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 9a513c905bb95bef79d96feb08621c1ec8d8c4bb Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum(a)suse.com>
Date: Tue, 6 Mar 2018 15:04:24 +0100
Subject: uas: fix comparison for error code
From: Oliver Neukum <oneukum(a)suse.com>
commit 9a513c905bb95bef79d96feb08621c1ec8d8c4bb upstream.
A typo broke the comparison.
Fixes: cbeef22fd611 ("usb: uas: unconditionally bring back host after reset")
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
CC: stable(a)kernel.org
Acked-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/uas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1076,7 +1076,7 @@ static int uas_post_reset(struct usb_int
return 0;
err = uas_configure_endpoints(devinfo);
- if (err && err != ENODEV)
+ if (err && err != -ENODEV)
shost_printk(KERN_ERR, shost,
"%s: alloc streams error %d after reset",
__func__, err);
Patches currently in stable-queue which might be from oneukum(a)suse.com are
queue-4.9/uas-fix-comparison-for-error-code.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()
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:
usb-gadget-f_fs-fix-use-after-free-in-ffs_fs_kill_sb.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 1a087f032111a88e826877449dfb93ceb22b78b9 Mon Sep 17 00:00:00 2001
From: Xinyong <xinyong.fang(a)linux.alibaba.com>
Date: Fri, 2 Mar 2018 19:20:07 +0800
Subject: usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()
From: Xinyong <xinyong.fang(a)linux.alibaba.com>
commit 1a087f032111a88e826877449dfb93ceb22b78b9 upstream.
When I debug a kernel crash issue in funcitonfs, found ffs_data.ref
overflowed, While functionfs is unmounting, ffs_data is put twice.
Commit 43938613c6fd ("drivers, usb: convert ffs_data.ref from atomic_t to
refcount_t") can avoid refcount overflow, but that is risk some situations.
So no need put ffs data in ffs_fs_kill_sb, already put in ffs_data_closed.
The issue can be reproduced in Mediatek mt6763 SoC, ffs for ADB device.
KASAN enabled configuration reports use-after-free errro.
BUG: KASAN: use-after-free in refcount_dec_and_test+0x14/0xe0 at addr ffffffc0579386a0
Read of size 4 by task umount/4650
====================================================
BUG kmalloc-512 (Tainted: P W O ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in ffs_fs_mount+0x194/0x844 age=22856 cpu=2 pid=566
alloc_debug_processing+0x1ac/0x1e8
___slab_alloc.constprop.63+0x640/0x648
__slab_alloc.isra.57.constprop.62+0x24/0x34
kmem_cache_alloc_trace+0x1a8/0x2bc
ffs_fs_mount+0x194/0x844
mount_fs+0x6c/0x1d0
vfs_kern_mount+0x50/0x1b4
do_mount+0x258/0x1034
INFO: Freed in ffs_data_put+0x25c/0x320 age=0 cpu=3 pid=4650
free_debug_processing+0x22c/0x434
__slab_free+0x2d8/0x3a0
kfree+0x254/0x264
ffs_data_put+0x25c/0x320
ffs_data_closed+0x124/0x15c
ffs_fs_kill_sb+0xb8/0x110
deactivate_locked_super+0x6c/0x98
deactivate_super+0xb0/0xbc
INFO: Object 0xffffffc057938600 @offset=1536 fp=0x (null)
......
Call trace:
[<ffffff900808cf5c>] dump_backtrace+0x0/0x250
[<ffffff900808d3a0>] show_stack+0x14/0x1c
[<ffffff90084a8c04>] dump_stack+0xa0/0xc8
[<ffffff900826c2b4>] print_trailer+0x158/0x260
[<ffffff900826d9d8>] object_err+0x3c/0x40
[<ffffff90082745f0>] kasan_report_error+0x2a8/0x754
[<ffffff9008274f84>] kasan_report+0x5c/0x60
[<ffffff9008273208>] __asan_load4+0x70/0x88
[<ffffff90084cd81c>] refcount_dec_and_test+0x14/0xe0
[<ffffff9008d98f9c>] ffs_data_put+0x80/0x320
[<ffffff9008d9d904>] ffs_fs_kill_sb+0xc8/0x110
[<ffffff90082852a0>] deactivate_locked_super+0x6c/0x98
[<ffffff900828537c>] deactivate_super+0xb0/0xbc
[<ffffff90082af0c0>] cleanup_mnt+0x64/0xec
[<ffffff90082af1b0>] __cleanup_mnt+0x10/0x18
[<ffffff90080d9e68>] task_work_run+0xcc/0x124
[<ffffff900808c8c0>] do_notify_resume+0x60/0x70
[<ffffff90080866e4>] work_pending+0x10/0x14
Cc: stable(a)vger.kernel.org
Signed-off-by: Xinyong <xinyong.fang(a)linux.alibaba.com>
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 | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1522,7 +1522,6 @@ ffs_fs_kill_sb(struct super_block *sb)
if (sb->s_fs_info) {
ffs_release_dev(sb->s_fs_info);
ffs_data_closed(sb->s_fs_info);
- ffs_data_put(sb->s_fs_info);
}
}
Patches currently in stable-queue which might be from xinyong.fang(a)linux.alibaba.com are
queue-4.9/usb-gadget-f_fs-fix-use-after-free-in-ffs_fs_kill_sb.patch
This is a note to let you know that I've just added the patch titled
tty/serial: atmel: add new version check for usart
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:
tty-serial-atmel-add-new-version-check-for-usart.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 fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 Mon Sep 17 00:00:00 2001
From: Jonas Danielsson <jonas(a)orbital-systems.com>
Date: Mon, 29 Jan 2018 12:39:15 +0100
Subject: tty/serial: atmel: add new version check for usart
From: Jonas Danielsson <jonas(a)orbital-systems.com>
commit fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 upstream.
On our at91sam9260 based board the usart0 and usart1 ports report
their versions (ATMEL_US_VERSION) as 0x10302. This version is not
included in the current checks in the driver.
Signed-off-by: Jonas Danielsson <jonas(a)orbital-systems.com>
Acked-by: Richard Genoud <richard.genoud(a)gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/atmel_serial.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1780,6 +1780,7 @@ static void atmel_get_ip_name(struct uar
switch (version) {
case 0x302:
case 0x10213:
+ case 0x10302:
dev_dbg(port->dev, "This version is usart\n");
atmel_port->has_frac_baudrate = true;
atmel_port->has_hw_timer = true;
Patches currently in stable-queue which might be from jonas(a)orbital-systems.com are
queue-4.9/tty-serial-atmel-add-new-version-check-for-usart.patch
This is a note to let you know that I've just added the patch titled
staging: comedi: fix comedi_nsamples_left.
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:
staging-comedi-fix-comedi_nsamples_left.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 a42ae5905140c324362fe5036ae1dbb16e4d359c Mon Sep 17 00:00:00 2001
From: Frank Mori Hess <fmh6jj(a)gmail.com>
Date: Thu, 15 Feb 2018 15:13:42 -0500
Subject: staging: comedi: fix comedi_nsamples_left.
From: Frank Mori Hess <fmh6jj(a)gmail.com>
commit a42ae5905140c324362fe5036ae1dbb16e4d359c upstream.
A rounding error was causing comedi_nsamples_left to
return the wrong value when nsamples was not a multiple
of the scan length.
Cc: <stable(a)vger.kernel.org> # v4.4+
Signed-off-by: Frank Mori Hess <fmh6jj(a)gmail.com>
Reviewed-by: Ian Abbott <abbotti(a)mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/comedi/drivers.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -484,8 +484,7 @@ unsigned int comedi_nsamples_left(struct
struct comedi_cmd *cmd = &async->cmd;
if (cmd->stop_src == TRIG_COUNT) {
- unsigned int nscans = nsamples / cmd->scan_end_arg;
- unsigned int scans_left = __comedi_nscans_left(s, nscans);
+ unsigned int scans_left = __comedi_nscans_left(s, cmd->stop_arg);
unsigned int scan_pos =
comedi_bytes_to_samples(s, async->scan_progress);
unsigned long long samples_left = 0;
Patches currently in stable-queue which might be from fmh6jj(a)gmail.com are
queue-4.9/staging-comedi-fix-comedi_nsamples_left.patch
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix lockdep issue during llseek
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:
staging-android-ashmem-fix-lockdep-issue-during-llseek.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 cb57469c9573f6018cd1302953dd45d6e05aba7b Mon Sep 17 00:00:00 2001
From: Joel Fernandes <joelaf(a)google.com>
Date: Fri, 16 Feb 2018 11:02:01 -0800
Subject: staging: android: ashmem: Fix lockdep issue during llseek
From: Joel Fernandes <joelaf(a)google.com>
commit cb57469c9573f6018cd1302953dd45d6e05aba7b upstream.
ashmem_mutex create a chain of dependencies like so:
(1)
mmap syscall ->
mmap_sem -> (acquired)
ashmem_mmap
ashmem_mutex (try to acquire)
(block)
(2)
llseek syscall ->
ashmem_llseek ->
ashmem_mutex -> (acquired)
inode_lock ->
inode->i_rwsem (try to acquire)
(block)
(3)
getdents ->
iterate_dir ->
inode_lock ->
inode->i_rwsem (acquired)
copy_to_user ->
mmap_sem (try to acquire)
There is a lock ordering created between mmap_sem and inode->i_rwsem
causing a lockdep splat [2] during a syzcaller test, this patch fixes
the issue by unlocking the mutex earlier. Functionally that's Ok since
we don't need to protect vfs_llseek.
[1] https://patchwork.kernel.org/patch/10185031/
[2] https://lkml.org/lkml/2018/1/10/48
Acked-by: Todd Kjos <tkjos(a)google.com>
Cc: Arve Hjonnevag <arve(a)android.com>
Cc: stable(a)vger.kernel.org
Reported-by: syzbot+8ec30bb7bf1a981a2012(a)syzkaller.appspotmail.com
Signed-off-by: Joel Fernandes <joelaf(a)google.com>
Acked-by: Greg Hackmann <ghackmann(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -343,24 +343,23 @@ static loff_t ashmem_llseek(struct file
mutex_lock(&ashmem_mutex);
if (asma->size == 0) {
- ret = -EINVAL;
- goto out;
+ mutex_unlock(&ashmem_mutex);
+ return -EINVAL;
}
if (!asma->file) {
- ret = -EBADF;
- goto out;
+ mutex_unlock(&ashmem_mutex);
+ return -EBADF;
}
+ mutex_unlock(&ashmem_mutex);
+
ret = vfs_llseek(asma->file, offset, origin);
if (ret < 0)
- goto out;
+ return ret;
/** Copy f_pos from backing file, since f_ops->llseek() sets it */
file->f_pos = asma->file->f_pos;
-
-out:
- mutex_unlock(&ashmem_mutex);
return ret;
}
Patches currently in stable-queue which might be from joelaf(a)google.com are
queue-4.9/staging-android-ashmem-fix-lockdep-issue-during-llseek.patch
This is a note to let you know that I've just added the patch titled
serial: sh-sci: prevent lockup on full TTY buffers
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:
serial-sh-sci-prevent-lockup-on-full-tty-buffers.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 7842055bfce4bf0170d0f61df8b2add8399697be Mon Sep 17 00:00:00 2001
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Date: Thu, 15 Feb 2018 13:02:27 +0100
Subject: serial: sh-sci: prevent lockup on full TTY buffers
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream.
When the TTY buffers fill up to the configured maximum, a system lockup
occurs:
[ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
[ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
[ 598.838755] Task dump for CPU 0:
[ 598.841977] swapper/0 R running task 0 0 0 0x00000022
[ 598.849023] Call trace:
[ 598.851476] __switch_to+0x98/0xb0
[ 598.854870] (null)
This can be prevented by doing a dummy read of the RX data register.
This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
as well.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Cc: stable <stable(a)vger.kernel.org>
Tested-by: Nguyen Viet Dung <dung.nguyen.aj(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -935,6 +935,8 @@ static void sci_receive_chars(struct uar
/* Tell the rest of the system the news. New characters! */
tty_flip_buffer_push(tport);
} else {
+ /* TTY buffers full; read from RX reg to prevent lockup */
+ serial_port_in(port, SCxRDR);
serial_port_in(port, SCxSR); /* dummy read */
sci_clear_SCxSR(port, SCxSR_RDxF_CLEAR(port));
}
Patches currently in stable-queue which might be from ulrich.hecht+renesas(a)gmail.com are
queue-4.9/serial-sh-sci-prevent-lockup-on-full-tty-buffers.patch
This is a note to let you know that I've just added the patch titled
serial: core: mark port as initialized in autoconfig
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:
serial-core-mark-port-as-initialized-in-autoconfig.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 714569064adee3c114a2a6490735b94abe269068 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Date: Sat, 3 Feb 2018 12:27:23 +0100
Subject: serial: core: mark port as initialized in autoconfig
From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
commit 714569064adee3c114a2a6490735b94abe269068 upstream.
This is a followup on 44117a1d1732 ("serial: core: mark port as
initialized after successful IRQ change").
Nikola has been using autoconfig via setserial and reported a crash
similar to what I fixed in the earlier mentioned commit. Here I do the
same fixup for the autoconfig. I wasn't sure that this is the right
approach. Nikola confirmed that it fixes his crash.
Fixes: b3b576461864 ("tty: serial_core: convert uart_open to use tty_port_open")
Link: http://lkml.kernel.org/r/20180131072000.GD1853@localhost.localdomain
Reported-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Tested-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Tested-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Acked-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/serial_core.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1135,6 +1135,8 @@ static int uart_do_autoconfig(struct tty
uport->ops->config_port(uport, flags);
ret = uart_startup(tty, state, 1);
+ if (ret == 0)
+ tty_port_set_initialized(port, true);
if (ret > 0)
ret = 0;
}
Patches currently in stable-queue which might be from bigeasy(a)linutronix.de are
queue-4.9/serial-core-mark-port-as-initialized-in-autoconfig.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
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:
serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.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 9f2068f35729948bde84d87a40d135015911345d Mon Sep 17 00:00:00 2001
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Date: Tue, 13 Feb 2018 15:04:46 +0100
Subject: serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
commit 9f2068f35729948bde84d87a40d135015911345d upstream.
Add PCI ids for two variants of Brainboxes UC-260 quad port
PCI serial cards.
Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -5100,6 +5100,17 @@ static struct pci_device_id serial_pci_t
PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */
pbn_b2_4_115200 },
/*
+ * BrainBoxes UC-260
+ */
+ { PCI_VENDOR_ID_INTASHIELD, 0x0D21,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ { PCI_VENDOR_ID_INTASHIELD, 0x0E34,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ /*
* Perle PCI-RAS cards
*/
{ PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9030,
Patches currently in stable-queue which might be from nikola.ciprich(a)linuxbox.cz are
queue-4.9/serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.patch
queue-4.9/serial-core-mark-port-as-initialized-in-autoconfig.patch
This is a note to let you know that I've just added the patch titled
PCI: dwc: Fix enumeration end when reaching root subordinate
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:
pci-dwc-fix-enumeration-end-when-reaching-root-subordinate.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 fc110ebdd014dd1368c98e7685b47789c31fab42 Mon Sep 17 00:00:00 2001
From: Koen Vandeputte <koen.vandeputte(a)ncentric.com>
Date: Wed, 7 Mar 2018 10:46:39 -0600
Subject: PCI: dwc: Fix enumeration end when reaching root subordinate
From: Koen Vandeputte <koen.vandeputte(a)ncentric.com>
commit fc110ebdd014dd1368c98e7685b47789c31fab42 upstream.
The subordinate value indicates the highest bus number which can be
reached downstream though a certain device.
Commit a20c7f36bd3d ("PCI: Do not allocate more buses than available in
parent") ensures that downstream devices cannot assign busnumbers higher
than the upstream device subordinate number, which was indeed illogical.
By default, dw_pcie_setup_rc() inits the Root Complex subordinate to a
value of 0x01.
Due to this combined with above commit, enumeration stops digging deeper
downstream as soon as bus num 0x01 has been assigned, which is always the
case for a bridge device.
This results in all devices behind a bridge bus remaining undetected, as
these would be connected to bus 0x02 or higher.
Fix this by initializing the RC to a subordinate value of 0xff, which is
not altering hardware behaviour in any way, but informs probing function
pci_scan_bridge() later on which reads this value back from register.
The following nasty errors during boot are also fixed by this:
pci_bus 0000:02: busn_res: can not insert [bus 02-ff] under [bus 01] (conflicts with (null) [bus 01])
...
pci_bus 0000:03: [bus 03] partially hidden behind bridge 0000:01 [bus 01]
...
pci_bus 0000:04: [bus 04] partially hidden behind bridge 0000:01 [bus 01]
...
pci_bus 0000:05: [bus 05] partially hidden behind bridge 0000:01 [bus 01]
pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 05
pci_bus 0000:02: busn_res: can not insert [bus 02-05] under [bus 01] (conflicts with (null) [bus 01])
pci_bus 0000:02: [bus 02-05] partially hidden behind bridge 0000:01 [bus 01]
Fixes: a20c7f36bd3d ("PCI: Do not allocate more buses than available in
parent")
Tested-by: Niklas Cassel <niklas.cassel(a)axis.com>
Tested-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Tested-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Signed-off-by: Koen Vandeputte <koen.vandeputte(a)ncentric.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Reviewed-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Acked-by: Lucas Stach <l.stach(a)pengutronix.de>
Cc: stable(a)vger.kernel.org # v4.15+
Cc: Binghui Wang <wangbinghui(a)hisilicon.com>
Cc: Jesper Nilsson <jesper.nilsson(a)axis.com>
Cc: Jianguo Sun <sunjianguo1(a)huawei.com>
Cc: Jingoo Han <jingoohan1(a)gmail.com>
Cc: Kishon Vijay Abraham I <kishon(a)ti.com>
Cc: Lucas Stach <l.stach(a)pengutronix.de>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Minghuan Lian <minghuan.Lian(a)freescale.com>
Cc: Mingkai Hu <mingkai.hu(a)freescale.com>
Cc: Murali Karicheri <m-karicheri2(a)ti.com>
Cc: Pratyush Anand <pratyush.anand(a)gmail.com>
Cc: Richard Zhu <hongxing.zhu(a)nxp.com>
Cc: Roy Zang <tie-fei.zang(a)freescale.com>
Cc: Shawn Guo <shawn.guo(a)linaro.org>
Cc: Stanimir Varbanov <svarbanov(a)mm-sol.com>
Cc: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Cc: Xiaowei Song <songxiaowei(a)hisilicon.com>
Cc: Zhou Wang <wangzhou1(a)hisilicon.com>
[fabio: adapted to the file location of 4.9 kernel]
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pcie-designware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -861,7 +861,7 @@ void dw_pcie_setup_rc(struct pcie_port *
/* setup bus numbers */
val = dw_pcie_readl_rc(pp, PCI_PRIMARY_BUS);
val &= 0xff000000;
- val |= 0x00010100;
+ val |= 0x00ff0100;
dw_pcie_writel_rc(pp, PCI_PRIMARY_BUS, val);
/* setup command register */
Patches currently in stable-queue which might be from koen.vandeputte(a)ncentric.com are
queue-4.9/pci-dwc-fix-enumeration-end-when-reaching-root-subordinate.patch
This is a note to let you know that I've just added the patch titled
earlycon: add reg-offset to physical address before mapping
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:
earlycon-add-reg-offset-to-physical-address-before-mapping.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 1f66dd36bb18437397ea0d7882c52f7e3c476e15 Mon Sep 17 00:00:00 2001
From: Greentime Hu <green.hu(a)gmail.com>
Date: Tue, 13 Feb 2018 17:09:08 +0800
Subject: earlycon: add reg-offset to physical address before mapping
From: Greentime Hu <green.hu(a)gmail.com>
commit 1f66dd36bb18437397ea0d7882c52f7e3c476e15 upstream.
It will get the wrong virtual address because port->mapbase is not added
the correct reg-offset yet. We have to update it before earlycon_map()
is called
Signed-off-by: Greentime Hu <greentime(a)andestech.com>
Acked-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Peter Hurley <peter(a)hurleysoftware.com>
Cc: stable(a)vger.kernel.org
Fixes: 088da2a17619 ("of: earlycon: Initialize port fields from DT properties")
Acked-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/earlycon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -253,11 +253,12 @@ int __init of_setup_earlycon(const struc
}
port->mapbase = addr;
port->uartclk = BASE_BAUD * 16;
- port->membase = earlycon_map(port->mapbase, SZ_4K);
val = of_get_flat_dt_prop(node, "reg-offset", NULL);
if (val)
port->mapbase += be32_to_cpu(*val);
+ port->membase = earlycon_map(port->mapbase, SZ_4K);
+
val = of_get_flat_dt_prop(node, "reg-shift", NULL);
if (val)
port->regshift = be32_to_cpu(*val);
Patches currently in stable-queue which might be from green.hu(a)gmail.com are
queue-4.9/earlycon-add-reg-offset-to-physical-address-before-mapping.patch
This is a note to let you know that I've just added the patch titled
ASoC: sgtl5000: Fix suspend/resume
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:
asoc-sgtl5000-fix-suspend-resume.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 a8992973edbb2555e956b90f6fe97c4bc14d761d Mon Sep 17 00:00:00 2001
From: Fabio Estevam <fabio.estevam(a)nxp.com>
Date: Fri, 16 Feb 2018 11:58:54 -0200
Subject: ASoC: sgtl5000: Fix suspend/resume
From: Fabio Estevam <fabio.estevam(a)nxp.com>
commit a8992973edbb2555e956b90f6fe97c4bc14d761d upstream.
Commit 8419caa72702 ("ASoC: sgtl5000: Do not disable regulators in
SND_SOC_BIAS_OFF") causes the sgtl5000 to fail after a suspend/resume
sequence:
Playing WAVE '/media/a2002011001-e02.wav' : Signed 16 bit Little
Endian, Rate 44100 Hz, Stereo
aplay: pcm_write:2051: write error: Input/output error
The problem is caused by the fact that the aforementioned commit
dropped the cache handling, so re-introduce the register map
resync to fix the problem.
Suggested-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/sgtl5000.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -774,15 +774,26 @@ static int sgtl5000_pcm_hw_params(struct
static int sgtl5000_set_bias_level(struct snd_soc_codec *codec,
enum snd_soc_bias_level level)
{
+ struct sgtl5000_priv *sgtl = snd_soc_codec_get_drvdata(codec);
+ int ret;
+
switch (level) {
case SND_SOC_BIAS_ON:
case SND_SOC_BIAS_PREPARE:
case SND_SOC_BIAS_STANDBY:
+ regcache_cache_only(sgtl->regmap, false);
+ ret = regcache_sync(sgtl->regmap);
+ if (ret) {
+ regcache_cache_only(sgtl->regmap, true);
+ return ret;
+ }
+
snd_soc_update_bits(codec, SGTL5000_CHIP_ANA_POWER,
SGTL5000_REFTOP_POWERUP,
SGTL5000_REFTOP_POWERUP);
break;
case SND_SOC_BIAS_OFF:
+ regcache_cache_only(sgtl->regmap, true);
snd_soc_update_bits(codec, SGTL5000_CHIP_ANA_POWER,
SGTL5000_REFTOP_POWERUP, 0);
break;
Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are
queue-4.9/asoc-sgtl5000-fix-suspend-resume.patch
queue-4.9/pci-dwc-fix-enumeration-end-when-reaching-root-subordinate.patch
This is a note to let you know that I've just added the patch titled
ASoC: rt5651: Fix regcache sync errors on resume
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:
asoc-rt5651-fix-regcache-sync-errors-on-resume.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 2d30e9494f1ea320aaaad0cff9ddd92c87eac355 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Sun, 18 Feb 2018 23:01:44 +0100
Subject: ASoC: rt5651: Fix regcache sync errors on resume
From: Hans de Goede <hdegoede(a)redhat.com>
commit 2d30e9494f1ea320aaaad0cff9ddd92c87eac355 upstream.
The ALC5651 does not like multi-write accesses, avoid them. This fixes:
rt5651 i2c-10EC5651:00: Unable to sync registers 0x27-0x28. -121
Errors on resume (and all registers after the registers in the error not
being synced).
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/rt5651.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -1736,6 +1736,7 @@ static const struct regmap_config rt5651
.num_reg_defaults = ARRAY_SIZE(rt5651_reg),
.ranges = rt5651_ranges,
.num_ranges = ARRAY_SIZE(rt5651_ranges),
+ .use_single_rw = true,
};
#if defined(CONFIG_OF)
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/asoc-rt5651-fix-regcache-sync-errors-on-resume.patch
queue-4.9/uas-fix-comparison-for-error-code.patch
This is a note to let you know that I've just added the patch titled
USB: usbmon: remove assignment from IS_ERR argument
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-usbmon-remove-assignment-from-is_err-argument.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 46c236dc7d1212d7417e6fb0317f91c44c719322 Mon Sep 17 00:00:00 2001
From: Julia Lawall <Julia.Lawall(a)lip6.fr>
Date: Sat, 26 Dec 2015 22:57:44 +0100
Subject: USB: usbmon: remove assignment from IS_ERR argument
From: Julia Lawall <Julia.Lawall(a)lip6.fr>
commit 46c236dc7d1212d7417e6fb0317f91c44c719322 upstream.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e1,e2;
statement S1,S2;
@@
+e1 = e2;
if (IS_ERR(
e1
- = e2
)) S1 else S2
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall(a)lip6.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/mon/mon_text.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/usb/mon/mon_text.c
+++ b/drivers/usb/mon/mon_text.c
@@ -386,7 +386,8 @@ static ssize_t mon_text_read_t(struct fi
struct mon_event_text *ep;
struct mon_text_ptr ptr;
- if (IS_ERR(ep = mon_text_read_wait(rp, file)))
+ ep = mon_text_read_wait(rp, file);
+ if (IS_ERR(ep))
return PTR_ERR(ep);
mutex_lock(&rp->printf_lock);
ptr.cnt = 0;
@@ -413,7 +414,8 @@ static ssize_t mon_text_read_u(struct fi
struct mon_event_text *ep;
struct mon_text_ptr ptr;
- if (IS_ERR(ep = mon_text_read_wait(rp, file)))
+ ep = mon_text_read_wait(rp, file);
+ if (IS_ERR(ep))
return PTR_ERR(ep);
mutex_lock(&rp->printf_lock);
ptr.cnt = 0;
Patches currently in stable-queue which might be from Julia.Lawall(a)lip6.fr are
queue-4.4/usb-usbmon-remove-assignment-from-is_err-argument.patch
This is a note to let you know that I've just added the patch titled
USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h
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-storage-add-jmicron-bridge-152d-2567-to-unusual_devs.h.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 5126a504b63d82785eaece3a9c30c660b313785a Mon Sep 17 00:00:00 2001
From: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
Date: Thu, 1 Mar 2018 19:34:29 +0200
Subject: USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h
From: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
commit 5126a504b63d82785eaece3a9c30c660b313785a upstream.
This USB-SATA controller seems to be similar with JMicron bridge
152d:2566 already on the list. Adding it here fixes "Invalid
field in cdb" errors.
Signed-off-by: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
Cc: stable(a)vger.kernel.org
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/unusual_devs.h | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2142,6 +2142,13 @@ UNUSUAL_DEV( 0x22b8, 0x3010, 0x0001, 0x
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY | US_FL_IGNORE_RESIDUE ),
+/* Reported by Teijo Kinnunen <teijo.kinnunen(a)code-q.fi> */
+UNUSUAL_DEV( 0x152d, 0x2567, 0x0117, 0x0117,
+ "JMicron",
+ "USB to ATA/ATAPI Bridge",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA ),
+
/* Reported-by George Cherian <george.cherian(a)cavium.com> */
UNUSUAL_DEV(0x152d, 0x9561, 0x0000, 0x9999,
"JMicron",
Patches currently in stable-queue which might be from teijo.kinnunen(a)code-q.fi are
queue-4.4/usb-storage-add-jmicron-bridge-152d-2567-to-unusual_devs.h.patch
This is a note to let you know that I've just added the patch titled
usb: quirks: add control message delay for 1b1c:1b20
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-quirks-add-control-message-delay-for-1b1c-1b20.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 cb88a0588717ba6c756cb5972d75766b273a6817 Mon Sep 17 00:00:00 2001
From: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
Date: Tue, 6 Mar 2018 09:38:49 +0100
Subject: usb: quirks: add control message delay for 1b1c:1b20
From: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
commit cb88a0588717ba6c756cb5972d75766b273a6817 upstream.
Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.
Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.
Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):
[ 29.103520] usb 1-8: string descriptor 0 read error: -110
[ 34.363097] usb 1-8: can't set config #1, error -110
Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:
[ 35.400533] usbhid 1-8:1.0: can't add hid device: -110
[ 35.401014] usbhid: probe of 1-8:1.0 failed with error -110
The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.
Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().
The overall boot time seems not to be influenced by these additional
delays, even on fast machines and lightweight distributions.
Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard")
Cc: stable(a)vger.kernel.org
Signed-off-by: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/message.c | 4 ++++
drivers/usb/core/quirks.c | 3 ++-
include/linux/usb/quirks.h | 3 +++
3 files changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -147,6 +147,10 @@ int usb_control_msg(struct usb_device *d
ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout);
+ /* Linger a bit, prior to the next control message. */
+ if (dev->quirks & USB_QUIRK_DELAY_CTRL_MSG)
+ msleep(200);
+
kfree(dr);
return ret;
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -229,7 +229,8 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
/* Corsair Strafe RGB */
- { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+ { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT |
+ USB_QUIRK_DELAY_CTRL_MSG },
/* Corsair K70 LUX */
{ USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT },
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -56,4 +56,7 @@
*/
#define USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL BIT(11)
+/* Device needs a pause after every control message. */
+#define USB_QUIRK_DELAY_CTRL_MSG BIT(13)
+
#endif /* __LINUX_USB_QUIRKS_H */
Patches currently in stable-queue which might be from danilokrummrich(a)dk-develop.de are
queue-4.4/usb-quirks-add-control-message-delay-for-1b1c-1b20.patch
This is a note to let you know that I've just added the patch titled
uas: fix comparison for error code
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:
uas-fix-comparison-for-error-code.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 9a513c905bb95bef79d96feb08621c1ec8d8c4bb Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum(a)suse.com>
Date: Tue, 6 Mar 2018 15:04:24 +0100
Subject: uas: fix comparison for error code
From: Oliver Neukum <oneukum(a)suse.com>
commit 9a513c905bb95bef79d96feb08621c1ec8d8c4bb upstream.
A typo broke the comparison.
Fixes: cbeef22fd611 ("usb: uas: unconditionally bring back host after reset")
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
CC: stable(a)kernel.org
Acked-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/uas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1052,7 +1052,7 @@ static int uas_post_reset(struct usb_int
return 0;
err = uas_configure_endpoints(devinfo);
- if (err && err != ENODEV)
+ if (err && err != -ENODEV)
shost_printk(KERN_ERR, shost,
"%s: alloc streams error %d after reset",
__func__, err);
Patches currently in stable-queue which might be from oneukum(a)suse.com are
queue-4.4/uas-fix-comparison-for-error-code.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()
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-fix-use-after-free-in-ffs_fs_kill_sb.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 1a087f032111a88e826877449dfb93ceb22b78b9 Mon Sep 17 00:00:00 2001
From: Xinyong <xinyong.fang(a)linux.alibaba.com>
Date: Fri, 2 Mar 2018 19:20:07 +0800
Subject: usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()
From: Xinyong <xinyong.fang(a)linux.alibaba.com>
commit 1a087f032111a88e826877449dfb93ceb22b78b9 upstream.
When I debug a kernel crash issue in funcitonfs, found ffs_data.ref
overflowed, While functionfs is unmounting, ffs_data is put twice.
Commit 43938613c6fd ("drivers, usb: convert ffs_data.ref from atomic_t to
refcount_t") can avoid refcount overflow, but that is risk some situations.
So no need put ffs data in ffs_fs_kill_sb, already put in ffs_data_closed.
The issue can be reproduced in Mediatek mt6763 SoC, ffs for ADB device.
KASAN enabled configuration reports use-after-free errro.
BUG: KASAN: use-after-free in refcount_dec_and_test+0x14/0xe0 at addr ffffffc0579386a0
Read of size 4 by task umount/4650
====================================================
BUG kmalloc-512 (Tainted: P W O ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in ffs_fs_mount+0x194/0x844 age=22856 cpu=2 pid=566
alloc_debug_processing+0x1ac/0x1e8
___slab_alloc.constprop.63+0x640/0x648
__slab_alloc.isra.57.constprop.62+0x24/0x34
kmem_cache_alloc_trace+0x1a8/0x2bc
ffs_fs_mount+0x194/0x844
mount_fs+0x6c/0x1d0
vfs_kern_mount+0x50/0x1b4
do_mount+0x258/0x1034
INFO: Freed in ffs_data_put+0x25c/0x320 age=0 cpu=3 pid=4650
free_debug_processing+0x22c/0x434
__slab_free+0x2d8/0x3a0
kfree+0x254/0x264
ffs_data_put+0x25c/0x320
ffs_data_closed+0x124/0x15c
ffs_fs_kill_sb+0xb8/0x110
deactivate_locked_super+0x6c/0x98
deactivate_super+0xb0/0xbc
INFO: Object 0xffffffc057938600 @offset=1536 fp=0x (null)
......
Call trace:
[<ffffff900808cf5c>] dump_backtrace+0x0/0x250
[<ffffff900808d3a0>] show_stack+0x14/0x1c
[<ffffff90084a8c04>] dump_stack+0xa0/0xc8
[<ffffff900826c2b4>] print_trailer+0x158/0x260
[<ffffff900826d9d8>] object_err+0x3c/0x40
[<ffffff90082745f0>] kasan_report_error+0x2a8/0x754
[<ffffff9008274f84>] kasan_report+0x5c/0x60
[<ffffff9008273208>] __asan_load4+0x70/0x88
[<ffffff90084cd81c>] refcount_dec_and_test+0x14/0xe0
[<ffffff9008d98f9c>] ffs_data_put+0x80/0x320
[<ffffff9008d9d904>] ffs_fs_kill_sb+0xc8/0x110
[<ffffff90082852a0>] deactivate_locked_super+0x6c/0x98
[<ffffff900828537c>] deactivate_super+0xb0/0xbc
[<ffffff90082af0c0>] cleanup_mnt+0x64/0xec
[<ffffff90082af1b0>] __cleanup_mnt+0x10/0x18
[<ffffff90080d9e68>] task_work_run+0xcc/0x124
[<ffffff900808c8c0>] do_notify_resume+0x60/0x70
[<ffffff90080866e4>] work_pending+0x10/0x14
Cc: stable(a)vger.kernel.org
Signed-off-by: Xinyong <xinyong.fang(a)linux.alibaba.com>
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 | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1333,7 +1333,6 @@ ffs_fs_kill_sb(struct super_block *sb)
if (sb->s_fs_info) {
ffs_release_dev(sb->s_fs_info);
ffs_data_closed(sb->s_fs_info);
- ffs_data_put(sb->s_fs_info);
}
}
Patches currently in stable-queue which might be from xinyong.fang(a)linux.alibaba.com are
queue-4.4/usb-gadget-f_fs-fix-use-after-free-in-ffs_fs_kill_sb.patch
This is a note to let you know that I've just added the patch titled
tty/serial: atmel: add new version check for usart
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:
tty-serial-atmel-add-new-version-check-for-usart.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 fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 Mon Sep 17 00:00:00 2001
From: Jonas Danielsson <jonas(a)orbital-systems.com>
Date: Mon, 29 Jan 2018 12:39:15 +0100
Subject: tty/serial: atmel: add new version check for usart
From: Jonas Danielsson <jonas(a)orbital-systems.com>
commit fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 upstream.
On our at91sam9260 based board the usart0 and usart1 ports report
their versions (ATMEL_US_VERSION) as 0x10302. This version is not
included in the current checks in the driver.
Signed-off-by: Jonas Danielsson <jonas(a)orbital-systems.com>
Acked-by: Richard Genoud <richard.genoud(a)gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/atmel_serial.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1783,6 +1783,7 @@ static void atmel_get_ip_name(struct uar
switch (version) {
case 0x302:
case 0x10213:
+ case 0x10302:
dev_dbg(port->dev, "This version is usart\n");
atmel_port->is_usart = true;
break;
Patches currently in stable-queue which might be from jonas(a)orbital-systems.com are
queue-4.4/tty-serial-atmel-add-new-version-check-for-usart.patch
This is a note to let you know that I've just added the patch titled
staging: comedi: fix comedi_nsamples_left.
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:
staging-comedi-fix-comedi_nsamples_left.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 a42ae5905140c324362fe5036ae1dbb16e4d359c Mon Sep 17 00:00:00 2001
From: Frank Mori Hess <fmh6jj(a)gmail.com>
Date: Thu, 15 Feb 2018 15:13:42 -0500
Subject: staging: comedi: fix comedi_nsamples_left.
From: Frank Mori Hess <fmh6jj(a)gmail.com>
commit a42ae5905140c324362fe5036ae1dbb16e4d359c upstream.
A rounding error was causing comedi_nsamples_left to
return the wrong value when nsamples was not a multiple
of the scan length.
Cc: <stable(a)vger.kernel.org> # v4.4+
Signed-off-by: Frank Mori Hess <fmh6jj(a)gmail.com>
Reviewed-by: Ian Abbott <abbotti(a)mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/comedi/drivers.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -484,8 +484,7 @@ unsigned int comedi_nsamples_left(struct
struct comedi_cmd *cmd = &async->cmd;
if (cmd->stop_src == TRIG_COUNT) {
- unsigned int nscans = nsamples / cmd->scan_end_arg;
- unsigned int scans_left = __comedi_nscans_left(s, nscans);
+ unsigned int scans_left = __comedi_nscans_left(s, cmd->stop_arg);
unsigned int scan_pos =
comedi_bytes_to_samples(s, async->scan_progress);
unsigned long long samples_left = 0;
Patches currently in stable-queue which might be from fmh6jj(a)gmail.com are
queue-4.4/staging-comedi-fix-comedi_nsamples_left.patch
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix lockdep issue during llseek
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:
staging-android-ashmem-fix-lockdep-issue-during-llseek.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 cb57469c9573f6018cd1302953dd45d6e05aba7b Mon Sep 17 00:00:00 2001
From: Joel Fernandes <joelaf(a)google.com>
Date: Fri, 16 Feb 2018 11:02:01 -0800
Subject: staging: android: ashmem: Fix lockdep issue during llseek
From: Joel Fernandes <joelaf(a)google.com>
commit cb57469c9573f6018cd1302953dd45d6e05aba7b upstream.
ashmem_mutex create a chain of dependencies like so:
(1)
mmap syscall ->
mmap_sem -> (acquired)
ashmem_mmap
ashmem_mutex (try to acquire)
(block)
(2)
llseek syscall ->
ashmem_llseek ->
ashmem_mutex -> (acquired)
inode_lock ->
inode->i_rwsem (try to acquire)
(block)
(3)
getdents ->
iterate_dir ->
inode_lock ->
inode->i_rwsem (acquired)
copy_to_user ->
mmap_sem (try to acquire)
There is a lock ordering created between mmap_sem and inode->i_rwsem
causing a lockdep splat [2] during a syzcaller test, this patch fixes
the issue by unlocking the mutex earlier. Functionally that's Ok since
we don't need to protect vfs_llseek.
[1] https://patchwork.kernel.org/patch/10185031/
[2] https://lkml.org/lkml/2018/1/10/48
Acked-by: Todd Kjos <tkjos(a)google.com>
Cc: Arve Hjonnevag <arve(a)android.com>
Cc: stable(a)vger.kernel.org
Reported-by: syzbot+8ec30bb7bf1a981a2012(a)syzkaller.appspotmail.com
Signed-off-by: Joel Fernandes <joelaf(a)google.com>
Acked-by: Greg Hackmann <ghackmann(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -330,24 +330,23 @@ static loff_t ashmem_llseek(struct file
mutex_lock(&ashmem_mutex);
if (asma->size == 0) {
- ret = -EINVAL;
- goto out;
+ mutex_unlock(&ashmem_mutex);
+ return -EINVAL;
}
if (!asma->file) {
- ret = -EBADF;
- goto out;
+ mutex_unlock(&ashmem_mutex);
+ return -EBADF;
}
+ mutex_unlock(&ashmem_mutex);
+
ret = vfs_llseek(asma->file, offset, origin);
if (ret < 0)
- goto out;
+ return ret;
/** Copy f_pos from backing file, since f_ops->llseek() sets it */
file->f_pos = asma->file->f_pos;
-
-out:
- mutex_unlock(&ashmem_mutex);
return ret;
}
Patches currently in stable-queue which might be from joelaf(a)google.com are
queue-4.4/staging-android-ashmem-fix-lockdep-issue-during-llseek.patch
This is a note to let you know that I've just added the patch titled
serial: sh-sci: prevent lockup on full TTY buffers
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:
serial-sh-sci-prevent-lockup-on-full-tty-buffers.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 7842055bfce4bf0170d0f61df8b2add8399697be Mon Sep 17 00:00:00 2001
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Date: Thu, 15 Feb 2018 13:02:27 +0100
Subject: serial: sh-sci: prevent lockup on full TTY buffers
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream.
When the TTY buffers fill up to the configured maximum, a system lockup
occurs:
[ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
[ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
[ 598.838755] Task dump for CPU 0:
[ 598.841977] swapper/0 R running task 0 0 0 0x00000022
[ 598.849023] Call trace:
[ 598.851476] __switch_to+0x98/0xb0
[ 598.854870] (null)
This can be prevented by doing a dummy read of the RX data register.
This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
as well.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Cc: stable <stable(a)vger.kernel.org>
Tested-by: Nguyen Viet Dung <dung.nguyen.aj(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -847,6 +847,8 @@ static void sci_receive_chars(struct uar
/* Tell the rest of the system the news. New characters! */
tty_flip_buffer_push(tport);
} else {
+ /* TTY buffers full; read from RX reg to prevent lockup */
+ serial_port_in(port, SCxRDR);
serial_port_in(port, SCxSR); /* dummy read */
sci_clear_SCxSR(port, SCxSR_RDxF_CLEAR(port));
}
Patches currently in stable-queue which might be from ulrich.hecht+renesas(a)gmail.com are
queue-4.4/serial-sh-sci-prevent-lockup-on-full-tty-buffers.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
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:
serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.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 9f2068f35729948bde84d87a40d135015911345d Mon Sep 17 00:00:00 2001
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Date: Tue, 13 Feb 2018 15:04:46 +0100
Subject: serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
commit 9f2068f35729948bde84d87a40d135015911345d upstream.
Add PCI ids for two variants of Brainboxes UC-260 quad port
PCI serial cards.
Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -5300,6 +5300,17 @@ static struct pci_device_id serial_pci_t
PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */
pbn_b2_4_115200 },
/*
+ * BrainBoxes UC-260
+ */
+ { PCI_VENDOR_ID_INTASHIELD, 0x0D21,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ { PCI_VENDOR_ID_INTASHIELD, 0x0E34,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ /*
* Perle PCI-RAS cards
*/
{ PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9030,
Patches currently in stable-queue which might be from nikola.ciprich(a)linuxbox.cz are
queue-4.4/serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.patch
This is a note to let you know that I've just added the patch titled
xhci: Fix front USB ports on ASUS PRIME B350M-A
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:
xhci-fix-front-usb-ports-on-asus-prime-b350m-a.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 191edc5e2e515aab1075a3f0ef23599e80be5f59 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Thu, 8 Mar 2018 17:17:17 +0200
Subject: xhci: Fix front USB ports on ASUS PRIME B350M-A
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 191edc5e2e515aab1075a3f0ef23599e80be5f59 upstream.
When a USB device gets plugged on ASUS PRIME B350M-A's front ports, the
xHC stops working:
[ 549.114587] xhci_hcd 0000:02:00.0: WARN: xHC CMD_RUN timeout
[ 549.114608] suspend_common(): xhci_pci_suspend+0x0/0xc0 returns -110
[ 549.114638] xhci_hcd 0000:02:00.0: can't suspend (hcd_pci_runtime_suspend returned -110)
Delay before running xHC command CMD_RUN can workaround the issue.
Use a new quirk to make the delay only targets to the affected xHC.
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-pci.c | 3 +++
drivers/usb/host/xhci.c | 3 +++
drivers/usb/host/xhci.h | 1 +
3 files changed, 7 insertions(+)
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -122,6 +122,9 @@ static void xhci_pci_quirks(struct devic
if (pdev->vendor == PCI_VENDOR_ID_AMD && usb_amd_find_chipset_info())
xhci->quirks |= XHCI_AMD_PLL_FIX;
+ if (pdev->vendor == PCI_VENDOR_ID_AMD && pdev->device == 0x43bb)
+ xhci->quirks |= XHCI_SUSPEND_DELAY;
+
if (pdev->vendor == PCI_VENDOR_ID_AMD)
xhci->quirks |= XHCI_TRUST_TX_LENGTH;
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -880,6 +880,9 @@ int xhci_suspend(struct xhci_hcd *xhci,
clear_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags);
del_timer_sync(&xhci->shared_hcd->rh_timer);
+ if (xhci->quirks & XHCI_SUSPEND_DELAY)
+ usleep_range(1000, 1500);
+
spin_lock_irq(&xhci->lock);
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &xhci->shared_hcd->flags);
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1823,6 +1823,7 @@ struct xhci_hcd {
/* Reserved. It was XHCI_U2_DISABLE_WAKE */
#define XHCI_ASMEDIA_MODIFY_FLOWCONTROL (1 << 28)
#define XHCI_HW_LPM_DISABLE (1 << 29)
+#define XHCI_SUSPEND_DELAY (1 << 30)
unsigned int num_active_eps;
unsigned int limit_active_eps;
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.15/xhci-fix-front-usb-ports-on-asus-prime-b350m-a.patch
This is a note to let you know that I've just added the patch titled
usbip: vudc: fix null pointer dereference on udc->lock
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:
usbip-vudc-fix-null-pointer-dereference-on-udc-lock.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 df3334c223a033f562645712e832ca4cbb326bbf Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king(a)canonical.com>
Date: Thu, 22 Feb 2018 17:39:17 +0000
Subject: usbip: vudc: fix null pointer dereference on udc->lock
From: Colin Ian King <colin.king(a)canonical.com>
commit df3334c223a033f562645712e832ca4cbb326bbf upstream.
Currently the driver attempts to spin lock on udc->lock before a NULL
pointer check is performed on udc, hence there is a potential null
pointer dereference on udc->lock. Fix this by moving the null check
on udc before the lock occurs.
Fixes: ea6873a45a22 ("usbip: vudc: Add SysFS infrastructure for VUDC")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Reviewed-by: Krzysztof Opasiak <k.opasiak(a)samsung.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/vudc_sysfs.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/usb/usbip/vudc_sysfs.c
+++ b/drivers/usb/usbip/vudc_sysfs.c
@@ -105,10 +105,14 @@ static ssize_t store_sockfd(struct devic
if (rv != 0)
return -EINVAL;
+ if (!udc) {
+ dev_err(dev, "no device");
+ return -ENODEV;
+ }
spin_lock_irqsave(&udc->lock, flags);
/* Don't export what we don't have */
- if (!udc || !udc->driver || !udc->pullup) {
- dev_err(dev, "no device or gadget not bound");
+ if (!udc->driver || !udc->pullup) {
+ dev_err(dev, "gadget not bound");
ret = -ENODEV;
goto unlock;
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.15/usbip-vudc-fix-null-pointer-dereference-on-udc-lock.patch
This is a note to let you know that I've just added the patch titled
USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h
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:
usb-storage-add-jmicron-bridge-152d-2567-to-unusual_devs.h.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 5126a504b63d82785eaece3a9c30c660b313785a Mon Sep 17 00:00:00 2001
From: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
Date: Thu, 1 Mar 2018 19:34:29 +0200
Subject: USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h
From: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
commit 5126a504b63d82785eaece3a9c30c660b313785a upstream.
This USB-SATA controller seems to be similar with JMicron bridge
152d:2566 already on the list. Adding it here fixes "Invalid
field in cdb" errors.
Signed-off-by: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
Cc: stable(a)vger.kernel.org
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/unusual_devs.h | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2124,6 +2124,13 @@ UNUSUAL_DEV( 0x152d, 0x2566, 0x0114, 0x
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA ),
+/* Reported by Teijo Kinnunen <teijo.kinnunen(a)code-q.fi> */
+UNUSUAL_DEV( 0x152d, 0x2567, 0x0117, 0x0117,
+ "JMicron",
+ "USB to ATA/ATAPI Bridge",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA ),
+
/* Reported-by George Cherian <george.cherian(a)cavium.com> */
UNUSUAL_DEV(0x152d, 0x9561, 0x0000, 0x9999,
"JMicron",
Patches currently in stable-queue which might be from teijo.kinnunen(a)code-q.fi are
queue-4.15/usb-storage-add-jmicron-bridge-152d-2567-to-unusual_devs.h.patch
This is a note to let you know that I've just added the patch titled
usb: quirks: add control message delay for 1b1c:1b20
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:
usb-quirks-add-control-message-delay-for-1b1c-1b20.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 cb88a0588717ba6c756cb5972d75766b273a6817 Mon Sep 17 00:00:00 2001
From: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
Date: Tue, 6 Mar 2018 09:38:49 +0100
Subject: usb: quirks: add control message delay for 1b1c:1b20
From: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
commit cb88a0588717ba6c756cb5972d75766b273a6817 upstream.
Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.
Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.
Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):
[ 29.103520] usb 1-8: string descriptor 0 read error: -110
[ 34.363097] usb 1-8: can't set config #1, error -110
Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:
[ 35.400533] usbhid 1-8:1.0: can't add hid device: -110
[ 35.401014] usbhid: probe of 1-8:1.0 failed with error -110
The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.
Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().
The overall boot time seems not to be influenced by these additional
delays, even on fast machines and lightweight distributions.
Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard")
Cc: stable(a)vger.kernel.org
Signed-off-by: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/message.c | 4 ++++
drivers/usb/core/quirks.c | 3 ++-
include/linux/usb/quirks.h | 3 +++
3 files changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -150,6 +150,10 @@ int usb_control_msg(struct usb_device *d
ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout);
+ /* Linger a bit, prior to the next control message. */
+ if (dev->quirks & USB_QUIRK_DELAY_CTRL_MSG)
+ msleep(200);
+
kfree(dr);
return ret;
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -230,7 +230,8 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
/* Corsair Strafe RGB */
- { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+ { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT |
+ USB_QUIRK_DELAY_CTRL_MSG },
/* Corsair K70 LUX */
{ USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT },
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -63,4 +63,7 @@
*/
#define USB_QUIRK_DISCONNECT_SUSPEND BIT(12)
+/* Device needs a pause after every control message. */
+#define USB_QUIRK_DELAY_CTRL_MSG BIT(13)
+
#endif /* __LINUX_USB_QUIRKS_H */
Patches currently in stable-queue which might be from danilokrummrich(a)dk-develop.de are
queue-4.15/usb-quirks-add-control-message-delay-for-1b1c-1b20.patch
This is a note to let you know that I've just added the patch titled
usb: host: xhci-rcar: add support for r8a77965
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:
usb-host-xhci-rcar-add-support-for-r8a77965.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 015dbeb2282030bf56762e21d25f09422edfd750 Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Tue, 27 Feb 2018 17:15:20 +0900
Subject: usb: host: xhci-rcar: add support for r8a77965
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
commit 015dbeb2282030bf56762e21d25f09422edfd750 upstream.
This patch adds support for r8a77965 (R-Car M3-N).
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Reviewed-by: Simon Horman <horms+renesas(a)verge.net.au>
Reviewed-by: Rob Herring <robh(a)kernel.org>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
drivers/usb/host/xhci-rcar.c | 4 ++++
2 files changed, 5 insertions(+)
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -12,6 +12,7 @@ Required properties:
- "renesas,xhci-r8a7793" for r8a7793 SoC
- "renesas,xhci-r8a7795" for r8a7795 SoC
- "renesas,xhci-r8a7796" for r8a7796 SoC
+ - "renesas,xhci-r8a77965" for r8a77965 SoC
- "renesas,rcar-gen2-xhci" for a generic R-Car Gen2 compatible device
- "renesas,rcar-gen3-xhci" for a generic R-Car Gen3 compatible device
- "xhci-platform" (deprecated)
--- a/drivers/usb/host/xhci-rcar.c
+++ b/drivers/usb/host/xhci-rcar.c
@@ -83,6 +83,10 @@ static const struct soc_device_attribute
.soc_id = "r8a7796",
.data = (void *)RCAR_XHCI_FIRMWARE_V3,
},
+ {
+ .soc_id = "r8a77965",
+ .data = (void *)RCAR_XHCI_FIRMWARE_V3,
+ },
{ /* sentinel */ },
};
Patches currently in stable-queue which might be from yoshihiro.shimoda.uh(a)renesas.com are
queue-4.15/serial-sh-sci-prevent-lockup-on-full-tty-buffers.patch
queue-4.15/usb-host-xhci-rcar-add-support-for-r8a77965.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()
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:
usb-gadget-f_fs-fix-use-after-free-in-ffs_fs_kill_sb.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 1a087f032111a88e826877449dfb93ceb22b78b9 Mon Sep 17 00:00:00 2001
From: Xinyong <xinyong.fang(a)linux.alibaba.com>
Date: Fri, 2 Mar 2018 19:20:07 +0800
Subject: usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()
From: Xinyong <xinyong.fang(a)linux.alibaba.com>
commit 1a087f032111a88e826877449dfb93ceb22b78b9 upstream.
When I debug a kernel crash issue in funcitonfs, found ffs_data.ref
overflowed, While functionfs is unmounting, ffs_data is put twice.
Commit 43938613c6fd ("drivers, usb: convert ffs_data.ref from atomic_t to
refcount_t") can avoid refcount overflow, but that is risk some situations.
So no need put ffs data in ffs_fs_kill_sb, already put in ffs_data_closed.
The issue can be reproduced in Mediatek mt6763 SoC, ffs for ADB device.
KASAN enabled configuration reports use-after-free errro.
BUG: KASAN: use-after-free in refcount_dec_and_test+0x14/0xe0 at addr ffffffc0579386a0
Read of size 4 by task umount/4650
====================================================
BUG kmalloc-512 (Tainted: P W O ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in ffs_fs_mount+0x194/0x844 age=22856 cpu=2 pid=566
alloc_debug_processing+0x1ac/0x1e8
___slab_alloc.constprop.63+0x640/0x648
__slab_alloc.isra.57.constprop.62+0x24/0x34
kmem_cache_alloc_trace+0x1a8/0x2bc
ffs_fs_mount+0x194/0x844
mount_fs+0x6c/0x1d0
vfs_kern_mount+0x50/0x1b4
do_mount+0x258/0x1034
INFO: Freed in ffs_data_put+0x25c/0x320 age=0 cpu=3 pid=4650
free_debug_processing+0x22c/0x434
__slab_free+0x2d8/0x3a0
kfree+0x254/0x264
ffs_data_put+0x25c/0x320
ffs_data_closed+0x124/0x15c
ffs_fs_kill_sb+0xb8/0x110
deactivate_locked_super+0x6c/0x98
deactivate_super+0xb0/0xbc
INFO: Object 0xffffffc057938600 @offset=1536 fp=0x (null)
......
Call trace:
[<ffffff900808cf5c>] dump_backtrace+0x0/0x250
[<ffffff900808d3a0>] show_stack+0x14/0x1c
[<ffffff90084a8c04>] dump_stack+0xa0/0xc8
[<ffffff900826c2b4>] print_trailer+0x158/0x260
[<ffffff900826d9d8>] object_err+0x3c/0x40
[<ffffff90082745f0>] kasan_report_error+0x2a8/0x754
[<ffffff9008274f84>] kasan_report+0x5c/0x60
[<ffffff9008273208>] __asan_load4+0x70/0x88
[<ffffff90084cd81c>] refcount_dec_and_test+0x14/0xe0
[<ffffff9008d98f9c>] ffs_data_put+0x80/0x320
[<ffffff9008d9d904>] ffs_fs_kill_sb+0xc8/0x110
[<ffffff90082852a0>] deactivate_locked_super+0x6c/0x98
[<ffffff900828537c>] deactivate_super+0xb0/0xbc
[<ffffff90082af0c0>] cleanup_mnt+0x64/0xec
[<ffffff90082af1b0>] __cleanup_mnt+0x10/0x18
[<ffffff90080d9e68>] task_work_run+0xcc/0x124
[<ffffff900808c8c0>] do_notify_resume+0x60/0x70
[<ffffff90080866e4>] work_pending+0x10/0x14
Cc: stable(a)vger.kernel.org
Signed-off-by: Xinyong <xinyong.fang(a)linux.alibaba.com>
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 | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1535,7 +1535,6 @@ ffs_fs_kill_sb(struct super_block *sb)
if (sb->s_fs_info) {
ffs_release_dev(sb->s_fs_info);
ffs_data_closed(sb->s_fs_info);
- ffs_data_put(sb->s_fs_info);
}
}
Patches currently in stable-queue which might be from xinyong.fang(a)linux.alibaba.com are
queue-4.15/usb-gadget-f_fs-fix-use-after-free-in-ffs_fs_kill_sb.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: Fix lock-up on ID change during system suspend/resume
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:
usb-dwc3-fix-lock-up-on-id-change-during-system-suspend-resume.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 084a804e01205bcd74cd0849bc72cb5c88f8e648 Mon Sep 17 00:00:00 2001
From: Roger Quadros <rogerq(a)ti.com>
Date: Tue, 27 Feb 2018 12:41:41 +0200
Subject: usb: dwc3: Fix lock-up on ID change during system suspend/resume
From: Roger Quadros <rogerq(a)ti.com>
commit 084a804e01205bcd74cd0849bc72cb5c88f8e648 upstream.
To reproduce the lock up do the following
- connect otg host adapter and a USB device to the dual-role port
so that it is in host mode.
- suspend to mem.
- disconnect otg adapter.
- resume the system.
If we call dwc3_host_exit() before tasks are thawed
xhci_plat_remove() seems to lock up at the second usb_remove_hcd() call.
To work around this we queue the _dwc3_set_mode() work on
the system_freezable_wq.
Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly")
Cc: <stable(a)vger.kernel.org> # v4.12+
Suggested-by: Manu Gautam <mgautam(a)codeaurora.org>
Signed-off-by: Roger Quadros <rogerq(a)ti.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/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -174,7 +174,7 @@ void dwc3_set_mode(struct dwc3 *dwc, u32
dwc->desired_dr_role = mode;
spin_unlock_irqrestore(&dwc->lock, flags);
- queue_work(system_power_efficient_wq, &dwc->drd_work);
+ queue_work(system_freezable_wq, &dwc->drd_work);
}
u32 dwc3_core_fifo_space(struct dwc3_ep *dep, u8 type)
Patches currently in stable-queue which might be from rogerq(a)ti.com are
queue-4.15/usb-dwc3-fix-lock-up-on-id-change-during-system-suspend-resume.patch
This is a note to let you know that I've just added the patch titled
uas: fix comparison for error code
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:
uas-fix-comparison-for-error-code.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 9a513c905bb95bef79d96feb08621c1ec8d8c4bb Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum(a)suse.com>
Date: Tue, 6 Mar 2018 15:04:24 +0100
Subject: uas: fix comparison for error code
From: Oliver Neukum <oneukum(a)suse.com>
commit 9a513c905bb95bef79d96feb08621c1ec8d8c4bb upstream.
A typo broke the comparison.
Fixes: cbeef22fd611 ("usb: uas: unconditionally bring back host after reset")
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
CC: stable(a)kernel.org
Acked-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/uas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1076,7 +1076,7 @@ static int uas_post_reset(struct usb_int
return 0;
err = uas_configure_endpoints(devinfo);
- if (err && err != ENODEV)
+ if (err && err != -ENODEV)
shost_printk(KERN_ERR, shost,
"%s: alloc streams error %d after reset",
__func__, err);
Patches currently in stable-queue which might be from oneukum(a)suse.com are
queue-4.15/uas-fix-comparison-for-error-code.patch
This is a note to let you know that I've just added the patch titled
tty/serial: atmel: add new version check for usart
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:
tty-serial-atmel-add-new-version-check-for-usart.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 fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 Mon Sep 17 00:00:00 2001
From: Jonas Danielsson <jonas(a)orbital-systems.com>
Date: Mon, 29 Jan 2018 12:39:15 +0100
Subject: tty/serial: atmel: add new version check for usart
From: Jonas Danielsson <jonas(a)orbital-systems.com>
commit fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 upstream.
On our at91sam9260 based board the usart0 and usart1 ports report
their versions (ATMEL_US_VERSION) as 0x10302. This version is not
included in the current checks in the driver.
Signed-off-by: Jonas Danielsson <jonas(a)orbital-systems.com>
Acked-by: Richard Genoud <richard.genoud(a)gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/atmel_serial.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1734,6 +1734,7 @@ static void atmel_get_ip_name(struct uar
switch (version) {
case 0x302:
case 0x10213:
+ case 0x10302:
dev_dbg(port->dev, "This version is usart\n");
atmel_port->has_frac_baudrate = true;
atmel_port->has_hw_timer = true;
Patches currently in stable-queue which might be from jonas(a)orbital-systems.com are
queue-4.15/tty-serial-atmel-add-new-version-check-for-usart.patch
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix lockdep issue during llseek
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:
staging-android-ashmem-fix-lockdep-issue-during-llseek.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 cb57469c9573f6018cd1302953dd45d6e05aba7b Mon Sep 17 00:00:00 2001
From: Joel Fernandes <joelaf(a)google.com>
Date: Fri, 16 Feb 2018 11:02:01 -0800
Subject: staging: android: ashmem: Fix lockdep issue during llseek
From: Joel Fernandes <joelaf(a)google.com>
commit cb57469c9573f6018cd1302953dd45d6e05aba7b upstream.
ashmem_mutex create a chain of dependencies like so:
(1)
mmap syscall ->
mmap_sem -> (acquired)
ashmem_mmap
ashmem_mutex (try to acquire)
(block)
(2)
llseek syscall ->
ashmem_llseek ->
ashmem_mutex -> (acquired)
inode_lock ->
inode->i_rwsem (try to acquire)
(block)
(3)
getdents ->
iterate_dir ->
inode_lock ->
inode->i_rwsem (acquired)
copy_to_user ->
mmap_sem (try to acquire)
There is a lock ordering created between mmap_sem and inode->i_rwsem
causing a lockdep splat [2] during a syzcaller test, this patch fixes
the issue by unlocking the mutex earlier. Functionally that's Ok since
we don't need to protect vfs_llseek.
[1] https://patchwork.kernel.org/patch/10185031/
[2] https://lkml.org/lkml/2018/1/10/48
Acked-by: Todd Kjos <tkjos(a)google.com>
Cc: Arve Hjonnevag <arve(a)android.com>
Cc: stable(a)vger.kernel.org
Reported-by: syzbot+8ec30bb7bf1a981a2012(a)syzkaller.appspotmail.com
Signed-off-by: Joel Fernandes <joelaf(a)google.com>
Acked-by: Greg Hackmann <ghackmann(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -334,24 +334,23 @@ static loff_t ashmem_llseek(struct file
mutex_lock(&ashmem_mutex);
if (asma->size == 0) {
- ret = -EINVAL;
- goto out;
+ mutex_unlock(&ashmem_mutex);
+ return -EINVAL;
}
if (!asma->file) {
- ret = -EBADF;
- goto out;
+ mutex_unlock(&ashmem_mutex);
+ return -EBADF;
}
+ mutex_unlock(&ashmem_mutex);
+
ret = vfs_llseek(asma->file, offset, origin);
if (ret < 0)
- goto out;
+ return ret;
/** Copy f_pos from backing file, since f_ops->llseek() sets it */
file->f_pos = asma->file->f_pos;
-
-out:
- mutex_unlock(&ashmem_mutex);
return ret;
}
Patches currently in stable-queue which might be from joelaf(a)google.com are
queue-4.15/staging-android-ashmem-fix-lockdep-issue-during-llseek.patch
This is a note to let you know that I've just added the patch titled
staging: comedi: fix comedi_nsamples_left.
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:
staging-comedi-fix-comedi_nsamples_left.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 a42ae5905140c324362fe5036ae1dbb16e4d359c Mon Sep 17 00:00:00 2001
From: Frank Mori Hess <fmh6jj(a)gmail.com>
Date: Thu, 15 Feb 2018 15:13:42 -0500
Subject: staging: comedi: fix comedi_nsamples_left.
From: Frank Mori Hess <fmh6jj(a)gmail.com>
commit a42ae5905140c324362fe5036ae1dbb16e4d359c upstream.
A rounding error was causing comedi_nsamples_left to
return the wrong value when nsamples was not a multiple
of the scan length.
Cc: <stable(a)vger.kernel.org> # v4.4+
Signed-off-by: Frank Mori Hess <fmh6jj(a)gmail.com>
Reviewed-by: Ian Abbott <abbotti(a)mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/comedi/drivers.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -484,8 +484,7 @@ unsigned int comedi_nsamples_left(struct
struct comedi_cmd *cmd = &async->cmd;
if (cmd->stop_src == TRIG_COUNT) {
- unsigned int nscans = nsamples / cmd->scan_end_arg;
- unsigned int scans_left = __comedi_nscans_left(s, nscans);
+ unsigned int scans_left = __comedi_nscans_left(s, cmd->stop_arg);
unsigned int scan_pos =
comedi_bytes_to_samples(s, async->scan_progress);
unsigned long long samples_left = 0;
Patches currently in stable-queue which might be from fmh6jj(a)gmail.com are
queue-4.15/staging-comedi-fix-comedi_nsamples_left.patch
This is a note to let you know that I've just added the patch titled
serial: sh-sci: prevent lockup on full TTY buffers
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:
serial-sh-sci-prevent-lockup-on-full-tty-buffers.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 7842055bfce4bf0170d0f61df8b2add8399697be Mon Sep 17 00:00:00 2001
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Date: Thu, 15 Feb 2018 13:02:27 +0100
Subject: serial: sh-sci: prevent lockup on full TTY buffers
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream.
When the TTY buffers fill up to the configured maximum, a system lockup
occurs:
[ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
[ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
[ 598.838755] Task dump for CPU 0:
[ 598.841977] swapper/0 R running task 0 0 0 0x00000022
[ 598.849023] Call trace:
[ 598.851476] __switch_to+0x98/0xb0
[ 598.854870] (null)
This can be prevented by doing a dummy read of the RX data register.
This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
as well.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Cc: stable <stable(a)vger.kernel.org>
Tested-by: Nguyen Viet Dung <dung.nguyen.aj(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -885,6 +885,8 @@ static void sci_receive_chars(struct uar
/* Tell the rest of the system the news. New characters! */
tty_flip_buffer_push(tport);
} else {
+ /* TTY buffers full; read from RX reg to prevent lockup */
+ serial_port_in(port, SCxRDR);
serial_port_in(port, SCxSR); /* dummy read */
sci_clear_SCxSR(port, SCxSR_RDxF_CLEAR(port));
}
Patches currently in stable-queue which might be from ulrich.hecht+renesas(a)gmail.com are
queue-4.15/serial-sh-sci-prevent-lockup-on-full-tty-buffers.patch
This is a note to let you know that I've just added the patch titled
serial: core: mark port as initialized in autoconfig
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:
serial-core-mark-port-as-initialized-in-autoconfig.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 714569064adee3c114a2a6490735b94abe269068 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Date: Sat, 3 Feb 2018 12:27:23 +0100
Subject: serial: core: mark port as initialized in autoconfig
From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
commit 714569064adee3c114a2a6490735b94abe269068 upstream.
This is a followup on 44117a1d1732 ("serial: core: mark port as
initialized after successful IRQ change").
Nikola has been using autoconfig via setserial and reported a crash
similar to what I fixed in the earlier mentioned commit. Here I do the
same fixup for the autoconfig. I wasn't sure that this is the right
approach. Nikola confirmed that it fixes his crash.
Fixes: b3b576461864 ("tty: serial_core: convert uart_open to use tty_port_open")
Link: http://lkml.kernel.org/r/20180131072000.GD1853@localhost.localdomain
Reported-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Tested-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Tested-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Acked-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/serial_core.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1144,6 +1144,8 @@ static int uart_do_autoconfig(struct tty
uport->ops->config_port(uport, flags);
ret = uart_startup(tty, state, 1);
+ if (ret == 0)
+ tty_port_set_initialized(port, true);
if (ret > 0)
ret = 0;
}
Patches currently in stable-queue which might be from bigeasy(a)linutronix.de are
queue-4.15/serial-core-mark-port-as-initialized-in-autoconfig.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
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:
serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.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 9f2068f35729948bde84d87a40d135015911345d Mon Sep 17 00:00:00 2001
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Date: Tue, 13 Feb 2018 15:04:46 +0100
Subject: serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
commit 9f2068f35729948bde84d87a40d135015911345d upstream.
Add PCI ids for two variants of Brainboxes UC-260 quad port
PCI serial cards.
Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -4699,6 +4699,17 @@ static const struct pci_device_id serial
PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */
pbn_b2_4_115200 },
/*
+ * BrainBoxes UC-260
+ */
+ { PCI_VENDOR_ID_INTASHIELD, 0x0D21,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ { PCI_VENDOR_ID_INTASHIELD, 0x0E34,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ /*
* Perle PCI-RAS cards
*/
{ PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9030,
Patches currently in stable-queue which might be from nikola.ciprich(a)linuxbox.cz are
queue-4.15/serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.patch
queue-4.15/serial-core-mark-port-as-initialized-in-autoconfig.patch
This is a note to let you know that I've just added the patch titled
scsi: sd_zbc: Fix potential memory leak
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:
scsi-sd_zbc-fix-potential-memory-leak.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 4b433924b2755a94f99258c178684a0e05c344de Mon Sep 17 00:00:00 2001
From: Damien Le Moal <damien.lemoal(a)wdc.com>
Date: Fri, 2 Mar 2018 07:19:28 +0900
Subject: scsi: sd_zbc: Fix potential memory leak
From: Damien Le Moal <damien.lemoal(a)wdc.com>
commit 4b433924b2755a94f99258c178684a0e05c344de upstream.
Rework sd_zbc_check_zone_size() to avoid a memory leak due to an early
return if sd_zbc_report_zones() fails.
Reported-by: David.butterfield <david.butterfield(a)wdc.com>
Signed-off-by: Damien Le Moal <damien.lemoal(a)wdc.com>
Cc: stable(a)vger.kernel.org
Reviewed-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sd_zbc.c | 35 +++++++++++++++--------------------
1 file changed, 15 insertions(+), 20 deletions(-)
--- a/drivers/scsi/sd_zbc.c
+++ b/drivers/scsi/sd_zbc.c
@@ -486,7 +486,7 @@ static int sd_zbc_check_capacity(struct
*/
static int sd_zbc_check_zone_size(struct scsi_disk *sdkp)
{
- u64 zone_blocks;
+ u64 zone_blocks = 0;
sector_t block = 0;
unsigned char *buf;
unsigned char *rec;
@@ -504,10 +504,8 @@ static int sd_zbc_check_zone_size(struct
/* Do a report zone to get the same field */
ret = sd_zbc_report_zones(sdkp, buf, SD_ZBC_BUF_SIZE, 0);
- if (ret) {
- zone_blocks = 0;
- goto out;
- }
+ if (ret)
+ goto out_free;
same = buf[4] & 0x0f;
if (same > 0) {
@@ -547,7 +545,7 @@ static int sd_zbc_check_zone_size(struct
ret = sd_zbc_report_zones(sdkp, buf,
SD_ZBC_BUF_SIZE, block);
if (ret)
- return ret;
+ goto out_free;
}
} while (block < sdkp->capacity);
@@ -555,35 +553,32 @@ static int sd_zbc_check_zone_size(struct
zone_blocks = sdkp->zone_blocks;
out:
- kfree(buf);
-
if (!zone_blocks) {
if (sdkp->first_scan)
sd_printk(KERN_NOTICE, sdkp,
"Devices with non constant zone "
"size are not supported\n");
- return -ENODEV;
- }
-
- if (!is_power_of_2(zone_blocks)) {
+ ret = -ENODEV;
+ } else if (!is_power_of_2(zone_blocks)) {
if (sdkp->first_scan)
sd_printk(KERN_NOTICE, sdkp,
"Devices with non power of 2 zone "
"size are not supported\n");
- return -ENODEV;
- }
-
- if (logical_to_sectors(sdkp->device, zone_blocks) > UINT_MAX) {
+ ret = -ENODEV;
+ } else if (logical_to_sectors(sdkp->device, zone_blocks) > UINT_MAX) {
if (sdkp->first_scan)
sd_printk(KERN_NOTICE, sdkp,
"Zone size too large\n");
- return -ENODEV;
+ ret = -ENODEV;
+ } else {
+ sdkp->zone_blocks = zone_blocks;
+ sdkp->zone_shift = ilog2(zone_blocks);
}
- sdkp->zone_blocks = zone_blocks;
- sdkp->zone_shift = ilog2(zone_blocks);
+out_free:
+ kfree(buf);
- return 0;
+ return ret;
}
static int sd_zbc_setup(struct scsi_disk *sdkp)
Patches currently in stable-queue which might be from damien.lemoal(a)wdc.com are
queue-4.15/scsi-sd_zbc-fix-potential-memory-leak.patch
This is a note to let you know that I've just added the patch titled
dm mpath: fix passing integrity data
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:
dm-mpath-fix-passing-integrity-data.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 8c5c147339d2e201108169327b1f99aa6d57d2cd Mon Sep 17 00:00:00 2001
From: Steffen Maier <maier(a)linux.vnet.ibm.com>
Date: Wed, 14 Mar 2018 15:33:06 +0100
Subject: dm mpath: fix passing integrity data
From: Steffen Maier <maier(a)linux.vnet.ibm.com>
commit 8c5c147339d2e201108169327b1f99aa6d57d2cd upstream.
After v4.12 commit e2460f2a4bc7 ("dm: mark targets that pass integrity
data"), dm-multipath, e.g. on DIF+DIX SCSI disk paths, does not support
block integrity any more. So add it to the whitelist.
This is also a pre-requisite to use block integrity with other dm layer(s)
on top of multipath, such as kpartx partitions (dm-linear) or LVM.
Also, bump target version to reflect this fix.
Fixes: e2460f2a4bc7 ("dm: mark targets that pass integrity data")
Cc: <stable(a)vger.kernel.org> #4.12+
Bisected-by: Fedor Loshakov <loshakov(a)linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier(a)linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/dm-mpath.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -1968,8 +1968,9 @@ static int multipath_busy(struct dm_targ
*---------------------------------------------------------------*/
static struct target_type multipath_target = {
.name = "multipath",
- .version = {1, 12, 0},
- .features = DM_TARGET_SINGLETON | DM_TARGET_IMMUTABLE,
+ .version = {1, 13, 0},
+ .features = DM_TARGET_SINGLETON | DM_TARGET_IMMUTABLE |
+ DM_TARGET_PASSES_INTEGRITY,
.module = THIS_MODULE,
.ctr = multipath_ctr,
.dtr = multipath_dtr,
Patches currently in stable-queue which might be from maier(a)linux.vnet.ibm.com are
queue-4.15/dm-mpath-fix-passing-integrity-data.patch
This is a note to let you know that I've just added the patch titled
earlycon: add reg-offset to physical address before mapping
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:
earlycon-add-reg-offset-to-physical-address-before-mapping.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 1f66dd36bb18437397ea0d7882c52f7e3c476e15 Mon Sep 17 00:00:00 2001
From: Greentime Hu <green.hu(a)gmail.com>
Date: Tue, 13 Feb 2018 17:09:08 +0800
Subject: earlycon: add reg-offset to physical address before mapping
From: Greentime Hu <green.hu(a)gmail.com>
commit 1f66dd36bb18437397ea0d7882c52f7e3c476e15 upstream.
It will get the wrong virtual address because port->mapbase is not added
the correct reg-offset yet. We have to update it before earlycon_map()
is called
Signed-off-by: Greentime Hu <greentime(a)andestech.com>
Acked-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Peter Hurley <peter(a)hurleysoftware.com>
Cc: stable(a)vger.kernel.org
Fixes: 088da2a17619 ("of: earlycon: Initialize port fields from DT properties")
Acked-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/earlycon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -250,11 +250,12 @@ int __init of_setup_earlycon(const struc
}
port->mapbase = addr;
port->uartclk = BASE_BAUD * 16;
- port->membase = earlycon_map(port->mapbase, SZ_4K);
val = of_get_flat_dt_prop(node, "reg-offset", NULL);
if (val)
port->mapbase += be32_to_cpu(*val);
+ port->membase = earlycon_map(port->mapbase, SZ_4K);
+
val = of_get_flat_dt_prop(node, "reg-shift", NULL);
if (val)
port->regshift = be32_to_cpu(*val);
Patches currently in stable-queue which might be from green.hu(a)gmail.com are
queue-4.15/earlycon-add-reg-offset-to-physical-address-before-mapping.patch
This is a note to let you know that I've just added the patch titled
ASoC: sun4i-i2s: Fix RX slot number of SUN8I
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:
asoc-sun4i-i2s-fix-rx-slot-number-of-sun8i.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 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: ASoC: sun4i-i2s: Fix RX slot number of SUN8I
From: Yong Deng <yong.deng(a)magewell.com>
commit 5a3386790a172cf738194e1574f631cd43c6140a upstream.
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
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sunxi/sun4i-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 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)
Patches currently in stable-queue which might be from yong.deng(a)magewell.com are
queue-4.15/asoc-sun4i-i2s-fix-rx-slot-number-of-sun8i.patch
This is a note to let you know that I've just added the patch titled
ASoC: wm_adsp: For TLV controls only register TLV get/set
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:
asoc-wm_adsp-for-tlv-controls-only-register-tlv-get-set.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 d7789f5bcdb298c4a302db471b1b20f74a20de95 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf(a)opensource.cirrus.com>
Date: Wed, 28 Feb 2018 10:31:10 +0000
Subject: ASoC: wm_adsp: For TLV controls only register TLV get/set
From: Richard Fitzgerald <rf(a)opensource.cirrus.com>
commit d7789f5bcdb298c4a302db471b1b20f74a20de95 upstream.
Normal 512-byte get/set of a TLV isn't supported but we were
registering the normal get/set anyway and relying on omitting
the SNDRV_CTL_ELEM_ACCESS_[READ|WRITE] flags to prevent them
being called.
Trouble is if this gets broken in the core ALSA code - as it has
been since at least 4.14 - the standard get/set can be called
unexpectedly and corrupt memory.
There's no point providing functions that won't be called and
it's a trivial change. The benefit is that if the ALSA core gets
broken again we get a big fat immediate NULL dereference instead
of a memory corruption timebomb.
Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/wm_adsp.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -1204,12 +1204,14 @@ static int wmfw_add_ctl(struct wm_adsp *
kcontrol->put = wm_coeff_put_acked;
break;
default:
- kcontrol->get = wm_coeff_get;
- kcontrol->put = wm_coeff_put;
-
- ctl->bytes_ext.max = ctl->len;
- ctl->bytes_ext.get = wm_coeff_tlv_get;
- ctl->bytes_ext.put = wm_coeff_tlv_put;
+ if (kcontrol->access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK) {
+ ctl->bytes_ext.max = ctl->len;
+ ctl->bytes_ext.get = wm_coeff_tlv_get;
+ ctl->bytes_ext.put = wm_coeff_tlv_put;
+ } else {
+ kcontrol->get = wm_coeff_get;
+ kcontrol->put = wm_coeff_put;
+ }
break;
}
Patches currently in stable-queue which might be from rf(a)opensource.cirrus.com are
queue-4.15/asoc-wm_adsp-for-tlv-controls-only-register-tlv-get-set.patch
This is a note to let you know that I've just added the patch titled
ASoC: rt5651: Fix regcache sync errors on resume
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:
asoc-rt5651-fix-regcache-sync-errors-on-resume.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 2d30e9494f1ea320aaaad0cff9ddd92c87eac355 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Sun, 18 Feb 2018 23:01:44 +0100
Subject: ASoC: rt5651: Fix regcache sync errors on resume
From: Hans de Goede <hdegoede(a)redhat.com>
commit 2d30e9494f1ea320aaaad0cff9ddd92c87eac355 upstream.
The ALC5651 does not like multi-write accesses, avoid them. This fixes:
rt5651 i2c-10EC5651:00: Unable to sync registers 0x27-0x28. -121
Errors on resume (and all registers after the registers in the error not
being synced).
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/rt5651.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -1722,6 +1722,7 @@ static const struct regmap_config rt5651
.num_reg_defaults = ARRAY_SIZE(rt5651_reg),
.ranges = rt5651_ranges,
.num_ranges = ARRAY_SIZE(rt5651_ranges),
+ .use_single_rw = true,
};
#if defined(CONFIG_OF)
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.15/asoc-rt5651-fix-regcache-sync-errors-on-resume.patch
queue-4.15/uas-fix-comparison-for-error-code.patch
This is a note to let you know that I've just added the patch titled
ASoC: sgtl5000: Fix suspend/resume
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:
asoc-sgtl5000-fix-suspend-resume.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 a8992973edbb2555e956b90f6fe97c4bc14d761d Mon Sep 17 00:00:00 2001
From: Fabio Estevam <fabio.estevam(a)nxp.com>
Date: Fri, 16 Feb 2018 11:58:54 -0200
Subject: ASoC: sgtl5000: Fix suspend/resume
From: Fabio Estevam <fabio.estevam(a)nxp.com>
commit a8992973edbb2555e956b90f6fe97c4bc14d761d upstream.
Commit 8419caa72702 ("ASoC: sgtl5000: Do not disable regulators in
SND_SOC_BIAS_OFF") causes the sgtl5000 to fail after a suspend/resume
sequence:
Playing WAVE '/media/a2002011001-e02.wav' : Signed 16 bit Little
Endian, Rate 44100 Hz, Stereo
aplay: pcm_write:2051: write error: Input/output error
The problem is caused by the fact that the aforementioned commit
dropped the cache handling, so re-introduce the register map
resync to fix the problem.
Suggested-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/sgtl5000.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -871,15 +871,26 @@ static int sgtl5000_pcm_hw_params(struct
static int sgtl5000_set_bias_level(struct snd_soc_codec *codec,
enum snd_soc_bias_level level)
{
+ struct sgtl5000_priv *sgtl = snd_soc_codec_get_drvdata(codec);
+ int ret;
+
switch (level) {
case SND_SOC_BIAS_ON:
case SND_SOC_BIAS_PREPARE:
case SND_SOC_BIAS_STANDBY:
+ regcache_cache_only(sgtl->regmap, false);
+ ret = regcache_sync(sgtl->regmap);
+ if (ret) {
+ regcache_cache_only(sgtl->regmap, true);
+ return ret;
+ }
+
snd_soc_update_bits(codec, SGTL5000_CHIP_ANA_POWER,
SGTL5000_REFTOP_POWERUP,
SGTL5000_REFTOP_POWERUP);
break;
case SND_SOC_BIAS_OFF:
+ regcache_cache_only(sgtl->regmap, true);
snd_soc_update_bits(codec, SGTL5000_CHIP_ANA_POWER,
SGTL5000_REFTOP_POWERUP, 0);
break;
Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are
queue-4.15/asoc-sgtl5000-fix-suspend-resume.patch
This is a note to let you know that I've just added the patch titled
xhci: Fix front USB ports on ASUS PRIME B350M-A
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:
xhci-fix-front-usb-ports-on-asus-prime-b350m-a.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 191edc5e2e515aab1075a3f0ef23599e80be5f59 Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Thu, 8 Mar 2018 17:17:17 +0200
Subject: xhci: Fix front USB ports on ASUS PRIME B350M-A
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 191edc5e2e515aab1075a3f0ef23599e80be5f59 upstream.
When a USB device gets plugged on ASUS PRIME B350M-A's front ports, the
xHC stops working:
[ 549.114587] xhci_hcd 0000:02:00.0: WARN: xHC CMD_RUN timeout
[ 549.114608] suspend_common(): xhci_pci_suspend+0x0/0xc0 returns -110
[ 549.114638] xhci_hcd 0000:02:00.0: can't suspend (hcd_pci_runtime_suspend returned -110)
Delay before running xHC command CMD_RUN can workaround the issue.
Use a new quirk to make the delay only targets to the affected xHC.
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-pci.c | 3 +++
drivers/usb/host/xhci.c | 3 +++
drivers/usb/host/xhci.h | 1 +
3 files changed, 7 insertions(+)
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -134,6 +134,9 @@ static void xhci_pci_quirks(struct devic
if (pdev->vendor == PCI_VENDOR_ID_AMD && usb_amd_find_chipset_info())
xhci->quirks |= XHCI_AMD_PLL_FIX;
+ if (pdev->vendor == PCI_VENDOR_ID_AMD && pdev->device == 0x43bb)
+ xhci->quirks |= XHCI_SUSPEND_DELAY;
+
if (pdev->vendor == PCI_VENDOR_ID_AMD)
xhci->quirks |= XHCI_TRUST_TX_LENGTH;
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -887,6 +887,9 @@ int xhci_suspend(struct xhci_hcd *xhci,
clear_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags);
del_timer_sync(&xhci->shared_hcd->rh_timer);
+ if (xhci->quirks & XHCI_SUSPEND_DELAY)
+ usleep_range(1000, 1500);
+
spin_lock_irq(&xhci->lock);
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &xhci->shared_hcd->flags);
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1830,6 +1830,7 @@ struct xhci_hcd {
#define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
/* Reserved. It was XHCI_U2_DISABLE_WAKE */
#define XHCI_ASMEDIA_MODIFY_FLOWCONTROL (1 << 28)
+#define XHCI_SUSPEND_DELAY (1 << 30)
unsigned int num_active_eps;
unsigned int limit_active_eps;
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.14/xhci-fix-front-usb-ports-on-asus-prime-b350m-a.patch
This is a note to let you know that I've just added the patch titled
usbip: vudc: fix null pointer dereference on udc->lock
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:
usbip-vudc-fix-null-pointer-dereference-on-udc-lock.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 df3334c223a033f562645712e832ca4cbb326bbf Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king(a)canonical.com>
Date: Thu, 22 Feb 2018 17:39:17 +0000
Subject: usbip: vudc: fix null pointer dereference on udc->lock
From: Colin Ian King <colin.king(a)canonical.com>
commit df3334c223a033f562645712e832ca4cbb326bbf upstream.
Currently the driver attempts to spin lock on udc->lock before a NULL
pointer check is performed on udc, hence there is a potential null
pointer dereference on udc->lock. Fix this by moving the null check
on udc before the lock occurs.
Fixes: ea6873a45a22 ("usbip: vudc: Add SysFS infrastructure for VUDC")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Reviewed-by: Krzysztof Opasiak <k.opasiak(a)samsung.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/vudc_sysfs.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/usb/usbip/vudc_sysfs.c
+++ b/drivers/usb/usbip/vudc_sysfs.c
@@ -117,10 +117,14 @@ static ssize_t store_sockfd(struct devic
if (rv != 0)
return -EINVAL;
+ if (!udc) {
+ dev_err(dev, "no device");
+ return -ENODEV;
+ }
spin_lock_irqsave(&udc->lock, flags);
/* Don't export what we don't have */
- if (!udc || !udc->driver || !udc->pullup) {
- dev_err(dev, "no device or gadget not bound");
+ if (!udc->driver || !udc->pullup) {
+ dev_err(dev, "gadget not bound");
ret = -ENODEV;
goto unlock;
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.14/usbip-vudc-fix-null-pointer-dereference-on-udc-lock.patch
This is a note to let you know that I've just added the patch titled
usb: quirks: add control message delay for 1b1c:1b20
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:
usb-quirks-add-control-message-delay-for-1b1c-1b20.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 cb88a0588717ba6c756cb5972d75766b273a6817 Mon Sep 17 00:00:00 2001
From: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
Date: Tue, 6 Mar 2018 09:38:49 +0100
Subject: usb: quirks: add control message delay for 1b1c:1b20
From: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
commit cb88a0588717ba6c756cb5972d75766b273a6817 upstream.
Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.
Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.
Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):
[ 29.103520] usb 1-8: string descriptor 0 read error: -110
[ 34.363097] usb 1-8: can't set config #1, error -110
Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:
[ 35.400533] usbhid 1-8:1.0: can't add hid device: -110
[ 35.401014] usbhid: probe of 1-8:1.0 failed with error -110
The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.
Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().
The overall boot time seems not to be influenced by these additional
delays, even on fast machines and lightweight distributions.
Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard")
Cc: stable(a)vger.kernel.org
Signed-off-by: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/message.c | 4 ++++
drivers/usb/core/quirks.c | 3 ++-
include/linux/usb/quirks.h | 3 +++
3 files changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -150,6 +150,10 @@ int usb_control_msg(struct usb_device *d
ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout);
+ /* Linger a bit, prior to the next control message. */
+ if (dev->quirks & USB_QUIRK_DELAY_CTRL_MSG)
+ msleep(200);
+
kfree(dr);
return ret;
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -229,7 +229,8 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
/* Corsair Strafe RGB */
- { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+ { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT |
+ USB_QUIRK_DELAY_CTRL_MSG },
/* Corsair K70 LUX */
{ USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT },
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -57,4 +57,7 @@
*/
#define USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL BIT(11)
+/* Device needs a pause after every control message. */
+#define USB_QUIRK_DELAY_CTRL_MSG BIT(13)
+
#endif /* __LINUX_USB_QUIRKS_H */
Patches currently in stable-queue which might be from danilokrummrich(a)dk-develop.de are
queue-4.14/usb-quirks-add-control-message-delay-for-1b1c-1b20.patch
This is a note to let you know that I've just added the patch titled
USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h
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:
usb-storage-add-jmicron-bridge-152d-2567-to-unusual_devs.h.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 5126a504b63d82785eaece3a9c30c660b313785a Mon Sep 17 00:00:00 2001
From: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
Date: Thu, 1 Mar 2018 19:34:29 +0200
Subject: USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h
From: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
commit 5126a504b63d82785eaece3a9c30c660b313785a upstream.
This USB-SATA controller seems to be similar with JMicron bridge
152d:2566 already on the list. Adding it here fixes "Invalid
field in cdb" errors.
Signed-off-by: Teijo Kinnunen <teijo.kinnunen(a)code-q.fi>
Cc: stable(a)vger.kernel.org
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/unusual_devs.h | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2137,6 +2137,13 @@ UNUSUAL_DEV( 0x152d, 0x2566, 0x0114, 0x
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA ),
+/* Reported by Teijo Kinnunen <teijo.kinnunen(a)code-q.fi> */
+UNUSUAL_DEV( 0x152d, 0x2567, 0x0117, 0x0117,
+ "JMicron",
+ "USB to ATA/ATAPI Bridge",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA ),
+
/* Reported-by George Cherian <george.cherian(a)cavium.com> */
UNUSUAL_DEV(0x152d, 0x9561, 0x0000, 0x9999,
"JMicron",
Patches currently in stable-queue which might be from teijo.kinnunen(a)code-q.fi are
queue-4.14/usb-storage-add-jmicron-bridge-152d-2567-to-unusual_devs.h.patch
This is a note to let you know that I've just added the patch titled
usb: host: xhci-rcar: add support for r8a77965
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:
usb-host-xhci-rcar-add-support-for-r8a77965.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 015dbeb2282030bf56762e21d25f09422edfd750 Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Tue, 27 Feb 2018 17:15:20 +0900
Subject: usb: host: xhci-rcar: add support for r8a77965
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
commit 015dbeb2282030bf56762e21d25f09422edfd750 upstream.
This patch adds support for r8a77965 (R-Car M3-N).
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Reviewed-by: Simon Horman <horms+renesas(a)verge.net.au>
Reviewed-by: Rob Herring <robh(a)kernel.org>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
drivers/usb/host/xhci-rcar.c | 4 ++++
2 files changed, 5 insertions(+)
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -12,6 +12,7 @@ Required properties:
- "renesas,xhci-r8a7793" for r8a7793 SoC
- "renesas,xhci-r8a7795" for r8a7795 SoC
- "renesas,xhci-r8a7796" for r8a7796 SoC
+ - "renesas,xhci-r8a77965" for r8a77965 SoC
- "renesas,rcar-gen2-xhci" for a generic R-Car Gen2 compatible device
- "renesas,rcar-gen3-xhci" for a generic R-Car Gen3 compatible device
- "xhci-platform" (deprecated)
--- a/drivers/usb/host/xhci-rcar.c
+++ b/drivers/usb/host/xhci-rcar.c
@@ -86,6 +86,10 @@ static const struct soc_device_attribute
.soc_id = "r8a7796",
.data = (void *)RCAR_XHCI_FIRMWARE_V3,
},
+ {
+ .soc_id = "r8a77965",
+ .data = (void *)RCAR_XHCI_FIRMWARE_V3,
+ },
{ /* sentinel */ },
};
Patches currently in stable-queue which might be from yoshihiro.shimoda.uh(a)renesas.com are
queue-4.14/serial-sh-sci-prevent-lockup-on-full-tty-buffers.patch
queue-4.14/usb-host-xhci-rcar-add-support-for-r8a77965.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()
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:
usb-gadget-f_fs-fix-use-after-free-in-ffs_fs_kill_sb.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 1a087f032111a88e826877449dfb93ceb22b78b9 Mon Sep 17 00:00:00 2001
From: Xinyong <xinyong.fang(a)linux.alibaba.com>
Date: Fri, 2 Mar 2018 19:20:07 +0800
Subject: usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()
From: Xinyong <xinyong.fang(a)linux.alibaba.com>
commit 1a087f032111a88e826877449dfb93ceb22b78b9 upstream.
When I debug a kernel crash issue in funcitonfs, found ffs_data.ref
overflowed, While functionfs is unmounting, ffs_data is put twice.
Commit 43938613c6fd ("drivers, usb: convert ffs_data.ref from atomic_t to
refcount_t") can avoid refcount overflow, but that is risk some situations.
So no need put ffs data in ffs_fs_kill_sb, already put in ffs_data_closed.
The issue can be reproduced in Mediatek mt6763 SoC, ffs for ADB device.
KASAN enabled configuration reports use-after-free errro.
BUG: KASAN: use-after-free in refcount_dec_and_test+0x14/0xe0 at addr ffffffc0579386a0
Read of size 4 by task umount/4650
====================================================
BUG kmalloc-512 (Tainted: P W O ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in ffs_fs_mount+0x194/0x844 age=22856 cpu=2 pid=566
alloc_debug_processing+0x1ac/0x1e8
___slab_alloc.constprop.63+0x640/0x648
__slab_alloc.isra.57.constprop.62+0x24/0x34
kmem_cache_alloc_trace+0x1a8/0x2bc
ffs_fs_mount+0x194/0x844
mount_fs+0x6c/0x1d0
vfs_kern_mount+0x50/0x1b4
do_mount+0x258/0x1034
INFO: Freed in ffs_data_put+0x25c/0x320 age=0 cpu=3 pid=4650
free_debug_processing+0x22c/0x434
__slab_free+0x2d8/0x3a0
kfree+0x254/0x264
ffs_data_put+0x25c/0x320
ffs_data_closed+0x124/0x15c
ffs_fs_kill_sb+0xb8/0x110
deactivate_locked_super+0x6c/0x98
deactivate_super+0xb0/0xbc
INFO: Object 0xffffffc057938600 @offset=1536 fp=0x (null)
......
Call trace:
[<ffffff900808cf5c>] dump_backtrace+0x0/0x250
[<ffffff900808d3a0>] show_stack+0x14/0x1c
[<ffffff90084a8c04>] dump_stack+0xa0/0xc8
[<ffffff900826c2b4>] print_trailer+0x158/0x260
[<ffffff900826d9d8>] object_err+0x3c/0x40
[<ffffff90082745f0>] kasan_report_error+0x2a8/0x754
[<ffffff9008274f84>] kasan_report+0x5c/0x60
[<ffffff9008273208>] __asan_load4+0x70/0x88
[<ffffff90084cd81c>] refcount_dec_and_test+0x14/0xe0
[<ffffff9008d98f9c>] ffs_data_put+0x80/0x320
[<ffffff9008d9d904>] ffs_fs_kill_sb+0xc8/0x110
[<ffffff90082852a0>] deactivate_locked_super+0x6c/0x98
[<ffffff900828537c>] deactivate_super+0xb0/0xbc
[<ffffff90082af0c0>] cleanup_mnt+0x64/0xec
[<ffffff90082af1b0>] __cleanup_mnt+0x10/0x18
[<ffffff90080d9e68>] task_work_run+0xcc/0x124
[<ffffff900808c8c0>] do_notify_resume+0x60/0x70
[<ffffff90080866e4>] work_pending+0x10/0x14
Cc: stable(a)vger.kernel.org
Signed-off-by: Xinyong <xinyong.fang(a)linux.alibaba.com>
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 | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1539,7 +1539,6 @@ ffs_fs_kill_sb(struct super_block *sb)
if (sb->s_fs_info) {
ffs_release_dev(sb->s_fs_info);
ffs_data_closed(sb->s_fs_info);
- ffs_data_put(sb->s_fs_info);
}
}
Patches currently in stable-queue which might be from xinyong.fang(a)linux.alibaba.com are
queue-4.14/usb-gadget-f_fs-fix-use-after-free-in-ffs_fs_kill_sb.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: Fix lock-up on ID change during system suspend/resume
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:
usb-dwc3-fix-lock-up-on-id-change-during-system-suspend-resume.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 084a804e01205bcd74cd0849bc72cb5c88f8e648 Mon Sep 17 00:00:00 2001
From: Roger Quadros <rogerq(a)ti.com>
Date: Tue, 27 Feb 2018 12:41:41 +0200
Subject: usb: dwc3: Fix lock-up on ID change during system suspend/resume
From: Roger Quadros <rogerq(a)ti.com>
commit 084a804e01205bcd74cd0849bc72cb5c88f8e648 upstream.
To reproduce the lock up do the following
- connect otg host adapter and a USB device to the dual-role port
so that it is in host mode.
- suspend to mem.
- disconnect otg adapter.
- resume the system.
If we call dwc3_host_exit() before tasks are thawed
xhci_plat_remove() seems to lock up at the second usb_remove_hcd() call.
To work around this we queue the _dwc3_set_mode() work on
the system_freezable_wq.
Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly")
Cc: <stable(a)vger.kernel.org> # v4.12+
Suggested-by: Manu Gautam <mgautam(a)codeaurora.org>
Signed-off-by: Roger Quadros <rogerq(a)ti.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/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -186,7 +186,7 @@ void dwc3_set_mode(struct dwc3 *dwc, u32
dwc->desired_dr_role = mode;
spin_unlock_irqrestore(&dwc->lock, flags);
- queue_work(system_power_efficient_wq, &dwc->drd_work);
+ queue_work(system_freezable_wq, &dwc->drd_work);
}
u32 dwc3_core_fifo_space(struct dwc3_ep *dep, u8 type)
Patches currently in stable-queue which might be from rogerq(a)ti.com are
queue-4.14/usb-dwc3-fix-lock-up-on-id-change-during-system-suspend-resume.patch
This is a note to let you know that I've just added the patch titled
staging: comedi: fix comedi_nsamples_left.
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:
staging-comedi-fix-comedi_nsamples_left.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 a42ae5905140c324362fe5036ae1dbb16e4d359c Mon Sep 17 00:00:00 2001
From: Frank Mori Hess <fmh6jj(a)gmail.com>
Date: Thu, 15 Feb 2018 15:13:42 -0500
Subject: staging: comedi: fix comedi_nsamples_left.
From: Frank Mori Hess <fmh6jj(a)gmail.com>
commit a42ae5905140c324362fe5036ae1dbb16e4d359c upstream.
A rounding error was causing comedi_nsamples_left to
return the wrong value when nsamples was not a multiple
of the scan length.
Cc: <stable(a)vger.kernel.org> # v4.4+
Signed-off-by: Frank Mori Hess <fmh6jj(a)gmail.com>
Reviewed-by: Ian Abbott <abbotti(a)mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/comedi/drivers.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -484,8 +484,7 @@ unsigned int comedi_nsamples_left(struct
struct comedi_cmd *cmd = &async->cmd;
if (cmd->stop_src == TRIG_COUNT) {
- unsigned int nscans = nsamples / cmd->scan_end_arg;
- unsigned int scans_left = __comedi_nscans_left(s, nscans);
+ unsigned int scans_left = __comedi_nscans_left(s, cmd->stop_arg);
unsigned int scan_pos =
comedi_bytes_to_samples(s, async->scan_progress);
unsigned long long samples_left = 0;
Patches currently in stable-queue which might be from fmh6jj(a)gmail.com are
queue-4.14/staging-comedi-fix-comedi_nsamples_left.patch
This is a note to let you know that I've just added the patch titled
uas: fix comparison for error code
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:
uas-fix-comparison-for-error-code.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 9a513c905bb95bef79d96feb08621c1ec8d8c4bb Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum(a)suse.com>
Date: Tue, 6 Mar 2018 15:04:24 +0100
Subject: uas: fix comparison for error code
From: Oliver Neukum <oneukum(a)suse.com>
commit 9a513c905bb95bef79d96feb08621c1ec8d8c4bb upstream.
A typo broke the comparison.
Fixes: cbeef22fd611 ("usb: uas: unconditionally bring back host after reset")
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
CC: stable(a)kernel.org
Acked-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/uas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1076,7 +1076,7 @@ static int uas_post_reset(struct usb_int
return 0;
err = uas_configure_endpoints(devinfo);
- if (err && err != ENODEV)
+ if (err && err != -ENODEV)
shost_printk(KERN_ERR, shost,
"%s: alloc streams error %d after reset",
__func__, err);
Patches currently in stable-queue which might be from oneukum(a)suse.com are
queue-4.14/uas-fix-comparison-for-error-code.patch
This is a note to let you know that I've just added the patch titled
tty/serial: atmel: add new version check for usart
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:
tty-serial-atmel-add-new-version-check-for-usart.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 fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 Mon Sep 17 00:00:00 2001
From: Jonas Danielsson <jonas(a)orbital-systems.com>
Date: Mon, 29 Jan 2018 12:39:15 +0100
Subject: tty/serial: atmel: add new version check for usart
From: Jonas Danielsson <jonas(a)orbital-systems.com>
commit fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 upstream.
On our at91sam9260 based board the usart0 and usart1 ports report
their versions (ATMEL_US_VERSION) as 0x10302. This version is not
included in the current checks in the driver.
Signed-off-by: Jonas Danielsson <jonas(a)orbital-systems.com>
Acked-by: Richard Genoud <richard.genoud(a)gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/atmel_serial.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1763,6 +1763,7 @@ static void atmel_get_ip_name(struct uar
switch (version) {
case 0x302:
case 0x10213:
+ case 0x10302:
dev_dbg(port->dev, "This version is usart\n");
atmel_port->has_frac_baudrate = true;
atmel_port->has_hw_timer = true;
Patches currently in stable-queue which might be from jonas(a)orbital-systems.com are
queue-4.14/tty-serial-atmel-add-new-version-check-for-usart.patch
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix lockdep issue during llseek
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:
staging-android-ashmem-fix-lockdep-issue-during-llseek.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 cb57469c9573f6018cd1302953dd45d6e05aba7b Mon Sep 17 00:00:00 2001
From: Joel Fernandes <joelaf(a)google.com>
Date: Fri, 16 Feb 2018 11:02:01 -0800
Subject: staging: android: ashmem: Fix lockdep issue during llseek
From: Joel Fernandes <joelaf(a)google.com>
commit cb57469c9573f6018cd1302953dd45d6e05aba7b upstream.
ashmem_mutex create a chain of dependencies like so:
(1)
mmap syscall ->
mmap_sem -> (acquired)
ashmem_mmap
ashmem_mutex (try to acquire)
(block)
(2)
llseek syscall ->
ashmem_llseek ->
ashmem_mutex -> (acquired)
inode_lock ->
inode->i_rwsem (try to acquire)
(block)
(3)
getdents ->
iterate_dir ->
inode_lock ->
inode->i_rwsem (acquired)
copy_to_user ->
mmap_sem (try to acquire)
There is a lock ordering created between mmap_sem and inode->i_rwsem
causing a lockdep splat [2] during a syzcaller test, this patch fixes
the issue by unlocking the mutex earlier. Functionally that's Ok since
we don't need to protect vfs_llseek.
[1] https://patchwork.kernel.org/patch/10185031/
[2] https://lkml.org/lkml/2018/1/10/48
Acked-by: Todd Kjos <tkjos(a)google.com>
Cc: Arve Hjonnevag <arve(a)android.com>
Cc: stable(a)vger.kernel.org
Reported-by: syzbot+8ec30bb7bf1a981a2012(a)syzkaller.appspotmail.com
Signed-off-by: Joel Fernandes <joelaf(a)google.com>
Acked-by: Greg Hackmann <ghackmann(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -334,24 +334,23 @@ static loff_t ashmem_llseek(struct file
mutex_lock(&ashmem_mutex);
if (asma->size == 0) {
- ret = -EINVAL;
- goto out;
+ mutex_unlock(&ashmem_mutex);
+ return -EINVAL;
}
if (!asma->file) {
- ret = -EBADF;
- goto out;
+ mutex_unlock(&ashmem_mutex);
+ return -EBADF;
}
+ mutex_unlock(&ashmem_mutex);
+
ret = vfs_llseek(asma->file, offset, origin);
if (ret < 0)
- goto out;
+ return ret;
/** Copy f_pos from backing file, since f_ops->llseek() sets it */
file->f_pos = asma->file->f_pos;
-
-out:
- mutex_unlock(&ashmem_mutex);
return ret;
}
Patches currently in stable-queue which might be from joelaf(a)google.com are
queue-4.14/staging-android-ashmem-fix-lockdep-issue-during-llseek.patch
This is a note to let you know that I've just added the patch titled
serial: sh-sci: prevent lockup on full TTY buffers
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:
serial-sh-sci-prevent-lockup-on-full-tty-buffers.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 7842055bfce4bf0170d0f61df8b2add8399697be Mon Sep 17 00:00:00 2001
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Date: Thu, 15 Feb 2018 13:02:27 +0100
Subject: serial: sh-sci: prevent lockup on full TTY buffers
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream.
When the TTY buffers fill up to the configured maximum, a system lockup
occurs:
[ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
[ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
[ 598.838755] Task dump for CPU 0:
[ 598.841977] swapper/0 R running task 0 0 0 0x00000022
[ 598.849023] Call trace:
[ 598.851476] __switch_to+0x98/0xb0
[ 598.854870] (null)
This can be prevented by doing a dummy read of the RX data register.
This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
as well.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Cc: stable <stable(a)vger.kernel.org>
Tested-by: Nguyen Viet Dung <dung.nguyen.aj(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -886,6 +886,8 @@ static void sci_receive_chars(struct uar
/* Tell the rest of the system the news. New characters! */
tty_flip_buffer_push(tport);
} else {
+ /* TTY buffers full; read from RX reg to prevent lockup */
+ serial_port_in(port, SCxRDR);
serial_port_in(port, SCxSR); /* dummy read */
sci_clear_SCxSR(port, SCxSR_RDxF_CLEAR(port));
}
Patches currently in stable-queue which might be from ulrich.hecht+renesas(a)gmail.com are
queue-4.14/serial-sh-sci-prevent-lockup-on-full-tty-buffers.patch
This is a note to let you know that I've just added the patch titled
serial: core: mark port as initialized in autoconfig
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:
serial-core-mark-port-as-initialized-in-autoconfig.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 714569064adee3c114a2a6490735b94abe269068 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Date: Sat, 3 Feb 2018 12:27:23 +0100
Subject: serial: core: mark port as initialized in autoconfig
From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
commit 714569064adee3c114a2a6490735b94abe269068 upstream.
This is a followup on 44117a1d1732 ("serial: core: mark port as
initialized after successful IRQ change").
Nikola has been using autoconfig via setserial and reported a crash
similar to what I fixed in the earlier mentioned commit. Here I do the
same fixup for the autoconfig. I wasn't sure that this is the right
approach. Nikola confirmed that it fixes his crash.
Fixes: b3b576461864 ("tty: serial_core: convert uart_open to use tty_port_open")
Link: http://lkml.kernel.org/r/20180131072000.GD1853@localhost.localdomain
Reported-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Tested-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Tested-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Acked-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/serial_core.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1157,6 +1157,8 @@ static int uart_do_autoconfig(struct tty
uport->ops->config_port(uport, flags);
ret = uart_startup(tty, state, 1);
+ if (ret == 0)
+ tty_port_set_initialized(port, true);
if (ret > 0)
ret = 0;
}
Patches currently in stable-queue which might be from bigeasy(a)linutronix.de are
queue-4.14/serial-core-mark-port-as-initialized-in-autoconfig.patch
This is a note to let you know that I've just added the patch titled
earlycon: add reg-offset to physical address before mapping
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:
earlycon-add-reg-offset-to-physical-address-before-mapping.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 1f66dd36bb18437397ea0d7882c52f7e3c476e15 Mon Sep 17 00:00:00 2001
From: Greentime Hu <green.hu(a)gmail.com>
Date: Tue, 13 Feb 2018 17:09:08 +0800
Subject: earlycon: add reg-offset to physical address before mapping
From: Greentime Hu <green.hu(a)gmail.com>
commit 1f66dd36bb18437397ea0d7882c52f7e3c476e15 upstream.
It will get the wrong virtual address because port->mapbase is not added
the correct reg-offset yet. We have to update it before earlycon_map()
is called
Signed-off-by: Greentime Hu <greentime(a)andestech.com>
Acked-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Peter Hurley <peter(a)hurleysoftware.com>
Cc: stable(a)vger.kernel.org
Fixes: 088da2a17619 ("of: earlycon: Initialize port fields from DT properties")
Acked-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/earlycon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -253,11 +253,12 @@ int __init of_setup_earlycon(const struc
}
port->mapbase = addr;
port->uartclk = BASE_BAUD * 16;
- port->membase = earlycon_map(port->mapbase, SZ_4K);
val = of_get_flat_dt_prop(node, "reg-offset", NULL);
if (val)
port->mapbase += be32_to_cpu(*val);
+ port->membase = earlycon_map(port->mapbase, SZ_4K);
+
val = of_get_flat_dt_prop(node, "reg-shift", NULL);
if (val)
port->regshift = be32_to_cpu(*val);
Patches currently in stable-queue which might be from green.hu(a)gmail.com are
queue-4.14/earlycon-add-reg-offset-to-physical-address-before-mapping.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
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:
serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.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 9f2068f35729948bde84d87a40d135015911345d Mon Sep 17 00:00:00 2001
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Date: Tue, 13 Feb 2018 15:04:46 +0100
Subject: serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
commit 9f2068f35729948bde84d87a40d135015911345d upstream.
Add PCI ids for two variants of Brainboxes UC-260 quad port
PCI serial cards.
Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -4701,6 +4701,17 @@ static const struct pci_device_id serial
PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */
pbn_b2_4_115200 },
/*
+ * BrainBoxes UC-260
+ */
+ { PCI_VENDOR_ID_INTASHIELD, 0x0D21,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ { PCI_VENDOR_ID_INTASHIELD, 0x0E34,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ /*
* Perle PCI-RAS cards
*/
{ PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9030,
Patches currently in stable-queue which might be from nikola.ciprich(a)linuxbox.cz are
queue-4.14/serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.patch
queue-4.14/serial-core-mark-port-as-initialized-in-autoconfig.patch
This is a note to let you know that I've just added the patch titled
ASoC: wm_adsp: For TLV controls only register TLV get/set
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:
asoc-wm_adsp-for-tlv-controls-only-register-tlv-get-set.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 d7789f5bcdb298c4a302db471b1b20f74a20de95 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf(a)opensource.cirrus.com>
Date: Wed, 28 Feb 2018 10:31:10 +0000
Subject: ASoC: wm_adsp: For TLV controls only register TLV get/set
From: Richard Fitzgerald <rf(a)opensource.cirrus.com>
commit d7789f5bcdb298c4a302db471b1b20f74a20de95 upstream.
Normal 512-byte get/set of a TLV isn't supported but we were
registering the normal get/set anyway and relying on omitting
the SNDRV_CTL_ELEM_ACCESS_[READ|WRITE] flags to prevent them
being called.
Trouble is if this gets broken in the core ALSA code - as it has
been since at least 4.14 - the standard get/set can be called
unexpectedly and corrupt memory.
There's no point providing functions that won't be called and
it's a trivial change. The benefit is that if the ALSA core gets
broken again we get a big fat immediate NULL dereference instead
of a memory corruption timebomb.
Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/wm_adsp.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -1204,12 +1204,14 @@ static int wmfw_add_ctl(struct wm_adsp *
kcontrol->put = wm_coeff_put_acked;
break;
default:
- kcontrol->get = wm_coeff_get;
- kcontrol->put = wm_coeff_put;
-
- ctl->bytes_ext.max = ctl->len;
- ctl->bytes_ext.get = wm_coeff_tlv_get;
- ctl->bytes_ext.put = wm_coeff_tlv_put;
+ if (kcontrol->access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK) {
+ ctl->bytes_ext.max = ctl->len;
+ ctl->bytes_ext.get = wm_coeff_tlv_get;
+ ctl->bytes_ext.put = wm_coeff_tlv_put;
+ } else {
+ kcontrol->get = wm_coeff_get;
+ kcontrol->put = wm_coeff_put;
+ }
break;
}
Patches currently in stable-queue which might be from rf(a)opensource.cirrus.com are
queue-4.14/asoc-wm_adsp-for-tlv-controls-only-register-tlv-get-set.patch
This is a note to let you know that I've just added the patch titled
dm mpath: fix passing integrity data
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dm-mpath-fix-passing-integrity-data.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 8c5c147339d2e201108169327b1f99aa6d57d2cd Mon Sep 17 00:00:00 2001
From: Steffen Maier <maier(a)linux.vnet.ibm.com>
Date: Wed, 14 Mar 2018 15:33:06 +0100
Subject: dm mpath: fix passing integrity data
From: Steffen Maier <maier(a)linux.vnet.ibm.com>
commit 8c5c147339d2e201108169327b1f99aa6d57d2cd upstream.
After v4.12 commit e2460f2a4bc7 ("dm: mark targets that pass integrity
data"), dm-multipath, e.g. on DIF+DIX SCSI disk paths, does not support
block integrity any more. So add it to the whitelist.
This is also a pre-requisite to use block integrity with other dm layer(s)
on top of multipath, such as kpartx partitions (dm-linear) or LVM.
Also, bump target version to reflect this fix.
Fixes: e2460f2a4bc7 ("dm: mark targets that pass integrity data")
Cc: <stable(a)vger.kernel.org> #4.12+
Bisected-by: Fedor Loshakov <loshakov(a)linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier(a)linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/dm-mpath.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -1941,8 +1941,9 @@ static int multipath_busy(struct dm_targ
*---------------------------------------------------------------*/
static struct target_type multipath_target = {
.name = "multipath",
- .version = {1, 12, 0},
- .features = DM_TARGET_SINGLETON | DM_TARGET_IMMUTABLE,
+ .version = {1, 13, 0},
+ .features = DM_TARGET_SINGLETON | DM_TARGET_IMMUTABLE |
+ DM_TARGET_PASSES_INTEGRITY,
.module = THIS_MODULE,
.ctr = multipath_ctr,
.dtr = multipath_dtr,
Patches currently in stable-queue which might be from maier(a)linux.vnet.ibm.com are
queue-4.14/dm-mpath-fix-passing-integrity-data.patch
This is a note to let you know that I've just added the patch titled
ASoC: sgtl5000: Fix suspend/resume
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:
asoc-sgtl5000-fix-suspend-resume.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 a8992973edbb2555e956b90f6fe97c4bc14d761d Mon Sep 17 00:00:00 2001
From: Fabio Estevam <fabio.estevam(a)nxp.com>
Date: Fri, 16 Feb 2018 11:58:54 -0200
Subject: ASoC: sgtl5000: Fix suspend/resume
From: Fabio Estevam <fabio.estevam(a)nxp.com>
commit a8992973edbb2555e956b90f6fe97c4bc14d761d upstream.
Commit 8419caa72702 ("ASoC: sgtl5000: Do not disable regulators in
SND_SOC_BIAS_OFF") causes the sgtl5000 to fail after a suspend/resume
sequence:
Playing WAVE '/media/a2002011001-e02.wav' : Signed 16 bit Little
Endian, Rate 44100 Hz, Stereo
aplay: pcm_write:2051: write error: Input/output error
The problem is caused by the fact that the aforementioned commit
dropped the cache handling, so re-introduce the register map
resync to fix the problem.
Suggested-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/sgtl5000.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -871,15 +871,26 @@ static int sgtl5000_pcm_hw_params(struct
static int sgtl5000_set_bias_level(struct snd_soc_codec *codec,
enum snd_soc_bias_level level)
{
+ struct sgtl5000_priv *sgtl = snd_soc_codec_get_drvdata(codec);
+ int ret;
+
switch (level) {
case SND_SOC_BIAS_ON:
case SND_SOC_BIAS_PREPARE:
case SND_SOC_BIAS_STANDBY:
+ regcache_cache_only(sgtl->regmap, false);
+ ret = regcache_sync(sgtl->regmap);
+ if (ret) {
+ regcache_cache_only(sgtl->regmap, true);
+ return ret;
+ }
+
snd_soc_update_bits(codec, SGTL5000_CHIP_ANA_POWER,
SGTL5000_REFTOP_POWERUP,
SGTL5000_REFTOP_POWERUP);
break;
case SND_SOC_BIAS_OFF:
+ regcache_cache_only(sgtl->regmap, true);
snd_soc_update_bits(codec, SGTL5000_CHIP_ANA_POWER,
SGTL5000_REFTOP_POWERUP, 0);
break;
Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are
queue-4.14/asoc-sgtl5000-fix-suspend-resume.patch
This is a note to let you know that I've just added the patch titled
ASoC: sun4i-i2s: Fix RX slot number of SUN8I
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:
asoc-sun4i-i2s-fix-rx-slot-number-of-sun8i.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 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: ASoC: sun4i-i2s: Fix RX slot number of SUN8I
From: Yong Deng <yong.deng(a)magewell.com>
commit 5a3386790a172cf738194e1574f631cd43c6140a upstream.
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
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sunxi/sun4i-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 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)
Patches currently in stable-queue which might be from yong.deng(a)magewell.com are
queue-4.14/asoc-sun4i-i2s-fix-rx-slot-number-of-sun8i.patch
This is a note to let you know that I've just added the patch titled
ASoC: rt5651: Fix regcache sync errors on resume
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:
asoc-rt5651-fix-regcache-sync-errors-on-resume.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 2d30e9494f1ea320aaaad0cff9ddd92c87eac355 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Sun, 18 Feb 2018 23:01:44 +0100
Subject: ASoC: rt5651: Fix regcache sync errors on resume
From: Hans de Goede <hdegoede(a)redhat.com>
commit 2d30e9494f1ea320aaaad0cff9ddd92c87eac355 upstream.
The ALC5651 does not like multi-write accesses, avoid them. This fixes:
rt5651 i2c-10EC5651:00: Unable to sync registers 0x27-0x28. -121
Errors on resume (and all registers after the registers in the error not
being synced).
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/rt5651.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -1694,6 +1694,7 @@ static const struct regmap_config rt5651
.num_reg_defaults = ARRAY_SIZE(rt5651_reg),
.ranges = rt5651_ranges,
.num_ranges = ARRAY_SIZE(rt5651_ranges),
+ .use_single_rw = true,
};
#if defined(CONFIG_OF)
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/asoc-rt5651-fix-regcache-sync-errors-on-resume.patch
queue-4.14/uas-fix-comparison-for-error-code.patch
This is a note to let you know that I've just added the patch titled
USB: usbmon: remove assignment from IS_ERR argument
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-usbmon-remove-assignment-from-is_err-argument.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 46c236dc7d1212d7417e6fb0317f91c44c719322 Mon Sep 17 00:00:00 2001
From: Julia Lawall <Julia.Lawall(a)lip6.fr>
Date: Sat, 26 Dec 2015 22:57:44 +0100
Subject: USB: usbmon: remove assignment from IS_ERR argument
From: Julia Lawall <Julia.Lawall(a)lip6.fr>
commit 46c236dc7d1212d7417e6fb0317f91c44c719322 upstream.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e1,e2;
statement S1,S2;
@@
+e1 = e2;
if (IS_ERR(
e1
- = e2
)) S1 else S2
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall(a)lip6.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/mon/mon_text.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/usb/mon/mon_text.c
+++ b/drivers/usb/mon/mon_text.c
@@ -386,7 +386,8 @@ static ssize_t mon_text_read_t(struct fi
struct mon_event_text *ep;
struct mon_text_ptr ptr;
- if (IS_ERR(ep = mon_text_read_wait(rp, file)))
+ ep = mon_text_read_wait(rp, file);
+ if (IS_ERR(ep))
return PTR_ERR(ep);
mutex_lock(&rp->printf_lock);
ptr.cnt = 0;
@@ -413,7 +414,8 @@ static ssize_t mon_text_read_u(struct fi
struct mon_event_text *ep;
struct mon_text_ptr ptr;
- if (IS_ERR(ep = mon_text_read_wait(rp, file)))
+ ep = mon_text_read_wait(rp, file);
+ if (IS_ERR(ep))
return PTR_ERR(ep);
mutex_lock(&rp->printf_lock);
ptr.cnt = 0;
Patches currently in stable-queue which might be from Julia.Lawall(a)lip6.fr are
queue-3.18/usb-usbmon-remove-assignment-from-is_err-argument.patch
This is a note to let you know that I've just added the patch titled
usb: quirks: add control message delay for 1b1c:1b20
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-quirks-add-control-message-delay-for-1b1c-1b20.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 cb88a0588717ba6c756cb5972d75766b273a6817 Mon Sep 17 00:00:00 2001
From: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
Date: Tue, 6 Mar 2018 09:38:49 +0100
Subject: usb: quirks: add control message delay for 1b1c:1b20
From: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
commit cb88a0588717ba6c756cb5972d75766b273a6817 upstream.
Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.
Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.
Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):
[ 29.103520] usb 1-8: string descriptor 0 read error: -110
[ 34.363097] usb 1-8: can't set config #1, error -110
Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:
[ 35.400533] usbhid 1-8:1.0: can't add hid device: -110
[ 35.401014] usbhid: probe of 1-8:1.0 failed with error -110
The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.
Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().
The overall boot time seems not to be influenced by these additional
delays, even on fast machines and lightweight distributions.
Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard")
Cc: stable(a)vger.kernel.org
Signed-off-by: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/message.c | 4 ++++
drivers/usb/core/quirks.c | 3 ++-
include/linux/usb/quirks.h | 3 +++
3 files changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -147,6 +147,10 @@ int usb_control_msg(struct usb_device *d
ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout);
+ /* Linger a bit, prior to the next control message. */
+ if (dev->quirks & USB_QUIRK_DELAY_CTRL_MSG)
+ msleep(200);
+
kfree(dr);
return ret;
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -219,7 +219,8 @@ static const struct usb_device_id usb_qu
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
/* Corsair Strafe RGB */
- { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+ { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT |
+ USB_QUIRK_DELAY_CTRL_MSG },
/* Corsair K70 LUX */
{ USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT },
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -56,4 +56,7 @@
*/
#define USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL BIT(11)
+/* Device needs a pause after every control message. */
+#define USB_QUIRK_DELAY_CTRL_MSG BIT(13)
+
#endif /* __LINUX_USB_QUIRKS_H */
Patches currently in stable-queue which might be from danilokrummrich(a)dk-develop.de are
queue-3.18/usb-quirks-add-control-message-delay-for-1b1c-1b20.patch
This is a note to let you know that I've just added the patch titled
uas: fix comparison for error code
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:
uas-fix-comparison-for-error-code.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 9a513c905bb95bef79d96feb08621c1ec8d8c4bb Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum(a)suse.com>
Date: Tue, 6 Mar 2018 15:04:24 +0100
Subject: uas: fix comparison for error code
From: Oliver Neukum <oneukum(a)suse.com>
commit 9a513c905bb95bef79d96feb08621c1ec8d8c4bb upstream.
A typo broke the comparison.
Fixes: cbeef22fd611 ("usb: uas: unconditionally bring back host after reset")
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
CC: stable(a)kernel.org
Acked-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/uas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1067,7 +1067,7 @@ static int uas_post_reset(struct usb_int
return 0;
err = uas_configure_endpoints(devinfo);
- if (err && err != ENODEV)
+ if (err && err != -ENODEV)
shost_printk(KERN_ERR, shost,
"%s: alloc streams error %d after reset",
__func__, err);
Patches currently in stable-queue which might be from oneukum(a)suse.com are
queue-3.18/uas-fix-comparison-for-error-code.patch
This is a note to let you know that I've just added the patch titled
tty/serial: atmel: add new version check for usart
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:
tty-serial-atmel-add-new-version-check-for-usart.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 fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 Mon Sep 17 00:00:00 2001
From: Jonas Danielsson <jonas(a)orbital-systems.com>
Date: Mon, 29 Jan 2018 12:39:15 +0100
Subject: tty/serial: atmel: add new version check for usart
From: Jonas Danielsson <jonas(a)orbital-systems.com>
commit fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 upstream.
On our at91sam9260 based board the usart0 and usart1 ports report
their versions (ATMEL_US_VERSION) as 0x10302. This version is not
included in the current checks in the driver.
Signed-off-by: Jonas Danielsson <jonas(a)orbital-systems.com>
Acked-by: Richard Genoud <richard.genoud(a)gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/atmel_serial.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1643,6 +1643,7 @@ static void atmel_get_ip_name(struct uar
switch (version) {
case 0x302:
case 0x10213:
+ case 0x10302:
dev_dbg(port->dev, "This version is usart\n");
atmel_port->is_usart = true;
break;
Patches currently in stable-queue which might be from jonas(a)orbital-systems.com are
queue-3.18/tty-serial-atmel-add-new-version-check-for-usart.patch
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix lockdep issue during llseek
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:
staging-android-ashmem-fix-lockdep-issue-during-llseek.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 cb57469c9573f6018cd1302953dd45d6e05aba7b Mon Sep 17 00:00:00 2001
From: Joel Fernandes <joelaf(a)google.com>
Date: Fri, 16 Feb 2018 11:02:01 -0800
Subject: staging: android: ashmem: Fix lockdep issue during llseek
From: Joel Fernandes <joelaf(a)google.com>
commit cb57469c9573f6018cd1302953dd45d6e05aba7b upstream.
ashmem_mutex create a chain of dependencies like so:
(1)
mmap syscall ->
mmap_sem -> (acquired)
ashmem_mmap
ashmem_mutex (try to acquire)
(block)
(2)
llseek syscall ->
ashmem_llseek ->
ashmem_mutex -> (acquired)
inode_lock ->
inode->i_rwsem (try to acquire)
(block)
(3)
getdents ->
iterate_dir ->
inode_lock ->
inode->i_rwsem (acquired)
copy_to_user ->
mmap_sem (try to acquire)
There is a lock ordering created between mmap_sem and inode->i_rwsem
causing a lockdep splat [2] during a syzcaller test, this patch fixes
the issue by unlocking the mutex earlier. Functionally that's Ok since
we don't need to protect vfs_llseek.
[1] https://patchwork.kernel.org/patch/10185031/
[2] https://lkml.org/lkml/2018/1/10/48
Acked-by: Todd Kjos <tkjos(a)google.com>
Cc: Arve Hjonnevag <arve(a)android.com>
Cc: stable(a)vger.kernel.org
Reported-by: syzbot+8ec30bb7bf1a981a2012(a)syzkaller.appspotmail.com
Signed-off-by: Joel Fernandes <joelaf(a)google.com>
Acked-by: Greg Hackmann <ghackmann(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -330,24 +330,23 @@ static loff_t ashmem_llseek(struct file
mutex_lock(&ashmem_mutex);
if (asma->size == 0) {
- ret = -EINVAL;
- goto out;
+ mutex_unlock(&ashmem_mutex);
+ return -EINVAL;
}
if (!asma->file) {
- ret = -EBADF;
- goto out;
+ mutex_unlock(&ashmem_mutex);
+ return -EBADF;
}
+ mutex_unlock(&ashmem_mutex);
+
ret = vfs_llseek(asma->file, offset, origin);
if (ret < 0)
- goto out;
+ return ret;
/** Copy f_pos from backing file, since f_ops->llseek() sets it */
file->f_pos = asma->file->f_pos;
-
-out:
- mutex_unlock(&ashmem_mutex);
return ret;
}
Patches currently in stable-queue which might be from joelaf(a)google.com are
queue-3.18/staging-android-ashmem-fix-lockdep-issue-during-llseek.patch
This is a note to let you know that I've just added the patch titled
serial: sh-sci: prevent lockup on full TTY buffers
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:
serial-sh-sci-prevent-lockup-on-full-tty-buffers.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 7842055bfce4bf0170d0f61df8b2add8399697be Mon Sep 17 00:00:00 2001
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Date: Thu, 15 Feb 2018 13:02:27 +0100
Subject: serial: sh-sci: prevent lockup on full TTY buffers
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream.
When the TTY buffers fill up to the configured maximum, a system lockup
occurs:
[ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
[ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
[ 598.838755] Task dump for CPU 0:
[ 598.841977] swapper/0 R running task 0 0 0 0x00000022
[ 598.849023] Call trace:
[ 598.851476] __switch_to+0x98/0xb0
[ 598.854870] (null)
This can be prevented by doing a dummy read of the RX data register.
This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
as well.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Cc: stable <stable(a)vger.kernel.org>
Tested-by: Nguyen Viet Dung <dung.nguyen.aj(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -736,6 +736,8 @@ static void sci_receive_chars(struct uar
/* Tell the rest of the system the news. New characters! */
tty_flip_buffer_push(tport);
} else {
+ /* TTY buffers full; read from RX reg to prevent lockup */
+ serial_port_in(port, SCxRDR);
serial_port_in(port, SCxSR); /* dummy read */
serial_port_out(port, SCxSR, SCxSR_RDxF_CLEAR(port));
}
Patches currently in stable-queue which might be from ulrich.hecht+renesas(a)gmail.com are
queue-3.18/serial-sh-sci-prevent-lockup-on-full-tty-buffers.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
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:
serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.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 9f2068f35729948bde84d87a40d135015911345d Mon Sep 17 00:00:00 2001
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Date: Tue, 13 Feb 2018 15:04:46 +0100
Subject: serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
commit 9f2068f35729948bde84d87a40d135015911345d upstream.
Add PCI ids for two variants of Brainboxes UC-260 quad port
PCI serial cards.
Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -4982,6 +4982,17 @@ static struct pci_device_id serial_pci_t
PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */
pbn_b2_4_115200 },
/*
+ * BrainBoxes UC-260
+ */
+ { PCI_VENDOR_ID_INTASHIELD, 0x0D21,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ { PCI_VENDOR_ID_INTASHIELD, 0x0E34,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ /*
* Perle PCI-RAS cards
*/
{ PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9030,
Patches currently in stable-queue which might be from nikola.ciprich(a)linuxbox.cz are
queue-3.18/serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.patch
This is a note to let you know that I've just added the patch titled
x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
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:
x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.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 b21ebf2fb4cde1618915a97cc773e287ff49173e Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools(a)gmail.com>
Date: Wed, 7 Feb 2018 14:20:09 -0800
Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
From: H.J. Lu <hjl.tools(a)gmail.com>
commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream.
On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared
objects must use PIC PLT. To use PIC PLT, you need to load
_GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on
x86-64 since x86-64 uses PC-relative PLT.
On x86-64, for 32-bit PC-relative branches, we can generate PLT32
relocation, instead of PC32 relocation, which can also be used as
a marker for 32-bit PC-relative branches. Linker can always reduce
PLT32 relocation to PC32 if function is defined locally. Local
functions should use PC32 relocation. As far as Linux kernel is
concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32
since Linux kernel doesn't use PLT.
R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in
binutils master branch which will become binutils 2.31.
[ hjl is working on having better documentation on this all, but a few
more notes from him:
"PLT32 relocation is used as marker for PC-relative branches. Because
of EBX, it looks odd to generate PLT32 relocation on i386 when EBX
doesn't have GOT.
As for symbol resolution, PLT32 and PC32 relocations are almost
interchangeable. But when linker sees PLT32 relocation against a
protected symbol, it can resolved locally at link-time since it is
used on a branch instruction. Linker can't do that for PC32
relocation"
but for the kernel use, the two are basically the same, and this
commit gets things building and working with the current binutils
master - Linus ]
Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/machine_kexec_64.c | 1 +
arch/x86/kernel/module.c | 1 +
arch/x86/tools/relocs.c | 3 +++
3 files changed, 5 insertions(+)
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -524,6 +524,7 @@ int arch_kexec_apply_relocations_add(con
goto overflow;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
value -= (u64)address;
*(u32 *)location = value;
break;
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -190,6 +190,7 @@ int apply_relocate_add(Elf64_Shdr *sechd
goto overflow;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
if (*(u32 *)loc != 0)
goto invalid_relocation;
val -= (u64)loc;
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -769,9 +769,12 @@ static int do_reloc64(struct section *se
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
/*
* PC relative relocations don't need to be adjusted unless
* referencing a percpu symbol.
+ *
+ * NB: R_X86_64_PLT32 can be treated as R_X86_64_PC32.
*/
if (is_percpu_sym(sym, symname))
add_reloc(&relocs32neg, offset);
Patches currently in stable-queue which might be from hjl.tools(a)gmail.com are
queue-4.9/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch
This is a note to let you know that I've just added the patch titled
x86/module: Detect and skip invalid relocations
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:
x86-module-detect-and-skip-invalid-relocations.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 eda9cec4c9a12208a6f69fbe68f72a6311d50032 Mon Sep 17 00:00:00 2001
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
Date: Fri, 3 Nov 2017 07:58:54 -0500
Subject: x86/module: Detect and skip invalid relocations
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
commit eda9cec4c9a12208a6f69fbe68f72a6311d50032 upstream.
There have been some cases where external tooling (e.g., kpatch-build)
creates a corrupt relocation which targets the wrong address. This is a
silent failure which can corrupt memory in unexpected places.
On x86, the bytes of data being overwritten by relocations are always
initialized to zero beforehand. Use that knowledge to add sanity checks
to detect such cases before they corrupt memory.
Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: jeyu(a)kernel.org
Cc: live-patching(a)vger.kernel.org
Link: http://lkml.kernel.org/r/37450d6c6225e54db107fba447ce9e56e5f758e9.150971355…
[ Restructured the messages, as it's unclear whether the relocation or the target is corrupted. ]
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/module.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -171,19 +171,27 @@ int apply_relocate_add(Elf64_Shdr *sechd
case R_X86_64_NONE:
break;
case R_X86_64_64:
+ if (*(u64 *)loc != 0)
+ goto invalid_relocation;
*(u64 *)loc = val;
break;
case R_X86_64_32:
+ if (*(u32 *)loc != 0)
+ goto invalid_relocation;
*(u32 *)loc = val;
if (val != *(u32 *)loc)
goto overflow;
break;
case R_X86_64_32S:
+ if (*(s32 *)loc != 0)
+ goto invalid_relocation;
*(s32 *)loc = val;
if ((s64)val != *(s32 *)loc)
goto overflow;
break;
case R_X86_64_PC32:
+ if (*(u32 *)loc != 0)
+ goto invalid_relocation;
val -= (u64)loc;
*(u32 *)loc = val;
#if 0
@@ -199,6 +207,11 @@ int apply_relocate_add(Elf64_Shdr *sechd
}
return 0;
+invalid_relocation:
+ pr_err("x86/modules: Skipping invalid relocation target, existing value is nonzero for type %d, loc %p, val %Lx\n",
+ (int)ELF64_R_TYPE(rel[i].r_info), loc, val);
+ return -ENOEXEC;
+
overflow:
pr_err("overflow in relocation type %d val %Lx\n",
(int)ELF64_R_TYPE(rel[i].r_info), val);
Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are
queue-4.9/x86-boot-objtool-annotate-indirect-jump-in-secondary_startup_64.patch
queue-4.9/x86-module-detect-and-skip-invalid-relocations.patch
queue-4.9/nospec-include-asm-barrier.h-dependency.patch
queue-4.9/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool.patch
queue-4.9/x86-paravirt-objtool-annotate-indirect-calls.patch
queue-4.9/nospec-kill-array_index_nospec_mask_check.patch
This is a note to let you know that I've just added the patch titled
x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
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-treat-r_x86_64_plt32-as-r_x86_64_pc32.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 b21ebf2fb4cde1618915a97cc773e287ff49173e Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools(a)gmail.com>
Date: Wed, 7 Feb 2018 14:20:09 -0800
Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
From: H.J. Lu <hjl.tools(a)gmail.com>
commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream.
On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared
objects must use PIC PLT. To use PIC PLT, you need to load
_GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on
x86-64 since x86-64 uses PC-relative PLT.
On x86-64, for 32-bit PC-relative branches, we can generate PLT32
relocation, instead of PC32 relocation, which can also be used as
a marker for 32-bit PC-relative branches. Linker can always reduce
PLT32 relocation to PC32 if function is defined locally. Local
functions should use PC32 relocation. As far as Linux kernel is
concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32
since Linux kernel doesn't use PLT.
R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in
binutils master branch which will become binutils 2.31.
[ hjl is working on having better documentation on this all, but a few
more notes from him:
"PLT32 relocation is used as marker for PC-relative branches. Because
of EBX, it looks odd to generate PLT32 relocation on i386 when EBX
doesn't have GOT.
As for symbol resolution, PLT32 and PC32 relocations are almost
interchangeable. But when linker sees PLT32 relocation against a
protected symbol, it can resolved locally at link-time since it is
used on a branch instruction. Linker can't do that for PC32
relocation"
but for the kernel use, the two are basically the same, and this
commit gets things building and working with the current binutils
master - Linus ]
Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/machine_kexec_64.c | 1 +
arch/x86/kernel/module.c | 1 +
arch/x86/tools/relocs.c | 3 +++
3 files changed, 5 insertions(+)
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -519,6 +519,7 @@ int arch_kexec_apply_relocations_add(con
goto overflow;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
value -= (u64)address;
*(u32 *)location = value;
break;
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -189,6 +189,7 @@ int apply_relocate_add(Elf64_Shdr *sechd
goto overflow;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
if (*(u32 *)loc != 0)
goto invalid_relocation;
val -= (u64)loc;
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -769,9 +769,12 @@ static int do_reloc64(struct section *se
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
/*
* PC relative relocations don't need to be adjusted unless
* referencing a percpu symbol.
+ *
+ * NB: R_X86_64_PLT32 can be treated as R_X86_64_PC32.
*/
if (is_percpu_sym(sym, symname))
add_reloc(&relocs32neg, offset);
Patches currently in stable-queue which might be from hjl.tools(a)gmail.com are
queue-4.4/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch
This is a note to let you know that I've just added the patch titled
x86/module: Detect and skip invalid relocations
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-module-detect-and-skip-invalid-relocations.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 eda9cec4c9a12208a6f69fbe68f72a6311d50032 Mon Sep 17 00:00:00 2001
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
Date: Fri, 3 Nov 2017 07:58:54 -0500
Subject: x86/module: Detect and skip invalid relocations
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
commit eda9cec4c9a12208a6f69fbe68f72a6311d50032 upstream.
There have been some cases where external tooling (e.g., kpatch-build)
creates a corrupt relocation which targets the wrong address. This is a
silent failure which can corrupt memory in unexpected places.
On x86, the bytes of data being overwritten by relocations are always
initialized to zero beforehand. Use that knowledge to add sanity checks
to detect such cases before they corrupt memory.
Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: jeyu(a)kernel.org
Cc: live-patching(a)vger.kernel.org
Link: http://lkml.kernel.org/r/37450d6c6225e54db107fba447ce9e56e5f758e9.150971355…
[ Restructured the messages, as it's unclear whether the relocation or the target is corrupted. ]
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/module.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -170,19 +170,27 @@ int apply_relocate_add(Elf64_Shdr *sechd
case R_X86_64_NONE:
break;
case R_X86_64_64:
+ if (*(u64 *)loc != 0)
+ goto invalid_relocation;
*(u64 *)loc = val;
break;
case R_X86_64_32:
+ if (*(u32 *)loc != 0)
+ goto invalid_relocation;
*(u32 *)loc = val;
if (val != *(u32 *)loc)
goto overflow;
break;
case R_X86_64_32S:
+ if (*(s32 *)loc != 0)
+ goto invalid_relocation;
*(s32 *)loc = val;
if ((s64)val != *(s32 *)loc)
goto overflow;
break;
case R_X86_64_PC32:
+ if (*(u32 *)loc != 0)
+ goto invalid_relocation;
val -= (u64)loc;
*(u32 *)loc = val;
#if 0
@@ -198,6 +206,11 @@ int apply_relocate_add(Elf64_Shdr *sechd
}
return 0;
+invalid_relocation:
+ pr_err("x86/modules: Skipping invalid relocation target, existing value is nonzero for type %d, loc %p, val %Lx\n",
+ (int)ELF64_R_TYPE(rel[i].r_info), loc, val);
+ return -ENOEXEC;
+
overflow:
pr_err("overflow in relocation type %d val %Lx\n",
(int)ELF64_R_TYPE(rel[i].r_info), val);
Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are
queue-4.4/x86-module-detect-and-skip-invalid-relocations.patch
queue-4.4/nospec-include-asm-barrier.h-dependency.patch
This is a note to let you know that I've just added the patch titled
x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
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:
x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.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 b21ebf2fb4cde1618915a97cc773e287ff49173e Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools(a)gmail.com>
Date: Wed, 7 Feb 2018 14:20:09 -0800
Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
From: H.J. Lu <hjl.tools(a)gmail.com>
commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream.
On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared
objects must use PIC PLT. To use PIC PLT, you need to load
_GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on
x86-64 since x86-64 uses PC-relative PLT.
On x86-64, for 32-bit PC-relative branches, we can generate PLT32
relocation, instead of PC32 relocation, which can also be used as
a marker for 32-bit PC-relative branches. Linker can always reduce
PLT32 relocation to PC32 if function is defined locally. Local
functions should use PC32 relocation. As far as Linux kernel is
concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32
since Linux kernel doesn't use PLT.
R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in
binutils master branch which will become binutils 2.31.
[ hjl is working on having better documentation on this all, but a few
more notes from him:
"PLT32 relocation is used as marker for PC-relative branches. Because
of EBX, it looks odd to generate PLT32 relocation on i386 when EBX
doesn't have GOT.
As for symbol resolution, PLT32 and PC32 relocations are almost
interchangeable. But when linker sees PLT32 relocation against a
protected symbol, it can resolved locally at link-time since it is
used on a branch instruction. Linker can't do that for PC32
relocation"
but for the kernel use, the two are basically the same, and this
commit gets things building and working with the current binutils
master - Linus ]
Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/machine_kexec_64.c | 1 +
arch/x86/kernel/module.c | 1 +
arch/x86/tools/relocs.c | 3 +++
3 files changed, 5 insertions(+)
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -542,6 +542,7 @@ int arch_kexec_apply_relocations_add(con
goto overflow;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
value -= (u64)address;
*(u32 *)location = value;
break;
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -191,6 +191,7 @@ int apply_relocate_add(Elf64_Shdr *sechd
goto overflow;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
if (*(u32 *)loc != 0)
goto invalid_relocation;
val -= (u64)loc;
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -770,9 +770,12 @@ static int do_reloc64(struct section *se
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
/*
* PC relative relocations don't need to be adjusted unless
* referencing a percpu symbol.
+ *
+ * NB: R_X86_64_PLT32 can be treated as R_X86_64_PC32.
*/
if (is_percpu_sym(sym, symname))
add_reloc(&relocs32neg, offset);
Patches currently in stable-queue which might be from hjl.tools(a)gmail.com are
queue-4.15/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch
This is a note to let you know that I've just added the patch titled
x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
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:
x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.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 b21ebf2fb4cde1618915a97cc773e287ff49173e Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools(a)gmail.com>
Date: Wed, 7 Feb 2018 14:20:09 -0800
Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
From: H.J. Lu <hjl.tools(a)gmail.com>
commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream.
On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared
objects must use PIC PLT. To use PIC PLT, you need to load
_GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on
x86-64 since x86-64 uses PC-relative PLT.
On x86-64, for 32-bit PC-relative branches, we can generate PLT32
relocation, instead of PC32 relocation, which can also be used as
a marker for 32-bit PC-relative branches. Linker can always reduce
PLT32 relocation to PC32 if function is defined locally. Local
functions should use PC32 relocation. As far as Linux kernel is
concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32
since Linux kernel doesn't use PLT.
R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in
binutils master branch which will become binutils 2.31.
[ hjl is working on having better documentation on this all, but a few
more notes from him:
"PLT32 relocation is used as marker for PC-relative branches. Because
of EBX, it looks odd to generate PLT32 relocation on i386 when EBX
doesn't have GOT.
As for symbol resolution, PLT32 and PC32 relocations are almost
interchangeable. But when linker sees PLT32 relocation against a
protected symbol, it can resolved locally at link-time since it is
used on a branch instruction. Linker can't do that for PC32
relocation"
but for the kernel use, the two are basically the same, and this
commit gets things building and working with the current binutils
master - Linus ]
Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/machine_kexec_64.c | 1 +
arch/x86/kernel/module.c | 1 +
arch/x86/tools/relocs.c | 3 +++
3 files changed, 5 insertions(+)
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -542,6 +542,7 @@ int arch_kexec_apply_relocations_add(con
goto overflow;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
value -= (u64)address;
*(u32 *)location = value;
break;
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -191,6 +191,7 @@ int apply_relocate_add(Elf64_Shdr *sechd
goto overflow;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
if (*(u32 *)loc != 0)
goto invalid_relocation;
val -= (u64)loc;
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -770,9 +770,12 @@ static int do_reloc64(struct section *se
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
/*
* PC relative relocations don't need to be adjusted unless
* referencing a percpu symbol.
+ *
+ * NB: R_X86_64_PLT32 can be treated as R_X86_64_PC32.
*/
if (is_percpu_sym(sym, symname))
add_reloc(&relocs32neg, offset);
Patches currently in stable-queue which might be from hjl.tools(a)gmail.com are
queue-4.14/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch
This is a note to let you know that I've just added the patch titled
x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
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-treat-r_x86_64_plt32-as-r_x86_64_pc32.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 b21ebf2fb4cde1618915a97cc773e287ff49173e Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools(a)gmail.com>
Date: Wed, 7 Feb 2018 14:20:09 -0800
Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
From: H.J. Lu <hjl.tools(a)gmail.com>
commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream.
On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared
objects must use PIC PLT. To use PIC PLT, you need to load
_GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on
x86-64 since x86-64 uses PC-relative PLT.
On x86-64, for 32-bit PC-relative branches, we can generate PLT32
relocation, instead of PC32 relocation, which can also be used as
a marker for 32-bit PC-relative branches. Linker can always reduce
PLT32 relocation to PC32 if function is defined locally. Local
functions should use PC32 relocation. As far as Linux kernel is
concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32
since Linux kernel doesn't use PLT.
R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in
binutils master branch which will become binutils 2.31.
[ hjl is working on having better documentation on this all, but a few
more notes from him:
"PLT32 relocation is used as marker for PC-relative branches. Because
of EBX, it looks odd to generate PLT32 relocation on i386 when EBX
doesn't have GOT.
As for symbol resolution, PLT32 and PC32 relocations are almost
interchangeable. But when linker sees PLT32 relocation against a
protected symbol, it can resolved locally at link-time since it is
used on a branch instruction. Linker can't do that for PC32
relocation"
but for the kernel use, the two are basically the same, and this
commit gets things building and working with the current binutils
master - Linus ]
Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/machine_kexec_64.c | 1 +
arch/x86/kernel/module.c | 1 +
arch/x86/tools/relocs.c | 3 +++
3 files changed, 5 insertions(+)
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -516,6 +516,7 @@ int arch_kexec_apply_relocations_add(con
goto overflow;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
value -= (u64)address;
*(u32 *)location = value;
break;
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -186,6 +186,7 @@ int apply_relocate_add(Elf64_Shdr *sechd
goto overflow;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
if (*(u32 *)loc != 0)
goto invalid_relocation;
val -= (u64)loc;
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -769,9 +769,12 @@ static int do_reloc64(struct section *se
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
/*
* PC relative relocations don't need to be adjusted unless
* referencing a percpu symbol.
+ *
+ * NB: R_X86_64_PLT32 can be treated as R_X86_64_PC32.
*/
if (is_percpu_sym(sym, symname))
add_reloc(&relocs32neg, offset);
Patches currently in stable-queue which might be from hjl.tools(a)gmail.com are
queue-3.18/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch
This is a note to let you know that I've just added the patch titled
x86/module: Detect and skip invalid relocations
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-module-detect-and-skip-invalid-relocations.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 eda9cec4c9a12208a6f69fbe68f72a6311d50032 Mon Sep 17 00:00:00 2001
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
Date: Fri, 3 Nov 2017 07:58:54 -0500
Subject: x86/module: Detect and skip invalid relocations
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
commit eda9cec4c9a12208a6f69fbe68f72a6311d50032 upstream.
There have been some cases where external tooling (e.g., kpatch-build)
creates a corrupt relocation which targets the wrong address. This is a
silent failure which can corrupt memory in unexpected places.
On x86, the bytes of data being overwritten by relocations are always
initialized to zero beforehand. Use that knowledge to add sanity checks
to detect such cases before they corrupt memory.
Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: jeyu(a)kernel.org
Cc: live-patching(a)vger.kernel.org
Link: http://lkml.kernel.org/r/37450d6c6225e54db107fba447ce9e56e5f758e9.150971355…
[ Restructured the messages, as it's unclear whether the relocation or the target is corrupted. ]
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/module.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -167,19 +167,27 @@ int apply_relocate_add(Elf64_Shdr *sechd
case R_X86_64_NONE:
break;
case R_X86_64_64:
+ if (*(u64 *)loc != 0)
+ goto invalid_relocation;
*(u64 *)loc = val;
break;
case R_X86_64_32:
+ if (*(u32 *)loc != 0)
+ goto invalid_relocation;
*(u32 *)loc = val;
if (val != *(u32 *)loc)
goto overflow;
break;
case R_X86_64_32S:
+ if (*(s32 *)loc != 0)
+ goto invalid_relocation;
*(s32 *)loc = val;
if ((s64)val != *(s32 *)loc)
goto overflow;
break;
case R_X86_64_PC32:
+ if (*(u32 *)loc != 0)
+ goto invalid_relocation;
val -= (u64)loc;
*(u32 *)loc = val;
#if 0
@@ -195,6 +203,11 @@ int apply_relocate_add(Elf64_Shdr *sechd
}
return 0;
+invalid_relocation:
+ pr_err("x86/modules: Skipping invalid relocation target, existing value is nonzero for type %d, loc %p, val %Lx\n",
+ (int)ELF64_R_TYPE(rel[i].r_info), loc, val);
+ return -ENOEXEC;
+
overflow:
pr_err("overflow in relocation type %d val %Lx\n",
(int)ELF64_R_TYPE(rel[i].r_info), val);
Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are
queue-3.18/x86-module-detect-and-skip-invalid-relocations.patch
Hi Greg,
The below patch recently landed in Linus' tree:
commit b21ebf2fb4cde1618915a97cc773e287ff49173e
Author: H.J. Lu <hjl.tools(a)gmail.com>
Date: Wed Feb 7 14:20:09 2018 -0800
x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared
objects must use PIC PLT. To use PIC PLT, you need to load
_GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on
x86-64 since x86-64 uses PC-relative PLT.
On x86-64, for 32-bit PC-relative branches, we can generate PLT32
relocation, instead of PC32 relocation, which can also be used as
a marker for 32-bit PC-relative branches. Linker can always reduce
PLT32 relocation to PC32 if function is defined locally. Local
functions should use PC32 relocation. As far as Linux kernel is
concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32
since Linux kernel doesn't use PLT.
R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in
binutils master branch which will become binutils 2.31.
[ hjl is working on having better documentation on this all, but a few
more notes from him:
"PLT32 relocation is used as marker for PC-relative branches. Because
of EBX, it looks odd to generate PLT32 relocation on i386 when EBX
doesn't have GOT.
As for symbol resolution, PLT32 and PC32 relocations are almost
interchangeable. But when linker sees PLT32 relocation against a
protected symbol, it can resolved locally at link-time since it is
used on a branch instruction. Linker can't do that for PC32
relocation"
but for the kernel use, the two are basically the same, and this
commit gets things building and working with the current binutils
master - Linus ]
Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
The commit message mentions that "R_X86_64_PLT32 for 32-bit
PC-relative branches has been enabled in binutils master branch which
will become binutils 2.31."
This probably means that builds of older kernels could fail with
binutils >= 2.31 and that the patch should be included in stable.
FYI: for pre-v4.14 kernel you might also want to include the below
patch. It isn't strictly needed, but is trivial and including it
avoids a conflict.
commit eda9cec4c9a12208a6f69fbe68f72a6311d50032
Author: Josh Poimboeuf <jpoimboe(a)redhat.com>
Date: Fri Nov 3 07:58:54 2017 -0500
x86/module: Detect and skip invalid relocations
Thanks
Matthias
On 03/13/2018 02:27 PM, Pavel Machek wrote:
> Hi!
>
>>>> At least 7b6af2c531 ("leds: core: Fix regression caused by commit
>>>> 2b83ff96f51d") is missing, causing visible regressions (LEDs not working at
>>>> all) on some OpenWrt devices. This was fixed in 4.4.121 by reverting the
>>>> offending commit, but if I followed the discussion correctly, 4.9 should
>>>> get the follow-up commit 7b6af2c531 instead (like 4.14 already did).
>>>>
>>>> Jacek's mail I replied to mentions that eb1610b4c273 ("led: core: Fix
>>>> blink_brightness setting race") should be included in 4.9 as well, but I
>>>> don't know the impact of the issue it fixes.
>>>
>>> It doesn't fix any reported issue, but is just an improvement
>>> aiming at preventing potential races while changing blink brightness.
>>>
>>> After taking closer look it turns out that for the patches in question
>>> to apply cleanly we need in 4.9 also a patch which introduces atomic
>>> bit fields for blink flags.
>>>
>>> Effectively, here is the list of patches required in 4.9 stable:
>>>
>>> Revert "led: core: Fix brightness setting when setting delay_off=0"
>>>
>>> followed by:
>>>
>>> a9c6ce57ec ("led: core: Use atomic bit-field for the blink-flags")
>>> eb1610b4c2 ("led: core: Fix blink_brightness setting race")
>>> 2b83ff96f5 ("led: core: Fix brightness setting when setting delay_off=0")
>>> 7b6af2c531 ("leds: core: Fix regression caused by commit 2b83ff96f51d")
>>
>> Odd, I just got another report that the 4.9.87 release fixed some
>> reported LED issues, so why do I need all of these?
Because 2b83ff96f5 introduces another bug, fixed in 7b6af2c531.
7b6af2c531 in turn uses atomic blink flags introduced in a9c6ce57ec.
eb1610b4c2 fixes theoretical races, actually we can do without it
in stable.
In order to avoid applying patch a9c6ce57ec, we could come up with the
below change which does exactly what 7b6af2c531 intended, but without
atomic blink flags, which are irrelevant for this bug.
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 3bce448..454ed4d 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -188,6 +188,7 @@ void led_blink_set(struct led_classdev *led_cdev,
{
del_timer_sync(&led_cdev->blink_timer);
+ led_cdev->flags &= ~LED_BLINK_SW;
led_cdev->flags &= ~LED_BLINK_ONESHOT;
led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP;
I can submit it to stable if it is preferred.
In every case tha patch 2b83ff96f5 needs to be reverted beforehand,
since otherwise none of the discussed patches will apply cleanly
(besides the aforementioned reasoning it has a truncated commit
message).
>> Should I just revert the single 2b83ff96f51d commit here instead?
>
> I believe so, yes.
>
> I'm not aware of any _really bad_ issues with LED subsystem in
> 4.9. Take a look at changelog of
> 2b83ff96f51d0b039c4561b9f95c824d7bddb85c -- it fixes rather
> theoretical issue; user can reproduce it by hand in shell, but,
> well... don't do it then.
Greg mentioned that 4.9.87 release fixed some LED issue for someone,
and it was the only LED related patch in that release.
> The rest of fixes ... fix some more theoretical races. I don't think
> it is -stable material, as I pointed out before.
--
Best regards,
Jacek Anaszewski
This is a note to let you know that I've just added the patch titled
Revert "ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux"
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:
revert-arm-dts-logicpd-torpedo-fix-i2c1-pinmux.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 669f2dc901fbac917e494d392cfcc0b8db764947 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Fri, 16 Mar 2018 13:39:47 +0100
Subject: Revert "ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux"
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
This reverts commit c86bfc7b7b01c4b98c29a39bd60e61fa8e337ebf which was
commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream.
The backport merged incorrectly, so I'm dropping it.
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Cc: Adam Ford <aford173(a)gmail.com>
Cc: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 --------
1 file changed, 8 deletions(-)
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -90,8 +90,6 @@
};
&i2c1 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c1_pins>;
clock-frequency = <2600000>;
twl: twl@48 {
@@ -148,12 +146,6 @@
OMAP3630_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP | MUX_MODE2) /* etk_ctl.sdmmc3_cmd */
>;
};
- i2c1_pins: pinmux_i2c1_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */
- OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */
- >;
- };
};
#include "twl4030.dtsi"
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.4/tc358743-fix-register-i2c_rd-wr-function-fix.patch
queue-4.4/netfilter-add-back-stackpointer-size-checks.patch
queue-4.4/watchdog-hpwdt-fix-unused-variable-warning.patch
queue-4.4/scsi-qla2xxx-fix-null-pointer-crash-due-to-active-timer-for-abts.patch
queue-4.4/watchdog-hpwdt-smbios-check.patch
queue-4.4/drm-amdgpu-notify-sbios-device-ready-before-send-request.patch
queue-4.4/workqueue-allow-retrieval-of-current-task-s-work-struct.patch
queue-4.4/loop-fix-lost-writes-caused-by-missing-flag.patch
queue-4.4/rdma-ucma-limit-possible-option-size.patch
queue-4.4/alsa-seq-don-t-allow-resizing-pool-in-use.patch
queue-4.4/netfilter-x_tables-pack-percpu-counter-allocations.patch
queue-4.4/revert-arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch
queue-4.4/arm-omap2-hide-omap3_save_secure_ram-on-non-omap3-builds.patch
queue-4.4/x86-mce-serialize-sysfs-changes.patch
queue-4.4/alsa-hda-add-dock-and-led-support-for-hp-probook-640-g2.patch
queue-4.4/netfilter-idletimer-be-syzkaller-friendly.patch
queue-4.4/netfilter-use-skb_to_full_sk-in-ip_route_me_harder.patch
queue-4.4/drm-radeon-fix-kv-harvesting.patch
queue-4.4/ubi-fix-race-condition-between-ubi-volume-creation-and-udev.patch
queue-4.4/drm-radeon-fix-deadlock-on-runtime-suspend.patch
queue-4.4/scsi-qla2xxx-replace-fcport-alloc-with-qla2x00_alloc_fcport.patch
queue-4.4/alsa-hda-add-dock-and-led-support-for-hp-elitebook-820-g3.patch
queue-4.4/watchdog-hpwdt-check-source-of-nmi.patch
queue-4.4/netfilter-ipv6-fix-use-after-free-write-in-nf_nat_ipv6_manip_pkt.patch
queue-4.4/mips-bmips-do-not-mask-ipis-during-suspend.patch
queue-4.4/netfilter-x_tables-pass-xt_counters-struct-instead-of-packet-counter.patch
queue-4.4/rdma-ucma-check-that-user-doesn-t-overflow-qp-state.patch
queue-4.4/nospec-include-asm-barrier.h-dependency.patch
queue-4.4/netfilter-ebtables-config_compat-don-t-trust-userland-offsets.patch
queue-4.4/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch
queue-4.4/alsa-seq-more-protection-for-concurrent-write-and-ioctl-races.patch
queue-4.4/nfs-fix-an-incorrect-type-in-struct-nfs_direct_req.patch
queue-4.4/netfilter-nfnetlink_queue-fix-timestamp-attribute.patch
queue-4.4/mips-ath25-check-for-kzalloc-allocation-failure.patch
queue-4.4/bcache-don-t-attach-backing-with-duplicate-uuid.patch
queue-4.4/kbuild-handle-builtin-dtb-file-names-containing-hyphens.patch
queue-4.4/drm-allow-determining-if-current-task-is-output-poll-worker.patch
queue-4.4/netfilter-bridge-ebt_among-add-missing-match-size-checks.patch
queue-4.4/netfilter-nat-cope-with-negative-port-range.patch
queue-4.4/netfilter-x_tables-fix-missing-timer-initialization-in-xt_led.patch
queue-4.4/ext4-inplace-xattr-block-update-fails-to-deduplicate-blocks.patch
queue-4.4/input-tca8418_keypad-remove-double-read-of-key-event-register.patch
queue-4.4/alsa-hda-realtek-fix-dock-line-out-volume-on-dell-precision-7520.patch
queue-4.4/drm-amdgpu-fix-kv-harvesting.patch
queue-4.4/drm-nouveau-fix-deadlock-on-runtime-suspend.patch
queue-4.4/input-matrix_keypad-fix-race-when-disabling-interrupts.patch
queue-4.4/mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.patch
queue-4.4/netfilter-x_tables-pass-xt_counters-struct-to-counter-allocator.patch
queue-4.4/rdma-mlx5-fix-integer-overflow-while-resizing-cq.patch
This is a note to let you know that I've just added the patch titled
net: phy: fix resume handling
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:
net-phy-fix-resume-handling.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 foo@baz Wed Feb 28 16:23:28 CET 2018
From: Russell King <rmk+kernel(a)armlinux.org.uk>
Date: Tue, 12 Dec 2017 10:45:36 +0000
Subject: net: phy: fix resume handling
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit f5e64032a799d4f54decc7eb6aafcdffb67f9ad9 ]
When a PHY has the BMCR_PDOWN bit set, it may decide to ignore writes
to other registers, or reset the registers to power-on defaults.
Micrel PHYs do this for their interrupt registers.
The current structure of phylib tries to enable interrupts before
resuming (and releasing) the BMCR_PDOWN bit. This fails, causing
Micrel PHYs to stop working after a suspend/resume sequence if they
are using interrupts.
Fix this by ensuring that the PHY driver resume methods do not take
the phydev->lock mutex themselves, but the callers of phy_resume()
take that lock. This then allows us to move the call to phy_resume()
before we enable interrupts in phy_start().
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/at803x.c | 4 ----
drivers/net/phy/phy.c | 9 +++------
drivers/net/phy/phy_device.c | 10 ++++++----
3 files changed, 9 insertions(+), 14 deletions(-)
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -239,14 +239,10 @@ static int at803x_resume(struct phy_devi
{
int value;
- mutex_lock(&phydev->lock);
-
value = phy_read(phydev, MII_BMCR);
value &= ~(BMCR_PDOWN | BMCR_ISOLATE);
phy_write(phydev, MII_BMCR, value);
- mutex_unlock(&phydev->lock);
-
return 0;
}
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -828,7 +828,6 @@ EXPORT_SYMBOL(phy_stop);
*/
void phy_start(struct phy_device *phydev)
{
- bool do_resume = false;
int err = 0;
mutex_lock(&phydev->lock);
@@ -841,6 +840,9 @@ void phy_start(struct phy_device *phydev
phydev->state = PHY_UP;
break;
case PHY_HALTED:
+ /* if phy was suspended, bring the physical link up again */
+ phy_resume(phydev);
+
/* make sure interrupts are re-enabled for the PHY */
if (phydev->irq != PHY_POLL) {
err = phy_enable_interrupts(phydev);
@@ -849,17 +851,12 @@ void phy_start(struct phy_device *phydev
}
phydev->state = PHY_RESUMING;
- do_resume = true;
break;
default:
break;
}
mutex_unlock(&phydev->lock);
- /* if phy was suspended, bring the physical link up again */
- if (do_resume)
- phy_resume(phydev);
-
phy_trigger_machine(phydev, true);
}
EXPORT_SYMBOL(phy_start);
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -135,7 +135,9 @@ static int mdio_bus_phy_resume(struct de
if (!mdio_bus_phy_may_suspend(phydev))
goto no_resume;
+ mutex_lock(&phydev->lock);
ret = phy_resume(phydev);
+ mutex_unlock(&phydev->lock);
if (ret < 0)
return ret;
@@ -1026,7 +1028,9 @@ int phy_attach_direct(struct net_device
if (err)
goto error;
+ mutex_lock(&phydev->lock);
phy_resume(phydev);
+ mutex_unlock(&phydev->lock);
phy_led_triggers_register(phydev);
return err;
@@ -1157,6 +1161,8 @@ int phy_resume(struct phy_device *phydev
struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
int ret = 0;
+ WARN_ON(!mutex_is_locked(&phydev->lock));
+
if (phydev->drv && phydrv->resume)
ret = phydrv->resume(phydev);
@@ -1639,13 +1645,9 @@ int genphy_resume(struct phy_device *phy
{
int value;
- mutex_lock(&phydev->lock);
-
value = phy_read(phydev, MII_BMCR);
phy_write(phydev, MII_BMCR, value & ~BMCR_PDOWN);
- mutex_unlock(&phydev->lock);
-
return 0;
}
EXPORT_SYMBOL(genphy_resume);
Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are
queue-4.14/arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.patch
queue-4.14/net-phy-fix-resume-handling.patch
This is a note to let you know that I've just added the patch titled
net: phy: Restore phy_resume() locking assumption
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:
net-phy-restore-phy_resume-locking-assumption.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 9c2c2e62df3fa30fb13fbeb7512a4eede729383b Mon Sep 17 00:00:00 2001
From: Andrew Lunn <andrew(a)lunn.ch>
Date: Tue, 27 Feb 2018 01:56:06 +0100
Subject: net: phy: Restore phy_resume() locking assumption
From: Andrew Lunn <andrew(a)lunn.ch>
commit 9c2c2e62df3fa30fb13fbeb7512a4eede729383b upstream.
commit f5e64032a799 ("net: phy: fix resume handling") changes the
locking semantics for phy_resume() such that the caller now needs to
hold the phy mutex. Not all call sites were adopted to this new
semantic, resulting in warnings from the added
WARN_ON(!mutex_is_locked(&phydev->lock)). Rather than change the
semantics, add a __phy_resume() and restore the old behavior of
phy_resume().
Reported-by: Heiner Kallweit <hkallweit1(a)gmail.com>
Fixes: f5e64032a799 ("net: phy: fix resume handling")
Signed-off-by: Andrew Lunn <andrew(a)lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/phy.c | 2 +-
drivers/net/phy/phy_device.c | 18 +++++++++++++-----
include/linux/phy.h | 1 +
3 files changed, 15 insertions(+), 6 deletions(-)
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -841,7 +841,7 @@ void phy_start(struct phy_device *phydev
break;
case PHY_HALTED:
/* if phy was suspended, bring the physical link up again */
- phy_resume(phydev);
+ __phy_resume(phydev);
/* make sure interrupts are re-enabled for the PHY */
if (phy_interrupt_is_valid(phydev)) {
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -135,9 +135,7 @@ static int mdio_bus_phy_resume(struct de
if (!mdio_bus_phy_may_suspend(phydev))
goto no_resume;
- mutex_lock(&phydev->lock);
ret = phy_resume(phydev);
- mutex_unlock(&phydev->lock);
if (ret < 0)
return ret;
@@ -1028,9 +1026,7 @@ int phy_attach_direct(struct net_device
if (err)
goto error;
- mutex_lock(&phydev->lock);
phy_resume(phydev);
- mutex_unlock(&phydev->lock);
phy_led_triggers_register(phydev);
return err;
@@ -1156,7 +1152,7 @@ int phy_suspend(struct phy_device *phyde
}
EXPORT_SYMBOL(phy_suspend);
-int phy_resume(struct phy_device *phydev)
+int __phy_resume(struct phy_device *phydev)
{
struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
int ret = 0;
@@ -1173,6 +1169,18 @@ int phy_resume(struct phy_device *phydev
return ret;
}
+EXPORT_SYMBOL(__phy_resume);
+
+int phy_resume(struct phy_device *phydev)
+{
+ int ret;
+
+ mutex_lock(&phydev->lock);
+ ret = __phy_resume(phydev);
+ mutex_unlock(&phydev->lock);
+
+ return ret;
+}
EXPORT_SYMBOL(phy_resume);
int phy_loopback(struct phy_device *phydev, bool enable)
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -817,6 +817,7 @@ void phy_device_remove(struct phy_device
int phy_init_hw(struct phy_device *phydev);
int phy_suspend(struct phy_device *phydev);
int phy_resume(struct phy_device *phydev);
+int __phy_resume(struct phy_device *phydev);
int phy_loopback(struct phy_device *phydev, bool enable);
struct phy_device *phy_attach(struct net_device *dev, const char *bus_id,
phy_interface_t interface);
Patches currently in stable-queue which might be from andrew(a)lunn.ch are
queue-4.14/net-phy-fix-resume-handling.patch
queue-4.14/net-phy-restore-phy_resume-locking-assumption.patch
This is a note to let you know that I've just added the patch titled
[PATCH] net: phy: fix resume handling
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:
net-phy-fix-resume-handling.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 6aae7a6232c6444941de8e5a1e0cc42442ab9bce Mon Sep 17 00:00:00 2001
From: Russell King <rmk+kernel(a)armlinux.org.uk>
Date: Tue, 12 Dec 2017 10:45:36 +0000
Subject: [PATCH] net: phy: fix resume handling
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit f5e64032a799d4f54decc7eb6aafcdffb67f9ad9 ]
When a PHY has the BMCR_PDOWN bit set, it may decide to ignore writes
to other registers, or reset the registers to power-on defaults.
Micrel PHYs do this for their interrupt registers.
The current structure of phylib tries to enable interrupts before
resuming (and releasing) the BMCR_PDOWN bit. This fails, causing
Micrel PHYs to stop working after a suspend/resume sequence if they
are using interrupts.
Fix this by ensuring that the PHY driver resume methods do not take
the phydev->lock mutex themselves, but the callers of phy_resume()
take that lock. This then allows us to move the call to phy_resume()
before we enable interrupts in phy_start().
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/at803x.c | 4 ----
drivers/net/phy/phy.c | 9 +++------
drivers/net/phy/phy_device.c | 10 ++++++----
3 files changed, 9 insertions(+), 14 deletions(-)
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -239,14 +239,10 @@ static int at803x_resume(struct phy_devi
{
int value;
- mutex_lock(&phydev->lock);
-
value = phy_read(phydev, MII_BMCR);
value &= ~(BMCR_PDOWN | BMCR_ISOLATE);
phy_write(phydev, MII_BMCR, value);
- mutex_unlock(&phydev->lock);
-
return 0;
}
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -828,7 +828,6 @@ EXPORT_SYMBOL(phy_stop);
*/
void phy_start(struct phy_device *phydev)
{
- bool do_resume = false;
int err = 0;
mutex_lock(&phydev->lock);
@@ -841,6 +840,9 @@ void phy_start(struct phy_device *phydev
phydev->state = PHY_UP;
break;
case PHY_HALTED:
+ /* if phy was suspended, bring the physical link up again */
+ phy_resume(phydev);
+
/* make sure interrupts are re-enabled for the PHY */
if (phy_interrupt_is_valid(phydev)) {
err = phy_enable_interrupts(phydev);
@@ -849,17 +851,12 @@ void phy_start(struct phy_device *phydev
}
phydev->state = PHY_RESUMING;
- do_resume = true;
break;
default:
break;
}
mutex_unlock(&phydev->lock);
- /* if phy was suspended, bring the physical link up again */
- if (do_resume)
- phy_resume(phydev);
-
phy_trigger_machine(phydev, true);
}
EXPORT_SYMBOL(phy_start);
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -135,7 +135,9 @@ static int mdio_bus_phy_resume(struct de
if (!mdio_bus_phy_may_suspend(phydev))
goto no_resume;
+ mutex_lock(&phydev->lock);
ret = phy_resume(phydev);
+ mutex_unlock(&phydev->lock);
if (ret < 0)
return ret;
@@ -1026,7 +1028,9 @@ int phy_attach_direct(struct net_device
if (err)
goto error;
+ mutex_lock(&phydev->lock);
phy_resume(phydev);
+ mutex_unlock(&phydev->lock);
phy_led_triggers_register(phydev);
return err;
@@ -1157,6 +1161,8 @@ int phy_resume(struct phy_device *phydev
struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
int ret = 0;
+ WARN_ON(!mutex_is_locked(&phydev->lock));
+
if (phydev->drv && phydrv->resume)
ret = phydrv->resume(phydev);
@@ -1639,13 +1645,9 @@ int genphy_resume(struct phy_device *phy
{
int value;
- mutex_lock(&phydev->lock);
-
value = phy_read(phydev, MII_BMCR);
phy_write(phydev, MII_BMCR, value & ~BMCR_PDOWN);
- mutex_unlock(&phydev->lock);
-
return 0;
}
EXPORT_SYMBOL(genphy_resume);
Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are
queue-4.14/net-phy-fix-resume-handling.patch
On Fri, Mar 16, 2018 at 10:31:16AM +0100, Rainer Fiebig wrote:
> Hi!
>
> When building 4.14.27 I got the a/m message. Same for 4.16-rc5.
> Building the kernel is OK, however. Same for Spectre- ect. mitigation.
>
> As I'm not sure whether this is a bug or a feature (and where to get libelf-devel from), any hint would be welcome.
It should be part of your Linux distribution, the help message says the
major different forms it is called, have you tried searching for those?
What Linux distro do you use?
thanks,
greg k-h
This is a note to let you know that I've just added the patch titled
siox: fix possible buffer overflow in device_add_store
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From f87deada80fe483e2286e29cd866dc66ddc2b6bc Mon Sep 17 00:00:00 2001
From: Gavin Schenk <g.schenk(a)eckelmann.de>
Date: Wed, 14 Feb 2018 15:25:02 +0100
Subject: siox: fix possible buffer overflow in device_add_store
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Width 20 given in format string is larger than destination
buffer 'type[20]', use %19s to prevent overflowing it.
Fixes: bbecb07fa0af ("siox: new driver framework for eckelmann SIOX")
Cc: stable <stable(a)vger.kernel.org>
Reported-by: David Binderman <dcb314(a)hotmail.com>
Signed-off-by: Gavin Schenk <g.schenk(a)eckelmann.de>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/siox/siox-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
index fdfcdea25867..16590dfaafa4 100644
--- a/drivers/siox/siox-core.c
+++ b/drivers/siox/siox-core.c
@@ -594,7 +594,7 @@ static ssize_t device_add_store(struct device *dev,
size_t inbytes = 0, outbytes = 0;
u8 statustype = 0;
- ret = sscanf(buf, "%20s %zu %zu %hhu", type, &inbytes,
+ ret = sscanf(buf, "%19s %zu %zu %hhu", type, &inbytes,
&outbytes, &statustype);
if (ret != 3 && ret != 4)
return -EINVAL;
--
2.16.2
This is a note to let you know that I've just added the patch titled
Revert "base: arch_topology: fix section mismatch build warnings"
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 9de9a449482677a75f1edd2049268a7efc40fc96 Mon Sep 17 00:00:00 2001
From: Gaku Inami <gaku.inami.xh(a)renesas.com>
Date: Tue, 13 Feb 2018 11:06:40 +0900
Subject: Revert "base: arch_topology: fix section mismatch build warnings"
This reverts commit 452562abb5b7 ("base: arch_topology: fix section
mismatch build warnings"). It causes the notifier call hangs in some
use-cases.
In some cases with using maxcpus, some of cpus are booted first and
then the remaining cpus are booted. As an example, some users who want
to realize fast boot up often use the following procedure.
1) Define all CPUs on device tree (CA57x4 + CA53x4)
2) Add "maxcpus=4" in bootargs
3) Kernel boot up with CA57x4
4) After kernel boot up, CA53x4 is booted from user
When kernel init was finished, CPUFREQ_POLICY_NOTIFIER was not still
unregisterd. This means that "__init init_cpu_capacity_callback()"
will be called after kernel init sequence. To avoid this problem,
it needs to remove __init{,data} annotations by reverting this commit.
Also, this commit was needed to fix kernel compile issue below.
However, this issue was also fixed by another patch: commit 82d8ba717ccb
("arch_topology: Fix section miss match warning due to
free_raw_capacity()") in v4.15 as well.
Whereas commit 452562abb5b7 added all the missing __init annotations,
commit 82d8ba717ccb removed it from free_raw_capacity().
WARNING: vmlinux.o(.text+0x548f24): Section mismatch in reference
from the function init_cpu_capacity_callback() to the variable
.init.text:$x
The function init_cpu_capacity_callback() references
the variable __init $x.
This is often because init_cpu_capacity_callback lacks a __init
annotation or the annotation of $x is wrong.
Fixes: 82d8ba717ccb ("arch_topology: Fix section miss match warning due to free_raw_capacity()")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Gaku Inami <gaku.inami.xh(a)renesas.com>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann(a)arm.com>
Tested-by: Dietmar Eggemann <dietmar.eggemann(a)arm.com>
Acked-by: Sudeep Holla <sudeep.holla(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/arch_topology.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 52ec5174bcb1..e7cb0c6ade81 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -169,11 +169,11 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
}
#ifdef CONFIG_CPU_FREQ
-static cpumask_var_t cpus_to_visit __initdata;
-static void __init parsing_done_workfn(struct work_struct *work);
-static __initdata DECLARE_WORK(parsing_done_work, parsing_done_workfn);
+static cpumask_var_t cpus_to_visit;
+static void parsing_done_workfn(struct work_struct *work);
+static DECLARE_WORK(parsing_done_work, parsing_done_workfn);
-static int __init
+static int
init_cpu_capacity_callback(struct notifier_block *nb,
unsigned long val,
void *data)
@@ -209,7 +209,7 @@ init_cpu_capacity_callback(struct notifier_block *nb,
return 0;
}
-static struct notifier_block init_cpu_capacity_notifier __initdata = {
+static struct notifier_block init_cpu_capacity_notifier = {
.notifier_call = init_cpu_capacity_callback,
};
@@ -242,7 +242,7 @@ static int __init register_cpufreq_notifier(void)
}
core_initcall(register_cpufreq_notifier);
-static void __init parsing_done_workfn(struct work_struct *work)
+static void parsing_done_workfn(struct work_struct *work)
{
cpufreq_unregister_notifier(&init_cpu_capacity_notifier,
CPUFREQ_POLICY_NOTIFIER);
--
2.16.2
Fix to convert array element type collectly.
Current perf-probe converts the type of array-elements
incorrectly. It always converts the types as a pointer
of array. This passes the "array" type DIE to the type
converter so that it can get correct "element of array"
type DIE from it.
E.g.
====
$ cat hello.c
#include <stdio.h>
void foo(int a[])
{
printf("%d\n", a[1]);
}
void main()
{
int a[3] = {4, 5, 6};
printf("%d\n", a[0]);
foo(a);
}
$ gcc -g hello.c -o hello
$ perf probe -x ./hello -D "foo a[1]"
====
Without this fix, above outputs
====
p:probe_hello/foo /tmp/hello:0x4d3 a=+4(-8(%bp)):u64
====
The "u64" means "int *", but a[1] is "int".
With this,
====
p:probe_hello/foo /tmp/hello:0x4d3 a=+4(-8(%bp)):s32
====
So, "int" correctly converted to "s32"
Fixes: b2a3c12b7442 ("perf probe: Support tracing an entry of array")
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
tools/perf/util/probe-finder.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index a5731de0e5eb..c37fbef1711d 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -423,20 +423,20 @@ static int convert_variable_fields(Dwarf_Die *vr_die, const char *varname,
pr_warning("Failed to get the type of %s.\n", varname);
return -ENOENT;
}
- pr_debug2("Var real type: (%x)\n", (unsigned)dwarf_dieoffset(&type));
+ pr_debug2("Var real type: %s (%x)\n", dwarf_diename(&type),
+ (unsigned)dwarf_dieoffset(&type));
tag = dwarf_tag(&type);
if (field->name[0] == '[' &&
(tag == DW_TAG_array_type || tag == DW_TAG_pointer_type)) {
- if (field->next)
- /* Save original type for next field */
- memcpy(die_mem, &type, sizeof(*die_mem));
+ /* Save original type for next field or type */
+ memcpy(die_mem, &type, sizeof(*die_mem));
/* Get the type of this array */
if (die_get_real_type(&type, &type) == NULL) {
pr_warning("Failed to get the type of %s.\n", varname);
return -ENOENT;
}
- pr_debug2("Array real type: (%x)\n",
+ pr_debug2("Array real type: %s (%x)\n", dwarf_diename(&type),
(unsigned)dwarf_dieoffset(&type));
if (tag == DW_TAG_pointer_type) {
ref = zalloc(sizeof(struct probe_trace_arg_ref));
@@ -448,9 +448,6 @@ static int convert_variable_fields(Dwarf_Die *vr_die, const char *varname,
*ref_ptr = ref;
}
ref->offset += dwarf_bytesize(&type) * field->index;
- if (!field->next)
- /* Save vr_die for converting types */
- memcpy(die_mem, vr_die, sizeof(*die_mem));
goto next;
} else if (tag == DW_TAG_pointer_type) {
/* Check the pointer and dereference */
The patch titled
Subject: mm/thp: do not wait for lock_page() in deferred_split_scan()
has been added to the -mm tree. Its filename is
mm-thp-do-not-wait-for-lock_page-in-deferred_split_scan.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-thp-do-not-wait-for-lock_page-i…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-thp-do-not-wait-for-lock_page-i…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Subject: mm/thp: do not wait for lock_page() in deferred_split_scan()
deferred_split_scan() gets called from reclaim path. Waiting for page
lock may lead to deadlock there.
Replace lock_page() with trylock_page() and skip the page if we failed to
lock it. We will get to the page on the next scan.
Link: http://lkml.kernel.org/r/20180315150747.31945-1-kirill.shutemov@linux.intel…
Fixes: 9a982250f773 ("thp: introduce deferred_split_huge_page()")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN mm/huge_memory.c~mm-thp-do-not-wait-for-lock_page-in-deferred_split_scan mm/huge_memory.c
--- a/mm/huge_memory.c~mm-thp-do-not-wait-for-lock_page-in-deferred_split_scan
+++ a/mm/huge_memory.c
@@ -2783,11 +2783,13 @@ static unsigned long deferred_split_scan
list_for_each_safe(pos, next, &list) {
page = list_entry((void *)pos, struct page, mapping);
- lock_page(page);
+ if (!trylock_page(page))
+ goto next;
/* split_huge_page() removes page from list on success */
if (!split_huge_page(page))
split++;
unlock_page(page);
+next:
put_page(page);
}
_
Patches currently in -mm which might be from kirill.shutemov(a)linux.intel.com are
mm-khugepaged-convert-vm_bug_on-to-collapse-fail.patch
mm-thp-do-not-wait-for-lock_page-in-deferred_split_scan.patch
The patch titled
Subject: mm/vmscan: wake up flushers for legacy cgroups too
has been added to the -mm tree. Its filename is
mm-vmscan-wake-up-flushers-for-legacy-cgroups-too.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-vmscan-wake-up-flushers-for-leg…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-vmscan-wake-up-flushers-for-leg…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Subject: mm/vmscan: wake up flushers for legacy cgroups too
Commit 726d061fbd36 ("mm: vmscan: kick flushers when we encounter dirty
pages on the LRU") added flusher invocation to shrink_inactive_list() when
many dirty pages on the LRU are encountered.
However, shrink_inactive_list() doesn't wake up flushers for legacy cgroup
reclaim, so the next commit bbef938429f5 ("mm: vmscan: remove old flusher
wakeup from direct reclaim path") removed the only source of flusher's
wake up in legacy mem cgroup reclaim path.
This leads to premature OOM if there is too many dirty pages in cgroup:
# mkdir /sys/fs/cgroup/memory/test
# echo $$ > /sys/fs/cgroup/memory/test/tasks
# echo 50M > /sys/fs/cgroup/memory/test/memory.limit_in_bytes
# dd if=/dev/zero of=tmp_file bs=1M count=100
Killed
dd invoked oom-killer: gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0
Call Trace:
dump_stack+0x46/0x65
dump_header+0x6b/0x2ac
oom_kill_process+0x21c/0x4a0
out_of_memory+0x2a5/0x4b0
mem_cgroup_out_of_memory+0x3b/0x60
mem_cgroup_oom_synchronize+0x2ed/0x330
pagefault_out_of_memory+0x24/0x54
__do_page_fault+0x521/0x540
page_fault+0x45/0x50
Task in /test killed as a result of limit of /test
memory: usage 51200kB, limit 51200kB, failcnt 73
memory+swap: usage 51200kB, limit 9007199254740988kB, failcnt 0
kmem: usage 296kB, limit 9007199254740988kB, failcnt 0
Memory cgroup stats for /test: cache:49632KB rss:1056KB rss_huge:0KB shmem:0KB
mapped_file:0KB dirty:49500KB writeback:0KB swap:0KB inactive_anon:0KB
active_anon:1168KB inactive_file:24760KB active_file:24960KB unevictable:0KB
Memory cgroup out of memory: Kill process 3861 (bash) score 88 or sacrifice child
Killed process 3876 (dd) total-vm:8484kB, anon-rss:1052kB, file-rss:1720kB, shmem-rss:0kB
oom_reaper: reaped process 3876 (dd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Wake up flushers in legacy cgroup reclaim too.
Link: http://lkml.kernel.org/r/20180315164553.17856-1-aryabinin@virtuozzo.com
Fixes: bbef938429f5 ("mm: vmscan: remove old flusher wakeup from direct reclaim path")
Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Tested-by: Shakeel Butt <shakeelb(a)google.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN mm/vmscan.c~mm-vmscan-wake-up-flushers-for-legacy-cgroups-too mm/vmscan.c
--- a/mm/vmscan.c~mm-vmscan-wake-up-flushers-for-legacy-cgroups-too
+++ a/mm/vmscan.c
@@ -1772,6 +1772,20 @@ shrink_inactive_list(unsigned long nr_to
set_bit(PGDAT_WRITEBACK, &pgdat->flags);
/*
+ * If dirty pages are scanned that are not queued for IO, it
+ * implies that flushers are not doing their job. This can
+ * happen when memory pressure pushes dirty pages to the end of
+ * the LRU before the dirty limits are breached and the dirty
+ * data has expired. It can also happen when the proportion of
+ * dirty pages grows not through writes but through memory
+ * pressure reclaiming all the clean cache. And in some cases,
+ * the flushers simply cannot keep up with the allocation
+ * rate. Nudge the flusher threads in case they are asleep.
+ */
+ if (stat.nr_unqueued_dirty == nr_taken)
+ wakeup_flusher_threads(WB_REASON_VMSCAN);
+
+ /*
* Legacy memcg will stall in page writeback so avoid forcibly
* stalling here.
*/
@@ -1783,22 +1797,9 @@ shrink_inactive_list(unsigned long nr_to
if (stat.nr_dirty && stat.nr_dirty == stat.nr_congested)
set_bit(PGDAT_CONGESTED, &pgdat->flags);
- /*
- * If dirty pages are scanned that are not queued for IO, it
- * implies that flushers are not doing their job. This can
- * happen when memory pressure pushes dirty pages to the end of
- * the LRU before the dirty limits are breached and the dirty
- * data has expired. It can also happen when the proportion of
- * dirty pages grows not through writes but through memory
- * pressure reclaiming all the clean cache. And in some cases,
- * the flushers simply cannot keep up with the allocation
- * rate. Nudge the flusher threads in case they are asleep, but
- * also allow kswapd to start writing pages during reclaim.
- */
- if (stat.nr_unqueued_dirty == nr_taken) {
- wakeup_flusher_threads(WB_REASON_VMSCAN);
+ /* Allow kswapd to start writing pages during reclaim. */
+ if (stat.nr_unqueued_dirty == nr_taken)
set_bit(PGDAT_DIRTY, &pgdat->flags);
- }
/*
* If kswapd scans pages marked marked for immediate
_
Patches currently in -mm which might be from aryabinin(a)virtuozzo.com are
mm-vmscan-wake-up-flushers-for-legacy-cgroups-too.patch
mm-vmscan-update-stale-comments.patch
mm-vmscan-replace-mm_vmscan_lru_shrink_inactive-with-shrink_page_list-tracepoint.patch
mm-vmscan-remove-redundant-current_may_throttle-check.patch
mm-vmscan-dont-change-pgdat-state-on-base-of-a-single-lru-list-state.patch
mm-vmscan-dont-mess-with-pgdat-flags-in-memcg-reclaim.patch
mm-kasan-dont-vfree-nonexistent-vm_area.patch
This is a note to let you know that I've just added the patch titled
siox: fix possible buffer overflow in device_add_store
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the char-misc-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From f87deada80fe483e2286e29cd866dc66ddc2b6bc Mon Sep 17 00:00:00 2001
From: Gavin Schenk <g.schenk(a)eckelmann.de>
Date: Wed, 14 Feb 2018 15:25:02 +0100
Subject: siox: fix possible buffer overflow in device_add_store
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Width 20 given in format string is larger than destination
buffer 'type[20]', use %19s to prevent overflowing it.
Fixes: bbecb07fa0af ("siox: new driver framework for eckelmann SIOX")
Cc: stable <stable(a)vger.kernel.org>
Reported-by: David Binderman <dcb314(a)hotmail.com>
Signed-off-by: Gavin Schenk <g.schenk(a)eckelmann.de>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/siox/siox-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
index fdfcdea25867..16590dfaafa4 100644
--- a/drivers/siox/siox-core.c
+++ b/drivers/siox/siox-core.c
@@ -594,7 +594,7 @@ static ssize_t device_add_store(struct device *dev,
size_t inbytes = 0, outbytes = 0;
u8 statustype = 0;
- ret = sscanf(buf, "%20s %zu %zu %hhu", type, &inbytes,
+ ret = sscanf(buf, "%19s %zu %zu %hhu", type, &inbytes,
&outbytes, &statustype);
if (ret != 3 && ret != 4)
return -EINVAL;
--
2.16.2
Current cleanup in the error path of xen_bind_pirq_msi_to_irq is
wrong. First of all there's an off-by-one in the cleanup loop, which
can lead to unbinding wrong IRQs.
Secondly IRQs not bound won't be freed, thus leaking IRQ numbers.
Note that there's no need to differentiate between bound and unbound
IRQs when freeing them, __unbind_from_irq will deal with both of them
correctly.
Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
Reported-by: Hooman Mirhadi <mirhadih(a)amazon.com>
Signed-off-by: Roger Pau Monné <roger.pau(a)citrix.com>
---
Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: Juergen Gross <jgross(a)suse.com>
Cc: Amit Shah <aams(a)amazon.com>
CC: stable(a)vger.kernel.org
Cc: xen-devel(a)lists.xenproject.org
---
drivers/xen/events/events_base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index b241bfa529ce..159faf1269fb 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -763,8 +763,8 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc,
mutex_unlock(&irq_mapping_update_lock);
return irq;
error_irq:
- for (; i >= 0; i--)
- __unbind_from_irq(irq + i);
+ while (nvec--)
+ __unbind_from_irq(irq + nvec);
mutex_unlock(&irq_mapping_update_lock);
return ret;
}
--
2.16.1
Hi,
Would you be interested in IT professionals?
Let me know your interest to send you more details like counts, pricing &
list info.
Regards,
Erin Clift
Marketing Associate
Please "Unsubscribe" if not interested in receiving further emails.
On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap()
may create pud/pmd mappings. Kernel panic was observed on arm64
systems with Cortex-A75 in the following steps as described by
Hanjun Guo.
1. ioremap a 4K size, valid page table will build,
2. iounmap it, pte0 will set to 0;
3. ioremap the same address with 2M size, pgd/pmd is unchanged,
then set the a new value for pmd;
4. pte0 is leaked;
5. CPU may meet exception because the old pmd is still in TLB,
which will lead to kernel panic.
This panic is not reproducible on x86. INVLPG, called from iounmap,
purges all levels of entries associated with purged address on x86.
x86 still has memory leak.
The patch changes the ioremap path to free unmapped page table(s) since
doing so in the unmap path has the following issues:
- The iounmap() path is shared with vunmap(). Since vmap() only
supports pte mappings, making vunmap() to free a pte page is an
overhead for regular vmap users as they do not need a pte page
freed up.
- Checking if all entries in a pte page are cleared in the unmap path
is racy, and serializing this check is expensive.
- The unmap path calls free_vmap_area_noflush() to do lazy TLB purges.
Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB
purge.
Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(),
which clear a given pud/pmd entry and free up a page for the lower
level entries.
This patch implements their stub functions on x86 and arm64, which
work as workaround.
Reported-by: Lei Li <lious.lilei(a)hisilicon.com>
Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: Wang Xuefeng <wxf.wang(a)hisilicon.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: Hanjun Guo <guohanjun(a)huawei.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Cc: Borislav Petkov <bp(a)suse.de>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Chintan Pandya <cpandya(a)codeaurora.org>
Cc: <stable(a)vger.kernel.org>
---
arch/arm64/mm/mmu.c | 10 ++++++++++
arch/x86/mm/pgtable.c | 24 ++++++++++++++++++++++++
include/asm-generic/pgtable.h | 10 ++++++++++
lib/ioremap.c | 6 ++++--
4 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 8c704f1e53c2..2dbb2c9f1ec1 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -972,3 +972,13 @@ int pmd_clear_huge(pmd_t *pmdp)
pmd_clear(pmdp);
return 1;
}
+
+int pud_free_pmd_page(pud_t *pud)
+{
+ return pud_none(*pud);
+}
+
+int pmd_free_pte_page(pmd_t *pmd)
+{
+ return pmd_none(*pmd);
+}
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 004abf9ebf12..1eed7ed518e6 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -702,4 +702,28 @@ int pmd_clear_huge(pmd_t *pmd)
return 0;
}
+
+/**
+ * pud_free_pmd_page - Clear pud entry and free pmd page.
+ * @pud: Pointer to a PUD.
+ *
+ * Context: The pud range has been unmaped and TLB purged.
+ * Return: 1 if clearing the entry succeeded. 0 otherwise.
+ */
+int pud_free_pmd_page(pud_t *pud)
+{
+ return pud_none(*pud);
+}
+
+/**
+ * pmd_free_pte_page - Clear pmd entry and free pte page.
+ * @pmd: Pointer to a PMD.
+ *
+ * Context: The pmd range has been unmaped and TLB purged.
+ * Return: 1 if clearing the entry succeeded. 0 otherwise.
+ */
+int pmd_free_pte_page(pmd_t *pmd)
+{
+ return pmd_none(*pmd);
+}
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 2cfa3075d148..2490800f7c5a 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -983,6 +983,8 @@ int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot);
int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
int pud_clear_huge(pud_t *pud);
int pmd_clear_huge(pmd_t *pmd);
+int pud_free_pmd_page(pud_t *pud);
+int pmd_free_pte_page(pmd_t *pmd);
#else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
static inline int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot)
{
@@ -1008,6 +1010,14 @@ static inline int pmd_clear_huge(pmd_t *pmd)
{
return 0;
}
+static inline int pud_free_pmd_page(pud_t *pud)
+{
+ return 0;
+}
+static inline int pmd_free_pte_page(pud_t *pmd)
+{
+ return 0;
+}
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
diff --git a/lib/ioremap.c b/lib/ioremap.c
index b808a390e4c3..54e5bbaa3200 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -91,7 +91,8 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long addr,
if (ioremap_pmd_enabled() &&
((next - addr) == PMD_SIZE) &&
- IS_ALIGNED(phys_addr + addr, PMD_SIZE)) {
+ IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
+ pmd_free_pte_page(pmd)) {
if (pmd_set_huge(pmd, phys_addr + addr, prot))
continue;
}
@@ -117,7 +118,8 @@ static inline int ioremap_pud_range(p4d_t *p4d, unsigned long addr,
if (ioremap_pud_enabled() &&
((next - addr) == PUD_SIZE) &&
- IS_ALIGNED(phys_addr + addr, PUD_SIZE)) {
+ IS_ALIGNED(phys_addr + addr, PUD_SIZE) &&
+ pud_free_pmd_page(pud)) {
if (pud_set_huge(pud, phys_addr + addr, prot))
continue;
}
A memory block was allocated in intel_svm_bind_mm() but never freed
in a failure path. This patch fixes this by free it to avoid memory
leakage.
Cc: Ashok Raj <ashok.raj(a)intel.com>
Cc: Jacob Pan <jacob.jun.pan(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # v4.4+
Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com>
---
drivers/iommu/intel-svm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 35a408d..3d4b924 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -396,6 +396,7 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int flags, struct svm_dev_
pasid_max - 1, GFP_KERNEL);
if (ret < 0) {
kfree(svm);
+ kfree(sdev);
goto out;
}
svm->pasid = ret;
--
2.7.4
This is a note to let you know that I've just added the patch titled
Revert "base: arch_topology: fix section mismatch build warnings"
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the driver-core-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 9de9a449482677a75f1edd2049268a7efc40fc96 Mon Sep 17 00:00:00 2001
From: Gaku Inami <gaku.inami.xh(a)renesas.com>
Date: Tue, 13 Feb 2018 11:06:40 +0900
Subject: Revert "base: arch_topology: fix section mismatch build warnings"
This reverts commit 452562abb5b7 ("base: arch_topology: fix section
mismatch build warnings"). It causes the notifier call hangs in some
use-cases.
In some cases with using maxcpus, some of cpus are booted first and
then the remaining cpus are booted. As an example, some users who want
to realize fast boot up often use the following procedure.
1) Define all CPUs on device tree (CA57x4 + CA53x4)
2) Add "maxcpus=4" in bootargs
3) Kernel boot up with CA57x4
4) After kernel boot up, CA53x4 is booted from user
When kernel init was finished, CPUFREQ_POLICY_NOTIFIER was not still
unregisterd. This means that "__init init_cpu_capacity_callback()"
will be called after kernel init sequence. To avoid this problem,
it needs to remove __init{,data} annotations by reverting this commit.
Also, this commit was needed to fix kernel compile issue below.
However, this issue was also fixed by another patch: commit 82d8ba717ccb
("arch_topology: Fix section miss match warning due to
free_raw_capacity()") in v4.15 as well.
Whereas commit 452562abb5b7 added all the missing __init annotations,
commit 82d8ba717ccb removed it from free_raw_capacity().
WARNING: vmlinux.o(.text+0x548f24): Section mismatch in reference
from the function init_cpu_capacity_callback() to the variable
.init.text:$x
The function init_cpu_capacity_callback() references
the variable __init $x.
This is often because init_cpu_capacity_callback lacks a __init
annotation or the annotation of $x is wrong.
Fixes: 82d8ba717ccb ("arch_topology: Fix section miss match warning due to free_raw_capacity()")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Gaku Inami <gaku.inami.xh(a)renesas.com>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann(a)arm.com>
Tested-by: Dietmar Eggemann <dietmar.eggemann(a)arm.com>
Acked-by: Sudeep Holla <sudeep.holla(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/arch_topology.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 52ec5174bcb1..e7cb0c6ade81 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -169,11 +169,11 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
}
#ifdef CONFIG_CPU_FREQ
-static cpumask_var_t cpus_to_visit __initdata;
-static void __init parsing_done_workfn(struct work_struct *work);
-static __initdata DECLARE_WORK(parsing_done_work, parsing_done_workfn);
+static cpumask_var_t cpus_to_visit;
+static void parsing_done_workfn(struct work_struct *work);
+static DECLARE_WORK(parsing_done_work, parsing_done_workfn);
-static int __init
+static int
init_cpu_capacity_callback(struct notifier_block *nb,
unsigned long val,
void *data)
@@ -209,7 +209,7 @@ init_cpu_capacity_callback(struct notifier_block *nb,
return 0;
}
-static struct notifier_block init_cpu_capacity_notifier __initdata = {
+static struct notifier_block init_cpu_capacity_notifier = {
.notifier_call = init_cpu_capacity_callback,
};
@@ -242,7 +242,7 @@ static int __init register_cpufreq_notifier(void)
}
core_initcall(register_cpufreq_notifier);
-static void __init parsing_done_workfn(struct work_struct *work)
+static void parsing_done_workfn(struct work_struct *work)
{
cpufreq_unregister_notifier(&init_cpu_capacity_notifier,
CPUFREQ_POLICY_NOTIFIER);
--
2.16.2
Tracepoint should only warn when a kernel API user does not respect the
required preconditions (e.g. same tracepoint enabled twice, or called
to remove a tracepoint that does not exist).
Silence warning in out-of-memory conditions, given that the error is
returned to the caller.
This ensures that out-of-memory error-injection testing does not trigger
warnings in tracepoint.c, which were seen by syzbot.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
Reported-by: syzbot+9c0d616860575a73166a(a)syzkaller.appspotmail.com
Reported-by: syzbot+4e9ae7fa46233396f64d(a)syzkaller.appspotmail.com
CC: Steven Rostedt <rostedt(a)goodmis.org>
CC: Ingo Molnar <mingo(a)redhat.com>
CC: Peter Zijlstra <peterz(a)infradead.org>
CC: Jiri Olsa <jolsa(a)redhat.com>
CC: Arnaldo Carvalho de Melo <acme(a)kernel.org>
CC: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
CC: Namhyung Kim <namhyung(a)kernel.org>
CC: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/001a114465e241a8720567419a72@google.com
Link: https://lkml.kernel.org/r/001a1140e0de15fc910567464190@google.com
---
kernel/tracepoint.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index 671b13457387..1e37da2e0c25 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -207,7 +207,7 @@ static int tracepoint_add_func(struct tracepoint *tp,
lockdep_is_held(&tracepoints_mutex));
old = func_add(&tp_funcs, func, prio);
if (IS_ERR(old)) {
- WARN_ON_ONCE(1);
+ WARN_ON_ONCE(PTR_ERR(old) != -ENOMEM);
return PTR_ERR(old);
}
@@ -239,7 +239,7 @@ static int tracepoint_remove_func(struct tracepoint *tp,
lockdep_is_held(&tracepoints_mutex));
old = func_remove(&tp_funcs, func);
if (IS_ERR(old)) {
- WARN_ON_ONCE(1);
+ WARN_ON_ONCE(PTR_ERR(old) != -ENOMEM);
return PTR_ERR(old);
}
--
2.11.0
From: Frank Mori Hess <fmh6jj(a)gmail.com>
Ack ai fifo error interrupts in interrupt handler to clear interrupt
after fifo overflow. It should prevent lock-ups after the ai fifo
overflows.
Cc: <stable(a)vger.kernel.org> # v4.2+
Signed-off-by: Frank Mori Hess <fmh6jj(a)gmail.com>
Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk>
---
I have not tested this patch on hardware. -- Frank Mori Hess
Applies cleanly to v4.2+, but needs backporting for earlier stable
kernels. -- Ian Abbott.
---
drivers/staging/comedi/drivers/ni_mio_common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c b/drivers/staging/comedi/drivers/ni_mio_common.c
index d6eb55b41814..e40a2c0a9543 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -1275,6 +1275,8 @@ static void ack_a_interrupt(struct comedi_device *dev, unsigned short a_status)
ack |= NISTC_INTA_ACK_AI_START;
if (a_status & NISTC_AI_STATUS1_STOP)
ack |= NISTC_INTA_ACK_AI_STOP;
+ if (a_status & NISTC_AI_STATUS1_OVER)
+ ack |= NISTC_INTA_ACK_AI_ERR;
if (ack)
ni_stc_writew(dev, ack, NISTC_INTA_ACK_REG);
}
--
2.16.1
PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the
currently active partition in mmc_blk_data->part_curr. These caches do
not always reflect changes if the ioctl call modifies the
PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE.
Write the PARTITION_CONFIG value extracted from the ioctl call to the
cache and update the currently active partition accordingly. This
ensures that the user space cannot change the values behind the
kernel's back. The next call to mmc_blk_part_switch() will operate on
the data set by the ioctl and reflect the changes appropriately.
Signed-off-by: Bastian Stender <bst(a)pengutronix.de>
Signed-off-by: Jan Luebbe <jlu(a)pengutronix.de>
Cc: stable(a)vger.kernel.org
---
drivers/mmc/core/block.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 20135a5de748..2cfb963d9f37 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -72,6 +72,7 @@ MODULE_ALIAS("mmc:block");
#define MMC_BLK_TIMEOUT_MS (10 * 1000)
#define MMC_SANITIZE_REQ_TIMEOUT 240000
#define MMC_EXTRACT_INDEX_FROM_ARG(x) ((x & 0x00FF0000) >> 16)
+#define MMC_EXTRACT_VALUE_FROM_ARG(x) ((x & 0x0000FF00) >> 8)
#define mmc_req_rel_wr(req) ((req->cmd_flags & REQ_FUA) && \
(rq_data_dir(req) == WRITE))
@@ -586,6 +587,24 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md,
return data.error;
}
+ /*
+ * Make sure the cache of the PARTITION_CONFIG register and
+ * PARTITION_ACCESS bits is updated in case the ioctl ext_csd write
+ * changed it successfully.
+ */
+ if ((MMC_EXTRACT_INDEX_FROM_ARG(cmd.arg) == EXT_CSD_PART_CONFIG) &&
+ (cmd.opcode == MMC_SWITCH)) {
+ struct mmc_blk_data *main_md = dev_get_drvdata(&card->dev);
+ u8 value = MMC_EXTRACT_VALUE_FROM_ARG(cmd.arg);
+
+ /*
+ * Update cache so the next mmc_blk_part_switch call operates
+ * on up-to-date data.
+ */
+ card->ext_csd.part_config = value;
+ main_md->part_curr = value & EXT_CSD_PART_CONFIG_ACC_MASK;
+ }
+
/*
* According to the SD specs, some commands require a delay after
* issuing the command.
--
2.16.1
On Friday 19 January 2018 08:15 PM, Maxime Ripard wrote:
> On Fri, Jan 19, 2018 at 05:25:41PM +0800, Chen-Yu Tsai wrote:
>> The AXP223 PMIC, like the AXP221, does not generate VBUS change
>> interrupts when N_VBUSEN is used to drive VBUS for the OTG port
>> on the board.
>>
>> This was not noticed until recently, as most A23/A33 boards use
>> a GPIO pin that does not support interrupts for OTG ID detection.
>> This forces the driver to use polling. However the A33-OlinuXino
>> uses a pin that does support interrupts, so the driver uses them.
>> However the VBUS interrupt never fires, and the driver never gets
>> to update the VBUS status. This results in musb timing out waiting
>> for VBUS to rise.
>>
>> This was worked around for the AXP221 by resorting to polling
>> changes in commit 91d96f06a760 ("phy-sun4i-usb: Add workaround for
>> missing Vbus det interrupts on A31"). This patch adds the A23 and
>> A33 to the list of SoCs that need the workaround.
>>
>> Fixes: fc1f45ed3043 ("phy-sun4i-usb: Add support for the usb-phys on the
>> sun8i-a33 SoC")
>> Fixes: 123dfdbcfaf5 ("phy-sun4i-usb: Add support for the usb-phys on the
>> sun8i-a23 SoC")
>> Cc: <stable(a)vger.kernel.org> # 4.3.x: 68dbc2ce77bb phy-sun4i-usb:
>> Use of_match_node to get model specific config data
>> Cc: <stable(a)vger.kernel.org> # 4.3.x: 5cf700ac9d50 phy: phy-sun4i-usb:
>> Fix optional gpios failing probe
>> Cc: <stable(a)vger.kernel.org> # 4.3.x: 04e59a0211ff phy-sun4i-usb:
>> Fix irq free conditions to match request conditions
>> Cc: <stable(a)vger.kernel.org> # 4.3.x: 91d96f06a760 phy-sun4i-usb:
>> Add workaround for missing Vbus det interrupts on A31
>> Cc: <stable(a)vger.kernel.org> # 4.3.x
>> Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
>> ---
>>
>> This list might get longer if the newer AXP8xx PMICs also have this
>> behavior. We could switch to a boolean in the per-compatible data,
>> or just always use polling. The yet-merged R40 support will have this
>> issue as well, as the R40 is paired with the AXP221. But for now,
>> I'd like to have something that is easier to backport to stable, so
>> we can at least fix this for the A23 and A33.
>>
>> Also, checkpatch.pl doesn't like the stable kernel prerequisite lines.
>
> Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
merged, thanks!
-Kishon
Once the ring buffer is copied to ring_scan_buffer and scanned,
the shadow batch buffer start address is only updated into
ring_scan_buffer, not the real ring address allocated through
intel_ring_begin in later copy_workload_to_ring_buffer.
This patch is only to set the right shadow batch buffer address
from Ring buffer, not include the shadow_wa_ctx.
v2:
- refine some comments. (Zhenyu)
v3:
- fix typo in title. (Zhenyu)
v4:
- remove the unnecessary comments. (Zhenyu)
- add comments in bb_start_cmd_va update. (Zhenyu)
Fixes: 0a53bc07f044 ("drm/i915/gvt: Separate cmd scan from request allocation")
Cc: stable(a)vger.kernel.org # v4.15
Cc: Zhenyu Wang <zhenyuw(a)linux.intel.com>
Cc: Yulei Zhang <yulei.zhang(a)intel.com>
Signed-off-by: fred gao <fred.gao(a)intel.com>
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 8 ++++++++
drivers/gpu/drm/i915/gvt/scheduler.c | 11 +++++++++++
drivers/gpu/drm/i915/gvt/scheduler.h | 1 +
3 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index c8454ac..db6b94d 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -471,6 +471,7 @@ struct parser_exec_state {
* used when ret from 2nd level batch buffer
*/
int saved_buf_addr_type;
+ bool is_ctx_wa;
struct cmd_info *info;
@@ -1715,6 +1716,11 @@ static int perform_bb_shadow(struct parser_exec_state *s)
bb->accessing = true;
bb->bb_start_cmd_va = s->ip_va;
+ if ((s->buf_type == BATCH_BUFFER_INSTRUCTION) && (!s->is_ctx_wa))
+ bb->bb_offset = s->ip_va - s->rb_va;
+ else
+ bb->bb_offset = 0;
+
/*
* ip_va saves the virtual address of the shadow batch buffer, while
* ip_gma saves the graphics address of the original batch buffer.
@@ -2571,6 +2577,7 @@ static int scan_workload(struct intel_vgpu_workload *workload)
s.ring_tail = gma_tail;
s.rb_va = workload->shadow_ring_buffer_va;
s.workload = workload;
+ s.is_ctx_wa = false;
if ((bypass_scan_mask & (1 << workload->ring_id)) ||
gma_head == gma_tail)
@@ -2624,6 +2631,7 @@ static int scan_wa_ctx(struct intel_shadow_wa_ctx *wa_ctx)
s.ring_tail = gma_tail;
s.rb_va = wa_ctx->indirect_ctx.shadow_va;
s.workload = workload;
+ s.is_ctx_wa = true;
if (!intel_gvt_ggtt_validate_range(s.vgpu, s.ring_start, s.ring_size)) {
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
index 9b92b4e..256313c 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -381,6 +381,17 @@ static int prepare_shadow_batch_buffer(struct intel_vgpu_workload *workload)
goto err;
}
+ /* For privilge batch buffer and not wa_ctx, the bb_start_cmd_va
+ * is only updated into ring_scan_buffer, not real ring address
+ * allocated in later copy_workload_to_ring_buffer. pls be noted
+ * shadow_ring_buffer_va is now pointed to real ring buffer va
+ * in copy_workload_to_ring_buffer.
+ */
+
+ if (bb->bb_offset)
+ bb->bb_start_cmd_va = workload->shadow_ring_buffer_va
+ + bb->bb_offset;
+
/* relocate shadow batch buffer */
bb->bb_start_cmd_va[1] = i915_ggtt_offset(bb->vma);
if (gmadr_bytes == 8)
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.h b/drivers/gpu/drm/i915/gvt/scheduler.h
index bab4097..68313d1 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.h
+++ b/drivers/gpu/drm/i915/gvt/scheduler.h
@@ -120,6 +120,7 @@ struct intel_vgpu_shadow_bb {
u32 *bb_start_cmd_va;
unsigned int clflush;
bool accessing;
+ unsigned long bb_offset;
};
#define workload_q_head(vgpu, ring_id) \
--
2.7.4
This is a note to let you know that I've just added the patch titled
mei: remove dev_err message on an unsupported ioctl
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From bb0829a741792b56c908d7745bc0b2b540293bcc Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king(a)canonical.com>
Date: Tue, 27 Feb 2018 16:21:05 +0000
Subject: mei: remove dev_err message on an unsupported ioctl
Currently the driver spams the kernel log on unsupported ioctls which is
unnecessary as the ioctl returns -ENOIOCTLCMD to indicate this anyway.
I suspect this was originally for debugging purposes but it really is not
required so remove it.
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/mei/main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index 401b1bc4d282..7465f17e1559 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -528,7 +528,6 @@ static long mei_ioctl(struct file *file, unsigned int cmd, unsigned long data)
break;
default:
- dev_err(dev->dev, ": unsupported ioctl %d.\n", cmd);
rets = -ENOIOCTLCMD;
}
--
2.16.2
On Wed, 14 Mar 2018 16:41:00 -0400 Doug Ledford <dledford(a)redhat.com> wrote:
> On Tue, 2018-03-13 at 14:51 -0700, akpm(a)linux-foundation.org wrote:
> > From: Andrew Morton <akpm(a)linux-foundation.org>
> > Subject: drivers/infiniband/core/verbs.c: fix build with gcc-4.4.4
> >
> > gcc-4.4.4 has issues with initialization of anonymous unions.
>
> That compiler was released in April of 2010, almost a full 8 years ago.
> What still uses it, and do we seriously care?
Documentation/Changes still says gcc-3.2. A few people are using the
older versions. There's talk going around about requiring something
more recent but nothing has happened yet.
The patch titled
Subject: x86/mm: implement free pmd/pte page interfaces
has been added to the -mm tree. Its filename is
x86-mm-implement-free-pmd-pte-page-interfaces.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/x86-mm-implement-free-pmd-pte-page…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/x86-mm-implement-free-pmd-pte-page…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Toshi Kani <toshi.kani(a)hpe.com>
Subject: x86/mm: implement free pmd/pte page interfaces
Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which clear
a given pud/pmd entry and free up lower level page table(s). Address
range associated with the pud/pmd entry must have been purged by INVLPG.
Link: http://lkml.kernel.org/r/20180314180155.19492-3-toshi.kani@hpe.com
Fixes: e61ce6ade404e ("mm: change ioremap to set up huge I/O mappings")
Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com>
Reported-by: Lei Li <lious.lilei(a)hisilicon.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Cc: Borislav Petkov <bp(a)suse.de>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/x86/mm/pgtable.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff -puN arch/x86/mm/pgtable.c~x86-mm-implement-free-pmd-pte-page-interfaces arch/x86/mm/pgtable.c
--- a/arch/x86/mm/pgtable.c~x86-mm-implement-free-pmd-pte-page-interfaces
+++ a/arch/x86/mm/pgtable.c
@@ -712,7 +712,22 @@ int pmd_clear_huge(pmd_t *pmd)
*/
int pud_free_pmd_page(pud_t *pud)
{
- return pud_none(*pud);
+ pmd_t *pmd;
+ int i;
+
+ if (pud_none(*pud))
+ return 1;
+
+ pmd = (pmd_t *)pud_page_vaddr(*pud);
+
+ for (i = 0; i < PTRS_PER_PMD; i++)
+ if (!pmd_free_pte_page(&pmd[i]))
+ return 0;
+
+ pud_clear(pud);
+ free_page((unsigned long)pmd);
+
+ return 1;
}
/**
@@ -724,6 +739,15 @@ int pud_free_pmd_page(pud_t *pud)
*/
int pmd_free_pte_page(pmd_t *pmd)
{
- return pmd_none(*pmd);
+ pte_t *pte;
+
+ if (pmd_none(*pmd))
+ return 1;
+
+ pte = (pte_t *)pmd_page_vaddr(*pmd);
+ pmd_clear(pmd);
+ free_page((unsigned long)pte);
+
+ return 1;
}
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
_
Patches currently in -mm which might be from toshi.kani(a)hpe.com are
mm-vmalloc-add-interfaces-to-free-unmapped-page-table.patch
x86-mm-implement-free-pmd-pte-page-interfaces.patch
The patch titled
Subject: mm/vmalloc: add interfaces to free unmapped page table
has been added to the -mm tree. Its filename is
mm-vmalloc-add-interfaces-to-free-unmapped-page-table.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-vmalloc-add-interfaces-to-free-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-vmalloc-add-interfaces-to-free-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Toshi Kani <toshi.kani(a)hpe.com>
Subject: mm/vmalloc: add interfaces to free unmapped page table
On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() may create
pud/pmd mappings. Kernel panic was observed on arm64 systems with
Cortex-A75 in the following steps as described by Hanjun Guo.
1. ioremap a 4K size, valid page table will build,
2. iounmap it, pte0 will set to 0;
3. ioremap the same address with 2M size, pgd/pmd is unchanged,
then set the a new value for pmd;
4. pte0 is leaked;
5. CPU may meet exception because the old pmd is still in TLB,
which will lead to kernel panic.
This panic is not reproducible on x86. INVLPG, called from iounmap,
purges all levels of entries associated with purged address on x86. x86
still has memory leak.
The patch changes the ioremap path to free unmapped page table(s) since
doing so in the unmap path has the following issues:
- The iounmap() path is shared with vunmap(). Since vmap() only
supports pte mappings, making vunmap() to free a pte page is an
overhead for regular vmap users as they do not need a pte page
freed up.
- Checking if all entries in a pte page are cleared in the unmap path
is racy, and serializing this check is expensive.
- The unmap path calls free_vmap_area_noflush() to do lazy TLB purges.
Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB
purge.
Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), which
clear a given pud/pmd entry and free up a page for the lower level
entries.
This patch implements their stub functions on x86 and arm64, which work as
workaround.
Link: http://lkml.kernel.org/r/20180314180155.19492-2-toshi.kani@hpe.com
Fixes: e61ce6ade404e ("mm: change ioremap to set up huge I/O mappings")
Reported-by: Lei Li <lious.lilei(a)hisilicon.com>
Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: Wang Xuefeng <wxf.wang(a)hisilicon.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: Hanjun Guo <guohanjun(a)huawei.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Cc: Borislav Petkov <bp(a)suse.de>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Chintan Pandya <cpandya(a)codeaurora.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/arm64/mm/mmu.c | 10 ++++++++++
arch/x86/mm/pgtable.c | 24 ++++++++++++++++++++++++
include/asm-generic/pgtable.h | 10 ++++++++++
lib/ioremap.c | 6 ++++--
4 files changed, 48 insertions(+), 2 deletions(-)
diff -puN arch/arm64/mm/mmu.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table arch/arm64/mm/mmu.c
--- a/arch/arm64/mm/mmu.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table
+++ a/arch/arm64/mm/mmu.c
@@ -972,3 +972,13 @@ int pmd_clear_huge(pmd_t *pmdp)
pmd_clear(pmdp);
return 1;
}
+
+int pud_free_pmd_page(pud_t *pud)
+{
+ return pud_none(*pud);
+}
+
+int pmd_free_pte_page(pmd_t *pmd)
+{
+ return pmd_none(*pmd);
+}
diff -puN arch/x86/mm/pgtable.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table arch/x86/mm/pgtable.c
--- a/arch/x86/mm/pgtable.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table
+++ a/arch/x86/mm/pgtable.c
@@ -702,4 +702,28 @@ int pmd_clear_huge(pmd_t *pmd)
return 0;
}
+
+/**
+ * pud_free_pmd_page - Clear pud entry and free pmd page.
+ * @pud: Pointer to a PUD.
+ *
+ * Context: The pud range has been unmaped and TLB purged.
+ * Return: 1 if clearing the entry succeeded. 0 otherwise.
+ */
+int pud_free_pmd_page(pud_t *pud)
+{
+ return pud_none(*pud);
+}
+
+/**
+ * pmd_free_pte_page - Clear pmd entry and free pte page.
+ * @pmd: Pointer to a PMD.
+ *
+ * Context: The pmd range has been unmaped and TLB purged.
+ * Return: 1 if clearing the entry succeeded. 0 otherwise.
+ */
+int pmd_free_pte_page(pmd_t *pmd)
+{
+ return pmd_none(*pmd);
+}
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
diff -puN include/asm-generic/pgtable.h~mm-vmalloc-add-interfaces-to-free-unmapped-page-table include/asm-generic/pgtable.h
--- a/include/asm-generic/pgtable.h~mm-vmalloc-add-interfaces-to-free-unmapped-page-table
+++ a/include/asm-generic/pgtable.h
@@ -983,6 +983,8 @@ int pud_set_huge(pud_t *pud, phys_addr_t
int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
int pud_clear_huge(pud_t *pud);
int pmd_clear_huge(pmd_t *pmd);
+int pud_free_pmd_page(pud_t *pud);
+int pmd_free_pte_page(pmd_t *pmd);
#else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
static inline int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot)
{
@@ -1008,6 +1010,14 @@ static inline int pmd_clear_huge(pmd_t *
{
return 0;
}
+static inline int pud_free_pmd_page(pud_t *pud)
+{
+ return 0;
+}
+static inline int pmd_free_pte_page(pud_t *pmd)
+{
+ return 0;
+}
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
diff -puN lib/ioremap.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table lib/ioremap.c
--- a/lib/ioremap.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table
+++ a/lib/ioremap.c
@@ -91,7 +91,8 @@ static inline int ioremap_pmd_range(pud_
if (ioremap_pmd_enabled() &&
((next - addr) == PMD_SIZE) &&
- IS_ALIGNED(phys_addr + addr, PMD_SIZE)) {
+ IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
+ pmd_free_pte_page(pmd)) {
if (pmd_set_huge(pmd, phys_addr + addr, prot))
continue;
}
@@ -117,7 +118,8 @@ static inline int ioremap_pud_range(p4d_
if (ioremap_pud_enabled() &&
((next - addr) == PUD_SIZE) &&
- IS_ALIGNED(phys_addr + addr, PUD_SIZE)) {
+ IS_ALIGNED(phys_addr + addr, PUD_SIZE) &&
+ pud_free_pmd_page(pud)) {
if (pud_set_huge(pud, phys_addr + addr, prot))
continue;
}
_
Patches currently in -mm which might be from toshi.kani(a)hpe.com are
mm-vmalloc-add-interfaces-to-free-unmapped-page-table.patch
x86-mm-implement-free-pmd-pte-page-interfaces.patch
This is a note to let you know that I've just added the patch titled
mei: remove dev_err message on an unsupported ioctl
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the char-misc-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From bb0829a741792b56c908d7745bc0b2b540293bcc Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king(a)canonical.com>
Date: Tue, 27 Feb 2018 16:21:05 +0000
Subject: mei: remove dev_err message on an unsupported ioctl
Currently the driver spams the kernel log on unsupported ioctls which is
unnecessary as the ioctl returns -ENOIOCTLCMD to indicate this anyway.
I suspect this was originally for debugging purposes but it really is not
required so remove it.
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/mei/main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index 401b1bc4d282..7465f17e1559 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -528,7 +528,6 @@ static long mei_ioctl(struct file *file, unsigned int cmd, unsigned long data)
break;
default:
- dev_err(dev->dev, ": unsupported ioctl %d.\n", cmd);
rets = -ENOIOCTLCMD;
}
--
2.16.2
This is a note to let you know that I've just added the patch titled
parport_pc: Add support for WCH CH382L PCI-E single parallel port
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 823f7923833c6cc2b16e601546d607dcfb368004 Mon Sep 17 00:00:00 2001
From: Alexander Gerasiov <gq(a)redlab-i.ru>
Date: Sun, 4 Feb 2018 02:50:22 +0300
Subject: parport_pc: Add support for WCH CH382L PCI-E single parallel port
card.
WCH CH382L is a PCI-E adapter with 1 parallel port. It is similair to CH382
but serial ports are not soldered on board. Detected as
Serial controller: Device 1c00:3050 (rev 10) (prog-if 05 [16850])
Signed-off-by: Alexander Gerasiov <gq(a)redlab-i.ru>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/parport/parport_pc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 489492b608cf..380916bff9e0 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2646,6 +2646,7 @@ enum parport_pc_pci_cards {
netmos_9901,
netmos_9865,
quatech_sppxp100,
+ wch_ch382l,
};
@@ -2708,6 +2709,7 @@ static struct parport_pc_pci {
/* netmos_9901 */ { 1, { { 0, -1 }, } },
/* netmos_9865 */ { 1, { { 0, -1 }, } },
/* quatech_sppxp100 */ { 1, { { 0, 1 }, } },
+ /* wch_ch382l */ { 1, { { 2, -1 }, } },
};
static const struct pci_device_id parport_pc_pci_tbl[] = {
@@ -2797,6 +2799,8 @@ static const struct pci_device_id parport_pc_pci_tbl[] = {
/* Quatech SPPXP-100 Parallel port PCI ExpressCard */
{ PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_SPPXP_100,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, quatech_sppxp100 },
+ /* WCH CH382L PCI-E single parallel port card */
+ { 0x1c00, 0x3050, 0x1c00, 0x3050, 0, 0, wch_ch382l },
{ 0, } /* terminate list */
};
MODULE_DEVICE_TABLE(pci, parport_pc_pci_tbl);
--
2.16.2
This is a note to let you know that I've just added the patch titled
vt: change SGR 21 to follow the standards
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 65d9982d7e523a1a8e7c9af012da0d166f72fc56 Mon Sep 17 00:00:00 2001
From: Mike Frysinger <vapier(a)chromium.org>
Date: Mon, 29 Jan 2018 17:08:21 -0500
Subject: vt: change SGR 21 to follow the standards
ECMA-48 [1] (aka ISO 6429) has defined SGR 21 as "doubly underlined"
since at least March 1984. The Linux kernel has treated it as SGR 22
"normal intensity" since it was added in Linux-0.96b in June 1992.
Before that, it was simply ignored. Other terminal emulators have
either ignored it, or treat it as double underline now. xterm for
example added support in its 304 release (May 2014) [2] where it was
previously ignoring it.
Changing this behavior shouldn't be an issue:
- It isn't a named capability in ncurses's terminfo database, so no
script is using libtinfo/libcurses to look this up, or using tput
to query & output the right sequence.
- Any script assuming SGR 21 will reset intensity in all terminals
already do not work correctly on non-Linux VTs (including running
under screen/tmux/etc...).
- If someone has written a script that only runs in the Linux VT, and
they're using SGR 21 (instead of SGR 22), the output should still
be readable.
imo it's important to change this as the Linux VT's non-conformance
is sometimes used as an argument for other terminal emulators to not
implement SGR 21 at all, or do so incorrectly.
[1]: https://www.ecma-international.org/publications/standards/Ecma-048.htm
[2]: https://github.com/ThomasDickey/xterm-snapshots/commit/2fd29cb98d214cb536bc…
Signed-off-by: Mike Frysinger <vapier(a)chromium.org>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/vt/vt.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 88b902c525d7..16c0fcd6904a 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1354,6 +1354,11 @@ static void csi_m(struct vc_data *vc)
case 3:
vc->vc_italic = 1;
break;
+ case 21:
+ /*
+ * No console drivers support double underline, so
+ * convert it to a single underline.
+ */
case 4:
vc->vc_underline = 1;
break;
@@ -1389,7 +1394,6 @@ static void csi_m(struct vc_data *vc)
vc->vc_disp_ctrl = 1;
vc->vc_toggle_meta = 1;
break;
- case 21:
case 22:
vc->vc_intensity = 1;
break;
--
2.16.2
From: Koen Vandeputte <koen.vandeputte(a)ncentric.com>
commit fc110ebdd014dd1368c98e7685b47789c31fab42 upstream.
The subordinate value indicates the highest bus number which can be
reached downstream though a certain device.
Commit a20c7f36bd3d ("PCI: Do not allocate more buses than available in
parent") ensures that downstream devices cannot assign busnumbers higher
than the upstream device subordinate number, which was indeed illogical.
By default, dw_pcie_setup_rc() inits the Root Complex subordinate to a
value of 0x01.
Due to this combined with above commit, enumeration stops digging deeper
downstream as soon as bus num 0x01 has been assigned, which is always the
case for a bridge device.
This results in all devices behind a bridge bus remaining undetected, as
these would be connected to bus 0x02 or higher.
Fix this by initializing the RC to a subordinate value of 0xff, which is
not altering hardware behaviour in any way, but informs probing function
pci_scan_bridge() later on which reads this value back from register.
The following nasty errors during boot are also fixed by this:
pci_bus 0000:02: busn_res: can not insert [bus 02-ff] under [bus 01] (conflicts with (null) [bus 01])
...
pci_bus 0000:03: [bus 03] partially hidden behind bridge 0000:01 [bus 01]
...
pci_bus 0000:04: [bus 04] partially hidden behind bridge 0000:01 [bus 01]
...
pci_bus 0000:05: [bus 05] partially hidden behind bridge 0000:01 [bus 01]
pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 05
pci_bus 0000:02: busn_res: can not insert [bus 02-05] under [bus 01] (conflicts with (null) [bus 01])
pci_bus 0000:02: [bus 02-05] partially hidden behind bridge 0000:01 [bus 01]
Fixes: a20c7f36bd3d ("PCI: Do not allocate more buses than available in
parent")
Tested-by: Niklas Cassel <niklas.cassel(a)axis.com>
Tested-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Tested-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Signed-off-by: Koen Vandeputte <koen.vandeputte(a)ncentric.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Reviewed-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Acked-by: Lucas Stach <l.stach(a)pengutronix.de>
Cc: stable(a)vger.kernel.org
Cc: Binghui Wang <wangbinghui(a)hisilicon.com>
Cc: Jesper Nilsson <jesper.nilsson(a)axis.com>
Cc: Jianguo Sun <sunjianguo1(a)huawei.com>
Cc: Jingoo Han <jingoohan1(a)gmail.com>
Cc: Kishon Vijay Abraham I <kishon(a)ti.com>
Cc: Lucas Stach <l.stach(a)pengutronix.de>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Minghuan Lian <minghuan.Lian(a)freescale.com>
Cc: Mingkai Hu <mingkai.hu(a)freescale.com>
Cc: Murali Karicheri <m-karicheri2(a)ti.com>
Cc: Pratyush Anand <pratyush.anand(a)gmail.com>
Cc: Richard Zhu <hongxing.zhu(a)nxp.com>
Cc: Roy Zang <tie-fei.zang(a)freescale.com>
Cc: Shawn Guo <shawn.guo(a)linaro.org>
Cc: Stanimir Varbanov <svarbanov(a)mm-sol.com>
Cc: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Cc: Xiaowei Song <songxiaowei(a)hisilicon.com>
Cc: Zhou Wang <wangzhou1(a)hisilicon.com>
[fabio: adapted to the file location of 4.9 kernel]
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
---
drivers/pci/host/pcie-designware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index af8f6e9..b3a8715 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -861,7 +861,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
/* setup bus numbers */
val = dw_pcie_readl_rc(pp, PCI_PRIMARY_BUS);
val &= 0xff000000;
- val |= 0x00010100;
+ val |= 0x00ff0100;
dw_pcie_writel_rc(pp, PCI_PRIMARY_BUS, val);
/* setup command register */
--
2.7.4
1. With the patch "x86/vector/msi: Switch to global reservation mode"
(4900be8360), the recent v4.15 and newer kernels always hang for 1-vCPU
Hyper-V VM with SR-IOV. This is because when we reach hv_compose_msi_msg()
by request_irq() -> request_threaded_irq() -> __setup_irq()->irq_startup()
-> __irq_startup() -> irq_domain_activate_irq() -> ... ->
msi_domain_activate() -> ... -> hv_compose_msi_msg(), local irq is
disabled in __setup_irq().
Fix this by polling the channel.
2. If the host is ejecting the VF device before we reach
hv_compose_msi_msg(), in a UP VM, we can hang in hv_compose_msi_msg()
forever, because at this time the host doesn't respond to the
CREATE_INTERRUPT request. This issue also happens to old kernels like
v4.14, v4.13, etc.
Fix this by polling the channel for the PCI_EJECT message and
hpdev->state, and by checking the PCI vendor ID.
Note: actually the above issues also happen to a SMP VM, if
"hbus->hdev->channel->target_cpu == smp_processor_id()" is true.
Signed-off-by: Dexuan Cui <decui(a)microsoft.com>
Tested-by: Adrian Suhov <v-adsuho(a)microsoft.com>
Tested-by: Chris Valean <v-chvale(a)microsoft.com>
Cc: stable(a)vger.kernel.org
Cc: Stephen Hemminger <sthemmin(a)microsoft.com>
Cc: K. Y. Srinivasan <kys(a)microsoft.com>
Cc: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Cc: Jack Morgenstein <jackm(a)mellanox.com>
---
drivers/pci/host/pci-hyperv.c | 58 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 265ba11e53e2..50cdefe3f6d3 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -521,6 +521,8 @@ struct hv_pci_compl {
s32 completion_status;
};
+static void hv_pci_onchannelcallback(void *context);
+
/**
* hv_pci_generic_compl() - Invoked for a completion packet
* @context: Set up by the sender of the packet.
@@ -665,6 +667,31 @@ static void _hv_pcifront_read_config(struct hv_pci_dev *hpdev, int where,
}
}
+static u16 hv_pcifront_get_vendor_id(struct hv_pci_dev *hpdev)
+{
+ u16 ret;
+ unsigned long flags;
+ void __iomem *addr = hpdev->hbus->cfg_addr + CFG_PAGE_OFFSET +
+ PCI_VENDOR_ID;
+
+ spin_lock_irqsave(&hpdev->hbus->config_lock, flags);
+
+ /* Choose the function to be read. (See comment above) */
+ writel(hpdev->desc.win_slot.slot, hpdev->hbus->cfg_addr);
+ /* Make sure the function was chosen before we start reading. */
+ mb();
+ /* Read from that function's config space. */
+ ret = readw(addr);
+ /*
+ * mb() is not required here, because the spin_unlock_irqrestore()
+ * is a barrier.
+ */
+
+ spin_unlock_irqrestore(&hpdev->hbus->config_lock, flags);
+
+ return ret;
+}
+
/**
* _hv_pcifront_write_config() - Internal PCI config write
* @hpdev: The PCI driver's representation of the device
@@ -1107,8 +1134,37 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
* Since this function is called with IRQ locks held, can't
* do normal wait for completion; instead poll.
*/
- while (!try_wait_for_completion(&comp.comp_pkt.host_event))
+ while (!try_wait_for_completion(&comp.comp_pkt.host_event)) {
+ /* 0xFFFF means an invalid PCI VENDOR ID. */
+ if (hv_pcifront_get_vendor_id(hpdev) == 0xFFFF) {
+ dev_err_once(&hbus->hdev->device,
+ "the device has gone\n");
+ goto free_int_desc;
+ }
+
+ /*
+ * When the higher level interrupt code calls us with
+ * interrupt disabled, we must poll the channel by calling
+ * the channel callback directly when channel->target_cpu is
+ * the current CPU. When the higher level interrupt code
+ * calls us with interrupt enabled, let's add the
+ * local_bh_disable()/enable() to avoid race.
+ */
+ local_bh_disable();
+
+ if (hbus->hdev->channel->target_cpu == smp_processor_id())
+ hv_pci_onchannelcallback(hbus);
+
+ local_bh_enable();
+
+ if (hpdev->state == hv_pcichild_ejecting) {
+ dev_err_once(&hbus->hdev->device,
+ "the device is being ejected\n");
+ goto free_int_desc;
+ }
+
udelay(100);
+ }
if (comp.comp_pkt.completion_status < 0) {
dev_err(&hbus->hdev->device,
--
2.7.4
This is a note to let you know that I've just added the patch titled
vt: change SGR 21 to follow the standards
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the tty-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 65d9982d7e523a1a8e7c9af012da0d166f72fc56 Mon Sep 17 00:00:00 2001
From: Mike Frysinger <vapier(a)chromium.org>
Date: Mon, 29 Jan 2018 17:08:21 -0500
Subject: vt: change SGR 21 to follow the standards
ECMA-48 [1] (aka ISO 6429) has defined SGR 21 as "doubly underlined"
since at least March 1984. The Linux kernel has treated it as SGR 22
"normal intensity" since it was added in Linux-0.96b in June 1992.
Before that, it was simply ignored. Other terminal emulators have
either ignored it, or treat it as double underline now. xterm for
example added support in its 304 release (May 2014) [2] where it was
previously ignoring it.
Changing this behavior shouldn't be an issue:
- It isn't a named capability in ncurses's terminfo database, so no
script is using libtinfo/libcurses to look this up, or using tput
to query & output the right sequence.
- Any script assuming SGR 21 will reset intensity in all terminals
already do not work correctly on non-Linux VTs (including running
under screen/tmux/etc...).
- If someone has written a script that only runs in the Linux VT, and
they're using SGR 21 (instead of SGR 22), the output should still
be readable.
imo it's important to change this as the Linux VT's non-conformance
is sometimes used as an argument for other terminal emulators to not
implement SGR 21 at all, or do so incorrectly.
[1]: https://www.ecma-international.org/publications/standards/Ecma-048.htm
[2]: https://github.com/ThomasDickey/xterm-snapshots/commit/2fd29cb98d214cb536bc…
Signed-off-by: Mike Frysinger <vapier(a)chromium.org>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/vt/vt.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 88b902c525d7..16c0fcd6904a 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1354,6 +1354,11 @@ static void csi_m(struct vc_data *vc)
case 3:
vc->vc_italic = 1;
break;
+ case 21:
+ /*
+ * No console drivers support double underline, so
+ * convert it to a single underline.
+ */
case 4:
vc->vc_underline = 1;
break;
@@ -1389,7 +1394,6 @@ static void csi_m(struct vc_data *vc)
vc->vc_disp_ctrl = 1;
vc->vc_toggle_meta = 1;
break;
- case 21:
case 22:
vc->vc_intensity = 1;
break;
--
2.16.2
This is a note to let you know that I've just added the patch titled
parport_pc: Add support for WCH CH382L PCI-E single parallel port
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the char-misc-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 823f7923833c6cc2b16e601546d607dcfb368004 Mon Sep 17 00:00:00 2001
From: Alexander Gerasiov <gq(a)redlab-i.ru>
Date: Sun, 4 Feb 2018 02:50:22 +0300
Subject: parport_pc: Add support for WCH CH382L PCI-E single parallel port
card.
WCH CH382L is a PCI-E adapter with 1 parallel port. It is similair to CH382
but serial ports are not soldered on board. Detected as
Serial controller: Device 1c00:3050 (rev 10) (prog-if 05 [16850])
Signed-off-by: Alexander Gerasiov <gq(a)redlab-i.ru>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/parport/parport_pc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 489492b608cf..380916bff9e0 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2646,6 +2646,7 @@ enum parport_pc_pci_cards {
netmos_9901,
netmos_9865,
quatech_sppxp100,
+ wch_ch382l,
};
@@ -2708,6 +2709,7 @@ static struct parport_pc_pci {
/* netmos_9901 */ { 1, { { 0, -1 }, } },
/* netmos_9865 */ { 1, { { 0, -1 }, } },
/* quatech_sppxp100 */ { 1, { { 0, 1 }, } },
+ /* wch_ch382l */ { 1, { { 2, -1 }, } },
};
static const struct pci_device_id parport_pc_pci_tbl[] = {
@@ -2797,6 +2799,8 @@ static const struct pci_device_id parport_pc_pci_tbl[] = {
/* Quatech SPPXP-100 Parallel port PCI ExpressCard */
{ PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_SPPXP_100,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, quatech_sppxp100 },
+ /* WCH CH382L PCI-E single parallel port card */
+ { 0x1c00, 0x3050, 0x1c00, 0x3050, 0, 0, wch_ch382l },
{ 0, } /* terminate list */
};
MODULE_DEVICE_TABLE(pci, parport_pc_pci_tbl);
--
2.16.2
From: Andri Yngvason <andri.yngvason(a)marel.com>
While waiting for the TX object to send an RTR, an external message with a
matching id can overwrite the TX data. In this case we must call the rx
routine and then try transmitting the message that was overwritten again.
The queue was being stalled because the RX event did not generate an
interrupt to wake up the queue again and the TX event did not happen
because the TXRQST flag is reset by the chip when new data is received.
According to the CC770 datasheet the id of a message object should not be
changed while the MSGVAL bit is set. This has been fixed by resetting the
MSGVAL bit before modifying the object in the transmit function and setting
it after. It is not enough to set & reset CPUUPD.
It is important to keep the MSGVAL bit reset while the message object is
being modified. Otherwise, during RTR transmission, a frame with matching
id could trigger an rx-interrupt, which would cause a race condition
between the interrupt routine and the transmit function.
Signed-off-by: Andri Yngvason <andri.yngvason(a)marel.com>
Tested-by: Richard Weinberger <richard(a)nod.at>
Cc: linux-stable <stable(a)vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
---
drivers/net/can/cc770/cc770.c | 94 ++++++++++++++++++++++++++++++-------------
drivers/net/can/cc770/cc770.h | 2 +
2 files changed, 68 insertions(+), 28 deletions(-)
diff --git a/drivers/net/can/cc770/cc770.c b/drivers/net/can/cc770/cc770.c
index 9fed163262e0..2743d82d4424 100644
--- a/drivers/net/can/cc770/cc770.c
+++ b/drivers/net/can/cc770/cc770.c
@@ -390,37 +390,23 @@ static int cc770_get_berr_counter(const struct net_device *dev,
return 0;
}
-static netdev_tx_t cc770_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static void cc770_tx(struct net_device *dev, int mo)
{
struct cc770_priv *priv = netdev_priv(dev);
- struct net_device_stats *stats = &dev->stats;
- struct can_frame *cf = (struct can_frame *)skb->data;
- unsigned int mo = obj2msgobj(CC770_OBJ_TX);
+ struct can_frame *cf = (struct can_frame *)priv->tx_skb->data;
u8 dlc, rtr;
u32 id;
int i;
- if (can_dropped_invalid_skb(dev, skb))
- return NETDEV_TX_OK;
-
- if ((cc770_read_reg(priv,
- msgobj[mo].ctrl1) & TXRQST_UNC) == TXRQST_SET) {
- netdev_err(dev, "TX register is still occupied!\n");
- return NETDEV_TX_BUSY;
- }
-
- netif_stop_queue(dev);
-
dlc = cf->can_dlc;
id = cf->can_id;
- if (cf->can_id & CAN_RTR_FLAG)
- rtr = 0;
- else
- rtr = MSGCFG_DIR;
+ rtr = cf->can_id & CAN_RTR_FLAG ? 0 : MSGCFG_DIR;
+
+ cc770_write_reg(priv, msgobj[mo].ctrl0,
+ MSGVAL_RES | TXIE_RES | RXIE_RES | INTPND_RES);
cc770_write_reg(priv, msgobj[mo].ctrl1,
RMTPND_RES | TXRQST_RES | CPUUPD_SET | NEWDAT_RES);
- cc770_write_reg(priv, msgobj[mo].ctrl0,
- MSGVAL_SET | TXIE_SET | RXIE_RES | INTPND_RES);
+
if (id & CAN_EFF_FLAG) {
id &= CAN_EFF_MASK;
cc770_write_reg(priv, msgobj[mo].config,
@@ -439,13 +425,30 @@ static netdev_tx_t cc770_start_xmit(struct sk_buff *skb, struct net_device *dev)
for (i = 0; i < dlc; i++)
cc770_write_reg(priv, msgobj[mo].data[i], cf->data[i]);
- /* Store echo skb before starting the transfer */
- can_put_echo_skb(skb, dev, 0);
-
cc770_write_reg(priv, msgobj[mo].ctrl1,
- RMTPND_RES | TXRQST_SET | CPUUPD_RES | NEWDAT_UNC);
+ RMTPND_UNC | TXRQST_SET | CPUUPD_RES | NEWDAT_UNC);
+ cc770_write_reg(priv, msgobj[mo].ctrl0,
+ MSGVAL_SET | TXIE_SET | RXIE_SET | INTPND_UNC);
+}
+
+static netdev_tx_t cc770_start_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct cc770_priv *priv = netdev_priv(dev);
+ unsigned int mo = obj2msgobj(CC770_OBJ_TX);
+
+ if (can_dropped_invalid_skb(dev, skb))
+ return NETDEV_TX_OK;
- stats->tx_bytes += dlc;
+ netif_stop_queue(dev);
+
+ if ((cc770_read_reg(priv,
+ msgobj[mo].ctrl1) & TXRQST_UNC) == TXRQST_SET) {
+ netdev_err(dev, "TX register is still occupied!\n");
+ return NETDEV_TX_BUSY;
+ }
+
+ priv->tx_skb = skb;
+ cc770_tx(dev, mo);
return NETDEV_TX_OK;
}
@@ -671,13 +674,47 @@ static void cc770_tx_interrupt(struct net_device *dev, unsigned int o)
struct cc770_priv *priv = netdev_priv(dev);
struct net_device_stats *stats = &dev->stats;
unsigned int mo = obj2msgobj(o);
+ struct can_frame *cf;
+ u8 ctrl1;
+
+ ctrl1 = cc770_read_reg(priv, msgobj[mo].ctrl1);
- /* Nothing more to send, switch off interrupts */
cc770_write_reg(priv, msgobj[mo].ctrl0,
MSGVAL_RES | TXIE_RES | RXIE_RES | INTPND_RES);
+ cc770_write_reg(priv, msgobj[mo].ctrl1,
+ RMTPND_RES | TXRQST_RES | MSGLST_RES | NEWDAT_RES);
- stats->tx_packets++;
+ if (unlikely(!priv->tx_skb)) {
+ netdev_err(dev, "missing tx skb in tx interrupt\n");
+ return;
+ }
+
+ if (unlikely(ctrl1 & MSGLST_SET)) {
+ stats->rx_over_errors++;
+ stats->rx_errors++;
+ }
+
+ /* When the CC770 is sending an RTR message and it receives a regular
+ * message that matches the id of the RTR message, it will overwrite the
+ * outgoing message in the TX register. When this happens we must
+ * process the received message and try to transmit the outgoing skb
+ * again.
+ */
+ if (unlikely(ctrl1 & NEWDAT_SET)) {
+ cc770_rx(dev, mo, ctrl1);
+ cc770_tx(dev, mo);
+ return;
+ }
+
+ can_put_echo_skb(priv->tx_skb, dev, 0);
can_get_echo_skb(dev, 0);
+
+ cf = (struct can_frame *)priv->tx_skb->data;
+ stats->tx_bytes += cf->can_dlc;
+ stats->tx_packets++;
+
+ priv->tx_skb = NULL;
+
netif_wake_queue(dev);
}
@@ -789,6 +826,7 @@ struct net_device *alloc_cc770dev(int sizeof_priv)
priv->can.do_set_bittiming = cc770_set_bittiming;
priv->can.do_set_mode = cc770_set_mode;
priv->can.ctrlmode_supported = CAN_CTRLMODE_3_SAMPLES;
+ priv->tx_skb = NULL;
memcpy(priv->obj_flags, cc770_obj_flags, sizeof(cc770_obj_flags));
diff --git a/drivers/net/can/cc770/cc770.h b/drivers/net/can/cc770/cc770.h
index a1739db98d91..95752e1d1283 100644
--- a/drivers/net/can/cc770/cc770.h
+++ b/drivers/net/can/cc770/cc770.h
@@ -193,6 +193,8 @@ struct cc770_priv {
u8 cpu_interface; /* CPU interface register */
u8 clkout; /* Clock out register */
u8 bus_config; /* Bus conffiguration register */
+
+ struct sk_buff *tx_skb;
};
struct net_device *alloc_cc770dev(int sizeof_priv);
--
2.16.1
Sehr geehrte Damen und Herren,
nach unserem Besuch Ihrer Homepage möchten wir Ihnen ein Angebot von Produkten vorstellen, das Ihnen ermöglichen wird, den Verkauf Ihrer Produkte sowie Dienstleistungen deutlich zu erhöhen.
Die Datenbanken der Firmen sind in für Sie interessante und relevante Zielgruppen unterglieder.
Ich biete Ihnen den ganz neuen Adressenkatalog der Schweizer Unternehmen an, in dem sich direkte Kontaktdaten der Firmeninhaber und Manager befinden.
Der neue Katalog enthält 187.764 schweizerische Firmen und stellt solche Daten zur Verfügung wie: Namen der Firma, Firmenanschrift, Kontaktdaten des Firmeninhabers oder des Managers, E-Mail-Adresse, Telefon, Faxnummer, Branche usw.
http://www.db-marketing-schweiz.net/?page=catalog
Die Verwendungsmöglichkeiten der Datenbanken sind praktisch unbegrenzt und Sie können durch Verwendung
der von uns entwickelten Programme des personalisierten Versendens von Angeboten u.ä. mittels
E-mailing bzw. Fax effektive und sichere Werbekampagnen damit durchführen.
Bitte informieren Sie sich über die weiteren Details einmal unverbindlich auf unseren Webseite:
http://www.db-marketing-schweiz.net/?page=catalog
MfG
GL-Marketing.
This is a note to let you know that I've just added the patch titled
scripts: recordmcount: break hardlinks
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:
scripts-recordmcount-break-hardlinks.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 dd39a26538e37f6c6131e829a4a510787e43c783 Mon Sep 17 00:00:00 2001
From: Russell King <rmk+kernel(a)arm.linux.org.uk>
Date: Fri, 11 Dec 2015 12:09:03 +0000
Subject: scripts: recordmcount: break hardlinks
From: Russell King <rmk+kernel(a)arm.linux.org.uk>
commit dd39a26538e37f6c6131e829a4a510787e43c783 upstream.
recordmcount edits the file in-place, which can cause problems when
using ccache in hardlink mode. Arrange for recordmcount to break a
hardlinked object.
Link: http://lkml.kernel.org/r/E1a7MVT-0000et-62@rmk-PC.arm.linux.org.uk
Cc: stable(a)vger.kernel.org # 2.6.37+
Signed-off-by: Russell King <rmk+kernel(a)arm.linux.org.uk>
Signed-off-by: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
scripts/recordmcount.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -201,6 +201,20 @@ static void *mmap_file(char const *fname
addr = umalloc(sb.st_size);
uread(fd_map, addr, sb.st_size);
}
+ if (sb.st_nlink != 1) {
+ /* file is hard-linked, break the hard link */
+ close(fd_map);
+ if (unlink(fname) < 0) {
+ perror(fname);
+ fail_file();
+ }
+ fd_map = open(fname, O_RDWR | O_CREAT, sb.st_mode);
+ if (fd_map < 0) {
+ perror(fname);
+ fail_file();
+ }
+ uwrite(fd_map, addr, sb.st_size);
+ }
return addr;
}
Patches currently in stable-queue which might be from rmk+kernel(a)arm.linux.org.uk are
queue-3.18/scripts-recordmcount-break-hardlinks.patch