* [PATCH 4.20 01/57] powerpc/tm: Unset MSR[TS] if not recheckpointing
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 02/57] Btrfs: fix deadlock when using free space tree due to block group creation Greg Kroah-Hartman
` (58 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Breno Leitao, Michal Suchánek,
Michael Ellerman
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <leitao@debian.org>
commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.
There is a TM Bad Thing bug that can be caused when you return from a
signal context in a suspended transaction but with ucontext MSR[TS] unset.
This forces regs->msr[TS] to be set at syscall entrance (since the CPU
state is transactional). It also calls treclaim() to flush the transaction
state, which is done based on the live (mfmsr) MSR state.
Since user context MSR[TS] is not set, then restore_tm_sigcontexts() is not
called, thus, not executing recheckpoint, keeping the CPU state as not
transactional. When calling rfid, SRR1 will have MSR[TS] set, but the CPU
state is non transactional, causing the TM Bad Thing with the following
stack:
[ 33.862316] Bad kernel stack pointer 3fffd9dce3e0 at c00000000000c47c
cpu 0x8: Vector: 700 (Program Check) at [c00000003ff7fd40]
pc: c00000000000c47c: fast_exception_return+0xac/0xb4
lr: 00003fff865f442c
sp: 3fffd9dce3e0
msr: 8000000102a03031
current = 0xc00000041f68b700
paca = 0xc00000000fb84800 softe: 0 irq_happened: 0x01
pid = 1721, comm = tm-signal-sigre
Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)
WARNING: exception is not recoverable, can't continue
The same problem happens on 32-bits signal handler, and the fix is very
similar, if tm_recheckpoint() is not executed, then regs->msr[TS] should be
zeroed.
This patch also fixes a sparse warning related to lack of indentation when
CONFIG_PPC_TRANSACTIONAL_MEM is set.
Fixes: 2b0a576d15e0e ("powerpc: Add new transactional memory state to the signal context")
CC: Stable <stable@vger.kernel.org> # 3.10+
Signed-off-by: Breno Leitao <leitao@debian.org>
Tested-by: Michal Suchánek <msuchanek@suse.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/signal_32.c | 18 +++++++++++++-----
arch/powerpc/kernel/signal_64.c | 20 ++++++++++++++++----
2 files changed, 29 insertions(+), 9 deletions(-)
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -1158,11 +1158,11 @@ SYSCALL_DEFINE0(rt_sigreturn)
{
struct rt_sigframe __user *rt_sf;
struct pt_regs *regs = current_pt_regs();
+ int tm_restore = 0;
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
struct ucontext __user *uc_transact;
unsigned long msr_hi;
unsigned long tmp;
- int tm_restore = 0;
#endif
/* Always make any pending restarted system calls return -EINTR */
current->restart_block.fn = do_no_restart_syscall;
@@ -1210,11 +1210,19 @@ SYSCALL_DEFINE0(rt_sigreturn)
goto bad;
}
}
- if (!tm_restore)
- /* Fall through, for non-TM restore */
+ if (!tm_restore) {
+ /*
+ * Unset regs->msr because ucontext MSR TS is not
+ * set, and recheckpoint was not called. This avoid
+ * hitting a TM Bad thing at RFID
+ */
+ regs->msr &= ~MSR_TS_MASK;
+ }
+ /* Fall through, for non-TM restore */
#endif
- if (do_setcontext(&rt_sf->uc, regs, 1))
- goto bad;
+ if (!tm_restore)
+ if (do_setcontext(&rt_sf->uc, regs, 1))
+ goto bad;
/*
* It's not clear whether or why it is desirable to save the
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -756,11 +756,23 @@ SYSCALL_DEFINE0(rt_sigreturn)
&uc_transact->uc_mcontext))
goto badframe;
}
- else
- /* Fall through, for non-TM restore */
#endif
- if (restore_sigcontext(current, NULL, 1, &uc->uc_mcontext))
- goto badframe;
+ /* Fall through, for non-TM restore */
+ if (!MSR_TM_ACTIVE(msr)) {
+ /*
+ * Unset MSR[TS] on the thread regs since MSR from user
+ * context does not have MSR active, and recheckpoint was
+ * not called since restore_tm_sigcontexts() was not called
+ * also.
+ *
+ * If not unsetting it, the code can RFID to userspace with
+ * MSR[TS] set, but without CPU in the proper state,
+ * causing a TM bad thing.
+ */
+ current->thread.regs->msr &= ~MSR_TS_MASK;
+ if (restore_sigcontext(current, NULL, 1, &uc->uc_mcontext))
+ goto badframe;
+ }
if (restore_altstack(&uc->uc_stack))
goto badframe;
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 02/57] Btrfs: fix deadlock when using free space tree due to block group creation
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 01/57] powerpc/tm: Unset MSR[TS] if not recheckpointing Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 03/57] usbcore: Select only first configuration for non-UAC3 compliant devices Greg Kroah-Hartman
` (57 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Filipe Manana, David Sterba
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <fdmanana@suse.com>
commit a6d8654d885d7d79a3fb82da64eaa489ca332a82 upstream.
When modifying the free space tree we can end up COWing one of its extent
buffers which in turn might result in allocating a new chunk, which in
turn can result in flushing (finish creation) of pending block groups. If
that happens we can deadlock because creating a pending block group needs
to update the free space tree, and if any of the updates tries to modify
the same extent buffer that we are COWing, we end up in a deadlock since
we try to write lock twice the same extent buffer.
So fix this by skipping pending block group creation if we are COWing an
extent buffer from the free space tree. This is a case missed by commit
5ce555578e091 ("Btrfs: fix deadlock when writing out free space caches").
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202173
Fixes: 5ce555578e091 ("Btrfs: fix deadlock when writing out free space caches")
CC: stable@vger.kernel.org # 4.18+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/ctree.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -1015,19 +1015,21 @@ static noinline int __btrfs_cow_block(st
parent_start = parent->start;
/*
- * If we are COWing a node/leaf from the extent, chunk or device trees,
- * make sure that we do not finish block group creation of pending block
- * groups. We do this to avoid a deadlock.
+ * If we are COWing a node/leaf from the extent, chunk, device or free
+ * space trees, make sure that we do not finish block group creation of
+ * pending block groups. We do this to avoid a deadlock.
* COWing can result in allocation of a new chunk, and flushing pending
* block groups (btrfs_create_pending_block_groups()) can be triggered
* when finishing allocation of a new chunk. Creation of a pending block
- * group modifies the extent, chunk and device trees, therefore we could
- * deadlock with ourselves since we are holding a lock on an extent
- * buffer that btrfs_create_pending_block_groups() may try to COW later.
+ * group modifies the extent, chunk, device and free space trees,
+ * therefore we could deadlock with ourselves since we are holding a
+ * lock on an extent buffer that btrfs_create_pending_block_groups() may
+ * try to COW later.
*/
if (root == fs_info->extent_root ||
root == fs_info->chunk_root ||
- root == fs_info->dev_root)
+ root == fs_info->dev_root ||
+ root == fs_info->free_space_root)
trans->can_flush_pending_bgs = false;
cow = btrfs_alloc_tree_block(trans, root, parent_start,
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 03/57] usbcore: Select only first configuration for non-UAC3 compliant devices
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 01/57] powerpc/tm: Unset MSR[TS] if not recheckpointing Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 02/57] Btrfs: fix deadlock when using free space tree due to block group creation Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 04/57] staging: rtl8188eu: Fix module loading from tasklet for CCMP encryption Greg Kroah-Hartman
` (56 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Con Kolivas, Saranya Gopal
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Saranya Gopal <saranya.gopal@intel.com>
commit ff2a8c532c14fd22fb26a36574d9ff199afbbe54 upstream.
In most of the UAC1 and UAC2 audio devices, the first
configuration is most often the best configuration.
However, with recent patch to support UAC3 configuration,
second configuration was unintentionally chosen for
some of the UAC1/2 devices that had more than one
configuration. This was because of the existing check
after the audio config check which selected any config
which had a non-vendor class. This patch fixes this issue.
Fixes: f13912d3f014 ("usbcore: Select UAC3 configuration for audio if present")
Reported-by: Con Kolivas <kernel@kolivas.org>
Signed-off-by: Saranya Gopal <saranya.gopal@intel.com>
Tested-by: Con Kolivas <kernel@kolivas.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/generic.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/usb/core/generic.c
+++ b/drivers/usb/core/generic.c
@@ -143,9 +143,12 @@ int usb_choose_configuration(struct usb_
continue;
}
- if (i > 0 && desc && is_audio(desc) && is_uac3_config(desc)) {
- best = c;
- break;
+ if (i > 0 && desc && is_audio(desc)) {
+ if (is_uac3_config(desc)) {
+ best = c;
+ break;
+ }
+ continue;
}
/* From the remaining configs, choose the first one whose
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 04/57] staging: rtl8188eu: Fix module loading from tasklet for CCMP encryption
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 03/57] usbcore: Select only first configuration for non-UAC3 compliant devices Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 05/57] staging: rtl8188eu: Fix module loading from tasklet for WEP encryption Greg Kroah-Hartman
` (55 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ivan Safonov, Larry Finger, Michael Straube
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <Larry.Finger@lwfinger.net>
commit 84cad97a717f5749a0236abd5ce68da582ea074f upstream.
Commit 6bd082af7e36 ("staging:r8188eu: use lib80211 CCMP decrypt")
causes scheduling while atomic bugs followed by a hard freeze whenever
the driver tries to connect to a CCMP-encrypted network. Experimentation
showed that the freezes were eliminated when module lib80211 was
preloaded, which can be forced by calling lib80211_get_crypto_ops()
directly rather than indirectly through try_then_request_module().
With this change, no BUG messages are logged.
Fixes: 6bd082af7e36 ("staging:r8188eu: use lib80211 CCMP decrypt")
Cc: Stable <stable@vger.kernel.org> # v4.17+
Reported-and-tested-by: Michael Straube <straube.linux@gmail.com>
Cc: Ivan Safonov <insafonov@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/rtl8188eu/core/rtw_security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -1291,7 +1291,7 @@ u32 rtw_aes_decrypt(struct adapter *pada
struct sk_buff *skb = ((struct recv_frame *)precvframe)->pkt;
void *crypto_private = NULL;
u8 *key, *pframe = skb->data;
- struct lib80211_crypto_ops *crypto_ops = try_then_request_module(lib80211_get_crypto_ops("CCMP"), "lib80211_crypt_ccmp");
+ struct lib80211_crypto_ops *crypto_ops = lib80211_get_crypto_ops("CCMP");
struct security_priv *psecuritypriv = &padapter->securitypriv;
char iv[8], icv[8];
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 05/57] staging: rtl8188eu: Fix module loading from tasklet for WEP encryption
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 04/57] staging: rtl8188eu: Fix module loading from tasklet for CCMP encryption Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 06/57] cpufreq: scpi/scmi: Fix freeing of dynamic OPPs Greg Kroah-Hartman
` (54 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Straube, Ivan Safonov, Larry Finger
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <Larry.Finger@lwfinger.net>
commit 7775665aadc48a562051834a73519129bf717d73 upstream.
Commit 2b2ea09e74a5 ("staging:r8188eu: Use lib80211 to decrypt WEP-frames")
causes scheduling while atomic bugs followed by a hard freeze whenever
the driver tries to connect to a WEP-encrypted network. Experimentation
showed that the freezes were eliminated when module lib80211 was
preloaded, which can be forced by calling lib80211_get_crypto_ops()
directly rather than indirectly through try_then_request_module().
With this change, no BUG messages are logged.
Fixes: 2b2ea09e74a5 ("staging:r8188eu: Use lib80211 to decrypt WEP-frames")
Cc: Stable <stable@vger.kernel.org> # v4.17+
Cc: Michael Straube <straube.linux@gmail.com>
Cc: Ivan Safonov <insafonov@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/rtl8188eu/core/rtw_security.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -154,7 +154,7 @@ void rtw_wep_encrypt(struct adapter *pad
pframe = ((struct xmit_frame *)pxmitframe)->buf_addr + hw_hdr_offset;
- crypto_ops = try_then_request_module(lib80211_get_crypto_ops("WEP"), "lib80211_crypt_wep");
+ crypto_ops = lib80211_get_crypto_ops("WEP");
if (!crypto_ops)
return;
@@ -210,7 +210,7 @@ int rtw_wep_decrypt(struct adapter *pad
void *crypto_private = NULL;
int status = _SUCCESS;
const int keyindex = prxattrib->key_index;
- struct lib80211_crypto_ops *crypto_ops = try_then_request_module(lib80211_get_crypto_ops("WEP"), "lib80211_crypt_wep");
+ struct lib80211_crypto_ops *crypto_ops = lib80211_get_crypto_ops("WEP");
char iv[4], icv[4];
if (!crypto_ops) {
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 06/57] cpufreq: scpi/scmi: Fix freeing of dynamic OPPs
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 05/57] staging: rtl8188eu: Fix module loading from tasklet for WEP encryption Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 07/57] cpufreq: scmi: Fix frequency invariance in slow path Greg Kroah-Hartman
` (53 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Valentin Schneider, Viresh Kumar,
Sudeep Holla, Rafael J. Wysocki
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viresh Kumar <viresh.kumar@linaro.org>
commit 1690d8bb91e370ab772062b79bd434ce815c4729 upstream.
Since the commit 2a4eb7358aba "OPP: Don't remove dynamic OPPs from
_dev_pm_opp_remove_table()", dynamically created OPP aren't
automatically removed anymore by dev_pm_opp_cpumask_remove_table(). This
affects the scpi and scmi cpufreq drivers which no longer free OPPs on
failures or on invocations of the policy->exit() callback.
Create a generic OPP helper dev_pm_opp_remove_all_dynamic() which can be
called from these drivers instead of dev_pm_opp_cpumask_remove_table().
In dev_pm_opp_remove_all_dynamic(), we need to make sure that the
opp_list isn't getting accessed simultaneously from other parts of the
OPP core while the helper is freeing dynamic OPPs, i.e. we can't drop
the opp_table->lock while traversing through the OPP list. And to
accomplish that, this patch also creates _opp_kref_release_unlocked()
which can be called from this new helper with the opp_table lock already
held.
Cc: 4.20 <stable@vger.kernel.org> # v4.20
Reported-by: Valentin Schneider <valentin.schneider@arm.com>
Fixes: 2a4eb7358aba "OPP: Don't remove dynamic OPPs from _dev_pm_opp_remove_table()"
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Valentin Schneider <valentin.schneider@arm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/cpufreq/scmi-cpufreq.c | 4 +-
drivers/cpufreq/scpi-cpufreq.c | 4 +-
drivers/opp/core.c | 63 +++++++++++++++++++++++++++++++++++++----
include/linux/pm_opp.h | 5 +++
4 files changed, 67 insertions(+), 9 deletions(-)
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -176,7 +176,7 @@ static int scmi_cpufreq_init(struct cpuf
out_free_priv:
kfree(priv);
out_free_opp:
- dev_pm_opp_cpumask_remove_table(policy->cpus);
+ dev_pm_opp_remove_all_dynamic(cpu_dev);
return ret;
}
@@ -188,7 +188,7 @@ static int scmi_cpufreq_exit(struct cpuf
cpufreq_cooling_unregister(priv->cdev);
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
kfree(priv);
- dev_pm_opp_cpumask_remove_table(policy->related_cpus);
+ dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
return 0;
}
--- a/drivers/cpufreq/scpi-cpufreq.c
+++ b/drivers/cpufreq/scpi-cpufreq.c
@@ -177,7 +177,7 @@ out_free_cpufreq_table:
out_free_priv:
kfree(priv);
out_free_opp:
- dev_pm_opp_cpumask_remove_table(policy->cpus);
+ dev_pm_opp_remove_all_dynamic(cpu_dev);
return ret;
}
@@ -190,7 +190,7 @@ static int scpi_cpufreq_exit(struct cpuf
clk_put(priv->clk);
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
kfree(priv);
- dev_pm_opp_cpumask_remove_table(policy->related_cpus);
+ dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
return 0;
}
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -951,11 +951,9 @@ void _opp_free(struct dev_pm_opp *opp)
kfree(opp);
}
-static void _opp_kref_release(struct kref *kref)
+static void _opp_kref_release(struct dev_pm_opp *opp,
+ struct opp_table *opp_table)
{
- struct dev_pm_opp *opp = container_of(kref, struct dev_pm_opp, kref);
- struct opp_table *opp_table = opp->opp_table;
-
/*
* Notify the changes in the availability of the operable
* frequency/voltage list.
@@ -964,7 +962,22 @@ static void _opp_kref_release(struct kre
opp_debug_remove_one(opp);
list_del(&opp->node);
kfree(opp);
+}
+
+static void _opp_kref_release_unlocked(struct kref *kref)
+{
+ struct dev_pm_opp *opp = container_of(kref, struct dev_pm_opp, kref);
+ struct opp_table *opp_table = opp->opp_table;
+
+ _opp_kref_release(opp, opp_table);
+}
+static void _opp_kref_release_locked(struct kref *kref)
+{
+ struct dev_pm_opp *opp = container_of(kref, struct dev_pm_opp, kref);
+ struct opp_table *opp_table = opp->opp_table;
+
+ _opp_kref_release(opp, opp_table);
mutex_unlock(&opp_table->lock);
}
@@ -975,10 +988,16 @@ void dev_pm_opp_get(struct dev_pm_opp *o
void dev_pm_opp_put(struct dev_pm_opp *opp)
{
- kref_put_mutex(&opp->kref, _opp_kref_release, &opp->opp_table->lock);
+ kref_put_mutex(&opp->kref, _opp_kref_release_locked,
+ &opp->opp_table->lock);
}
EXPORT_SYMBOL_GPL(dev_pm_opp_put);
+static void dev_pm_opp_put_unlocked(struct dev_pm_opp *opp)
+{
+ kref_put(&opp->kref, _opp_kref_release_unlocked);
+}
+
/**
* dev_pm_opp_remove() - Remove an OPP from OPP table
* @dev: device for which we do this operation
@@ -1022,6 +1041,40 @@ void dev_pm_opp_remove(struct device *de
}
EXPORT_SYMBOL_GPL(dev_pm_opp_remove);
+/**
+ * dev_pm_opp_remove_all_dynamic() - Remove all dynamically created OPPs
+ * @dev: device for which we do this operation
+ *
+ * This function removes all dynamically created OPPs from the opp table.
+ */
+void dev_pm_opp_remove_all_dynamic(struct device *dev)
+{
+ struct opp_table *opp_table;
+ struct dev_pm_opp *opp, *temp;
+ int count = 0;
+
+ opp_table = _find_opp_table(dev);
+ if (IS_ERR(opp_table))
+ return;
+
+ mutex_lock(&opp_table->lock);
+ list_for_each_entry_safe(opp, temp, &opp_table->opp_list, node) {
+ if (opp->dynamic) {
+ dev_pm_opp_put_unlocked(opp);
+ count++;
+ }
+ }
+ mutex_unlock(&opp_table->lock);
+
+ /* Drop the references taken by dev_pm_opp_add() */
+ while (count--)
+ dev_pm_opp_put_opp_table(opp_table);
+
+ /* Drop the reference taken by _find_opp_table() */
+ dev_pm_opp_put_opp_table(opp_table);
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_remove_all_dynamic);
+
struct dev_pm_opp *_opp_allocate(struct opp_table *table)
{
struct dev_pm_opp *opp;
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -108,6 +108,7 @@ void dev_pm_opp_put(struct dev_pm_opp *o
int dev_pm_opp_add(struct device *dev, unsigned long freq,
unsigned long u_volt);
void dev_pm_opp_remove(struct device *dev, unsigned long freq);
+void dev_pm_opp_remove_all_dynamic(struct device *dev);
int dev_pm_opp_enable(struct device *dev, unsigned long freq);
@@ -214,6 +215,10 @@ static inline void dev_pm_opp_remove(str
{
}
+static inline void dev_pm_opp_remove_all_dynamic(struct device *dev)
+{
+}
+
static inline int dev_pm_opp_enable(struct device *dev, unsigned long freq)
{
return 0;
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 07/57] cpufreq: scmi: Fix frequency invariance in slow path
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 06/57] cpufreq: scpi/scmi: Fix freeing of dynamic OPPs Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 08/57] x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE Greg Kroah-Hartman
` (52 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Quentin Perret, Viresh Kumar,
Sudeep Holla, Rafael J. Wysocki
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Quentin Perret <quentin.perret@arm.com>
commit 0e141d1c65c1dd31c914eb2e11651adcc1a15912 upstream.
The scmi-cpufreq driver calls the arch_set_freq_scale() callback on
frequency changes to provide scale-invariant load-tracking signals to
the scheduler. However, in the slow path, it does so while specifying
the current and max frequencies in different units, hence resulting in a
broken freq_scale factor.
Fix this by passing all frequencies in KHz, as stored in the CPUFreq
frequency table.
Fixes: 99d6bdf33877 (cpufreq: add support for CPU DVFS based on SCMI message protocol)
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Cc: 4.17+ <stable@vger.kernel.org> # v4.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/cpufreq/scmi-cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -52,9 +52,9 @@ scmi_cpufreq_set_target(struct cpufreq_p
int ret;
struct scmi_data *priv = policy->driver_data;
struct scmi_perf_ops *perf_ops = handle->perf_ops;
- u64 freq = policy->freq_table[index].frequency * 1000;
+ u64 freq = policy->freq_table[index].frequency;
- ret = perf_ops->freq_set(handle, priv->domain_id, freq, false);
+ ret = perf_ops->freq_set(handle, priv->domain_id, freq * 1000, false);
if (!ret)
arch_set_freq_scale(policy->related_cpus, freq,
policy->cpuinfo.max_freq);
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 08/57] x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 07/57] cpufreq: scmi: Fix frequency invariance in slow path Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 09/57] ALSA: hda/realtek - Support Dell headset mode for New AIO platform Greg Kroah-Hartman
` (51 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, WANG Chao, Borislav Petkov,
Zhenzhong Duan, Masahiro Yamada, H. Peter Anvin, Andi Kleen,
Andrew Morton, Andy Lutomirski, Arnd Bergmann, Daniel Borkmann,
David Woodhouse, Geert Uytterhoeven, Jessica Yu, Jiri Kosina,
Kees Cook, Konrad Rzeszutek Wilk, Luc Van Oostenryck,
Michal Marek, Miguel Ojeda, Peter Zijlstra, Tim Chen,
Vasily Gorbik, linux-kbuild, srinivas.eeda, x86-ml
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: WANG Chao <chao.wang@ucloud.cn>
commit e4f358916d528d479c3c12bd2fd03f2d5a576380 upstream.
Commit
4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")
replaced the RETPOLINE define with CONFIG_RETPOLINE checks. Remove the
remaining pieces.
[ bp: Massage commit message. ]
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")
Signed-off-by: WANG Chao <chao.wang@ucloud.cn>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jessica Yu <jeyu@kernel.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Kees Cook <keescook@chromium.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: linux-kbuild@vger.kernel.org
Cc: srinivas.eeda@oracle.com
Cc: stable <stable@vger.kernel.org>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20181210163725.95977-1-chao.wang@ucloud.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/bugs.c | 2 +-
include/linux/compiler-gcc.h | 2 +-
include/linux/module.h | 2 +-
scripts/mod/modpost.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -213,7 +213,7 @@ static enum spectre_v2_mitigation spectr
static enum spectre_v2_user_mitigation spectre_v2_user __ro_after_init =
SPECTRE_V2_USER_NONE;
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
static bool spectre_v2_bad_module;
bool retpoline_module_ok(bool has_retpoline)
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -68,7 +68,7 @@
*/
#define uninitialized_var(x) x = x
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
#define __noretpoline __attribute__((__indirect_branch__("keep")))
#endif
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -817,7 +817,7 @@ static inline void module_bug_finalize(c
static inline void module_bug_cleanup(struct module *mod) {}
#endif /* CONFIG_GENERIC_BUG */
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
extern bool retpoline_module_ok(bool has_retpoline);
#else
static inline bool retpoline_module_ok(bool has_retpoline)
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -2157,7 +2157,7 @@ static void add_intree_flag(struct buffe
/* Cannot check for assembler */
static void add_retpoline(struct buffer *b)
{
- buf_printf(b, "\n#ifdef RETPOLINE\n");
+ buf_printf(b, "\n#ifdef CONFIG_RETPOLINE\n");
buf_printf(b, "MODULE_INFO(retpoline, \"Y\");\n");
buf_printf(b, "#endif\n");
}
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 09/57] ALSA: hda/realtek - Support Dell headset mode for New AIO platform
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 08/57] x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 10/57] ALSA: hda/realtek - Add unplug function into unplug state of Headset Mode for ALC225 Greg Kroah-Hartman
` (50 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kailang Yang, Takashi Iwai
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kailang Yang <kailang@realtek.com>
commit c2a7c55a04065c3b0c32d23b099db7ea1dbf6250 upstream.
Dell has new platform for ALC274.
This will support to enable headset mode.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6503,6 +6503,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1028, 0x0871, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0872, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0873, "Dell Precision 3930", ALC255_FIXUP_DUMMY_LINEOUT_VERB),
+ SND_PCI_QUIRK(0x1028, 0x0935, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB),
SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x164b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2),
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 10/57] ALSA: hda/realtek - Add unplug function into unplug state of Headset Mode for ALC225
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 09/57] ALSA: hda/realtek - Support Dell headset mode for New AIO platform Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 11/57] ALSA: hda/realtek - Disable headset Mic VREF for headset mode of ALC225 Greg Kroah-Hartman
` (49 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kailang Yang, Takashi Iwai
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kailang Yang <kailang@realtek.com>
commit 4d4b0c52bde470c379f5d168d5c139ad866cb808 upstream.
Forgot to add unplug function to unplug state of headset mode
for ALC225.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4102,6 +4102,7 @@ static void alc_headset_mode_unplugged(s
case 0x10ec0295:
case 0x10ec0289:
case 0x10ec0299:
+ alc_process_coef_fw(codec, alc225_pre_hsmode);
alc_process_coef_fw(codec, coef0225);
break;
case 0x10ec0867:
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 11/57] ALSA: hda/realtek - Disable headset Mic VREF for headset mode of ALC225
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 10/57] ALSA: hda/realtek - Add unplug function into unplug state of Headset Mode for ALC225 Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 12/57] CIFS: Fix adjustment of credits for MTU requests Greg Kroah-Hartman
` (48 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kailang Yang, Takashi Iwai
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kailang Yang <kailang@realtek.com>
commit d1dd42110d2727e81b9265841a62bc84c454c3a2 upstream.
Disable Headset Mic VREF for headset mode of ALC225.
This will be controlled by coef bits of headset mode functions.
[ Fixed a compile warning and code simplification -- tiwai ]
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5381,6 +5381,13 @@ static void alc285_fixup_invalidate_dacs
snd_hda_override_wcaps(codec, 0x03, 0);
}
+static void alc_fixup_disable_mic_vref(struct hda_codec *codec,
+ const struct hda_fixup *fix, int action)
+{
+ if (action == HDA_FIXUP_ACT_PRE_PROBE)
+ snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ);
+}
+
/* for hda_fixup_thinkpad_acpi() */
#include "thinkpad_helper.c"
@@ -5493,6 +5500,7 @@ enum {
ALC293_FIXUP_LENOVO_SPK_NOISE,
ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY,
ALC255_FIXUP_DELL_SPK_NOISE,
+ ALC225_FIXUP_DISABLE_MIC_VREF,
ALC225_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_FIXUP_DISABLE_DAC3,
ALC280_FIXUP_HP_HEADSET_MIC,
@@ -6192,6 +6200,12 @@ static const struct hda_fixup alc269_fix
.chained = true,
.chain_id = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE
},
+ [ALC225_FIXUP_DISABLE_MIC_VREF] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc_fixup_disable_mic_vref,
+ .chained = true,
+ .chain_id = ALC269_FIXUP_DELL1_MIC_NO_PRESENCE
+ },
[ALC225_FIXUP_DELL1_MIC_NO_PRESENCE] = {
.type = HDA_FIXUP_VERBS,
.v.verbs = (const struct hda_verb[]) {
@@ -6201,7 +6215,7 @@ static const struct hda_fixup alc269_fix
{}
},
.chained = true,
- .chain_id = ALC269_FIXUP_DELL1_MIC_NO_PRESENCE
+ .chain_id = ALC225_FIXUP_DISABLE_MIC_VREF
},
[ALC280_FIXUP_HP_HEADSET_MIC] = {
.type = HDA_FIXUP_FUNC,
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 12/57] CIFS: Fix adjustment of credits for MTU requests
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 11/57] ALSA: hda/realtek - Disable headset Mic VREF for headset mode of ALC225 Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 13/57] CIFS: Do not set credits to 1 if the server didnt grant anything Greg Kroah-Hartman
` (47 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pavel Shilovsky, Steve French
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Shilovsky <pshilov@microsoft.com>
commit b983f7e92348d7e7d091db1b78b7915e9dd3d63a upstream.
Currently for MTU requests we allocate maximum possible credits
in advance and then adjust them according to the request size.
While we were adjusting the number of credits belonging to the
server, we were skipping adjustment of credits belonging to the
request. This patch fixes it by setting request credits to
CreditCharge field value of SMB2 packet header.
Also ask 1 credit more for async read and write operations to
increase parallelism and match the behavior of other operations.
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/smb2pdu.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -3197,12 +3197,14 @@ smb2_async_readv(struct cifs_readdata *r
if (rdata->credits) {
shdr->CreditCharge = cpu_to_le16(DIV_ROUND_UP(rdata->bytes,
SMB2_MAX_BUFFER_SIZE));
- shdr->CreditRequest = shdr->CreditCharge;
+ shdr->CreditRequest =
+ cpu_to_le16(le16_to_cpu(shdr->CreditCharge) + 1);
spin_lock(&server->req_lock);
server->credits += rdata->credits -
le16_to_cpu(shdr->CreditCharge);
spin_unlock(&server->req_lock);
wake_up(&server->request_q);
+ rdata->credits = le16_to_cpu(shdr->CreditCharge);
flags |= CIFS_HAS_CREDITS;
}
@@ -3474,12 +3476,14 @@ smb2_async_writev(struct cifs_writedata
if (wdata->credits) {
shdr->CreditCharge = cpu_to_le16(DIV_ROUND_UP(wdata->bytes,
SMB2_MAX_BUFFER_SIZE));
- shdr->CreditRequest = shdr->CreditCharge;
+ shdr->CreditRequest =
+ cpu_to_le16(le16_to_cpu(shdr->CreditCharge) + 1);
spin_lock(&server->req_lock);
server->credits += wdata->credits -
le16_to_cpu(shdr->CreditCharge);
spin_unlock(&server->req_lock);
wake_up(&server->request_q);
+ wdata->credits = le16_to_cpu(shdr->CreditCharge);
flags |= CIFS_HAS_CREDITS;
}
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 13/57] CIFS: Do not set credits to 1 if the server didnt grant anything
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 12/57] CIFS: Fix adjustment of credits for MTU requests Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 14/57] CIFS: Do not hide EINTR after sending network packets Greg Kroah-Hartman
` (46 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pavel Shilovsky, Steve French
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Shilovsky <pshilov@microsoft.com>
commit 33fa5c8b8a7dbe6353a56eaa654b790348890d42 upstream.
Currently we reset the number of total credits granted by the server
to 1 if the server didn't grant us anything int the response. This
violates the SMB3 protocol - we need to trust the server and use
the credit values from the response. Fix this by removing the
corresponding code.
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/transport.c | 2 --
1 file changed, 2 deletions(-)
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -892,8 +892,6 @@ compound_send_recv(const unsigned int xi
for (i = 0; i < num_rqst; i++)
if (midQ[i]->resp_buf)
credits += ses->server->ops->get_credits(midQ[i]);
- if (!credits)
- credits = 1;
for (i = 0; i < num_rqst; i++) {
if (rc < 0)
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 14/57] CIFS: Do not hide EINTR after sending network packets
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 13/57] CIFS: Do not set credits to 1 if the server didnt grant anything Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 19:22 ` Pavel Shilovskiy
2019-01-15 16:35 ` [PATCH 4.20 15/57] CIFS: Fix credit computation for compounded requests Greg Kroah-Hartman
` (45 subsequent siblings)
59 siblings, 1 reply; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pavel Shilovsky, Jeff Layton, Steve French
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Shilovsky <pshilov@microsoft.com>
commit ee13919c2e8d1f904e035ad4b4239029a8994131 upstream.
Currently we hide EINTR code returned from sock_sendmsg()
and return 0 instead. This makes a caller think that we
successfully completed the network operation which is not
true. Fix this by properly returning EINTR to callers.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -385,7 +385,7 @@ smbd_done:
if (rc < 0 && rc != -EINTR)
cifs_dbg(VFS, "Error %d sending data on socket to server\n",
rc);
- else
+ else if (rc > 0)
rc = 0;
return rc;
^ permalink raw reply [flat|nested] 66+ messages in thread* RE: [PATCH 4.20 14/57] CIFS: Do not hide EINTR after sending network packets
2019-01-15 16:35 ` [PATCH 4.20 14/57] CIFS: Do not hide EINTR after sending network packets Greg Kroah-Hartman
@ 2019-01-15 19:22 ` Pavel Shilovskiy
2019-01-16 6:37 ` Greg Kroah-Hartman
0 siblings, 1 reply; 66+ messages in thread
From: Pavel Shilovskiy @ 2019-01-15 19:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel; +Cc: stable, Jeff Layton, Steven French
Hi Greg,
I am wondering if it is possible to include exact stable kernel version (e.g. 4.20.3 in this case) in the email. This would help to quickly understand which kernel version should be installed in order to get the fix.
Best regards,
Pavel Shilovsky
-----Original Message-----
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sent: Tuesday, January 15, 2019 8:36 AM
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; stable@vger.kernel.org; Pavel Shilovskiy <pshilov@microsoft.com>; Jeff Layton <jlayton@kernel.org>; Steven French <Steven.French@microsoft.com>
Subject: [PATCH 4.20 14/57] CIFS: Do not hide EINTR after sending network packets
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Shilovsky <pshilov@microsoft.com>
commit ee13919c2e8d1f904e035ad4b4239029a8994131 upstream.
Currently we hide EINTR code returned from sock_sendmsg() and return 0 instead. This makes a caller think that we successfully completed the network operation which is not true. Fix this by properly returning EINTR to callers.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -385,7 +385,7 @@ smbd_done:
if (rc < 0 && rc != -EINTR)
cifs_dbg(VFS, "Error %d sending data on socket to server\n",
rc);
- else
+ else if (rc > 0)
rc = 0;
return rc;
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4.20 14/57] CIFS: Do not hide EINTR after sending network packets
2019-01-15 19:22 ` Pavel Shilovskiy
@ 2019-01-16 6:37 ` Greg Kroah-Hartman
0 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-16 6:37 UTC (permalink / raw)
To: Pavel Shilovskiy; +Cc: linux-kernel, stable, Jeff Layton, Steven French
On Tue, Jan 15, 2019 at 07:22:38PM +0000, Pavel Shilovskiy wrote:
> Hi Greg,
>
> I am wondering if it is possible to include exact stable kernel
> version (e.g. 4.20.3 in this case) in the email. This would help to
> quickly understand which kernel version should be installed in order
> to get the fix.
Given that this is not in a released kernel yet, it's hard to give you a
final version :)
We have had times when a stable release happens while a -rc is out for
review due to special circumstances, so you couldn't always rely on my
email for this, as well as the fact that sometimes we drop patches from
-rc releases before they are in a real release, so such an email would
lie and confuse people.
Just watch the kernel releases, and use git to see what commit is
in what release, it's not that difficult. Especially as you are going
to want to track this across multiple stable releases, so any guess I
might provide here isn't going to help you out much.
greg k-h
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4.20 15/57] CIFS: Fix credit computation for compounded requests
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 14/57] CIFS: Do not hide EINTR after sending network packets Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 16/57] cifs: Fix potential OOB access of lock element array Greg Kroah-Hartman
` (44 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pavel Shilovsky, Steve French
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Shilovsky <pshilov@microsoft.com>
commit 8544f4aa9dd19a04d1244dae10feecc813ccf175 upstream.
In SMB3 protocol every part of the compound chain consumes credits
individually, so we need to call wait_for_free_credits() for each
of the PDUs in the chain. If an operation is interrupted, we must
ensure we return all credits taken from the server structure back.
Without this patch server can sometimes disconnect the session
due to credit mismatches, especially when first operation(s)
are large writes.
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/transport.c | 59 ++++++++++++++++++++++++++++++++++++----------------
1 file changed, 41 insertions(+), 18 deletions(-)
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -793,7 +793,8 @@ compound_send_recv(const unsigned int xi
int i, j, rc = 0;
int timeout, optype;
struct mid_q_entry *midQ[MAX_COMPOUND];
- unsigned int credits = 0;
+ bool cancelled_mid[MAX_COMPOUND] = {false};
+ unsigned int credits[MAX_COMPOUND] = {0};
char *buf;
timeout = flags & CIFS_TIMEOUT_MASK;
@@ -811,13 +812,31 @@ compound_send_recv(const unsigned int xi
return -ENOENT;
/*
- * Ensure that we do not send more than 50 overlapping requests
- * to the same server. We may make this configurable later or
- * use ses->maxReq.
+ * Ensure we obtain 1 credit per request in the compound chain.
+ * It can be optimized further by waiting for all the credits
+ * at once but this can wait long enough if we don't have enough
+ * credits due to some heavy operations in progress or the server
+ * not granting us much, so a fallback to the current approach is
+ * needed anyway.
*/
- rc = wait_for_free_request(ses->server, timeout, optype);
- if (rc)
- return rc;
+ for (i = 0; i < num_rqst; i++) {
+ rc = wait_for_free_request(ses->server, timeout, optype);
+ if (rc) {
+ /*
+ * We haven't sent an SMB packet to the server yet but
+ * we already obtained credits for i requests in the
+ * compound chain - need to return those credits back
+ * for future use. Note that we need to call add_credits
+ * multiple times to match the way we obtained credits
+ * in the first place and to account for in flight
+ * requests correctly.
+ */
+ for (j = 0; j < i; j++)
+ add_credits(ses->server, 1, optype);
+ return rc;
+ }
+ credits[i] = 1;
+ }
/*
* Make sure that we sign in the same order that we send on this socket
@@ -833,8 +852,10 @@ compound_send_recv(const unsigned int xi
for (j = 0; j < i; j++)
cifs_delete_mid(midQ[j]);
mutex_unlock(&ses->server->srv_mutex);
+
/* Update # of requests on wire to server */
- add_credits(ses->server, 1, optype);
+ for (j = 0; j < num_rqst; j++)
+ add_credits(ses->server, credits[j], optype);
return PTR_ERR(midQ[i]);
}
@@ -881,17 +902,16 @@ compound_send_recv(const unsigned int xi
if (midQ[i]->mid_state == MID_REQUEST_SUBMITTED) {
midQ[i]->mid_flags |= MID_WAIT_CANCELLED;
midQ[i]->callback = DeleteMidQEntry;
- spin_unlock(&GlobalMid_Lock);
- add_credits(ses->server, 1, optype);
- return rc;
+ cancelled_mid[i] = true;
}
spin_unlock(&GlobalMid_Lock);
}
}
for (i = 0; i < num_rqst; i++)
- if (midQ[i]->resp_buf)
- credits += ses->server->ops->get_credits(midQ[i]);
+ if (!cancelled_mid[i] && midQ[i]->resp_buf
+ && (midQ[i]->mid_state == MID_RESPONSE_RECEIVED))
+ credits[i] = ses->server->ops->get_credits(midQ[i]);
for (i = 0; i < num_rqst; i++) {
if (rc < 0)
@@ -899,8 +919,9 @@ compound_send_recv(const unsigned int xi
rc = cifs_sync_mid_result(midQ[i], ses->server);
if (rc != 0) {
- add_credits(ses->server, credits, optype);
- return rc;
+ /* mark this mid as cancelled to not free it below */
+ cancelled_mid[i] = true;
+ goto out;
}
if (!midQ[i]->resp_buf ||
@@ -947,9 +968,11 @@ out:
* This is prevented above by using a noop callback that will not
* wake this thread except for the very last PDU.
*/
- for (i = 0; i < num_rqst; i++)
- cifs_delete_mid(midQ[i]);
- add_credits(ses->server, credits, optype);
+ for (i = 0; i < num_rqst; i++) {
+ if (!cancelled_mid[i])
+ cifs_delete_mid(midQ[i]);
+ add_credits(ses->server, credits[i], optype);
+ }
return rc;
}
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 16/57] cifs: Fix potential OOB access of lock element array
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 15/57] CIFS: Fix credit computation for compounded requests Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 17/57] cifs: check kzalloc return Greg Kroah-Hartman
` (43 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ross Lagerwall, Steve French
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ross Lagerwall <ross.lagerwall@citrix.com>
commit b9a74cde94957d82003fb9f7ab4777938ca851cd upstream.
If maxBuf is small but non-zero, it could result in a zero sized lock
element array which we would then try and access OOB.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/file.c | 8 ++++----
fs/cifs/smb2file.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1131,10 +1131,10 @@ cifs_push_mandatory_locks(struct cifsFil
/*
* Accessing maxBuf is racy with cifs_reconnect - need to store value
- * and check it for zero before using.
+ * and check it before using.
*/
max_buf = tcon->ses->server->maxBuf;
- if (!max_buf) {
+ if (max_buf < (sizeof(struct smb_hdr) + sizeof(LOCKING_ANDX_RANGE))) {
free_xid(xid);
return -EINVAL;
}
@@ -1471,10 +1471,10 @@ cifs_unlock_range(struct cifsFileInfo *c
/*
* Accessing maxBuf is racy with cifs_reconnect - need to store value
- * and check it for zero before using.
+ * and check it before using.
*/
max_buf = tcon->ses->server->maxBuf;
- if (!max_buf)
+ if (max_buf < (sizeof(struct smb_hdr) + sizeof(LOCKING_ANDX_RANGE)))
return -EINVAL;
max_num = (max_buf - sizeof(struct smb_hdr)) /
--- a/fs/cifs/smb2file.c
+++ b/fs/cifs/smb2file.c
@@ -122,10 +122,10 @@ smb2_unlock_range(struct cifsFileInfo *c
/*
* Accessing maxBuf is racy with cifs_reconnect - need to store value
- * and check it for zero before using.
+ * and check it before using.
*/
max_buf = tcon->ses->server->maxBuf;
- if (!max_buf)
+ if (max_buf < sizeof(struct smb2_lock_element))
return -EINVAL;
max_num = max_buf / sizeof(struct smb2_lock_element);
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 17/57] cifs: check kzalloc return
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 16/57] cifs: Fix potential OOB access of lock element array Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:35 ` [PATCH 4.20 18/57] ARM: davinci: dm355-evm: fix label names in GPIO lookup entries Greg Kroah-Hartman
` (42 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joe Perches, Steve French
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Perches <joe@perches.com>
commit 0544b324e62c177c3a9e9c3bdce22e6db9f34588 upstream.
kzalloc can return NULL so an additional check is needed. While there
is a check for ret_buf there is no check for the allocation of
ret_buf->crfid.fid - this check is thus added. Both call-sites
of tconInfoAlloc() check for NULL return of tconInfoAlloc()
so returning NULL on failure of kzalloc() here seems appropriate.
As the kzalloc() is the only thing here that can fail it is
moved to the beginning so as not to initialize other resources
on failure of kzalloc.
Fixes: 3d4ef9a15343 ("smb3: fix redundant opens on root")
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/misc.c | 34 ++++++++++++++++++++--------------
1 file changed, 20 insertions(+), 14 deletions(-)
--- a/fs/cifs/misc.c
+++ b/fs/cifs/misc.c
@@ -111,21 +111,27 @@ struct cifs_tcon *
tconInfoAlloc(void)
{
struct cifs_tcon *ret_buf;
- ret_buf = kzalloc(sizeof(struct cifs_tcon), GFP_KERNEL);
- if (ret_buf) {
- atomic_inc(&tconInfoAllocCount);
- ret_buf->tidStatus = CifsNew;
- ++ret_buf->tc_count;
- INIT_LIST_HEAD(&ret_buf->openFileList);
- INIT_LIST_HEAD(&ret_buf->tcon_list);
- spin_lock_init(&ret_buf->open_file_lock);
- mutex_init(&ret_buf->crfid.fid_mutex);
- ret_buf->crfid.fid = kzalloc(sizeof(struct cifs_fid),
- GFP_KERNEL);
- spin_lock_init(&ret_buf->stat_lock);
- atomic_set(&ret_buf->num_local_opens, 0);
- atomic_set(&ret_buf->num_remote_opens, 0);
+
+ ret_buf = kzalloc(sizeof(*ret_buf), GFP_KERNEL);
+ if (!ret_buf)
+ return NULL;
+ ret_buf->crfid.fid = kzalloc(sizeof(*ret_buf->crfid.fid), GFP_KERNEL);
+ if (!ret_buf->crfid.fid) {
+ kfree(ret_buf);
+ return NULL;
}
+
+ atomic_inc(&tconInfoAllocCount);
+ ret_buf->tidStatus = CifsNew;
+ ++ret_buf->tc_count;
+ INIT_LIST_HEAD(&ret_buf->openFileList);
+ INIT_LIST_HEAD(&ret_buf->tcon_list);
+ spin_lock_init(&ret_buf->open_file_lock);
+ mutex_init(&ret_buf->crfid.fid_mutex);
+ spin_lock_init(&ret_buf->stat_lock);
+ atomic_set(&ret_buf->num_local_opens, 0);
+ atomic_set(&ret_buf->num_remote_opens, 0);
+
return ret_buf;
}
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 18/57] ARM: davinci: dm355-evm: fix label names in GPIO lookup entries
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 17/57] cifs: check kzalloc return Greg Kroah-Hartman
@ 2019-01-15 16:35 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 19/57] ARM: davinci: da850-evm: " Greg Kroah-Hartman
` (41 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bartosz Golaszewski, Sekhar Nori
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
commit 94777ed3b644a1af09843f729b2a3f25794bed0f upstream.
Since commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") the gpiochip label no longer has an ID
suffix. Update the GPIO lookup entries.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-davinci/board-dm355-evm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -117,9 +117,9 @@ static struct platform_device davinci_na
static struct gpiod_lookup_table i2c_recovery_gpiod_table = {
.dev_id = "i2c_davinci.1",
.table = {
- GPIO_LOOKUP("davinci_gpio.0", DM355_I2C_SDA_PIN, "sda",
+ GPIO_LOOKUP("davinci_gpio", DM355_I2C_SDA_PIN, "sda",
GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
- GPIO_LOOKUP("davinci_gpio.0", DM355_I2C_SCL_PIN, "scl",
+ GPIO_LOOKUP("davinci_gpio", DM355_I2C_SCL_PIN, "scl",
GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
},
};
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 19/57] ARM: davinci: da850-evm: fix label names in GPIO lookup entries
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2019-01-15 16:35 ` [PATCH 4.20 18/57] ARM: davinci: dm355-evm: fix label names in GPIO lookup entries Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 20/57] ARM: davinci: omapl138-hawk: " Greg Kroah-Hartman
` (40 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bartosz Golaszewski, Sekhar Nori
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
commit c3f08cceb6a59f328f1c847b002729d1584c7a32 upstream.
Since commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") the gpiochip label no longer has an ID
suffix. Update the GPIO lookup entries.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-davinci/board-da850-evm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -780,9 +780,9 @@ static struct gpiod_lookup_table mmc_gpi
.dev_id = "da830-mmc.0",
.table = {
/* gpio chip 2 contains gpio range 64-95 */
- GPIO_LOOKUP("davinci_gpio.0", DA850_MMCSD_CD_PIN, "cd",
+ GPIO_LOOKUP("davinci_gpio", DA850_MMCSD_CD_PIN, "cd",
GPIO_ACTIVE_LOW),
- GPIO_LOOKUP("davinci_gpio.0", DA850_MMCSD_WP_PIN, "wp",
+ GPIO_LOOKUP("davinci_gpio", DA850_MMCSD_WP_PIN, "wp",
GPIO_ACTIVE_HIGH),
},
};
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 20/57] ARM: davinci: omapl138-hawk: fix label names in GPIO lookup entries
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 19/57] ARM: davinci: da850-evm: " Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 21/57] ARM: davinci: dm644x-evm: " Greg Kroah-Hartman
` (39 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bartosz Golaszewski, Sekhar Nori
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
commit 054b8dc381b1c784852ad3e109270d236a58b71d upstream.
Since commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") the gpiochip label no longer has an ID
suffix. Update the GPIO lookup entries.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -134,9 +134,9 @@ static const short hawk_mmcsd0_pins[] =
static struct gpiod_lookup_table mmc_gpios_table = {
.dev_id = "da830-mmc.0",
.table = {
- GPIO_LOOKUP("davinci_gpio.0", DA850_HAWK_MMCSD_CD_PIN, "cd",
+ GPIO_LOOKUP("davinci_gpio", DA850_HAWK_MMCSD_CD_PIN, "cd",
GPIO_ACTIVE_LOW),
- GPIO_LOOKUP("davinci_gpio.0", DA850_HAWK_MMCSD_WP_PIN, "wp",
+ GPIO_LOOKUP("davinci_gpio", DA850_HAWK_MMCSD_WP_PIN, "wp",
GPIO_ACTIVE_LOW),
},
};
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 21/57] ARM: davinci: dm644x-evm: fix label names in GPIO lookup entries
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 20/57] ARM: davinci: omapl138-hawk: " Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 22/57] ARM: davinci: da830-evm: " Greg Kroah-Hartman
` (38 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bartosz Golaszewski, Sekhar Nori
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
commit 7f1015b29d9b9eb1cd3c038d6c30d698c6d7782e upstream.
Since commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") the gpiochip label no longer has an ID
suffix. Update the GPIO lookup entries.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-davinci/board-dm644x-evm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -638,9 +638,9 @@ static struct i2c_board_info __initdata
static struct gpiod_lookup_table i2c_recovery_gpiod_table = {
.dev_id = "i2c_davinci.1",
.table = {
- GPIO_LOOKUP("davinci_gpio.0", DM644X_I2C_SDA_PIN, "sda",
+ GPIO_LOOKUP("davinci_gpio", DM644X_I2C_SDA_PIN, "sda",
GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
- GPIO_LOOKUP("davinci_gpio.0", DM644X_I2C_SCL_PIN, "scl",
+ GPIO_LOOKUP("davinci_gpio", DM644X_I2C_SCL_PIN, "scl",
GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
},
};
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 22/57] ARM: davinci: da830-evm: fix label names in GPIO lookup entries
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 21/57] ARM: davinci: dm644x-evm: " Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 23/57] usb: cdc-acm: send ZLP for Telit 3G Intel based modems Greg Kroah-Hartman
` (37 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bartosz Golaszewski, Sekhar Nori
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
commit cc557afb4d10cba175fd08d51c557004a229eded upstream.
Since commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") the gpiochip label no longer has an ID
suffix. Update the GPIO lookup entries.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-davinci/board-da830-evm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -207,9 +207,9 @@ static struct gpiod_lookup_table mmc_gpi
.dev_id = "da830-mmc.0",
.table = {
/* gpio chip 1 contains gpio range 32-63 */
- GPIO_LOOKUP("davinci_gpio.0", DA830_MMCSD_CD_PIN, "cd",
+ GPIO_LOOKUP("davinci_gpio", DA830_MMCSD_CD_PIN, "cd",
GPIO_ACTIVE_LOW),
- GPIO_LOOKUP("davinci_gpio.0", DA830_MMCSD_WP_PIN, "wp",
+ GPIO_LOOKUP("davinci_gpio", DA830_MMCSD_WP_PIN, "wp",
GPIO_ACTIVE_LOW),
},
};
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 23/57] usb: cdc-acm: send ZLP for Telit 3G Intel based modems
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 22/57] ARM: davinci: da830-evm: " Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 24/57] USB: storage: dont insert sane sense for SPC3+ when bad sense specified Greg Kroah-Hartman
` (36 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Daniele Palmas
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniele Palmas <dnlplm@gmail.com>
commit 34aabf918717dd14e05051896aaecd3b16b53d95 upstream.
Telit 3G Intel based modems require zero packet to be sent if
out data size is equal to the endpoint max packet size.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/class/cdc-acm.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1865,6 +1865,13 @@ static const struct usb_device_id acm_id
.driver_info = IGNORE_DEVICE,
},
+ { USB_DEVICE(0x1bc7, 0x0021), /* Telit 3G ACM only composition */
+ .driver_info = SEND_ZERO_PACKET,
+ },
+ { USB_DEVICE(0x1bc7, 0x0023), /* Telit 3G ACM + ECM composition */
+ .driver_info = SEND_ZERO_PACKET,
+ },
+
/* control interfaces without any protocol set */
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM,
USB_CDC_PROTO_NONE) },
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 24/57] USB: storage: dont insert sane sense for SPC3+ when bad sense specified
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 23/57] usb: cdc-acm: send ZLP for Telit 3G Intel based modems Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 25/57] USB: storage: add quirk for SMI SM3350 Greg Kroah-Hartman
` (35 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Icenowy Zheng, Alan Stern
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Icenowy Zheng <icenowy@aosc.io>
commit c5603d2fdb424849360fe7e3f8c1befc97571b8c upstream.
Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to
prevent this behavior, because SMI SM3350 UFS-USB bridge controller,
which claims SPC4, will show strange behavior with 96-byte sense
(put the chip into a wrong state that cannot read/write anything).
Check the presence of US_FL_BAD_SENSE when assuming US_FL_SANE_SENSE on
SPC4+ devices.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/storage/scsiglue.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -235,8 +235,12 @@ static int slave_configure(struct scsi_d
if (!(us->fflags & US_FL_NEEDS_CAP16))
sdev->try_rc_10_first = 1;
- /* assume SPC3 or latter devices support sense size > 18 */
- if (sdev->scsi_level > SCSI_SPC_2)
+ /*
+ * assume SPC3 or latter devices support sense size > 18
+ * unless US_FL_BAD_SENSE quirk is specified.
+ */
+ if (sdev->scsi_level > SCSI_SPC_2 &&
+ !(us->fflags & US_FL_BAD_SENSE))
us->fflags |= US_FL_SANE_SENSE;
/*
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 25/57] USB: storage: add quirk for SMI SM3350
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 24/57] USB: storage: dont insert sane sense for SPC3+ when bad sense specified Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 26/57] USB: Add USB_QUIRK_DELAY_CTRL_MSG quirk for Corsair K70 RGB Greg Kroah-Hartman
` (34 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Icenowy Zheng, Alan Stern
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Icenowy Zheng <icenowy@aosc.io>
commit 0a99cc4b8ee83885ab9f097a3737d1ab28455ac0 upstream.
The SMI SM3350 USB-UFS bridge controller cannot handle long sense request
correctly and will make the chip refuse to do read/write when requested
long sense.
Add a bad sense quirk for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/storage/unusual_devs.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1266,6 +1266,18 @@ UNUSUAL_DEV( 0x090c, 0x1132, 0x0000, 0xf
US_FL_FIX_CAPACITY ),
/*
+ * Reported by Icenowy Zheng <icenowy@aosc.io>
+ * The SMI SM3350 USB-UFS bridge controller will enter a wrong state
+ * that do not process read/write command if a long sense is requested,
+ * so force to use 18-byte sense.
+ */
+UNUSUAL_DEV( 0x090c, 0x3350, 0x0000, 0xffff,
+ "SMI",
+ "SM3350 UFS-to-USB-Mass-Storage bridge",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BAD_SENSE ),
+
+/*
* Reported by Paul Hartman <paul.hartman+linux@gmail.com>
* This card reader returns "Illegal Request, Logical Block Address
* Out of Range" for the first READ(10) after a new card is inserted.
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 26/57] USB: Add USB_QUIRK_DELAY_CTRL_MSG quirk for Corsair K70 RGB
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 25/57] USB: storage: add quirk for SMI SM3350 Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 27/57] fork, memcg: fix cached_stacks case Greg Kroah-Hartman
` (33 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jack Stocker
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jack Stocker <jackstocker.93@gmail.com>
commit 3483254b89438e60f719937376c5e0ce2bc46761 upstream.
To match the Corsair Strafe RGB, the Corsair K70 RGB also requires
USB_QUIRK_DELAY_CTRL_MSG to completely resolve boot connection issues
discussed here: https://github.com/ckb-next/ckb-next/issues/42.
Otherwise roughly 1 in 10 boots the keyboard will fail to be detected.
Patch that applied delay control quirk for Corsair Strafe RGB:
cb88a0588717 ("usb: quirks: add control message delay for 1b1c:1b20")
Previous K70 RGB patch to add delay-init quirk:
7a1646d92257 ("Add delay-init quirk for Corsair K70 RGB keyboards")
Signed-off-by: Jack Stocker <jackstocker.93@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -394,7 +394,8 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x1a40, 0x0101), .driver_info = USB_QUIRK_HUB_SLOW_RESET },
/* Corsair K70 RGB */
- { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+ { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT |
+ USB_QUIRK_DELAY_CTRL_MSG },
/* Corsair Strafe */
{ USB_DEVICE(0x1b1c, 0x1b15), .driver_info = USB_QUIRK_DELAY_INIT |
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 27/57] fork, memcg: fix cached_stacks case
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 26/57] USB: Add USB_QUIRK_DELAY_CTRL_MSG quirk for Corsair K70 RGB Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 28/57] slab: alien caches must not be initialized if the allocation of the alien cache failed Greg Kroah-Hartman
` (32 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Shakeel Butt, Michal Hocko,
Rik van Riel, Roman Gushchin, Johannes Weiner, Tejun Heo,
Andrew Morton, Linus Torvalds
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shakeel Butt <shakeelb@google.com>
commit ba4a45746c362b665e245c50b870615f02f34781 upstream.
Commit 5eed6f1dff87 ("fork,memcg: fix crash in free_thread_stack on
memcg charge fail") fixes a crash caused due to failed memcg charge of
the kernel stack. However the fix misses the cached_stacks case which
this patch fixes. So, the same crash can happen if the memcg charge of
a cached stack is failed.
Link: http://lkml.kernel.org/r/20190102180145.57406-1-shakeelb@google.com
Fixes: 5eed6f1dff87 ("fork,memcg: fix crash in free_thread_stack on memcg charge fail")
Signed-off-by: Shakeel Butt <shakeelb@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Rik van Riel <riel@surriel.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Roman Gushchin <guro@fb.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/fork.c | 1 +
1 file changed, 1 insertion(+)
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -221,6 +221,7 @@ static unsigned long *alloc_thread_stack
memset(s->addr, 0, THREAD_SIZE);
tsk->stack_vm_area = s;
+ tsk->stack = s->addr;
return s->addr;
}
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 28/57] slab: alien caches must not be initialized if the allocation of the alien cache failed
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 27/57] fork, memcg: fix cached_stacks case Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 29/57] mm/usercopy.c: no check page span for stack objects Greg Kroah-Hartman
` (31 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christoph Lameter,
syzbot+d6ed4ec679652b4fd4e4, Andrew Morton, Pekka Enberg,
David Rientjes, Joonsoo Kim, Linus Torvalds
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Lameter <cl@linux.com>
commit 09c2e76ed734a1d36470d257a778aaba28e86531 upstream.
Callers of __alloc_alien() check for NULL. We must do the same check in
__alloc_alien_cache to avoid NULL pointer dereferences on allocation
failures.
Link: http://lkml.kernel.org/r/010001680f42f192-82b4e12e-1565-4ee0-ae1f-1e98974906aa-000000@email.amazonses.com
Fixes: 49dfc304ba241 ("slab: use the lock on alien_cache, instead of the lock on array_cache")
Fixes: c8522a3a5832b ("Slab: introduce alloc_alien")
Signed-off-by: Christoph Lameter <cl@linux.com>
Reported-by: syzbot+d6ed4ec679652b4fd4e4@syzkaller.appspotmail.com
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/slab.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -679,8 +679,10 @@ static struct alien_cache *__alloc_alien
struct alien_cache *alc = NULL;
alc = kmalloc_node(memsize, gfp, node);
- init_arraycache(&alc->ac, entries, batch);
- spin_lock_init(&alc->lock);
+ if (alc) {
+ init_arraycache(&alc->ac, entries, batch);
+ spin_lock_init(&alc->lock);
+ }
return alc;
}
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 29/57] mm/usercopy.c: no check page span for stack objects
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 28/57] slab: alien caches must not be initialized if the allocation of the alien cache failed Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 30/57] mm, memcg: fix reclaim deadlock with writeback Greg Kroah-Hartman
` (30 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Qian Cai, Kees Cook, Andrew Morton,
Linus Torvalds
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qian Cai <cai@lca.pw>
commit 7bff3c06997374fb9b9991536a547b840549a813 upstream.
It is easy to trigger this with CONFIG_HARDENED_USERCOPY_PAGESPAN=y,
usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 23)!
kernel BUG at mm/usercopy.c:102!
For example,
print_worker_info
char name[WQ_NAME_LEN] = { };
char desc[WORKER_DESC_LEN] = { };
probe_kernel_read(name, wq->name, sizeof(name) - 1);
probe_kernel_read(desc, worker->desc, sizeof(desc) - 1);
__copy_from_user_inatomic
check_object_size
check_heap_object
check_page_span
This is because on-stack variables could cross PAGE_SIZE boundary, and
failed this check,
if (likely(((unsigned long)ptr & (unsigned long)PAGE_MASK) ==
((unsigned long)end & (unsigned long)PAGE_MASK)))
ptr = FFFF889007D7EFF8
end = FFFF889007D7F00E
Hence, fix it by checking if it is a stack object first.
[keescook@chromium.org: improve comments after reorder]
Link: http://lkml.kernel.org/r/20190103165151.GA32845@beast
Link: http://lkml.kernel.org/r/20181231030254.99441-1-cai@lca.pw
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/usercopy.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/mm/usercopy.c
+++ b/mm/usercopy.c
@@ -247,7 +247,8 @@ static DEFINE_STATIC_KEY_FALSE_RO(bypass
/*
* Validates that the given object is:
* - not bogus address
- * - known-safe heap or stack object
+ * - fully contained by stack (or stack frame, when available)
+ * - fully within SLAB object (or object whitelist area, when available)
* - not in kernel text
*/
void __check_object_size(const void *ptr, unsigned long n, bool to_user)
@@ -262,9 +263,6 @@ void __check_object_size(const void *ptr
/* Check for invalid addresses. */
check_bogus_address((const unsigned long)ptr, n, to_user);
- /* Check for bad heap object. */
- check_heap_object(ptr, n, to_user);
-
/* Check for bad stack object. */
switch (check_stack_object(ptr, n)) {
case NOT_STACK:
@@ -282,6 +280,9 @@ void __check_object_size(const void *ptr
usercopy_abort("process stack", NULL, to_user, 0, n);
}
+ /* Check for bad heap object. */
+ check_heap_object(ptr, n, to_user);
+
/* Check for object in kernel to avoid text exposure. */
check_kernel_text_object((const unsigned long)ptr, n, to_user);
}
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 30/57] mm, memcg: fix reclaim deadlock with writeback
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 29/57] mm/usercopy.c: no check page span for stack objects Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 31/57] ACPI: power: Skip duplicate power resource references in _PRx Greg Kroah-Hartman
` (29 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michal Hocko, Liu Bo,
Kirill A. Shutemov, Johannes Weiner, Jan Kara, Dave Chinner,
Theodore Tso, Vladimir Davydov, Shakeel Butt, Andrew Morton,
Linus Torvalds
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Hocko <mhocko@suse.com>
commit 63f3655f950186752236bb88a22f8252c11ce394 upstream.
Liu Bo has experienced a deadlock between memcg (legacy) reclaim and the
ext4 writeback
task1:
wait_on_page_bit+0x82/0xa0
shrink_page_list+0x907/0x960
shrink_inactive_list+0x2c7/0x680
shrink_node_memcg+0x404/0x830
shrink_node+0xd8/0x300
do_try_to_free_pages+0x10d/0x330
try_to_free_mem_cgroup_pages+0xd5/0x1b0
try_charge+0x14d/0x720
memcg_kmem_charge_memcg+0x3c/0xa0
memcg_kmem_charge+0x7e/0xd0
__alloc_pages_nodemask+0x178/0x260
alloc_pages_current+0x95/0x140
pte_alloc_one+0x17/0x40
__pte_alloc+0x1e/0x110
alloc_set_pte+0x5fe/0xc20
do_fault+0x103/0x970
handle_mm_fault+0x61e/0xd10
__do_page_fault+0x252/0x4d0
do_page_fault+0x30/0x80
page_fault+0x28/0x30
task2:
__lock_page+0x86/0xa0
mpage_prepare_extent_to_map+0x2e7/0x310 [ext4]
ext4_writepages+0x479/0xd60
do_writepages+0x1e/0x30
__writeback_single_inode+0x45/0x320
writeback_sb_inodes+0x272/0x600
__writeback_inodes_wb+0x92/0xc0
wb_writeback+0x268/0x300
wb_workfn+0xb4/0x390
process_one_work+0x189/0x420
worker_thread+0x4e/0x4b0
kthread+0xe6/0x100
ret_from_fork+0x41/0x50
He adds
"task1 is waiting for the PageWriteback bit of the page that task2 has
collected in mpd->io_submit->io_bio, and tasks2 is waiting for the
LOCKED bit the page which tasks1 has locked"
More precisely task1 is handling a page fault and it has a page locked
while it charges a new page table to a memcg. That in turn hits a
memory limit reclaim and the memcg reclaim for legacy controller is
waiting on the writeback but that is never going to finish because the
writeback itself is waiting for the page locked in the #PF path. So
this is essentially ABBA deadlock:
lock_page(A)
SetPageWriteback(A)
unlock_page(A)
lock_page(B)
lock_page(B)
pte_alloc_pne
shrink_page_list
wait_on_page_writeback(A)
SetPageWriteback(B)
unlock_page(B)
# flush A, B to clear the writeback
This accumulating of more pages to flush is used by several filesystems
to generate a more optimal IO patterns.
Waiting for the writeback in legacy memcg controller is a workaround for
pre-mature OOM killer invocations because there is no dirty IO
throttling available for the controller. There is no easy way around
that unfortunately. Therefore fix this specific issue by pre-allocating
the page table outside of the page lock. We have that handy
infrastructure for that already so simply reuse the fault-around pattern
which already does this.
There are probably other hidden __GFP_ACCOUNT | GFP_KERNEL allocations
from under a fs page locked but they should be really rare. I am not
aware of a better solution unfortunately.
[akpm@linux-foundation.org: fix mm/memory.c:__do_fault()]
[akpm@linux-foundation.org: coding-style fixes]
[mhocko@kernel.org: enhance comment, per Johannes]
Link: http://lkml.kernel.org/r/20181214084948.GA5624@dhcp22.suse.cz
Link: http://lkml.kernel.org/r/20181213092221.27270-1-mhocko@kernel.org
Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
Signed-off-by: Michal Hocko <mhocko@suse.com>
Reported-by: Liu Bo <bo.liu@linux.alibaba.com>
Debugged-by: Liu Bo <bo.liu@linux.alibaba.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Liu Bo <bo.liu@linux.alibaba.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/memory.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2993,6 +2993,29 @@ static vm_fault_t __do_fault(struct vm_f
struct vm_area_struct *vma = vmf->vma;
vm_fault_t ret;
+ /*
+ * Preallocate pte before we take page_lock because this might lead to
+ * deadlocks for memcg reclaim which waits for pages under writeback:
+ * lock_page(A)
+ * SetPageWriteback(A)
+ * unlock_page(A)
+ * lock_page(B)
+ * lock_page(B)
+ * pte_alloc_pne
+ * shrink_page_list
+ * wait_on_page_writeback(A)
+ * SetPageWriteback(B)
+ * unlock_page(B)
+ * # flush A, B to clear the writeback
+ */
+ if (pmd_none(*vmf->pmd) && !vmf->prealloc_pte) {
+ vmf->prealloc_pte = pte_alloc_one(vmf->vma->vm_mm,
+ vmf->address);
+ if (!vmf->prealloc_pte)
+ return VM_FAULT_OOM;
+ smp_wmb(); /* See comment in __pte_alloc() */
+ }
+
ret = vma->vm_ops->fault(vmf);
if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE | VM_FAULT_RETRY |
VM_FAULT_DONE_COW)))
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 31/57] ACPI: power: Skip duplicate power resource references in _PRx
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 30/57] mm, memcg: fix reclaim deadlock with writeback Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 32/57] ACPI / PMIC: xpower: Fix TS-pin current-source handling Greg Kroah-Hartman
` (28 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans de Goede, Rafael J. Wysocki
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 7d7b467cb95bf29597b417d4990160d4ea6d69b9 upstream.
Some ACPI tables contain duplicate power resource references like this:
Name (_PR0, Package (0x04) // _PR0: Power Resources for D0
{
P28P,
P18P,
P18P,
CLK4
})
This causes a WARN_ON in sysfs_add_link_to_group() because we end up
adding a link to the same acpi_device twice:
sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/808622C1:00/OVTI2680:00/power_resources_D0/LNXPOWER:0a'
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.12-301.fc29.x86_64 #1
Hardware name: Insyde CherryTrail/Type2 - Board Product Name, BIOS jumperx.T87.KFBNEEA02 04/13/2016
Call Trace:
dump_stack+0x5c/0x80
sysfs_warn_dup.cold.3+0x17/0x2a
sysfs_do_create_link_sd.isra.2+0xa9/0xb0
sysfs_add_link_to_group+0x30/0x50
acpi_power_expose_list+0x74/0xa0
acpi_power_add_remove_device+0x50/0xa0
acpi_add_single_object+0x26b/0x5f0
acpi_bus_check_add+0xc4/0x250
...
To address this issue, make acpi_extract_power_resources() check for
duplicates and simply skip them when found.
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[ rjw: Subject & changelog, comments ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/power.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -131,6 +131,23 @@ void acpi_power_resources_list_free(stru
}
}
+static bool acpi_power_resource_is_dup(union acpi_object *package,
+ unsigned int start, unsigned int i)
+{
+ acpi_handle rhandle, dup;
+ unsigned int j;
+
+ /* The caller is expected to check the package element types */
+ rhandle = package->package.elements[i].reference.handle;
+ for (j = start; j < i; j++) {
+ dup = package->package.elements[j].reference.handle;
+ if (dup == rhandle)
+ return true;
+ }
+
+ return false;
+}
+
int acpi_extract_power_resources(union acpi_object *package, unsigned int start,
struct list_head *list)
{
@@ -150,6 +167,11 @@ int acpi_extract_power_resources(union a
err = -ENODEV;
break;
}
+
+ /* Some ACPI tables contain duplicate power resource references */
+ if (acpi_power_resource_is_dup(package, start, i))
+ continue;
+
err = acpi_add_power_resource(rhandle);
if (err)
break;
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 32/57] ACPI / PMIC: xpower: Fix TS-pin current-source handling
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 31/57] ACPI: power: Skip duplicate power resource references in _PRx Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 33/57] ACPI/IORT: Fix rc_dma_get_range() Greg Kroah-Hartman
` (27 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Andy Shevchenko,
Rafael J. Wysocki
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 2b531d71595d2b5b12782a49b23c335869e2621e upstream.
The current-source used for the battery temp-sensor (TS) is shared with the
GPADC. For proper fuel-gauge and charger operation the TS current-source
needs to be permanently on. But to read the GPADC we need to temporary
switch the TS current-source to ondemand, so that the GPADC can use it,
otherwise we will always read an all 0 value.
The switching from on to on-ondemand is not necessary when the TS
current-source is off (this happens on devices which do not have a TS).
Prior to this commit there were 2 issues with our handling of the TS
current-source switching:
1) We were writing hardcoded values to the ADC TS pin-ctrl register,
overwriting various other unrelated bits. Specifically we were overwriting
the current-source setting for the TS and GPIO0 pins, forcing it to 80ųA
independent of its original setting. On a Chuwi Vi10 tablet this was
causing us to get a too high adc value (due to a too high current-source)
resulting in acpi_lpat_raw_to_temp() returning -ENOENT, resulting in:
ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
ACPI Error: Method parse/execution failed \_SB.SXP1._TMP, AE_ERROR
This commit fixes this by using regmap_update_bits to change only the
relevant bits.
2) At the end of intel_xpower_pmic_get_raw_temp() we were unconditionally
enabling the TS current-source even on devices where the TS-pin is not used
and the current-source thus was off on entry of the function.
This commit fixes this by checking if the TS current-source is off when
entering intel_xpower_pmic_get_raw_temp() and if so it is left as is.
Fixes: 58eefe2f3f53 (ACPI / PMIC: xpower: Do pinswitch ... reading GPADC)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/pmic/intel_pmic_xpower.c | 41 +++++++++++++++++++++++++++-------
1 file changed, 33 insertions(+), 8 deletions(-)
--- a/drivers/acpi/pmic/intel_pmic_xpower.c
+++ b/drivers/acpi/pmic/intel_pmic_xpower.c
@@ -20,8 +20,11 @@
#define GPI1_LDO_ON (3 << 0)
#define GPI1_LDO_OFF (4 << 0)
-#define AXP288_ADC_TS_PIN_GPADC 0xf2
-#define AXP288_ADC_TS_PIN_ON 0xf3
+#define AXP288_ADC_TS_CURRENT_ON_OFF_MASK GENMASK(1, 0)
+#define AXP288_ADC_TS_CURRENT_OFF (0 << 0)
+#define AXP288_ADC_TS_CURRENT_ON_WHEN_CHARGING (1 << 0)
+#define AXP288_ADC_TS_CURRENT_ON_ONDEMAND (2 << 0)
+#define AXP288_ADC_TS_CURRENT_ON (3 << 0)
static struct pmic_table power_table[] = {
{
@@ -212,22 +215,44 @@ out:
*/
static int intel_xpower_pmic_get_raw_temp(struct regmap *regmap, int reg)
{
+ int ret, adc_ts_pin_ctrl;
u8 buf[2];
- int ret;
- ret = regmap_write(regmap, AXP288_ADC_TS_PIN_CTRL,
- AXP288_ADC_TS_PIN_GPADC);
+ /*
+ * The current-source used for the battery temp-sensor (TS) is shared
+ * with the GPADC. For proper fuel-gauge and charger operation the TS
+ * current-source needs to be permanently on. But to read the GPADC we
+ * need to temporary switch the TS current-source to ondemand, so that
+ * the GPADC can use it, otherwise we will always read an all 0 value.
+ *
+ * Note that the switching from on to on-ondemand is not necessary
+ * when the TS current-source is off (this happens on devices which
+ * do not use the TS-pin).
+ */
+ ret = regmap_read(regmap, AXP288_ADC_TS_PIN_CTRL, &adc_ts_pin_ctrl);
if (ret)
return ret;
- /* After switching to the GPADC pin give things some time to settle */
- usleep_range(6000, 10000);
+ if (adc_ts_pin_ctrl & AXP288_ADC_TS_CURRENT_ON_OFF_MASK) {
+ ret = regmap_update_bits(regmap, AXP288_ADC_TS_PIN_CTRL,
+ AXP288_ADC_TS_CURRENT_ON_OFF_MASK,
+ AXP288_ADC_TS_CURRENT_ON_ONDEMAND);
+ if (ret)
+ return ret;
+
+ /* Wait a bit after switching the current-source */
+ usleep_range(6000, 10000);
+ }
ret = regmap_bulk_read(regmap, AXP288_GP_ADC_H, buf, 2);
if (ret == 0)
ret = (buf[0] << 4) + ((buf[1] >> 4) & 0x0f);
- regmap_write(regmap, AXP288_ADC_TS_PIN_CTRL, AXP288_ADC_TS_PIN_ON);
+ if (adc_ts_pin_ctrl & AXP288_ADC_TS_CURRENT_ON_OFF_MASK) {
+ regmap_update_bits(regmap, AXP288_ADC_TS_PIN_CTRL,
+ AXP288_ADC_TS_CURRENT_ON_OFF_MASK,
+ AXP288_ADC_TS_CURRENT_ON);
+ }
return ret;
}
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 33/57] ACPI/IORT: Fix rc_dma_get_range()
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 32/57] ACPI / PMIC: xpower: Fix TS-pin current-source handling Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 34/57] i2c: dev: prevent adapter retries and timeout being set as minus value Greg Kroah-Hartman
` (26 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Auger, Jean-Philippe Brucker,
Lorenzo Pieralisi, Robin Murphy, Will Deacon, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Rafael J. Wysocki
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
commit c7777236dd8f587f6a8d6800c03df318fd4d2627 upstream.
When executed for a PCI_ROOT_COMPLEX type, iort_match_node_callback()
expects the opaque pointer argument to be a PCI bus device. At the
moment rc_dma_get_range() passes the PCI endpoint instead of the bus,
and we've been lucky to have pci_domain_nr(ptr) return 0 instead of
crashing. Pass the bus device to iort_scan_node().
Fixes: 5ac65e8c8941 ("ACPI/IORT: Support address size limit for root complexes")
Reported-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Cc: stable@vger.kernel.org
Cc: Will Deacon <will.deacon@arm.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/arm64/iort.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -951,9 +951,10 @@ static int rc_dma_get_range(struct devic
{
struct acpi_iort_node *node;
struct acpi_iort_root_complex *rc;
+ struct pci_bus *pbus = to_pci_dev(dev)->bus;
node = iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
- iort_match_node_callback, dev);
+ iort_match_node_callback, &pbus->dev);
if (!node || node->revision < 1)
return -ENODEV;
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 34/57] i2c: dev: prevent adapter retries and timeout being set as minus value
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 33/57] ACPI/IORT: Fix rc_dma_get_range() Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 35/57] mtd: rawnand: qcom: fix memory corruption that causes panic Greg Kroah-Hartman
` (25 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Yi Zeng, Wolfram Sang, stable
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yi Zeng <yizeng@asrmicro.com>
commit 6ebec961d59bccf65d08b13fc1ad4e6272a89338 upstream.
If adapter->retries is set to a minus value from user space via ioctl,
it will make __i2c_transfer and __i2c_smbus_xfer skip the calling to
adapter->algo->master_xfer and adapter->algo->smbus_xfer that is
registered by the underlying bus drivers, and return value 0 to all the
callers. The bus driver will never be accessed anymore by all users,
besides, the users may still get successful return value without any
error or information log print out.
If adapter->timeout is set to minus value from user space via ioctl,
it will make the retrying loop in __i2c_transfer and __i2c_smbus_xfer
always break after the the first try, due to the time_after always
returns true.
Signed-off-by: Yi Zeng <yizeng@asrmicro.com>
[wsa: minor grammar updates to commit message]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/i2c-dev.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -470,9 +470,15 @@ static long i2cdev_ioctl(struct file *fi
data_arg.data);
}
case I2C_RETRIES:
+ if (arg > INT_MAX)
+ return -EINVAL;
+
client->adapter->retries = arg;
break;
case I2C_TIMEOUT:
+ if (arg > INT_MAX)
+ return -EINVAL;
+
/* For historical reasons, user-space sets the timeout
* value in units of 10 ms.
*/
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 35/57] mtd: rawnand: qcom: fix memory corruption that causes panic
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 34/57] i2c: dev: prevent adapter retries and timeout being set as minus value Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 36/57] vfio/type1: Fix unmap overflow off-by-one Greg Kroah-Hartman
` (24 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christian Lamparter, Miquel Raynal,
Boris Brezillon
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Lamparter <chunkeey@gmail.com>
commit 81d9bdf59092e4755fc4307c93c4589ef0fe2e0f upstream.
This patch fixes a memory corruption that occurred in the
qcom-nandc driver since it was converted to nand_scan().
On boot, an affected device will panic from a NPE at a weird place:
| Unable to handle kernel NULL pointer dereference at virtual address 0
| pgd = (ptrval)
| [00000000] *pgd=00000000
| Internal error: Oops: 80000005 [#1] SMP ARM
| CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.9 #0
| Hardware name: Generic DT based system
| PC is at (null)
| LR is at nand_block_isbad+0x90/0xa4
| pc : [<00000000>] lr : [<c0592240>] psr: 80000013
| sp : cf839d40 ip : 00000000 fp : cfae9e20
| r10: cf815810 r9 : 00000000 r8 : 00000000
| r7 : 00000000 r6 : 00000000 r5 : 00000001 r4 : cf815810
| r3 : 00000000 r2 : cfae9810 r1 : ffffffff r0 : cf815810
| Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
| Control: 10c5387d Table: 8020406a DAC: 00000051
| Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
| [<c0592240>] (nand_block_isbad) from [<c0580a94>]
| [<c0580a94>] (allocate_partition) from [<c05811e4>]
| [<c05811e4>] (add_mtd_partitions) from [<c0581164>]
| [<c0581164>] (parse_mtd_partitions) from [<c057def4>]
| [<c057def4>] (mtd_device_parse_register) from [<c059d274>]
| [<c059d274>] (qcom_nandc_probe) from [<c0567f00>]
The problem is that the nand_scan()'s qcom_nand_attach_chip callback
is updating the nandc->max_cwperpage from 1 to 4. This causes the
sg_init_table of clear_bam_transaction() in the driver's
qcom_nandc_block_bad() to memset much more than what was initially
allocated by alloc_bam_transaction().
This patch restores the old behavior by reallocating the shared bam
transaction alloc_bam_transaction() after the chip was identified,
but before mtd_device_parse_register() (which is an alias for
mtd_device_register() - see panic) gets called. This fixes the
corruption and the driver is working again.
Cc: stable@vger.kernel.org
Fixes: 6a3cec64f18c ("mtd: rawnand: qcom: convert driver to nand_scan()")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/nand/raw/qcom_nandc.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -2833,6 +2833,16 @@ static int qcom_nand_host_init_and_regis
if (ret)
return ret;
+ if (nandc->props->is_bam) {
+ free_bam_transaction(nandc);
+ nandc->bam_txn = alloc_bam_transaction(nandc);
+ if (!nandc->bam_txn) {
+ dev_err(nandc->dev,
+ "failed to allocate bam transaction\n");
+ return -ENOMEM;
+ }
+ }
+
ret = mtd_device_register(mtd, NULL, 0);
if (ret)
nand_cleanup(chip);
@@ -2847,16 +2857,6 @@ static int qcom_probe_nand_devices(struc
struct qcom_nand_host *host;
int ret;
- if (nandc->props->is_bam) {
- free_bam_transaction(nandc);
- nandc->bam_txn = alloc_bam_transaction(nandc);
- if (!nandc->bam_txn) {
- dev_err(nandc->dev,
- "failed to allocate bam transaction\n");
- return -ENOMEM;
- }
- }
-
for_each_available_child_of_node(dn, child) {
host = devm_kzalloc(dev, sizeof(*host), GFP_KERNEL);
if (!host) {
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 36/57] vfio/type1: Fix unmap overflow off-by-one
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 35/57] mtd: rawnand: qcom: fix memory corruption that causes panic Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 37/57] drm/amdgpu: Add new VegaM pci id Greg Kroah-Hartman
` (23 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pei Zhang, Dan Carpenter, Peter Xu,
Cornelia Huck, Alex Williamson
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <alex.williamson@redhat.com>
commit 58fec830fc19208354895d9832785505046d6c01 upstream.
The below referenced commit adds a test for integer overflow, but in
doing so prevents the unmap ioctl from ever including the last page of
the address space. Subtract one to compare to the last address of the
unmap to avoid the overflow and wrap-around.
Fixes: 71a7d3d78e3c ("vfio/type1: silence integer overflow warning")
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1662291
Cc: stable@vger.kernel.org # v4.15+
Reported-by: Pei Zhang <pezhang@redhat.com>
Debugged-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Tested-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/vfio/vfio_iommu_type1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -878,7 +878,7 @@ static int vfio_dma_do_unmap(struct vfio
return -EINVAL;
if (!unmap->size || unmap->size & mask)
return -EINVAL;
- if (unmap->iova + unmap->size < unmap->iova ||
+ if (unmap->iova + unmap->size - 1 < unmap->iova ||
unmap->size > SIZE_MAX)
return -EINVAL;
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 37/57] drm/amdgpu: Add new VegaM pci id
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 36/57] vfio/type1: Fix unmap overflow off-by-one Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 38/57] PCI: dwc: Use interrupt masking instead of disabling Greg Kroah-Hartman
` (22 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Leo Liu, Alex Deucher
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
commit f6653a0e0877572c87f6dab5351e7bd6b6b7100c upstream.
Add a new pci id.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -864,6 +864,7 @@ static const struct pci_device_id pciidl
/* VEGAM */
{0x1002, 0x694C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGAM},
{0x1002, 0x694E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGAM},
+ {0x1002, 0x694F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGAM},
/* Vega 10 */
{0x1002, 0x6860, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10},
{0x1002, 0x6861, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10},
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 38/57] PCI: dwc: Use interrupt masking instead of disabling
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 37/57] drm/amdgpu: Add new VegaM pci id Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 39/57] PCI: dwc: Take lock when ACKing an interrupt Greg Kroah-Hartman
` (21 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Niklas Cassel, Gustavo Pimentel,
Stanimir Varbanov, Marc Zyngier, Lorenzo Pieralisi
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <marc.zyngier@arm.com>
commit 830920e065e90db318a0da98bf13a02b641eae7f upstream.
The dwc driver is showing an interesting level of brokeness, as it
insists on using the enable/disable set of registers to mask/unmask
MSIs, meaning that an MSIs being generated while the interrupt is in
that "disabled" state will simply be lost.
Let's move to the mask/unmask set of registers, which offers the
expected semantics.
Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains
hierarchical API")
Link: https://lore.kernel.org/linux-pci/20181113225734.8026-1-marc.zyngier@arm.com/
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Tested-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
[lorenzo.pieralisi@arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/controller/dwc/pcie-designware-host.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -168,8 +168,8 @@ static void dw_pci_bottom_mask(struct ir
bit = data->hwirq % MAX_MSI_IRQS_PER_CTRL;
pp->irq_status[ctrl] &= ~(1 << bit);
- dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4,
- pp->irq_status[ctrl]);
+ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_MASK + res, 4,
+ ~pp->irq_status[ctrl]);
}
raw_spin_unlock_irqrestore(&pp->lock, flags);
@@ -191,8 +191,8 @@ static void dw_pci_bottom_unmask(struct
bit = data->hwirq % MAX_MSI_IRQS_PER_CTRL;
pp->irq_status[ctrl] |= 1 << bit;
- dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4,
- pp->irq_status[ctrl]);
+ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_MASK + res, 4,
+ ~pp->irq_status[ctrl]);
}
raw_spin_unlock_irqrestore(&pp->lock, flags);
@@ -658,10 +658,15 @@ void dw_pcie_setup_rc(struct pcie_port *
num_ctrls = pp->num_vectors / MAX_MSI_IRQS_PER_CTRL;
/* Initialize IRQ Status array */
- for (ctrl = 0; ctrl < num_ctrls; ctrl++)
- dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE +
+ for (ctrl = 0; ctrl < num_ctrls; ctrl++) {
+ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_MASK +
(ctrl * MSI_REG_CTRL_BLOCK_SIZE),
- 4, &pp->irq_status[ctrl]);
+ 4, ~0);
+ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE +
+ (ctrl * MSI_REG_CTRL_BLOCK_SIZE),
+ 4, ~0);
+ pp->irq_status[ctrl] = 0;
+ }
/* Setup RC BARs */
dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 0x00000004);
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 39/57] PCI: dwc: Take lock when ACKing an interrupt
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 38/57] PCI: dwc: Use interrupt masking instead of disabling Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 40/57] PCI: dwc: Move interrupt acking into the proper callback Greg Kroah-Hartman
` (20 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Niklas Cassel, Gustavo Pimentel,
Stanimir Varbanov, Marc Zyngier, Lorenzo Pieralisi
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <marc.zyngier@arm.com>
commit fce5423e4f431c71933d6c1f850b540a314aa6ee upstream.
Bizarrely, there is no lock taken in the irq_ack() helper. This
puts the ACK callback provided by a specific platform in a awkward
situation where there is no synchronization that would be expected
on other callback.
Introduce the required lock, giving some level of uniformity among
callbacks.
Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains
hierarchical API")
Link: https://lore.kernel.org/linux-pci/20181113225734.8026-1-marc.zyngier@arm.com/
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Tested-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
[lorenzo.pieralisi@arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/controller/dwc/pcie-designware-host.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -202,11 +202,16 @@ static void dw_pci_bottom_ack(struct irq
{
struct msi_desc *msi = irq_data_get_msi_desc(d);
struct pcie_port *pp;
+ unsigned long flags;
pp = msi_desc_to_pci_sysdata(msi);
+ raw_spin_lock_irqsave(&pp->lock, flags);
+
if (pp->ops->msi_irq_ack)
pp->ops->msi_irq_ack(d->hwirq, pp);
+
+ raw_spin_unlock_irqrestore(&pp->lock, flags);
}
static struct irq_chip dw_pci_msi_bottom_irq_chip = {
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 40/57] PCI: dwc: Move interrupt acking into the proper callback
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 39/57] PCI: dwc: Take lock when ACKing an interrupt Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 41/57] drm/amd/display: Fix MST dp_blank REG_WAIT timeout Greg Kroah-Hartman
` (19 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Trent Piepho, Niklas Cassel,
Gustavo Pimentel, Stanimir Varbanov, Marc Zyngier,
Lorenzo Pieralisi
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <marc.zyngier@arm.com>
commit 3f7bb2ec20ce07c02b2002349d256c91a463fcc5 upstream.
The write to the status register is really an ACK for the HW,
and should be treated as such by the driver. Let's move it to the
irq_ack() callback, which will prevent people from moving it around
in order to paper over other bugs.
Fixes: 8c934095fa2f ("PCI: dwc: Clear MSI interrupt status after it is handled,
not before")
Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains
hierarchical API")
Link: https://lore.kernel.org/linux-pci/20181113225734.8026-1-marc.zyngier@arm.com/
Reported-by: Trent Piepho <tpiepho@impinj.com>
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Tested-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
[lorenzo.pieralisi@arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/controller/dwc/pcie-designware-host.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -99,9 +99,6 @@ irqreturn_t dw_handle_msi_irq(struct pci
(i * MAX_MSI_IRQS_PER_CTRL) +
pos);
generic_handle_irq(irq);
- dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS +
- (i * MSI_REG_CTRL_BLOCK_SIZE),
- 4, 1 << pos);
pos++;
}
}
@@ -200,14 +197,18 @@ static void dw_pci_bottom_unmask(struct
static void dw_pci_bottom_ack(struct irq_data *d)
{
- struct msi_desc *msi = irq_data_get_msi_desc(d);
- struct pcie_port *pp;
+ struct pcie_port *pp = irq_data_get_irq_chip_data(d);
+ unsigned int res, bit, ctrl;
unsigned long flags;
- pp = msi_desc_to_pci_sysdata(msi);
+ ctrl = d->hwirq / MAX_MSI_IRQS_PER_CTRL;
+ res = ctrl * MSI_REG_CTRL_BLOCK_SIZE;
+ bit = d->hwirq % MAX_MSI_IRQS_PER_CTRL;
raw_spin_lock_irqsave(&pp->lock, flags);
+ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS + res, 4, 1 << bit);
+
if (pp->ops->msi_irq_ack)
pp->ops->msi_irq_ack(d->hwirq, pp);
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 41/57] drm/amd/display: Fix MST dp_blank REG_WAIT timeout
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 40/57] PCI: dwc: Move interrupt acking into the proper callback Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 42/57] drm/fb-helper: Partially bring back workaround for bugs of SDL 1.2 Greg Kroah-Hartman
` (18 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jerry (Fangzhi) Zuo, Hersen Wu,
Harry Wentland, Alex Deucher, Lyude Paul
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
commit 8c9d90eebd23b6d40ddf4ce5df5ca2b932336a06 upstream.
Need to blank stream before deallocate MST payload.
[drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:944
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2201 at /var/lib/dkms/amdgpu/18.50-690240/build/amd/amdgpu/../display/dc/dc_helper.c:249 generic_reg_wait+0xe7/0x160 [amdgpu]
Call Trace:
dce110_stream_encoder_dp_blank+0x11c/0x180 [amdgpu]
core_link_disable_stream+0x40/0x230 [amdgpu]
? generic_reg_update_ex+0xdb/0x130 [amdgpu]
dce110_reset_hw_ctx_wrap+0xb7/0x1f0 [amdgpu]
dce110_apply_ctx_to_hw+0x30/0x430 [amdgpu]
? dce110_apply_ctx_for_surface+0x206/0x260 [amdgpu]
dc_commit_state+0x2ba/0x4d0 [amdgpu]
amdgpu_dm_atomic_commit_tail+0x297/0xd70 [amdgpu]
? amdgpu_bo_pin_restricted+0x58/0x260 [amdgpu]
? wait_for_completion_timeout+0x1f/0x120
? wait_for_completion_interruptible+0x1c/0x160
commit_tail+0x3d/0x60 [drm_kms_helper]
drm_atomic_helper_commit+0xf6/0x100 [drm_kms_helper]
drm_atomic_connector_commit_dpms+0xe5/0xf0 [drm]
drm_mode_obj_set_property_ioctl+0x14f/0x250 [drm]
drm_mode_connector_property_set_ioctl+0x2e/0x40 [drm]
drm_ioctl+0x1e0/0x430 [drm]
? drm_mode_connector_set_obj_prop+0x70/0x70 [drm]
? ep_read_events_proc+0xb0/0xb0
? ep_scan_ready_list.constprop.18+0x1e6/0x1f0
? timerqueue_add+0x52/0x80
amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
do_vfs_ioctl+0x90/0x5f0
SyS_ioctl+0x74/0x80
do_syscall_64+0x74/0x140
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
---[ end trace 3ed7b77a97d60f72 ]---
Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2617,11 +2617,11 @@ void core_link_disable_stream(struct pip
{
struct dc *core_dc = pipe_ctx->stream->ctx->dc;
+ core_dc->hwss.blank_stream(pipe_ctx);
+
if (pipe_ctx->stream->signal == SIGNAL_TYPE_DISPLAY_PORT_MST)
deallocate_mst_payload(pipe_ctx);
- core_dc->hwss.blank_stream(pipe_ctx);
-
core_dc->hwss.disable_stream(pipe_ctx, option);
disable_link(pipe_ctx->stream->sink->link, pipe_ctx->stream->signal);
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 42/57] drm/fb-helper: Partially bring back workaround for bugs of SDL 1.2
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 41/57] drm/amd/display: Fix MST dp_blank REG_WAIT timeout Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 43/57] drm/i915: Unwind failure on pinning the gen7 ppgtt Greg Kroah-Hartman
` (17 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, saahriktu, Ivan Mironov, Daniel Vetter
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Mironov <mironov.ivan@gmail.com>
commit 62d85b3bf9d978ed4b6b2aeef5cf0ccf1423906e upstream.
SDL 1.2 sets all fields related to the pixel format to zero in some
cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all
pixel format changing requests"), there was an unintentional workaround
for this that existed for more than a decade. First in device-specific DRM
drivers, then here in drm_fb_helper.c.
Previous code containing this workaround just ignores pixel format fields
from userspace code. Not a good thing either, as this way, driver may
silently use pixel format different from what client actually requested,
and this in turn will lead to displaying garbage on the screen. I think
that returning EINVAL to userspace in this particular case is the right
option, so I decided to left code from problematic commit untouched
instead of just reverting it entirely.
Here is the steps required to reproduce this problem exactly:
1) Compile fceux[2] with SDL 1.2.15 and without GTK or OpenGL
support. SDL should be compiled with fbdev support (which is
on by default).
2) Create /etc/fb.modes with following contents (values seems
not used, and just required to trigger problematic code in
SDL):
mode "test"
geometry 1 1 1 1 1
timings 1 1 1 1 1 1 1
endmode
3) Create ~/.fceux/fceux.cfg with following contents:
SDL.Hotkeys.Quit = 27
SDL.DoubleBuffering = 1
4) Ensure that screen resolution is at least 1280x960 (e.g.
append "video=Virtual-1:1280x960-32" to the kernel cmdline
for qemu/QXL).
5) Try to run fceux on VT with some ROM file[3]:
# ./fceux color_test.nes
[1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c,
FB_SetVideoMode()
[2] http://www.fceux.com
[3] Example ROM: https://github.com/bokuweb/rustynes/blob/master/roms/color_test.nes
Reported-by: saahriktu <mail@saahriktu.org>
Suggested-by: saahriktu <mail@saahriktu.org>
Cc: stable@vger.kernel.org
Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing requests")
Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
[danvet: Delete misleading comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com
Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_fb_helper.c | 126 +++++++++++++++++++++++-----------------
1 file changed, 73 insertions(+), 53 deletions(-)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1621,6 +1621,64 @@ static bool drm_fb_pixel_format_equal(co
var_1->transp.msb_right == var_2->transp.msb_right;
}
+static void drm_fb_helper_fill_pixel_fmt(struct fb_var_screeninfo *var,
+ u8 depth)
+{
+ switch (depth) {
+ case 8:
+ var->red.offset = 0;
+ var->green.offset = 0;
+ var->blue.offset = 0;
+ var->red.length = 8; /* 8bit DAC */
+ var->green.length = 8;
+ var->blue.length = 8;
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ break;
+ case 15:
+ var->red.offset = 10;
+ var->green.offset = 5;
+ var->blue.offset = 0;
+ var->red.length = 5;
+ var->green.length = 5;
+ var->blue.length = 5;
+ var->transp.offset = 15;
+ var->transp.length = 1;
+ break;
+ case 16:
+ var->red.offset = 11;
+ var->green.offset = 5;
+ var->blue.offset = 0;
+ var->red.length = 5;
+ var->green.length = 6;
+ var->blue.length = 5;
+ var->transp.offset = 0;
+ break;
+ case 24:
+ var->red.offset = 16;
+ var->green.offset = 8;
+ var->blue.offset = 0;
+ var->red.length = 8;
+ var->green.length = 8;
+ var->blue.length = 8;
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ break;
+ case 32:
+ var->red.offset = 16;
+ var->green.offset = 8;
+ var->blue.offset = 0;
+ var->red.length = 8;
+ var->green.length = 8;
+ var->blue.length = 8;
+ var->transp.offset = 24;
+ var->transp.length = 8;
+ break;
+ default:
+ break;
+ }
+}
+
/**
* drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
* @var: screeninfo to check
@@ -1651,6 +1709,20 @@ int drm_fb_helper_check_var(struct fb_va
}
/*
+ * Workaround for SDL 1.2, which is known to be setting all pixel format
+ * fields values to zero in some cases. We treat this situation as a
+ * kind of "use some reasonable autodetected values".
+ */
+ if (!var->red.offset && !var->green.offset &&
+ !var->blue.offset && !var->transp.offset &&
+ !var->red.length && !var->green.length &&
+ !var->blue.length && !var->transp.length &&
+ !var->red.msb_right && !var->green.msb_right &&
+ !var->blue.msb_right && !var->transp.msb_right) {
+ drm_fb_helper_fill_pixel_fmt(var, fb->format->depth);
+ }
+
+ /*
* drm fbdev emulation doesn't support changing the pixel format at all,
* so reject all pixel format changing requests.
*/
@@ -1961,59 +2033,7 @@ void drm_fb_helper_fill_var(struct fb_in
info->var.yoffset = 0;
info->var.activate = FB_ACTIVATE_NOW;
- switch (fb->format->depth) {
- case 8:
- info->var.red.offset = 0;
- info->var.green.offset = 0;
- info->var.blue.offset = 0;
- info->var.red.length = 8; /* 8bit DAC */
- info->var.green.length = 8;
- info->var.blue.length = 8;
- info->var.transp.offset = 0;
- info->var.transp.length = 0;
- break;
- case 15:
- info->var.red.offset = 10;
- info->var.green.offset = 5;
- info->var.blue.offset = 0;
- info->var.red.length = 5;
- info->var.green.length = 5;
- info->var.blue.length = 5;
- info->var.transp.offset = 15;
- info->var.transp.length = 1;
- break;
- case 16:
- info->var.red.offset = 11;
- info->var.green.offset = 5;
- info->var.blue.offset = 0;
- info->var.red.length = 5;
- info->var.green.length = 6;
- info->var.blue.length = 5;
- info->var.transp.offset = 0;
- break;
- case 24:
- info->var.red.offset = 16;
- info->var.green.offset = 8;
- info->var.blue.offset = 0;
- info->var.red.length = 8;
- info->var.green.length = 8;
- info->var.blue.length = 8;
- info->var.transp.offset = 0;
- info->var.transp.length = 0;
- break;
- case 32:
- info->var.red.offset = 16;
- info->var.green.offset = 8;
- info->var.blue.offset = 0;
- info->var.red.length = 8;
- info->var.green.length = 8;
- info->var.blue.length = 8;
- info->var.transp.offset = 24;
- info->var.transp.length = 8;
- break;
- default:
- break;
- }
+ drm_fb_helper_fill_pixel_fmt(&info->var, fb->format->depth);
info->var.xres = fb_width;
info->var.yres = fb_height;
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 43/57] drm/i915: Unwind failure on pinning the gen7 ppgtt
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 42/57] drm/fb-helper: Partially bring back workaround for bugs of SDL 1.2 Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 44/57] drm/amdgpu: Dont ignore rc from drm_dp_mst_topology_mgr_resume() Greg Kroah-Hartman
` (16 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chris Wilson, Joonas Lahtinen,
Mika Kuoppala, Matthew Auld, Jani Nikula
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <chris@chris-wilson.co.uk>
commit 280d479b310298dfeb1d6f9a1617eca37beb6ce4 upstream.
If we fail to pin the ggtt vma slot for the ppgtt page tables, we need
to unwind the locals before reporting the error. Or else on subsequent
attempts to bind the page tables into the ggtt, we will already believe
that the vma has been pinned and continue on blithely. If something else
should happen to be at that location, choas ensues.
Fixes: a2bbf7148342 ("drm/i915/gtt: Only keep gen6 page directories pinned while active")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: <stable@vger.kernel.org> # v4.19+
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181222030623.21710-1-chris@chris-wilson.co.uk
(cherry picked from commit d4de753526f4d99f541f1b6ed1d963005c09700c)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2117,6 +2117,7 @@ static struct i915_vma *pd_vma_create(st
int gen6_ppgtt_pin(struct i915_hw_ppgtt *base)
{
struct gen6_hw_ppgtt *ppgtt = to_gen6_ppgtt(base);
+ int err;
/*
* Workaround the limited maximum vma->pin_count and the aliasing_ppgtt
@@ -2132,9 +2133,17 @@ int gen6_ppgtt_pin(struct i915_hw_ppgtt
* allocator works in address space sizes, so it's multiplied by page
* size. We allocate at the top of the GTT to avoid fragmentation.
*/
- return i915_vma_pin(ppgtt->vma,
- 0, GEN6_PD_ALIGN,
- PIN_GLOBAL | PIN_HIGH);
+ err = i915_vma_pin(ppgtt->vma,
+ 0, GEN6_PD_ALIGN,
+ PIN_GLOBAL | PIN_HIGH);
+ if (err)
+ goto unpin;
+
+ return 0;
+
+unpin:
+ ppgtt->pin_count = 0;
+ return err;
}
void gen6_ppgtt_unpin(struct i915_hw_ppgtt *base)
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 44/57] drm/amdgpu: Dont ignore rc from drm_dp_mst_topology_mgr_resume()
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 43/57] drm/i915: Unwind failure on pinning the gen7 ppgtt Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 45/57] drm/amdgpu: Dont fail resume process if resuming atomic state fails Greg Kroah-Hartman
` (15 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lyude Paul, Harry Wentland, Jerry Zuo
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude Paul <lyude@redhat.com>
commit fe7553bef8d676d1d8b40666868b33ec39b9df5d upstream.
drm_dp_mst_topology_mgr_resume() returns whether or not it managed to
find the topology in question after a suspend resume cycle, and the
driver is supposed to check this value and disable MST accordingly if
it's gone-in addition to sending a hotplug in order to notify userspace
that something changed during suspend.
Currently, amdgpu just makes the mistake of ignoring the return code
from drm_dp_mst_topology_mgr_resume() which means that if a topology was
removed in suspend, amdgpu never notices and assumes it's still
connected which leads to all sorts of problems.
So, fix this by actually checking the rc from
drm_dp_mst_topology_mgr_resume(). Also, reformat the rest of the
function while we're at it to fix the over-indenting.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Cc: Jerry Zuo <Jerry.Zuo@amd.com>
Cc: <stable@vger.kernel.org> # v4.15+
Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-2-lyude@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 34 +++++++++++++++-------
1 file changed, 24 insertions(+), 10 deletions(-)
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -645,22 +645,36 @@ static void s3_handle_mst(struct drm_dev
{
struct amdgpu_dm_connector *aconnector;
struct drm_connector *connector;
+ struct drm_dp_mst_topology_mgr *mgr;
+ int ret;
+ bool need_hotplug = false;
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- aconnector = to_amdgpu_dm_connector(connector);
- if (aconnector->dc_link->type == dc_connection_mst_branch &&
- !aconnector->mst_port) {
-
- if (suspend)
- drm_dp_mst_topology_mgr_suspend(&aconnector->mst_mgr);
- else
- drm_dp_mst_topology_mgr_resume(&aconnector->mst_mgr);
- }
+ list_for_each_entry(connector, &dev->mode_config.connector_list,
+ head) {
+ aconnector = to_amdgpu_dm_connector(connector);
+ if (aconnector->dc_link->type != dc_connection_mst_branch ||
+ aconnector->mst_port)
+ continue;
+
+ mgr = &aconnector->mst_mgr;
+
+ if (suspend) {
+ drm_dp_mst_topology_mgr_suspend(mgr);
+ } else {
+ ret = drm_dp_mst_topology_mgr_resume(mgr);
+ if (ret < 0) {
+ drm_dp_mst_topology_mgr_set_mst(mgr, false);
+ need_hotplug = true;
+ }
+ }
}
drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ if (need_hotplug)
+ drm_kms_helper_hotplug_event(dev);
}
static int dm_hw_init(void *handle)
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 45/57] drm/amdgpu: Dont fail resume process if resuming atomic state fails
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (43 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 44/57] drm/amdgpu: Dont ignore rc from drm_dp_mst_topology_mgr_resume() Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 46/57] rbd: dont return 0 on unmap if RBD_DEV_FLAG_REMOVING is set Greg Kroah-Hartman
` (14 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lyude Paul, Harry Wentland, Jerry Zuo
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude Paul <lyude@redhat.com>
commit 2d1af6a11cb9d88e0e3dd10258904c437fe1b315 upstream.
This is an ugly one unfortunately. Currently, all DRM drivers supporting
atomic modesetting will save the state that userspace had set before
suspending, then attempt to restore that state on resume. This probably
worked very well at one point, like many other things, until DP MST came
into the picture. While it's easy to restore state on normal display
connectors that were disconnected during suspend regardless of their
state post-resume, this can't really be done with MST because of the
fact that setting up a downstream sink requires performing sideband
transactions between the source and the MST hub, sending out the ACT
packets, etc.
Because of this, there isn't really a guarantee that we can restore the
atomic state we had before suspend once we've resumed. This sucks pretty
bad, but so far I haven't run into any compositors that this actually
causes serious issues with. Most compositors will notice the hotplug we
send afterwards, and then reprobe state.
Since nouveau and i915 also don't fail the suspend/resume process due to
failing to restore the atomic state, let's make amdgpu match this
behavior. Better to resume the GPU properly, then to stop the process
half way because of a potentially unavoidable atomic commit failure.
Eventually, we'll have a real fix for this problem on the DRM level. But
we've got some more important low-hanging fruit to deal with first.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Cc: Jerry Zuo <Jerry.Zuo@amd.com>
Cc: <stable@vger.kernel.org> # v4.15+
Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-3-lyude@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -830,7 +830,6 @@ static int dm_resume(void *handle)
struct drm_plane_state *new_plane_state;
struct dm_plane_state *dm_new_plane_state;
enum dc_connection_type new_connection_type = dc_connection_none;
- int ret;
int i;
/* power on hardware */
@@ -903,13 +902,13 @@ static int dm_resume(void *handle)
}
}
- ret = drm_atomic_helper_resume(ddev, dm->cached_state);
+ drm_atomic_helper_resume(ddev, dm->cached_state);
dm->cached_state = NULL;
amdgpu_dm_irq_resume_late(adev);
- return ret;
+ return 0;
}
static const struct amd_ip_funcs amdgpu_dm_funcs = {
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 46/57] rbd: dont return 0 on unmap if RBD_DEV_FLAG_REMOVING is set
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 45/57] drm/amdgpu: Dont fail resume process if resuming atomic state fails Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 47/57] ext4: make sure enough credits are reserved for dioread_nolock writes Greg Kroah-Hartman
` (13 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ilya Dryomov, Dongsheng Yang
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <idryomov@gmail.com>
commit 85f5a4d666fd9be73856ed16bb36c5af5b406b29 upstream.
There is a window between when RBD_DEV_FLAG_REMOVING is set and when
the device is removed from rbd_dev_list. During this window, we set
"already" and return 0.
Returning 0 from write(2) can confuse userspace tools because
0 indicates that nothing was written. In particular, "rbd unmap"
will retry the write multiple times a second:
10:28:05.463299 write(4, "0", 1) = 0
10:28:05.463509 write(4, "0", 1) = 0
10:28:05.463720 write(4, "0", 1) = 0
10:28:05.463942 write(4, "0", 1) = 0
10:28:05.464155 write(4, "0", 1) = 0
Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Tested-by: Dongsheng Yang <dongsheng.yang@easystack.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/block/rbd.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -5986,7 +5986,6 @@ static ssize_t do_rbd_remove(struct bus_
struct list_head *tmp;
int dev_id;
char opt_buf[6];
- bool already = false;
bool force = false;
int ret;
@@ -6019,13 +6018,13 @@ static ssize_t do_rbd_remove(struct bus_
spin_lock_irq(&rbd_dev->lock);
if (rbd_dev->open_count && !force)
ret = -EBUSY;
- else
- already = test_and_set_bit(RBD_DEV_FLAG_REMOVING,
- &rbd_dev->flags);
+ else if (test_and_set_bit(RBD_DEV_FLAG_REMOVING,
+ &rbd_dev->flags))
+ ret = -EINPROGRESS;
spin_unlock_irq(&rbd_dev->lock);
}
spin_unlock(&rbd_dev_list_lock);
- if (ret < 0 || already)
+ if (ret)
return ret;
if (force) {
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 47/57] ext4: make sure enough credits are reserved for dioread_nolock writes
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 46/57] rbd: dont return 0 on unmap if RBD_DEV_FLAG_REMOVING is set Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 48/57] ext4: fix a potential fiemap/page fault deadlock w/ inline_data Greg Kroah-Hartman
` (12 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Theodore Tso, stable
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <tytso@mit.edu>
commit 812c0cab2c0dfad977605dbadf9148490ca5d93f upstream.
There are enough credits reserved for most dioread_nolock writes;
however, if the extent tree is sufficiently deep, and/or quota is
enabled, the code was not allowing for all eventualities when
reserving journal credits for the unwritten extent conversion.
This problem can be seen using xfstests ext4/034:
WARNING: CPU: 1 PID: 257 at fs/ext4/ext4_jbd2.c:271 __ext4_handle_dirty_metadata+0x10c/0x180
Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work
RIP: 0010:__ext4_handle_dirty_metadata+0x10c/0x180
...
EXT4-fs: ext4_free_blocks:4938: aborting transaction: error 28 in __ext4_handle_dirty_metadata
EXT4: jbd2_journal_dirty_metadata failed: handle type 11 started at line 4921, credits 4/0, errcode -28
EXT4-fs error (device dm-1) in ext4_free_blocks:4950: error 28
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2778,7 +2778,8 @@ static int ext4_writepages(struct addres
* We may need to convert up to one extent per block in
* the page and we may dirty the inode.
*/
- rsv_blocks = 1 + (PAGE_SIZE >> inode->i_blkbits);
+ rsv_blocks = 1 + ext4_chunk_trans_blocks(inode,
+ PAGE_SIZE >> inode->i_blkbits);
}
/*
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 48/57] ext4: fix a potential fiemap/page fault deadlock w/ inline_data
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 47/57] ext4: make sure enough credits are reserved for dioread_nolock writes Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 49/57] ext4: avoid kernel warning when writing the superblock to a dead device Greg Kroah-Hartman
` (11 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Theodore Tso, stable
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <tytso@mit.edu>
commit 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 upstream.
The ext4_inline_data_fiemap() function calls fiemap_fill_next_extent()
while still holding the xattr semaphore. This is not necessary and it
triggers a circular lockdep warning. This is because
fiemap_fill_next_extent() could trigger a page fault when it writes
into page which triggers a page fault. If that page is mmaped from
the inline file in question, this could very well result in a
deadlock.
This problem can be reproduced using generic/519 with a file system
configuration which has the inline_data feature enabled.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/inline.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -1890,12 +1890,12 @@ int ext4_inline_data_fiemap(struct inode
physical += (char *)ext4_raw_inode(&iloc) - iloc.bh->b_data;
physical += offsetof(struct ext4_inode, i_block);
- if (physical)
- error = fiemap_fill_next_extent(fieinfo, start, physical,
- inline_len, flags);
brelse(iloc.bh);
out:
up_read(&EXT4_I(inode)->xattr_sem);
+ if (physical)
+ error = fiemap_fill_next_extent(fieinfo, start, physical,
+ inline_len, flags);
return (error < 0 ? error : 0);
}
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 49/57] ext4: avoid kernel warning when writing the superblock to a dead device
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 48/57] ext4: fix a potential fiemap/page fault deadlock w/ inline_data Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 50/57] ext4: use ext4_write_inode() when fsyncing w/o a journal Greg Kroah-Hartman
` (10 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Theodore Tso
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <tytso@mit.edu>
commit e86807862e6880809f191c4cea7f88a489f0ed34 upstream.
The xfstests generic/475 test switches the underlying device with
dm-error while running a stress test. This results in a large number
of file system errors, and since we can't lock the buffer head when
marking the superblock dirty in the ext4_grp_locked_error() case, it's
possible the superblock to be !buffer_uptodate() without
buffer_write_io_error() being true.
We need to set buffer_uptodate() before we call mark_buffer_dirty() or
this will trigger a WARN_ON. It's safe to do this since the
superblock must have been properly read into memory or the mount would
have been successful. So if buffer_uptodate() is not set, we can
safely assume that this happened due to a failed attempt to write the
superblock.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4905,7 +4905,7 @@ static int ext4_commit_super(struct supe
ext4_superblock_csum_set(sb);
if (sync)
lock_buffer(sbh);
- if (buffer_write_io_error(sbh)) {
+ if (buffer_write_io_error(sbh) || !buffer_uptodate(sbh)) {
/*
* Oh, dear. A previous attempt to write the
* superblock failed. This could happen because the
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 50/57] ext4: use ext4_write_inode() when fsyncing w/o a journal
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (48 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 49/57] ext4: avoid kernel warning when writing the superblock to a dead device Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 51/57] ext4: track writeback errors using the generic tracking infrastructure Greg Kroah-Hartman
` (9 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Theodore Tso, stable
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <tytso@mit.edu>
commit ad211f3e94b314a910d4af03178a0b52a7d1ee0a upstream.
In no-journal mode, we previously used __generic_file_fsync() in
no-journal mode. This triggers a lockdep warning, and in addition,
it's not safe to depend on the inode writeback mechanism in the case
ext4. We can solve both problems by calling ext4_write_inode()
directly.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/fsync.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/fs/ext4/fsync.c
+++ b/fs/ext4/fsync.c
@@ -116,8 +116,16 @@ int ext4_sync_file(struct file *file, lo
goto out;
}
+ ret = file_write_and_wait_range(file, start, end);
+ if (ret)
+ return ret;
+
if (!journal) {
- ret = __generic_file_fsync(file, start, end, datasync);
+ struct writeback_control wbc = {
+ .sync_mode = WB_SYNC_ALL
+ };
+
+ ret = ext4_write_inode(inode, &wbc);
if (!ret)
ret = ext4_sync_parent(inode);
if (test_opt(inode->i_sb, BARRIER))
@@ -125,9 +133,6 @@ int ext4_sync_file(struct file *file, lo
goto out;
}
- ret = file_write_and_wait_range(file, start, end);
- if (ret)
- return ret;
/*
* data=writeback,ordered:
* The caller's filemap_fdatawrite()/wait will sync the data.
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 51/57] ext4: track writeback errors using the generic tracking infrastructure
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (49 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 50/57] ext4: use ext4_write_inode() when fsyncing w/o a journal Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 52/57] ext4: fix special inode number checks in __ext4_iget() Greg Kroah-Hartman
` (8 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Theodore Tso, stable
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <tytso@mit.edu>
commit 95cb67138746451cc84cf8e516e14989746e93b0 upstream.
We already using mapping_set_error() in fs/ext4/page_io.c, so all we
need to do is to use file_check_and_advance_wb_err() when handling
fsync() requests in ext4_sync_file().
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/fsync.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/ext4/fsync.c
+++ b/fs/ext4/fsync.c
@@ -164,6 +164,9 @@ int ext4_sync_file(struct file *file, lo
ret = err;
}
out:
+ err = file_check_and_advance_wb_err(file);
+ if (ret == 0)
+ ret = err;
trace_ext4_sync_file_exit(inode, ret);
return ret;
}
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 52/57] ext4: fix special inode number checks in __ext4_iget()
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (50 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 51/57] ext4: track writeback errors using the generic tracking infrastructure Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 53/57] mm: page_mapped: dont assume compound page is huge or THP Greg Kroah-Hartman
` (7 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Theodore Tso, Dan Carpenter, stable
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <tytso@mit.edu>
commit 191ce17876c9367819c4b0a25b503c0f6d9054d8 upstream.
The check for special (reserved) inode number checks in __ext4_iget()
was broken by commit 8a363970d1dc: ("ext4: avoid declaring fs
inconsistent due to invalid file handles"). This was caused by a
botched reversal of the sense of the flag now known as
EXT4_IGET_SPECIAL (when it was previously named EXT4_IGET_NORMAL).
Fix the logic appropriately.
Fixes: 8a363970d1dc ("ext4: avoid declaring fs inconsistent...")
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4834,7 +4834,7 @@ struct inode *__ext4_iget(struct super_b
gid_t i_gid;
projid_t i_projid;
- if (((flags & EXT4_IGET_NORMAL) &&
+ if ((!(flags & EXT4_IGET_SPECIAL) &&
(ino < EXT4_FIRST_INO(sb) && ino != EXT4_ROOT_INO)) ||
(ino < EXT4_ROOT_INO) ||
(ino > le32_to_cpu(EXT4_SB(sb)->s_es->s_inodes_count))) {
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 53/57] mm: page_mapped: dont assume compound page is huge or THP
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (51 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 52/57] ext4: fix special inode number checks in __ext4_iget() Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 54/57] sunrpc: use-after-free in svc_process_common() Greg Kroah-Hartman
` (6 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jan Stancek, Kirill A. Shutemov,
Michal Hocko, Kirill A. Shutemov, David Hildenbrand,
Andrea Arcangeli, Andrew Morton, Linus Torvalds, Laszlo Ersek
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Stancek <jstancek@redhat.com>
commit 8ab88c7169b7fba98812ead6524b9d05bc76cf00 upstream.
LTP proc01 testcase has been observed to rarely trigger crashes
on arm64:
page_mapped+0x78/0xb4
stable_page_flags+0x27c/0x338
kpageflags_read+0xfc/0x164
proc_reg_read+0x7c/0xb8
__vfs_read+0x58/0x178
vfs_read+0x90/0x14c
SyS_read+0x60/0xc0
The issue is that page_mapped() assumes that if compound page is not
huge, then it must be THP. But if this is 'normal' compound page
(COMPOUND_PAGE_DTOR), then following loop can keep running (for
HPAGE_PMD_NR iterations) until it tries to read from memory that isn't
mapped and triggers a panic:
for (i = 0; i < hpage_nr_pages(page); i++) {
if (atomic_read(&page[i]._mapcount) >= 0)
return true;
}
I could replicate this on x86 (v4.20-rc4-98-g60b548237fed) only
with a custom kernel module [1] which:
- allocates compound page (PAGEC) of order 1
- allocates 2 normal pages (COPY), which are initialized to 0xff (to
satisfy _mapcount >= 0)
- 2 PAGEC page structs are copied to address of first COPY page
- second page of COPY is marked as not present
- call to page_mapped(COPY) now triggers fault on access to 2nd COPY
page at offset 0x30 (_mapcount)
[1] https://github.com/jstancek/reproducers/blob/master/kernel/page_mapped_crash/repro.c
Fix the loop to iterate for "1 << compound_order" pages.
Kirrill said "IIRC, sound subsystem can producuce custom mapped compound
pages".
Link: http://lkml.kernel.org/r/c440d69879e34209feba21e12d236d06bc0a25db.1543577156.git.jstancek@redhat.com
Fixes: e1534ae95004 ("mm: differentiate page_mapped() from page_mapcount() for compound pages")
Signed-off-by: Jan Stancek <jstancek@redhat.com>
Debugged-by: Laszlo Ersek <lersek@redhat.com>
Suggested-by: "Kirill A. Shutemov" <kirill@shutemov.name>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/util.c
+++ b/mm/util.c
@@ -478,7 +478,7 @@ bool page_mapped(struct page *page)
return true;
if (PageHuge(page))
return false;
- for (i = 0; i < hpage_nr_pages(page); i++) {
+ for (i = 0; i < (1 << compound_order(page)); i++) {
if (atomic_read(&page[i]._mapcount) >= 0)
return true;
}
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 54/57] sunrpc: use-after-free in svc_process_common()
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (52 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 53/57] mm: page_mapped: dont assume compound page is huge or THP Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 55/57] Btrfs: fix access to available allocation bits when starting balance Greg Kroah-Hartman
` (5 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vasily Averin, J. Bruce Fields
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vasily Averin <vvs@virtuozzo.com>
commit d4b09acf924b84bae77cad090a9d108e70b43643 upstream.
if node have NFSv41+ mounts inside several net namespaces
it can lead to use-after-free in svc_process_common()
svc_process_common()
/* Setup reply header */
rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr(rqstp); <<< HERE
svc_process_common() can use incorrect rqstp->rq_xprt,
its caller function bc_svc_process() takes it from serv->sv_bc_xprt.
The problem is that serv is global structure but sv_bc_xprt
is assigned per-netnamespace.
According to Trond, the whole "let's set up rqstp->rq_xprt
for the back channel" is nothing but a giant hack in order
to work around the fact that svc_process_common() uses it
to find the xpt_ops, and perform a couple of (meaningless
for the back channel) tests of xpt_flags.
All we really need in svc_process_common() is to be able to run
rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr()
Bruce J Fields points that this xpo_prep_reply_hdr() call
is an awfully roundabout way just to do "svc_putnl(resv, 0);"
in the tcp case.
This patch does not initialiuze rqstp->rq_xprt in bc_svc_process(),
now it calls svc_process_common() with rqstp->rq_xprt = NULL.
To adjust reply header svc_process_common() just check
rqstp->rq_prot and calls svc_tcp_prep_reply_hdr() for tcp case.
To handle rqstp->rq_xprt = NULL case in functions called from
svc_process_common() patch intruduces net namespace pointer
svc_rqst->rq_bc_net and adjust SVC_NET() definition.
Some other function was also adopted to properly handle described case.
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Cc: stable@vger.kernel.org
Fixes: 23c20ecd4475 ("NFS: callback up - users counting cleanup")
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
v2: added lost extern svc_tcp_prep_reply_hdr()
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/sunrpc/svc.h | 5 ++++-
include/trace/events/sunrpc.h | 6 ++++--
net/sunrpc/svc.c | 11 +++++++----
net/sunrpc/svc_xprt.c | 5 +++--
net/sunrpc/svcsock.c | 2 +-
5 files changed, 19 insertions(+), 10 deletions(-)
--- a/include/linux/sunrpc/svc.h
+++ b/include/linux/sunrpc/svc.h
@@ -295,9 +295,12 @@ struct svc_rqst {
struct svc_cacherep * rq_cacherep; /* cache info */
struct task_struct *rq_task; /* service thread */
spinlock_t rq_lock; /* per-request lock */
+ struct net *rq_bc_net; /* pointer to backchannel's
+ * net namespace
+ */
};
-#define SVC_NET(svc_rqst) (svc_rqst->rq_xprt->xpt_net)
+#define SVC_NET(rqst) (rqst->rq_xprt ? rqst->rq_xprt->xpt_net : rqst->rq_bc_net)
/*
* Rigorous type checking on sockaddr type conversions
--- a/include/trace/events/sunrpc.h
+++ b/include/trace/events/sunrpc.h
@@ -569,7 +569,8 @@ TRACE_EVENT(svc_process,
__field(u32, vers)
__field(u32, proc)
__string(service, name)
- __string(addr, rqst->rq_xprt->xpt_remotebuf)
+ __string(addr, rqst->rq_xprt ?
+ rqst->rq_xprt->xpt_remotebuf : "(null)")
),
TP_fast_assign(
@@ -577,7 +578,8 @@ TRACE_EVENT(svc_process,
__entry->vers = rqst->rq_vers;
__entry->proc = rqst->rq_proc;
__assign_str(service, name);
- __assign_str(addr, rqst->rq_xprt->xpt_remotebuf);
+ __assign_str(addr, rqst->rq_xprt ?
+ rqst->rq_xprt->xpt_remotebuf : "(null)");
),
TP_printk("addr=%s xid=0x%08x service=%s vers=%u proc=%u",
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -1144,6 +1144,8 @@ void svc_printk(struct svc_rqst *rqstp,
static __printf(2,3) void svc_printk(struct svc_rqst *rqstp, const char *fmt, ...) {}
#endif
+extern void svc_tcp_prep_reply_hdr(struct svc_rqst *);
+
/*
* Common routine for processing the RPC request.
*/
@@ -1172,7 +1174,8 @@ svc_process_common(struct svc_rqst *rqst
clear_bit(RQ_DROPME, &rqstp->rq_flags);
/* Setup reply header */
- rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr(rqstp);
+ if (rqstp->rq_prot == IPPROTO_TCP)
+ svc_tcp_prep_reply_hdr(rqstp);
svc_putu32(resv, rqstp->rq_xid);
@@ -1244,7 +1247,7 @@ svc_process_common(struct svc_rqst *rqst
* for lower versions. RPC_PROG_MISMATCH seems to be the closest
* fit.
*/
- if (versp->vs_need_cong_ctrl &&
+ if (versp->vs_need_cong_ctrl && rqstp->rq_xprt &&
!test_bit(XPT_CONG_CTRL, &rqstp->rq_xprt->xpt_flags))
goto err_bad_vers;
@@ -1336,7 +1339,7 @@ svc_process_common(struct svc_rqst *rqst
return 0;
close:
- if (test_bit(XPT_TEMP, &rqstp->rq_xprt->xpt_flags))
+ if (rqstp->rq_xprt && test_bit(XPT_TEMP, &rqstp->rq_xprt->xpt_flags))
svc_close_xprt(rqstp->rq_xprt);
dprintk("svc: svc_process close\n");
return 0;
@@ -1459,10 +1462,10 @@ bc_svc_process(struct svc_serv *serv, st
dprintk("svc: %s(%p)\n", __func__, req);
/* Build the svc_rqst used by the common processing routine */
- rqstp->rq_xprt = serv->sv_bc_xprt;
rqstp->rq_xid = req->rq_xid;
rqstp->rq_prot = req->rq_xprt->prot;
rqstp->rq_server = serv;
+ rqstp->rq_bc_net = req->rq_xprt->xprt_net;
rqstp->rq_addrlen = sizeof(req->rq_xprt->addr);
memcpy(&rqstp->rq_addr, &req->rq_xprt->addr, rqstp->rq_addrlen);
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -468,10 +468,11 @@ out:
*/
void svc_reserve(struct svc_rqst *rqstp, int space)
{
+ struct svc_xprt *xprt = rqstp->rq_xprt;
+
space += rqstp->rq_res.head[0].iov_len;
- if (space < rqstp->rq_reserved) {
- struct svc_xprt *xprt = rqstp->rq_xprt;
+ if (xprt && space < rqstp->rq_reserved) {
atomic_sub((rqstp->rq_reserved - space), &xprt->xpt_reserved);
rqstp->rq_reserved = space;
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -1173,7 +1173,7 @@ static int svc_tcp_sendto(struct svc_rqs
/*
* Setup response header. TCP has a 4B record length field.
*/
-static void svc_tcp_prep_reply_hdr(struct svc_rqst *rqstp)
+void svc_tcp_prep_reply_hdr(struct svc_rqst *rqstp)
{
struct kvec *resv = &rqstp->rq_res.head[0];
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 55/57] Btrfs: fix access to available allocation bits when starting balance
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (53 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 54/57] sunrpc: use-after-free in svc_process_common() Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 56/57] Btrfs: fix deadlock when enabling quotas due to concurrent snapshot creation Greg Kroah-Hartman
` (4 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nikolay Borisov, Filipe Manana, David Sterba
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <fdmanana@suse.com>
commit 5a8067c0d17feb7579db0476191417b441a8996e upstream.
The available allocation bits members from struct btrfs_fs_info are
protected by a sequence lock, and when starting balance we access them
incorrectly in two different ways:
1) In the read sequence lock loop at btrfs_balance() we use the values we
read from fs_info->avail_*_alloc_bits and we can immediately do actions
that have side effects and can not be undone (printing a message and
jumping to a label). This is wrong because a retry might be needed, so
our actions must not have side effects and must be repeatable as long
as read_seqretry() returns a non-zero value. In other words, we were
essentially ignoring the sequence lock;
2) Right below the read sequence lock loop, we were reading the values
from avail_metadata_alloc_bits and avail_data_alloc_bits without any
protection from concurrent writers, that is, reading them outside of
the read sequence lock critical section.
So fix this by making sure we only read the available allocation bits
while in a read sequence lock critical section and that what we do in the
critical section is repeatable (has nothing that can not be undone) so
that any eventual retry that is needed is handled properly.
Fixes: de98ced9e743 ("Btrfs: use seqlock to protect fs_info->avail_{data, metadata, system}_alloc_bits")
Fixes: 14506127979a ("btrfs: fix a bogus warning when converting only data or metadata")
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/volumes.c | 39 +++++++++++++++++++++++----------------
1 file changed, 23 insertions(+), 16 deletions(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3724,6 +3724,7 @@ int btrfs_balance(struct btrfs_fs_info *
int ret;
u64 num_devices;
unsigned seq;
+ bool reducing_integrity;
if (btrfs_fs_closing(fs_info) ||
atomic_read(&fs_info->balance_pause_req) ||
@@ -3803,24 +3804,30 @@ int btrfs_balance(struct btrfs_fs_info *
!(bctl->sys.target & allowed)) ||
((bctl->meta.flags & BTRFS_BALANCE_ARGS_CONVERT) &&
(fs_info->avail_metadata_alloc_bits & allowed) &&
- !(bctl->meta.target & allowed))) {
- if (bctl->flags & BTRFS_BALANCE_FORCE) {
- btrfs_info(fs_info,
- "balance: force reducing metadata integrity");
- } else {
- btrfs_err(fs_info,
- "balance: reduces metadata integrity, use --force if you want this");
- ret = -EINVAL;
- goto out;
- }
- }
+ !(bctl->meta.target & allowed)))
+ reducing_integrity = true;
+ else
+ reducing_integrity = false;
+
+ /* if we're not converting, the target field is uninitialized */
+ meta_target = (bctl->meta.flags & BTRFS_BALANCE_ARGS_CONVERT) ?
+ bctl->meta.target : fs_info->avail_metadata_alloc_bits;
+ data_target = (bctl->data.flags & BTRFS_BALANCE_ARGS_CONVERT) ?
+ bctl->data.target : fs_info->avail_data_alloc_bits;
} while (read_seqretry(&fs_info->profiles_lock, seq));
- /* if we're not converting, the target field is uninitialized */
- meta_target = (bctl->meta.flags & BTRFS_BALANCE_ARGS_CONVERT) ?
- bctl->meta.target : fs_info->avail_metadata_alloc_bits;
- data_target = (bctl->data.flags & BTRFS_BALANCE_ARGS_CONVERT) ?
- bctl->data.target : fs_info->avail_data_alloc_bits;
+ if (reducing_integrity) {
+ if (bctl->flags & BTRFS_BALANCE_FORCE) {
+ btrfs_info(fs_info,
+ "balance: force reducing metadata integrity");
+ } else {
+ btrfs_err(fs_info,
+ "balance: reduces metadata integrity, use --force if you want this");
+ ret = -EINVAL;
+ goto out;
+ }
+ }
+
if (btrfs_get_num_tolerated_disk_barrier_failures(meta_target) <
btrfs_get_num_tolerated_disk_barrier_failures(data_target)) {
int meta_index = btrfs_bg_flags_to_raid_index(meta_target);
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 56/57] Btrfs: fix deadlock when enabling quotas due to concurrent snapshot creation
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (54 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 55/57] Btrfs: fix access to available allocation bits when starting balance Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-15 16:36 ` [PATCH 4.20 57/57] Btrfs: use nofs context when initializing security xattrs to avoid deadlock Greg Kroah-Hartman
` (3 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Filipe Manana, David Sterba
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <fdmanana@suse.com>
commit 9a6f209e36500efac51528132a3e3083586eda5f upstream.
If the quota enable and snapshot creation ioctls are called concurrently
we can get into a deadlock where the task enabling quotas will deadlock
on the fs_info->qgroup_ioctl_lock mutex because it attempts to lock it
twice, or the task creating a snapshot tries to commit the transaction
while the task enabling quota waits for the former task to commit the
transaction while holding the mutex. The following time diagrams show how
both cases happen.
First scenario:
CPU 0 CPU 1
btrfs_ioctl()
btrfs_ioctl_quota_ctl()
btrfs_quota_enable()
mutex_lock(fs_info->qgroup_ioctl_lock)
btrfs_start_transaction()
btrfs_ioctl()
btrfs_ioctl_snap_create_v2
create_snapshot()
--> adds snapshot to the
list pending_snapshots
of the current
transaction
btrfs_commit_transaction()
create_pending_snapshots()
create_pending_snapshot()
qgroup_account_snapshot()
btrfs_qgroup_inherit()
mutex_lock(fs_info->qgroup_ioctl_lock)
--> deadlock, mutex already locked
by this task at
btrfs_quota_enable()
Second scenario:
CPU 0 CPU 1
btrfs_ioctl()
btrfs_ioctl_quota_ctl()
btrfs_quota_enable()
mutex_lock(fs_info->qgroup_ioctl_lock)
btrfs_start_transaction()
btrfs_ioctl()
btrfs_ioctl_snap_create_v2
create_snapshot()
--> adds snapshot to the
list pending_snapshots
of the current
transaction
btrfs_commit_transaction()
--> waits for task at
CPU 0 to release
its transaction
handle
btrfs_commit_transaction()
--> sees another task started
the transaction commit first
--> releases its transaction
handle
--> waits for the transaction
commit to be completed by
the task at CPU 1
create_pending_snapshot()
qgroup_account_snapshot()
btrfs_qgroup_inherit()
mutex_lock(fs_info->qgroup_ioctl_lock)
--> deadlock, task at CPU 0
has the mutex locked but
it is waiting for us to
finish the transaction
commit
So fix this by setting the quota enabled flag in fs_info after committing
the transaction at btrfs_quota_enable(). This ends up serializing quota
enable and snapshot creation as if the snapshot creation happened just
before the quota enable request. The quota rescan task, scheduled after
committing the transaction in btrfs_quote_enable(), will do the accounting.
Fixes: 6426c7ad697d ("btrfs: qgroup: Fix qgroup accounting when creating snapshot")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/qgroup.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -1013,16 +1013,22 @@ out_add_root:
btrfs_abort_transaction(trans, ret);
goto out_free_path;
}
- spin_lock(&fs_info->qgroup_lock);
- fs_info->quota_root = quota_root;
- set_bit(BTRFS_FS_QUOTA_ENABLED, &fs_info->flags);
- spin_unlock(&fs_info->qgroup_lock);
ret = btrfs_commit_transaction(trans);
trans = NULL;
if (ret)
goto out_free_path;
+ /*
+ * Set quota enabled flag after committing the transaction, to avoid
+ * deadlocks on fs_info->qgroup_ioctl_lock with concurrent snapshot
+ * creation.
+ */
+ spin_lock(&fs_info->qgroup_lock);
+ fs_info->quota_root = quota_root;
+ set_bit(BTRFS_FS_QUOTA_ENABLED, &fs_info->flags);
+ spin_unlock(&fs_info->qgroup_lock);
+
ret = qgroup_rescan_init(fs_info, 0, 1);
if (!ret) {
qgroup_rescan_zero_tracking(fs_info);
^ permalink raw reply [flat|nested] 66+ messages in thread* [PATCH 4.20 57/57] Btrfs: use nofs context when initializing security xattrs to avoid deadlock
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (55 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 56/57] Btrfs: fix deadlock when enabling quotas due to concurrent snapshot creation Greg Kroah-Hartman
@ 2019-01-15 16:36 ` Greg Kroah-Hartman
2019-01-16 2:00 ` [PATCH 4.20 00/57] 4.20.3-stable review shuah
` (2 subsequent siblings)
59 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-15 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nikolay Borisov, Filipe Manana, David Sterba
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <fdmanana@suse.com>
commit 827aa18e7b903c5ff3b3cd8fec328a99b1dbd411 upstream.
When initializing the security xattrs, we are holding a transaction handle
therefore we need to use a GFP_NOFS context in order to avoid a deadlock
with reclaim in case it's triggered.
Fixes: 39a27ec1004e8 ("btrfs: use GFP_KERNEL for xattr and acl allocations")
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/xattr.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/fs/btrfs/xattr.c
+++ b/fs/btrfs/xattr.c
@@ -11,6 +11,7 @@
#include <linux/security.h>
#include <linux/posix_acl_xattr.h>
#include <linux/iversion.h>
+#include <linux/sched/mm.h>
#include "ctree.h"
#include "btrfs_inode.h"
#include "transaction.h"
@@ -422,9 +423,15 @@ static int btrfs_initxattrs(struct inode
{
const struct xattr *xattr;
struct btrfs_trans_handle *trans = fs_info;
+ unsigned int nofs_flag;
char *name;
int err = 0;
+ /*
+ * We're holding a transaction handle, so use a NOFS memory allocation
+ * context to avoid deadlock if reclaim happens.
+ */
+ nofs_flag = memalloc_nofs_save();
for (xattr = xattr_array; xattr->name != NULL; xattr++) {
name = kmalloc(XATTR_SECURITY_PREFIX_LEN +
strlen(xattr->name) + 1, GFP_KERNEL);
@@ -440,6 +447,7 @@ static int btrfs_initxattrs(struct inode
if (err < 0)
break;
}
+ memalloc_nofs_restore(nofs_flag);
return err;
}
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH 4.20 00/57] 4.20.3-stable review
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (56 preceding siblings ...)
2019-01-15 16:36 ` [PATCH 4.20 57/57] Btrfs: use nofs context when initializing security xattrs to avoid deadlock Greg Kroah-Hartman
@ 2019-01-16 2:00 ` shuah
2019-01-16 6:56 ` Greg Kroah-Hartman
2019-01-16 11:47 ` Naresh Kamboju
2019-01-16 20:38 ` Guenter Roeck
59 siblings, 1 reply; 66+ messages in thread
From: shuah @ 2019-01-16 2:00 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, shuah
On 1/15/19 9:35 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.20.3 release.
> There are 57 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Jan 17 15:48:32 UTC 2019.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.20.3-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.20.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH 4.20 00/57] 4.20.3-stable review
2019-01-16 2:00 ` [PATCH 4.20 00/57] 4.20.3-stable review shuah
@ 2019-01-16 6:56 ` Greg Kroah-Hartman
0 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-16 6:56 UTC (permalink / raw)
To: shuah
Cc: linux-kernel, torvalds, akpm, linux, patches, ben.hutchings,
lkft-triage, stable
On Tue, Jan 15, 2019 at 07:00:59PM -0700, shuah wrote:
> On 1/15/19 9:35 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.20.3 release.
> > There are 57 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Jan 17 15:48:32 UTC 2019.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.20.3-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.20.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4.20 00/57] 4.20.3-stable review
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (57 preceding siblings ...)
2019-01-16 2:00 ` [PATCH 4.20 00/57] 4.20.3-stable review shuah
@ 2019-01-16 11:47 ` Naresh Kamboju
2019-01-16 16:13 ` Greg Kroah-Hartman
2019-01-16 20:38 ` Guenter Roeck
59 siblings, 1 reply; 66+ messages in thread
From: Naresh Kamboju @ 2019-01-16 11:47 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Tue, 15 Jan 2019 at 22:15, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.20.3 release.
> There are 57 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Jan 17 15:48:32 UTC 2019.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.20.3-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.20.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.20.3-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.20.y
git commit: b993fcf79d3f027340477d3a9382f559cd717591
git describe: v4.20.2-58-gb993fcf79d3f
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.20-oe/build/v4.20.2-58-gb993fcf79d3f
No regressions (compared to build v4.20.2)
No fixes (compared to build v4.20.2)
Ran 20575 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* spectre-meltdown-checker-test
* ltp-fs-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH 4.20 00/57] 4.20.3-stable review
2019-01-16 11:47 ` Naresh Kamboju
@ 2019-01-16 16:13 ` Greg Kroah-Hartman
0 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-16 16:13 UTC (permalink / raw)
To: Naresh Kamboju
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Wed, Jan 16, 2019 at 05:17:49PM +0530, Naresh Kamboju wrote:
> On Tue, 15 Jan 2019 at 22:15, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 4.20.3 release.
> > There are 57 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Jan 17 15:48:32 UTC 2019.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.20.3-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.20.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
Thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4.20 00/57] 4.20.3-stable review
2019-01-15 16:35 [PATCH 4.20 00/57] 4.20.3-stable review Greg Kroah-Hartman
` (58 preceding siblings ...)
2019-01-16 11:47 ` Naresh Kamboju
@ 2019-01-16 20:38 ` Guenter Roeck
2019-01-16 21:45 ` Greg Kroah-Hartman
59 siblings, 1 reply; 66+ messages in thread
From: Guenter Roeck @ 2019-01-16 20:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
On Tue, Jan 15, 2019 at 05:35:41PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.20.3 release.
> There are 57 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Jan 17 15:48:32 UTC 2019.
> Anything received after that time might be too late.
>
Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 343 pass: 343 fail: 0
Guenter
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [PATCH 4.20 00/57] 4.20.3-stable review
2019-01-16 20:38 ` Guenter Roeck
@ 2019-01-16 21:45 ` Greg Kroah-Hartman
0 siblings, 0 replies; 66+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-16 21:45 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
On Wed, Jan 16, 2019 at 12:38:44PM -0800, Guenter Roeck wrote:
> On Tue, Jan 15, 2019 at 05:35:41PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.20.3 release.
> > There are 57 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Jan 17 15:48:32 UTC 2019.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 159 pass: 159 fail: 0
> Qemu test results:
> total: 343 pass: 343 fail: 0
Wonderful, thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 66+ messages in thread