USB controller ASM1042 stops working after commit de3ef1eb1cd0 ("PM /
core: Drop run_wake flag from struct dev_pm_info").
The device in question is not power managed by platform firmware,
furthermore, it only supports PME# from D3cold:
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Before commit de3ef1eb1cd0, the device never gets runtime suspended.
After that commit, the device gets runtime suspended to D3hot, which can
not generate any PME#.
usb_hcd_pci_probe() unconditionally calls device_wakeup_enable(), hence
device_can_wakeup() in pci_dev_run_wake() always returns true.
So pci_dev_run_wake() needs to check PME wakeup capability as its first
condition.
In addition, change wakeup flag passed to pci_target_state() from false
to true, because we want to find the deepest state that the device can
still generate PME#. In this case, it's D0 for the device in question.
Fixes: de3ef1eb1cd0 ("PM / core: Drop run_wake flag from struct dev_pm_info")
Cc: stable(a)vger.kernel.org # 4.13+
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
---
v4: Correct some errors in commit log.
v3: State the reason why the wakeup flag gets changed.
v2: Explicitly check dev->pme_support.
drivers/pci/pci.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a04197ce767d..c2616cad3a1d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2138,16 +2138,16 @@ bool pci_dev_run_wake(struct pci_dev *dev)
{
struct pci_bus *bus = dev->bus;
- if (device_can_wakeup(&dev->dev))
- return true;
-
if (!dev->pme_support)
return false;
/* PME-capable in principle, but not from the target power state */
- if (!pci_pme_capable(dev, pci_target_state(dev, false)))
+ if (!pci_pme_capable(dev, pci_target_state(dev, true)))
return false;
+ if (device_can_wakeup(&dev->dev))
+ return true;
+
while (bus->parent) {
struct pci_dev *bridge = bus->self;
--
2.17.0
NAND chips require a bit of time to take the NAND operation into
account and set the BUSY bit in the STATUS reg. Make sure we don't poll
the STATUS reg too early in nand_soft_waitrdy().
Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
---
Changes in v2:
- Move the ndelay() to nand_soft_waitrdy() instead of having it in the
FSMC driver
---
drivers/mtd/nand/raw/nand_base.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 72f3a89da513..da94fcb4dd9b 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -706,12 +706,17 @@ static void nand_wait_status_ready(struct mtd_info *mtd, unsigned long timeo)
*/
int nand_soft_waitrdy(struct nand_chip *chip, unsigned long timeout_ms)
{
+ const struct nand_sdr_timings *timings;
u8 status = 0;
int ret;
if (!chip->exec_op)
return -ENOTSUPP;
+ /* Wait tWB before polling the STATUS reg. */
+ timings = nand_get_sdr_timings(&chip->data_interface);
+ ndelay(PSEC_TO_NSEC(sdr->tWB_max));
+
ret = nand_status_op(chip, NULL);
if (ret)
return ret;
--
2.14.1
Paolo Bonzini <pbonzini(a)redhat.com> wrote:
> -ftracer can duplicate asm blocks causing compilation to fail in
> noclone functions. For example, KVM declares a global variable
> in an asm like
>
> asm("2: ... \n
> .pushsection data \n
> .global vmx_return \n
> vmx_return: .long 2b");
>
> and -ftracer causes a double declaration.
>
> Cc: Andrew Morton <akpm(a)linux-foundation.org>
> Cc: Michal Marek <mmarek(a)suse.cz>
> Cc: stable(a)vger.kernel.org
> Cc: kvm(a)vger.kernel.org
> Reported-by: Linda Walsh <lkml(a)tlinx.org>
> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
> ---
> include/linux/compiler-gcc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 22ab246feed3..eeae401a2412 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -199,7 +199,7 @@
> #define unreachable() __builtin_unreachable()
>
> /* Mark a function definition as prohibited from being cloned. */
> -#define __noclone __attribute__((__noclone__))
> +#define __noclone __attribute__((__noclone__, __optimize__("no-tracer")))
[ Bringing the thread back from the dead for context ]
Setting different optimization attributes to certain functions apparently
prevents gcc from inlining functions with different “optimizations”. This
results in poor compilation - most notably of vmx_vcpu_run() - and causes
short functions such as to_vmx() not to be inlined.
Regards,
Nadav
The s390 CPU measurement facility sampling mode
supports basic entries and diagnostic entries.
Each entry has a valid bit to indicate the
status of the entry as valid or invalid.
This bit is bit 31 in the diagnostic entry,
but the bit mask definition refers to bit 30.
Fix this by making the reserved field one
bit larger.
Cc: stable(a)vger.kernel.org # v3.14+
Fixes: 7e75fc3ff4cf ("s390/cpum_sf: Add raw data sampling to support the diagnostic-sampling function")
Signed-off-by: Thomas Richter <tmricht(a)linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner(a)linux.vnet.ibm.com>
---
arch/s390/include/asm/cpu_mf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/include/asm/cpu_mf.h b/arch/s390/include/asm/cpu_mf.h
index f58d17e9dd65..7093a27520ee 100644
--- a/arch/s390/include/asm/cpu_mf.h
+++ b/arch/s390/include/asm/cpu_mf.h
@@ -113,7 +113,7 @@ struct hws_basic_entry {
struct hws_diag_entry {
unsigned int def:16; /* 0-15 Data Entry Format */
- unsigned int R:14; /* 16-19 and 20-30 reserved */
+ unsigned int R:15; /* 16-19 and 20-30 reserved */
unsigned int I:1; /* 31 entry valid or invalid */
u8 data[]; /* Machine-dependent sample data */
} __packed;
--
2.16.3
On 5/3/2018 2:13 AM, gregkh(a)linuxfoundation.org wrote:
> This is a note to let you know that I've just added the patch titled
>
> mm/kmemleak.c: wait for scan completion before disabling free
>
> to the 3.18-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> mm-kmemleak.c-wait-for-scan-completion-before-disabling-free.patch
> and it can be found in the queue-3.18 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
>
>
> From foo@baz Wed May 2 13:21:44 PDT 2018
> From: Vinayak Menon <vinmenon(a)codeaurora.org>
> Date: Wed, 28 Mar 2018 16:01:16 -0700
> Subject: mm/kmemleak.c: wait for scan completion before disabling free
>
> From: Vinayak Menon <vinmenon(a)codeaurora.org>
>
> [ Upstream commit 914b6dfff790544d9b77dfd1723adb3745ec9700 ]
>
> A crash is observed when kmemleak_scan accesses the object->pointer,
> likely due to the following race.
>
> TASK A TASK B TASK C
> kmemleak_write
> (with "scan" and
> NOT "scan=on")
> kmemleak_scan()
> create_object
> kmem_cache_alloc fails
> kmemleak_disable
> kmemleak_do_cleanup
> kmemleak_free_enabled = 0
> kfree
> kmemleak_free bails out
> (kmemleak_free_enabled is 0)
> slub frees object->pointer
> update_checksum
> crash - object->pointer
> freed (DEBUG_PAGEALLOC)
>
> kmemleak_do_cleanup waits for the scan thread to complete, but not for
> direct call to kmemleak_scan via kmemleak_write. So add a wait for
> kmemleak_scan completion before disabling kmemleak_free, and while at it
> fix the comment on stop_scan_thread.
>
> [vinmenon(a)codeaurora.org: fix stop_scan_thread comment]
> Link: http://lkml.kernel.org/r/1522219972-22809-1-git-send-email-vinmenon@codeaur…
> Link: http://lkml.kernel.org/r/1522063429-18992-1-git-send-email-vinmenon@codeaur…
> Signed-off-by: Vinayak Menon <vinmenon(a)codeaurora.org>
> Reviewed-by: Catalin Marinas <catalin.marinas(a)arm.com>
> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> ---
> mm/kmemleak.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -1481,8 +1481,7 @@ static void start_scan_thread(void)
> }
>
> /*
> - * Stop the automatic memory scanning thread. This function must be called
> - * with the scan_mutex held.
> + * Stop the automatic memory scanning thread.
> */
> static void stop_scan_thread(void)
> {
> @@ -1746,12 +1745,15 @@ static void kmemleak_do_cleanup(struct w
> mutex_lock(&scan_mutex);
> stop_scan_thread();
>
> + mutex_lock(&scan_mutex);
The lock is taken once above stop_scan_thread() and can result in a deadlock.
The lock was removed from kmemleak_do_cleanup by following commit which is not present on 3.18
commit 5f369f374ba4889fe3c17883402db5ee8d254216
Author: Catalin Marinas <catalin.marinas(a)arm.com>
Date: Wed Jun 24 16:58:31 2015 -0700
mm: kmemleak: do not acquire scan_mutex in kmemleak_do_cleanup()
So we may have to pick the above patch too.
> /*
> - * Once the scan thread has stopped, it is safe to no longer track
> - * object freeing. Ordering of the scan thread stopping and the memory
> - * accesses below is guaranteed by the kthread_stop() function.
> + * Once it is made sure that kmemleak_scan has stopped, it is safe to no
> + * longer track object freeing. Ordering of the scan thread stopping and
> + * the memory accesses below is guaranteed by the kthread_stop()
> + * function.
> */
> kmemleak_free_enabled = 0;
> + mutex_unlock(&scan_mutex);
>
> if (!kmemleak_found_leaks)
> __kmemleak_do_cleanup();
>
>
> Patches currently in stable-queue which might be from vinmenon(a)codeaurora.org are
>
> queue-3.18/mm-kmemleak.c-wait-for-scan-completion-before-disabling-free.patch