Decided to add Enric's commit because it is also a bug fix instead
of modifying Chris commit.
Chris Chiu (1):
tpm: self test failure should not cause suspend to fail
Enric Balletbo i Serra (1):
tpm: do not suspend/resume if power stays on
drivers/char/tpm/tpm-interface.c | 7 +++++++
drivers/char/tpm/tpm.h | 2 ++
drivers/char/tpm/tpm_of.c | 3 +++
3 files changed, 12 insertions(+)
--
2.17.0
Changes since v8 [1]:
* Rebase on v4.17-rc2
* Fix get_user_pages_fast() for ZONE_DEVICE pages to revalidate the pte,
pmd, pud after taking references (Jan)
* Kill dax_layout_lock(). With get_user_pages_fast() for ZONE_DEVICE
fixed we can then rely on the {pte,pmd}_lock to synchronize
dax_layout_busy_page() vs new page references (Jan)
* Hold the iolock over repeated invocations of dax_layout_busy_page() to
enable truncate/hole-punch to make forward progress in the presence of
a constant stream of new direct-I/O requests (Jan).
[1]: https://lists.01.org/pipermail/linux-nvdimm/2018-March/015058.html
---
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
---
Dan Williams (9):
dax, dm: introduce ->fs_{claim,release}() dax_device infrastructure
mm, dax: enable filesystems to trigger dev_pagemap ->page_free callbacks
memremap: split devm_memremap_pages() and memremap() infrastructure
mm, dev_pagemap: introduce CONFIG_DEV_PAGEMAP_OPS
mm: fix __gup_device_huge vs unmap
mm, fs, dax: handle layout changes to pinned dax mappings
xfs: prepare xfs_break_layouts() to be called with XFS_MMAPLOCK_EXCL
xfs: prepare xfs_break_layouts() for another layout type
xfs, dax: introduce xfs_break_dax_layouts()
drivers/dax/super.c | 99 ++++++++++++++++++++--
drivers/md/dm.c | 57 +++++++++++++
drivers/nvdimm/pmem.c | 3 -
fs/Kconfig | 2
fs/dax.c | 97 +++++++++++++++++++++
fs/ext2/super.c | 6 +
fs/ext4/super.c | 6 +
fs/xfs/xfs_file.c | 72 +++++++++++++++-
fs/xfs/xfs_inode.h | 16 ++++
fs/xfs/xfs_ioctl.c | 8 --
fs/xfs/xfs_iops.c | 16 ++--
fs/xfs/xfs_pnfs.c | 16 ++--
fs/xfs/xfs_pnfs.h | 6 +
fs/xfs/xfs_super.c | 20 ++--
include/linux/dax.h | 71 +++++++++++++++-
include/linux/memremap.h | 25 ++----
include/linux/mm.h | 71 ++++++++++++----
kernel/Makefile | 3 -
kernel/iomem.c | 167 +++++++++++++++++++++++++++++++++++++
kernel/memremap.c | 208 ++++++----------------------------------------
mm/Kconfig | 5 +
mm/gup.c | 37 ++++++--
mm/hmm.c | 13 ---
mm/swap.c | 3 -
24 files changed, 730 insertions(+), 297 deletions(-)
create mode 100644 kernel/iomem.c
The schedutil driver sets sg_policy->next_freq to UINT_MAX on certain
occasions:
- In sugov_start(), when the schedutil governor is started for a group
of CPUs.
- And whenever we need to force a freq update before rate-limit
duration, which happens when:
- there is an update in cpufreq policy limits.
- Or when the utilization of DL scheduling class increases.
In return, get_next_freq() doesn't return a cached next_freq value but
instead recalculates the next frequency. This has some side effects
though and may significantly delay a required increase in frequency.
In sugov_update_single() we try to avoid decreasing frequency if the CPU
has not been idle recently. Consider this scenario, the available range
of frequencies for a CPU are from 800 MHz to 2.5 GHz and current
frequency is 800 MHz. From one of the call paths
sg_policy->need_freq_update is set to true and hence
sg_policy->next_freq is set to UINT_MAX. Now if the CPU had been busy,
next_f will always be less than UINT_MAX, whatever the value of next_f
is. And so even when we wanted to increase the frequency, we will
overwrite next_f with UINT_MAX and will not change the frequency
eventually. This will continue until the time CPU stays busy. This isn't
cross checked with any specific test cases, but rather based on general
code review.
Fix that by not resetting the sg_policy->need_freq_update flag from
sugov_should_update_freq() but get_next_freq() and we wouldn't need to
overwrite sg_policy->next_freq anymore.
Cc: 4.12+ <stable(a)vger.kernel.org> # 4.12+
Fixes: b7eaf1aab9f8 ("cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely")
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
kernel/sched/cpufreq_schedutil.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index d2c6083304b4..daaca23697dc 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -95,15 +95,8 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time)
if (sg_policy->work_in_progress)
return false;
- if (unlikely(sg_policy->need_freq_update)) {
- sg_policy->need_freq_update = false;
- /*
- * This happens when limits change, so forget the previous
- * next_freq value and force an update.
- */
- sg_policy->next_freq = UINT_MAX;
+ if (unlikely(sg_policy->need_freq_update))
return true;
- }
delta_ns = time - sg_policy->last_freq_update_time;
@@ -165,8 +158,10 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy,
freq = (freq + (freq >> 2)) * util / max;
- if (freq == sg_policy->cached_raw_freq && sg_policy->next_freq != UINT_MAX)
+ if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update)
return sg_policy->next_freq;
+
+ sg_policy->need_freq_update = false;
sg_policy->cached_raw_freq = freq;
return cpufreq_driver_resolve_freq(policy, freq);
}
@@ -670,7 +665,7 @@ static int sugov_start(struct cpufreq_policy *policy)
sg_policy->freq_update_delay_ns = sg_policy->tunables->rate_limit_us * NSEC_PER_USEC;
sg_policy->last_freq_update_time = 0;
- sg_policy->next_freq = UINT_MAX;
+ sg_policy->next_freq = 0;
sg_policy->work_in_progress = false;
sg_policy->need_freq_update = false;
sg_policy->cached_raw_freq = 0;
--
2.15.0.194.g9af6a3dea062
The patch
spi: pxa2xx: Allow 64-bit DMA
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From efc4a13724b852ddaa3358402a8dec024ffbcb17 Mon Sep 17 00:00:00 2001
From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Date: Thu, 19 Apr 2018 19:53:32 +0300
Subject: [PATCH] spi: pxa2xx: Allow 64-bit DMA
Currently the 32-bit device address only is supported for DMA. However,
starting from Intel Sunrisepoint PCH the DMA address of the device FIFO
can be 64-bit.
Change the respective variable to be compatible with DMA engine
expectations, i.e. to phys_addr_t.
Fixes: 34cadd9c1bcb ("spi: pxa2xx: Add support for Intel Sunrisepoint")
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
drivers/spi/spi-pxa2xx.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 513ec6c6e25b..0ae7defd3492 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -38,7 +38,7 @@ struct driver_data {
/* SSP register addresses */
void __iomem *ioaddr;
- u32 ssdr_physical;
+ phys_addr_t ssdr_physical;
/* SSP masks*/
u32 dma_cr1;
--
2.17.0
This is the start of the stable review cycle for the 4.9.99 release.
There are 32 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 May 10 07:39:44 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.99-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.9.99-rc1
Heiko Carstens <heiko.carstens(a)de.ibm.com>
s390/facilites: use stfle_fac_list array size for MAX_FACILITY_BIT
João Paulo Rechi Vita <jprvita(a)gmail.com>
platform/x86: asus-wireless: Fix NULL pointer dereference
Bin Liu <b-liu(a)ti.com>
usb: musb: trace: fix NULL pointer dereference in musb_g_tx()
Bin Liu <b-liu(a)ti.com>
usb: musb: host: fix potential NULL pointer dereference
SZ Lin (林上智) <sz.lin(a)moxa.com>
USB: serial: option: adding support for ublox R410M
Johan Hovold <johan(a)kernel.org>
USB: serial: option: reimplement interface masking
Alan Stern <stern(a)rowland.harvard.edu>
USB: Accept bulk endpoints with 1024-byte maxpacket
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
USB: serial: visor: handle potential invalid device configuration
Ben Hutchings <ben.hutchings(a)codethink.co.uk>
test_firmware: fix setting old custom fw path back on exit, second try
Sean Paul <seanpaul(a)chromium.org>
drm/bridge: vga-dac: Fix edid memory leak
Thomas Hellstrom <thellstrom(a)vmware.com>
drm/vmwgfx: Fix a buffer object leak
Sebastian Sanchez <sebastian.sanchez(a)intel.com>
IB/hfi1: Fix NULL pointer dereference when invalid num_vls is used
Danit Goldberg <danitg(a)mellanox.com>
IB/mlx5: Use unlimited rate when static rate is not supported
SZ Lin (林上智) <sz.lin(a)moxa.com>
NET: usb: qmi_wwan: add support for ublox R410M PID 0x90b2
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/mlx5: Protect from shift operand overflow
Roland Dreier <roland(a)purestorage.com>
RDMA/ucma: Allow resolving address w/o specifying source address
Raju Rangoju <rajur(a)chelsio.com>
RDMA/cxgb4: release hw resources on device removal
Darrick J. Wong <darrick.wong(a)oracle.com>
xfs: prevent creating negative-sized file via INSERT_RANGE
Vittorio Gambaletta (VittGam) <linuxbugs(a)vittgam.net>
Input: atmel_mxt_ts - add touchpad button mapping for Samsung Chromebook Pro
Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Input: leds - fix out of bound access
Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
tracepoint: Do not warn on ENOMEM
Takashi Iwai <tiwai(a)suse.de>
ALSA: aloop: Add missing cable lock to ctl API callbacks
Robert Rosengren <robert.rosengren(a)axis.com>
ALSA: aloop: Mark paused device as inactive
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix races at MIDI encoding in snd_virmidi_output_trigger()
Takashi Iwai <tiwai(a)suse.de>
ALSA: pcm: Check PCM state at xfern compat ioctl
Kristian Evensen <kristian.evensen(a)gmail.com>
USB: serial: option: Add support for Quectel EP06
Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
serial: imx: ensure UCR3 and UFCR are setup correctly
LEROY Christophe <christophe.leroy(a)c-s.fr>
crypto: talitos - fix IPsec cipher in length
Marc Zyngier <marc.zyngier(a)arm.com>
arm/arm64: KVM: Add PSCI version selection API
Teng Qin <qinteng(a)fb.com>
bpf: map_get_next_key to return first key on NULL
Tejun Heo <tj(a)kernel.org>
percpu: include linux/sched.h for cond_resched()
Tan Xiaojun <tanxiaojun(a)huawei.com>
perf/core: Fix the perf_cpu_time_max_percent check
-------------
Diffstat:
Documentation/virtual/kvm/api.txt | 9 +-
Documentation/virtual/kvm/arm/psci.txt | 30 ++
Makefile | 4 +-
arch/arm/include/asm/kvm_host.h | 3 +
arch/arm/include/uapi/asm/kvm.h | 6 +
arch/arm/kvm/guest.c | 13 +
arch/arm/kvm/psci.c | 60 +++
arch/arm64/include/asm/kvm_host.h | 3 +
arch/arm64/include/uapi/asm/kvm.h | 6 +
arch/arm64/kvm/guest.c | 14 +-
arch/s390/include/asm/facility.h | 2 +-
drivers/crypto/talitos.c | 41 +-
drivers/gpu/drm/bridge/dumb-vga-dac.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 1 +
drivers/infiniband/core/ucma.c | 2 +-
drivers/infiniband/hw/cxgb4/device.c | 9 +-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 4 +
drivers/infiniband/hw/cxgb4/resource.c | 26 +-
drivers/infiniband/hw/hfi1/init.c | 2 +
drivers/infiniband/hw/hfi1/pcie.c | 3 -
drivers/infiniband/hw/mlx5/qp.c | 22 +-
drivers/input/input-leds.c | 8 +-
drivers/input/touchscreen/atmel_mxt_ts.c | 9 +
drivers/net/usb/qmi_wwan.c | 1 +
drivers/platform/x86/asus-wireless.c | 4 +-
drivers/tty/serial/imx.c | 14 +-
drivers/usb/core/config.c | 4 +-
drivers/usb/musb/musb_gadget.c | 3 +-
drivers/usb/musb/musb_host.c | 4 +-
drivers/usb/serial/option.c | 448 ++++++++--------------
drivers/usb/serial/visor.c | 69 ++--
fs/xfs/xfs_file.c | 14 +-
include/kvm/arm_psci.h | 16 +-
kernel/bpf/arraymap.c | 2 +-
kernel/bpf/hashtab.c | 9 +-
kernel/bpf/syscall.c | 20 +-
kernel/events/core.c | 2 +-
kernel/tracepoint.c | 4 +-
mm/percpu.c | 1 +
sound/core/pcm_compat.c | 2 +
sound/core/seq/seq_virmidi.c | 4 +-
sound/drivers/aloop.c | 29 +-
tools/testing/selftests/firmware/fw_filesystem.sh | 6 +-
43 files changed, 530 insertions(+), 407 deletions(-)
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
Hello,
On 05/02/2018 10:43 PM, gregkh(a)linuxfoundation.org wrote:
> This is a note to let you know that I've just added the patch titled
>
> ASoC: samsung: i2s: Ensure the RCLK rate is properly determined
>
> 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:
> asoc-samsung-i2s-ensure-the-rclk-rate-is-properly-determined.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.
Please drop this patch from the stable queue for 3.18 as it depends
on patch
074b89bb5fb7 ASoC: samsung: i2s: Add clock provider for the I2S internal clocks
$ git describe 074b89bb5fb7
v3.19-rc1-14-g074b89bb5fb7
There is a related build break reported by kbuild test robot already.
--
Thanks,
Sylwester
Hello,
On 05/02/2018 10:43 PM, gregkh(a)linuxfoundation.org wrote:
> Patches currently in stable-queue which might be from a.hajda(a)samsung.com are
>
> queue-3.18/clk-samsung-exynos5260-fix-pll-rates.patch
> queue-3.18/clk-samsung-exynos3250-fix-pll-rates.patch
> queue-3.18/clk-samsung-s3c2410-fix-pll-rates.patch
> queue-3.18/clk-samsung-exynos5250-fix-pll-rates.patch
Please drop the above patches from 3.18 stable queue, they may
potentially cause regressions if other drivers, like audio card,
are not also updated accordingly.
--
Thanks,
Sylwester
From: Jens Remus <jremus(a)linux.ibm.com>
zfcp_erp_adapter_reopen() schedules blocking of all of the adapter's
rports via zfcp_scsi_schedule_rports_block() and enqueues a reopen
adapter ERP action via zfcp_erp_action_enqueue(). Both are separately
processed asynchronously and concurrently.
Blocking of rports is done in a kworker by zfcp_scsi_rport_work(). It
calls zfcp_scsi_rport_block(), which then traces a DBF REC "scpdely" via
zfcp_dbf_rec_trig().
zfcp_dbf_rec_trig() acquires the DBF REC spin lock and then iterates with
list_for_each() over the adapter's ERP ready list without holding the ERP
lock. This opens a race window in which the current list entry can be
moved to another list, causing list_for_each() to iterate forever on the
wrong list, as the erp_ready_head is never encountered as terminal
condition.
Meanwhile the ERP action can be processed in the ERP thread by
zfcp_erp_thread(). It calls zfcp_erp_strategy(), which acquires the ERP
lock and then calls zfcp_erp_action_to_running() to move the ERP action
from the ready to the running list.
zfcp_erp_action_to_running() can move the ERP action using list_move()
just during the aforementioned race window. It then traces a REC RUN
"erator1" via zfcp_dbf_rec_run().
zfcp_dbf_rec_run() tries to acquire the DBF REC spin lock. If this is held
by the infinitely looping kworker, it effectively spins forever.
Example Sequence Diagram:
Process ERP Thread rport_work
------------------- ------------------- -------------------
zfcp_erp_adapter_reopen()
zfcp_erp_adapter_block()
zfcp_scsi_schedule_rports_block()
lock ERP zfcp_scsi_rport_work()
zfcp_erp_action_enqueue(ZFCP_ERP_ACTION_REOPEN_ADAPTER)
list_add_tail() on ready !(rport_task==RPORT_ADD)
wake_up() ERP thread zfcp_scsi_rport_block()
zfcp_dbf_rec_trig() zfcp_erp_strategy() zfcp_dbf_rec_trig()
unlock ERP lock DBF REC
zfcp_erp_wait() lock ERP
| zfcp_erp_action_to_running()
| list_for_each() ready
| list_move() current entry
| ready to running
| zfcp_dbf_rec_run() endless loop over running
| zfcp_dbf_rec_run_lvl()
| lock DBF REC spins forever
Any adapter recovery can trigger this, such as setting the device offline
or reboot.
V4.9 commit 4eeaa4f3f1d6 ("zfcp: close window with unblocked rport during
rport gone") introduced additional tracing of (un)blocking of rports. It
missed that the adapter->erp_lock must be held when calling
zfcp_dbf_rec_trig().
This fix uses the approach formerly introduced by commit aa0fec62391c
("[SCSI] zfcp: Fix sparse warning by providing new entry in dbf") that got
later removed by commit ae0904f60fab ("[SCSI] zfcp: Redesign of the debug
tracing for recovery actions.").
Introduce zfcp_dbf_rec_trig_lock(), a wrapper for zfcp_dbf_rec_trig() that
acquires and releases the adapter->erp_lock for read.
Reported-by: Sebastian Ott <sebott(a)linux.ibm.com>
Signed-off-by: Jens Remus <jremus(a)linux.ibm.com>
Fixes: 4eeaa4f3f1d6 ("zfcp: close window with unblocked rport during rport gone")
Cc: <stable(a)vger.kernel.org> # 2.6.32+
Reviewed-by: Benjamin Block <bblock(a)linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier(a)linux.ibm.com>
---
James, Martin,
this is an important zfcp regression fix.
It would be nice if it could make it into 4.17-rcX.
The patch applies to James' fixes branch or Martin's 4.17/scsi-fixes branch.
Regards,
Steffen
drivers/s390/scsi/zfcp_dbf.c | 23 ++++++++++++++++++++++-
drivers/s390/scsi/zfcp_ext.h | 5 ++++-
drivers/s390/scsi/zfcp_scsi.c | 14 +++++++-------
3 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
index a8b831000b2d..18c4f933e8b9 100644
--- a/drivers/s390/scsi/zfcp_dbf.c
+++ b/drivers/s390/scsi/zfcp_dbf.c
@@ -4,7 +4,7 @@
*
* Debug traces for zfcp.
*
- * Copyright IBM Corp. 2002, 2017
+ * Copyright IBM Corp. 2002, 2018
*/
#define KMSG_COMPONENT "zfcp"
@@ -308,6 +308,27 @@ void zfcp_dbf_rec_trig(char *tag, struct zfcp_adapter *adapter,
spin_unlock_irqrestore(&dbf->rec_lock, flags);
}
+/**
+ * zfcp_dbf_rec_trig_lock - trace event related to triggered recovery with lock
+ * @tag: identifier for event
+ * @adapter: adapter on which the erp_action should run
+ * @port: remote port involved in the erp_action
+ * @sdev: scsi device involved in the erp_action
+ * @want: wanted erp_action
+ * @need: required erp_action
+ *
+ * The adapter->erp_lock must not be held.
+ */
+void zfcp_dbf_rec_trig_lock(char *tag, struct zfcp_adapter *adapter,
+ struct zfcp_port *port, struct scsi_device *sdev,
+ u8 want, u8 need)
+{
+ unsigned long flags;
+
+ read_lock_irqsave(&adapter->erp_lock, flags);
+ zfcp_dbf_rec_trig(tag, adapter, port, sdev, want, need);
+ read_unlock_irqrestore(&adapter->erp_lock, flags);
+}
/**
* zfcp_dbf_rec_run_lvl - trace event related to running recovery
diff --git a/drivers/s390/scsi/zfcp_ext.h b/drivers/s390/scsi/zfcp_ext.h
index bf8ea4df2bb8..e5eed8aac0ce 100644
--- a/drivers/s390/scsi/zfcp_ext.h
+++ b/drivers/s390/scsi/zfcp_ext.h
@@ -4,7 +4,7 @@
*
* External function declarations.
*
- * Copyright IBM Corp. 2002, 2016
+ * Copyright IBM Corp. 2002, 2018
*/
#ifndef ZFCP_EXT_H
@@ -35,6 +35,9 @@ extern int zfcp_dbf_adapter_register(struct zfcp_adapter *);
extern void zfcp_dbf_adapter_unregister(struct zfcp_adapter *);
extern void zfcp_dbf_rec_trig(char *, struct zfcp_adapter *,
struct zfcp_port *, struct scsi_device *, u8, u8);
+extern void zfcp_dbf_rec_trig_lock(char *tag, struct zfcp_adapter *adapter,
+ struct zfcp_port *port,
+ struct scsi_device *sdev, u8 want, u8 need);
extern void zfcp_dbf_rec_run(char *, struct zfcp_erp_action *);
extern void zfcp_dbf_rec_run_lvl(int level, char *tag,
struct zfcp_erp_action *erp);
diff --git a/drivers/s390/scsi/zfcp_scsi.c b/drivers/s390/scsi/zfcp_scsi.c
index 4d2ba5682493..22f9562f415c 100644
--- a/drivers/s390/scsi/zfcp_scsi.c
+++ b/drivers/s390/scsi/zfcp_scsi.c
@@ -4,7 +4,7 @@
*
* Interface to Linux SCSI midlayer.
*
- * Copyright IBM Corp. 2002, 2017
+ * Copyright IBM Corp. 2002, 2018
*/
#define KMSG_COMPONENT "zfcp"
@@ -618,9 +618,9 @@ static void zfcp_scsi_rport_register(struct zfcp_port *port)
ids.port_id = port->d_id;
ids.roles = FC_RPORT_ROLE_FCP_TARGET;
- zfcp_dbf_rec_trig("scpaddy", port->adapter, port, NULL,
- ZFCP_PSEUDO_ERP_ACTION_RPORT_ADD,
- ZFCP_PSEUDO_ERP_ACTION_RPORT_ADD);
+ zfcp_dbf_rec_trig_lock("scpaddy", port->adapter, port, NULL,
+ ZFCP_PSEUDO_ERP_ACTION_RPORT_ADD,
+ ZFCP_PSEUDO_ERP_ACTION_RPORT_ADD);
rport = fc_remote_port_add(port->adapter->scsi_host, 0, &ids);
if (!rport) {
dev_err(&port->adapter->ccw_device->dev,
@@ -642,9 +642,9 @@ static void zfcp_scsi_rport_block(struct zfcp_port *port)
struct fc_rport *rport = port->rport;
if (rport) {
- zfcp_dbf_rec_trig("scpdely", port->adapter, port, NULL,
- ZFCP_PSEUDO_ERP_ACTION_RPORT_DEL,
- ZFCP_PSEUDO_ERP_ACTION_RPORT_DEL);
+ zfcp_dbf_rec_trig_lock("scpdely", port->adapter, port, NULL,
+ ZFCP_PSEUDO_ERP_ACTION_RPORT_DEL,
+ ZFCP_PSEUDO_ERP_ACTION_RPORT_DEL);
fc_remote_port_delete(rport);
port->rport = NULL;
}
--
2.13.5