Skip to contentSkip to conversation

4.9.126-stable review

PATCH In review Greg Kroah-Hartman 5 participants 76 messages Sep 7, 2018 – Sep 10, 2018

Subsystems (10)
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.9.126-stable review

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 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.126-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.9.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 4.9.126-rc1

Jeremy Cline <[email protected]>
fs/quota: Fix spectre gadget in do_quotactl

Horia Geantă <[email protected]>
crypto: caam/jr - fix descriptor DMA unmapping

Ondrej Mosnacek <[email protected]>
crypto: vmx - Fix sleep-in-atomic bugs

Adrian Hunter <[email protected]>
perf auxtrace: Fix queue resize

Shan Hai <[email protected]>

    bcache: release dc->writeback_lock properly in bch_writeback_thread()

Steven Rostedt (VMware) <[email protected]>
printk/tracing: Do not trace printk_nmi_enter()

Vishal Verma <[email protected]>
libnvdimm: fix ars_status output length calculation

Christian Brauner <[email protected]>
getxattr: use correct xattr length

Mikulas Patocka <[email protected]>
udlfb: set optimal write delay

Mikulas Patocka <[email protected]>
fb: fix lost console when the user unplugs a USB adapter

Vignesh R <[email protected]>
pwm: tiehrpwm: Fix disabling of output of PWMs

Richard Weinberger <[email protected]>
ubifs: Fix synced_i_size calculation for xattr inodes

Richard Weinberger <[email protected]>
ubifs: Check data node size before truncate

Richard Weinberger <[email protected]>
Revert "UBIFS: Fix potential integer overflow in allocation"

Richard Weinberger <[email protected]>
ubifs: Fix memory leak in lprobs self-check

Jann Horn <[email protected]>
userns: move user access out of the mutex

Jann Horn <[email protected]>
sys: don't hold uts_sem while accessing userspace memory

Al Viro <[email protected]>
osf_getdomainname(): use copy_to_user()

Jacob Pan <[email protected]>
iommu/vt-d: Fix dev iotlb pfsid use

Jacob Pan <[email protected]>
iommu/vt-d: Add definitions for PFSID

Peter Zijlstra <[email protected]>
mm/tlb: Remove tlb_remove_table() non-concurrent condition

Yannik Sembritzki <[email protected]>
Fix kexec forbidding kernels signed with keys in the secondary keyring to boot

Yannik Sembritzki <[email protected]>
Replace magic for trusting the secondary keyring with #define

Jon Hunter <[email protected]>
ARM: tegra: Fix Tegra30 Cardhu PCA954x reset

Bill Baker <[email protected]>
NFSv4 client live hangs after live data migration recovery

Dan Carpenter <[email protected]>
pnfs/blocklayout: off by one in bl_map_stripe()

Max Filippov <[email protected]>
xtensa: increase ranges in ___invalidate_{i,d}cache_all

Max Filippov <[email protected]>

    xtensa: limit offsets in __loop_cache_{all,page}

Paolo Bonzini <[email protected]>
KVM: VMX: fixes for vmentry_l1d_flush module parameter

zhangyi (F) <[email protected]>
PM / sleep: wakeup: Fix build error caused by missing SRCU support

Tomas Bortoli <[email protected]>
9p: fix multiple NULL-pointer-dereferences

Rafael David Tinoco <[email protected]>
mfd: hi655x: Fix regmap area declared size for hi655x

Steven Rostedt (VMware) <[email protected]>
uprobes: Use synchronize_rcu() not synchronize_sched()

Steven Rostedt (VMware) <[email protected]>
tracing/blktrace: Fix to allow setting same value

Steven Rostedt (VMware) <[email protected]>
tracing: Do not call start/stop() functions when tracing_on does not change

Johan Hovold <[email protected]>
rtc: omap: fix potential crash on power off

Nadav Amit <[email protected]>
vmw_balloon: fix VMCI use when balloon built into kernel

Nadav Amit <[email protected]>
vmw_balloon: VMCI_DOORBELL_SET does not check status

Nadav Amit <[email protected]>
vmw_balloon: do not use 2MB without batching

Nadav Amit <[email protected]>
vmw_balloon: fix inflation of 64-bit GFNs

Lars-Peter Clausen <[email protected]>
iio: ad9523: Fix return value for ad952x_store()

Lars-Peter Clausen <[email protected]>
iio: ad9523: Fix displayed phase

Tycho Andersen <[email protected]>
uart: fix race between uart_put_char() and uart_shutdown()

Mike Snitzer <[email protected]>
dm cache metadata: save in-core policy_hint_size to on-disk superblock

Hou Tao <[email protected]>
dm thin: stop no_space_timeout worker when switching to write-mode

Tomas Bortoli <[email protected]>
net/9p/trans_fd.c: fix race-condition by flushing workqueue before the kfree()

Tomas Bortoli <[email protected]>
net/9p/client.c: version pointer uninitialized

jiangyiwen <[email protected]>
9p/virtio: fix off-by-one error in sg list bounds check

piaojun <[email protected]>
fs/9p/xattr.c: catch the error of p9_client_clunk when setting xattr failed

Bart Van Assche <[email protected]>

    RDMA/rxe: Set wqe->status correctly if an unexpected response is received

Bart Van Assche <[email protected]>
ib_srpt: Fix a use-after-free in srpt_close_ch()

Vaibhav Jain <[email protected]>
cxl: Fix wrong comparison in cxl_adapter_context_get()

Benjamin Herrenschmidt <[email protected]>
powerpc/powernv/pci: Work around races in PCI bridge enabling

Mahesh Salgaonkar <[email protected]>
powerpc/pseries: Fix endianness while restoring of r3 in MCE handler.

Hari Bathini <[email protected]>
powerpc/fadump: handle crash memory ranges array index overflow

Gustavo A. R. Silva <[email protected]>
mailbox: xgene-slimpro: Fix potential NULL pointer dereference

Daniel Mack <[email protected]>
libertas: fix suspend and resume for SDIO connected cards

Matthew Auld <[email protected]>
drm/i915/userptr: reject zero user_size

Krzysztof Kozlowski <[email protected]>
spi: spi-fsl-dspi: Fix imprecise abort on VF500 during probe

Bartosz Golaszewski <[email protected]>
spi: davinci: fix a NULL pointer dereference

Chirantan Ekbote <[email protected]>
9p/net: Fix zero-copy path in the 9p virtio transport

Alexander Aring <[email protected]>
net: mac802154: tx: expand tailroom if necessary

Alexander Aring <[email protected]>
net: 6lowpan: fix reserved space for single frames

-------------

Diffstat:

 Makefile                                        |  4 +-
 arch/alpha/kernel/osf_sys.c                     | 64 ++++++++---------
 arch/arm/boot/dts/tegra30-cardhu.dtsi           |  1 +
 arch/powerpc/include/asm/fadump.h               |  3 -
 arch/powerpc/kernel/fadump.c                    | 91 +++++++++++++++++++----
 arch/powerpc/platforms/powernv/pci-ioda.c       | 37 ++++++++++
 arch/powerpc/platforms/pseries/ras.c            |  2 +-
 arch/sparc/kernel/sys_sparc_32.c                | 22 +++---
 arch/sparc/kernel/sys_sparc_64.c                | 20 +++---
 arch/x86/kernel/kexec-bzimage64.c               |  2 +-
 arch/x86/kvm/vmx.c                              | 26 ++++---
 arch/xtensa/include/asm/cacheasm.h              | 69 +++++++++++-------
 certs/system_keyring.c                          |  3 +-
 crypto/asymmetric_keys/pkcs7_key_type.c         |  2 +-
 drivers/crypto/caam/jr.c                        |  3 +-
 drivers/crypto/vmx/aes_cbc.c                    | 30 ++++----
 drivers/crypto/vmx/aes_xts.c                    | 21 ++++--
 drivers/gpu/drm/i915/i915_gem_userptr.c         |  3 +
 drivers/iio/frequency/ad9523.c                  |  4 +-
 drivers/infiniband/sw/rxe/rxe_comp.c            |  1 +
 drivers/infiniband/ulp/srpt/ib_srpt.c           |  3 +-
 drivers/iommu/dmar.c                            |  6 +-
 drivers/iommu/intel-iommu.c                     | 18 ++++-
 drivers/mailbox/mailbox-xgene-slimpro.c         |  6 +-
 drivers/md/bcache/writeback.c                   |  4 +-
 drivers/md/dm-cache-metadata.c                  |  3 +-
 drivers/md/dm-thin.c                            |  2 +
 drivers/mfd/hi655x-pmic.c                       |  2 +-
 drivers/misc/cxl/main.c                         |  2 +-
 drivers/misc/vmw_balloon.c                      | 67 ++++++++++-------
 drivers/net/wireless/marvell/libertas/dev.h     |  1 +
 drivers/net/wireless/marvell/libertas/if_sdio.c | 30 ++++++--
 drivers/nvdimm/bus.c                            |  4 +-
 drivers/pwm/pwm-tiehrpwm.c                      |  2 +
 drivers/rtc/rtc-omap.c                          | 14 ++--
 drivers/spi/spi-davinci.c                       |  2 +-
 drivers/spi/spi-fsl-dspi.c                      | 24 +++----
 drivers/tty/serial/serial_core.c                | 17 +++--
 drivers/video/fbdev/core/fbmem.c                | 38 ++++++++--
 fs/9p/xattr.c                                   |  6 +-
 fs/nfs/blocklayout/dev.c                        |  2 +-
 fs/nfs/nfs4proc.c                               |  9 ++-
 fs/quota/quota.c                                |  2 +
 fs/ubifs/journal.c                              | 18 ++++-
 fs/ubifs/lprops.c                               |  8 +--
 fs/xattr.c                                      |  2 +-
 include/linux/intel-iommu.h                     |  8 ++-
 include/linux/sunrpc/clnt.h                     |  1 +
 include/linux/verification.h                    |  6 ++
 include/video/udlfb.h                           |  2 +-
 kernel/power/Kconfig                            |  1 +
 kernel/printk/nmi.c                             |  4 +-
 kernel/sys.c                                    | 95 ++++++++++++-------------
 kernel/trace/blktrace.c                         |  4 ++
 kernel/trace/trace.c                            |  4 +-
 kernel/trace/trace_uprobe.c                     |  2 +-
 kernel/user_namespace.c                         | 24 +++----
 kernel/utsname_sysctl.c                         | 41 ++++++-----
 mm/memory.c                                     |  9 ---
 net/9p/client.c                                 |  2 +-
 net/9p/trans_fd.c                               |  7 +-
 net/9p/trans_rdma.c                             |  3 +
 net/9p/trans_virtio.c                           | 13 +++-
 net/ieee802154/6lowpan/tx.c                     | 21 +++++-
 net/mac802154/tx.c                              | 15 +++-
 net/sunrpc/clnt.c                               | 28 +++++---
 tools/perf/util/auxtrace.c                      |  3 +
 67 files changed, 653 insertions(+), 340 deletions(-)
author maintainer
#1 lore raw

PATCH 1/63 net: 6lowpan: fix reserved space for single frames

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexander Aring <[email protected]>

commit ac74f87c789af40936a80131c4759f3e72579c3a upstream.

This patch fixes patch add handling to take care tail and headroom for single 6lowpan frames. We need to be sure we have a skb with the right head and tailroom for single frames. This patch do it by using skb_copy_expand() if head and tailroom is not enough allocated by upper layer.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195059

---
 net/ieee802154/6lowpan/tx.c |   21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)
net/ieee802154/6lowpan/tx.c +18 -3
@@ -266,9 +266,24 @@ netdev_tx_t lowpan_xmit(struct sk_buff *
 	/* We must take a copy of the skb before we modify/replace the ipv6
 	 * header as the header could be used elsewhere
 	 */
-	skb = skb_unshare(skb, GFP_ATOMIC);
-	if (!skb)
-		return NET_XMIT_DROP;
+	if (unlikely(skb_headroom(skb) < ldev->needed_headroom ||
+		     skb_tailroom(skb) < ldev->needed_tailroom)) {
+		struct sk_buff *nskb;
+
+		nskb = skb_copy_expand(skb, ldev->needed_headroom,
+				       ldev->needed_tailroom, GFP_ATOMIC);
+		if (likely(nskb)) {
+			consume_skb(skb);
+			skb = nskb;
+		} else {
+			kfree_skb(skb);
+			return NET_XMIT_DROP;
+		}
+	} else {
+		skb = skb_unshare(skb, GFP_ATOMIC);
+		if (!skb)
+			return NET_XMIT_DROP;
+	}
 
 	ret = lowpan_header(skb, ldev, &dgram_size, &dgram_offset);
 	if (ret < 0) {
author maintainer
#2 lore raw

PATCH 2/63 net: mac802154: tx: expand tailroom if necessary

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexander Aring <[email protected]>

commit f9c52831133050c6b82aa8b6831c92da2bbf2a0b upstream.

This patch is necessary if case of AF_PACKET or other socket interface which I am aware of it and didn't allocated the necessary room.

---
 net/mac802154/tx.c |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)
net/mac802154/tx.c +14 -1
@@ -63,8 +63,21 @@ ieee802154_tx(struct ieee802154_local *l
 	int ret;
 
 	if (!(local->hw.flags & IEEE802154_HW_TX_OMIT_CKSUM)) {
-		u16 crc = crc_ccitt(0, skb->data, skb->len);
+		struct sk_buff *nskb;
+		u16 crc;
 
+		if (unlikely(skb_tailroom(skb) < IEEE802154_FCS_LEN)) {
+			nskb = skb_copy_expand(skb, 0, IEEE802154_FCS_LEN,
+					       GFP_ATOMIC);
+			if (likely(nskb)) {
+				consume_skb(skb);
+				skb = nskb;
+			} else {
+				goto err_tx;
+			}
+		}
+
+		crc = crc_ccitt(0, skb->data, skb->len);
 		put_unaligned_le16(crc, skb_put(skb, 2));
 	}
 
author maintainer
#3 lore raw

PATCH 3/63 9p/net: Fix zero-copy path in the 9p virtio transport

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chirantan Ekbote <[email protected]>

commit d28c756caee6e414d9ba367d0b92da24145af2a8 upstream.

The zero-copy optimization when reading or writing large chunks of data is quite useful. However, the 9p messages created through the zero-copy write path have an incorrect message size: it should be the size of the header + size of the data being written but instead it's just the size of the header.

This only works if the server ignores the size field of the message and otherwise breaks the framing of the protocol. Fix this by re-writing the message size field with the correct value.

Tested by running dd if=/dev/zero of=out bs=4k count=1 inside a virtio-9p mount.

---
 net/9p/trans_virtio.c |    7 +++++++
 1 file changed, 7 insertions(+)
net/9p/trans_virtio.c +7 -0
@@ -406,6 +406,7 @@ p9_virtio_zc_request(struct p9_client *c
 	p9_debug(P9_DEBUG_TRANS, "virtio request\n");
 
 	if (uodata) {
+		__le32 sz;
 		int n = p9_get_mapped_pages(chan, &out_pages, uodata,
 					    outlen, &offs, &need_drop);
 		if (n < 0)
@@ -416,6 +417,12 @@ p9_virtio_zc_request(struct p9_client *c
 			memcpy(&req->tc->sdata[req->tc->size - 4], &v, 4);
 			outlen = n;
 		}
+		/* The size field of the message must include the length of the
+		 * header and the length of the data.  We didn't actually know
+		 * the length of the data until this point so add it in now.
+		 */
+		sz = cpu_to_le32(req->tc->size + outlen);
+		memcpy(&req->tc->sdata[0], &sz, sizeof(sz));
 	} else if (uidata) {
 		int n = p9_get_mapped_pages(chan, &in_pages, uidata,
 					    inlen, &offs, &need_drop);
#4 lore raw

Re: [PATCH 4.9 03/63] 9p/net: Fix zero-copy path in the 9p virtio transport

Quoted 3 lines · Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

Do your scripts have a bad hair day ? The subject says 4.18.

Guenter

Quoted 58 lines

------------------

From: Chirantan Ekbote <[email protected]>

commit d28c756caee6e414d9ba367d0b92da24145af2a8 upstream.

The zero-copy optimization when reading or writing large chunks of data is quite useful. However, the 9p messages created through the zero-copy write path have an incorrect message size: it should be the size of the header + size of the data being written but instead it's just the size of the header.

This only works if the server ignores the size field of the message and otherwise breaks the framing of the protocol. Fix this by re-writing the message size field with the correct value.

Tested by running dd if=/dev/zero of=out bs=4k count=1 inside a virtio-9p mount.

---
 net/9p/trans_virtio.c |    7 +++++++
 1 file changed, 7 insertions(+)
net/9p/trans_virtio.c +7 -0
@@ -406,6 +406,7 @@ p9_virtio_zc_request(struct p9_client *c
        p9_debug(P9_DEBUG_TRANS, "virtio request\n");
 
        if (uodata) {
+               __le32 sz;
                int n = p9_get_mapped_pages(chan, &out_pages, uodata,
                                            outlen, &offs, &need_drop);
                if (n < 0)
@@ -416,6 +417,12 @@ p9_virtio_zc_request(struct p9_client *c
                        memcpy(&req->tc->sdata[req->tc->size - 4], &v, 4);
                        outlen = n;
                }
+               /* The size field of the message must include the length of the
+                * header and the length of the data.  We didn't actually know
+                * the length of the data until this point so add it in now.
+                */
+               sz = cpu_to_le32(req->tc->size + outlen);
+               memcpy(&req->tc->sdata[0], &sz, sizeof(sz));
        } else if (uidata) {
                int n = p9_get_mapped_pages(chan, &in_pages, uidata,
                                            inlen, &offs, &need_drop);
#5 lore raw

Re: [PATCH 4.9 03/63] 9p/net: Fix zero-copy path in the 9p virtio transport

Quoted 9 lines · Guenter Roeck
Quoted 3 lines · Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

Do your scripts have a bad hair day ? The subject says 4.18.

Hmm, I suspect it is the gmail UI messing with me. Sorry for the noise.

Guenter

Quoted 60 lines

Guenter

Quoted 58 lines

------------------

From: Chirantan Ekbote <[email protected]>

commit d28c756caee6e414d9ba367d0b92da24145af2a8 upstream.

The zero-copy optimization when reading or writing large chunks of data is quite useful. However, the 9p messages created through the zero-copy write path have an incorrect message size: it should be the size of the header + size of the data being written but instead it's just the size of the header.

This only works if the server ignores the size field of the message and otherwise breaks the framing of the protocol. Fix this by re-writing the message size field with the correct value.

Tested by running dd if=/dev/zero of=out bs=4k count=1 inside a virtio-9p mount.

---
 net/9p/trans_virtio.c |    7 +++++++
 1 file changed, 7 insertions(+)
net/9p/trans_virtio.c +7 -0
@@ -406,6 +406,7 @@ p9_virtio_zc_request(struct p9_client *c
        p9_debug(P9_DEBUG_TRANS, "virtio request\n");
 
        if (uodata) {
+               __le32 sz;
                int n = p9_get_mapped_pages(chan, &out_pages, uodata,
                                            outlen, &offs, &need_drop);
                if (n < 0)
@@ -416,6 +417,12 @@ p9_virtio_zc_request(struct p9_client *c
                        memcpy(&req->tc->sdata[req->tc->size - 4], &v, 4);
                        outlen = n;
                }
+               /* The size field of the message must include the length of the
+                * header and the length of the data.  We didn't actually know
+                * the length of the data until this point so add it in now.
+                */
+               sz = cpu_to_le32(req->tc->size + outlen);
+               memcpy(&req->tc->sdata[0], &sz, sizeof(sz));
        } else if (uidata) {
                int n = p9_get_mapped_pages(chan, &in_pages, uidata,
                                            inlen, &offs, &need_drop);
author maintainer
#6 lore raw

PATCH 4/63 spi: davinci: fix a NULL pointer dereference

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bartosz Golaszewski <[email protected]>

commit 563a53f3906a6b43692498e5b3ae891fac93a4af upstream.

On non-OF systems spi->controlled_data may be NULL. This causes a NULL pointer derefence on dm365-evm.

---
 drivers/spi/spi-davinci.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-davinci.c +1 -1
@@ -215,7 +215,7 @@ static void davinci_spi_chipselect(struc
 	pdata = &dspi->pdata;
 
 	/* program delay transfers if tx_delay is non zero */
-	if (spicfg->wdelay)
+	if (spicfg && spicfg->wdelay)
 		spidat1 |= SPIDAT1_WDEL;
 
 	/*
author maintainer
#7 lore raw

PATCH 5/63 spi: spi-fsl-dspi: Fix imprecise abort on VF500 during probe

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Krzysztof Kozlowski <[email protected]>

commit d8ffee2f551a627ffb7b216e2da322cb9a037f77 upstream.

Registers of DSPI should not be accessed before enabling its clock. On Toradex Colibri VF50 on Iris carrier board this could be seen during bootup as imprecise abort:

    Unhandled fault: imprecise external abort (0x1c06) at 0x00000000
    Internal error: : 1c06 [#1] ARM
    Modules linked in:
    CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.39-dirty #97
    Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
    Backtrace:
    [<804166a8>] (regmap_write) from [<80466b5c>] (dspi_probe+0x1f0/0x8dc)
    [<8046696c>] (dspi_probe) from [<8040107c>] (platform_drv_probe+0x54/0xb8)
    [<80401028>] (platform_drv_probe) from [<803ff53c>] (driver_probe_device+0x280/0x2f8)
    [<803ff2bc>] (driver_probe_device) from [<803ff674>] (__driver_attach+0xc0/0xc4)
    [<803ff5b4>] (__driver_attach) from [<803fd818>] (bus_for_each_dev+0x70/0xa4)
    [<803fd7a8>] (bus_for_each_dev) from [<803fee74>] (driver_attach+0x24/0x28)
    [<803fee50>] (driver_attach) from [<803fe980>] (bus_add_driver+0x1a0/0x218)
    [<803fe7e0>] (bus_add_driver) from [<803fffe8>] (driver_register+0x80/0x100)
    [<803fff68>] (driver_register) from [<80400fdc>] (__platform_driver_register+0x48/0x50)
    [<80400f94>] (__platform_driver_register) from [<8091cf7c>] (fsl_dspi_driver_init+0x1c/0x20)
    [<8091cf60>] (fsl_dspi_driver_init) from [<8010195c>] (do_one_initcall+0x4c/0x174)
    [<80101910>] (do_one_initcall) from [<80900e8c>] (kernel_init_freeable+0x144/0x1d8)
    [<80900d48>] (kernel_init_freeable) from [<805ff6a8>] (kernel_init+0x10/0x114)
    [<805ff698>] (kernel_init) from [<80107be8>] (ret_from_fork+0x14/0x2c)
Fixes 5ee67b587a2b ("spi: dspi: clear SPI_SR before enable interrupt")
---
 drivers/spi/spi-fsl-dspi.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)
drivers/spi/spi-fsl-dspi.c +12 -12
@@ -715,31 +715,31 @@ static int dspi_probe(struct platform_de
 		return PTR_ERR(dspi->regmap);
 	}
 
+	dspi->clk = devm_clk_get(&pdev->dev, "dspi");
+	if (IS_ERR(dspi->clk)) {
+		ret = PTR_ERR(dspi->clk);
+		dev_err(&pdev->dev, "unable to get clock\n");
+		goto out_master_put;
+	}
+	ret = clk_prepare_enable(dspi->clk);
+	if (ret)
+		goto out_master_put;
+
 	dspi_init(dspi);
 	dspi->irq = platform_get_irq(pdev, 0);
 	if (dspi->irq < 0) {
 		dev_err(&pdev->dev, "can't get platform irq\n");
 		ret = dspi->irq;
-		goto out_master_put;
+		goto out_clk_put;
 	}
 
 	ret = devm_request_irq(&pdev->dev, dspi->irq, dspi_interrupt, 0,
 			pdev->name, dspi);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Unable to attach DSPI interrupt\n");
-		goto out_master_put;
+		goto out_clk_put;
 	}
 
-	dspi->clk = devm_clk_get(&pdev->dev, "dspi");
-	if (IS_ERR(dspi->clk)) {
-		ret = PTR_ERR(dspi->clk);
-		dev_err(&pdev->dev, "unable to get clock\n");
-		goto out_master_put;
-	}
-	ret = clk_prepare_enable(dspi->clk);
-	if (ret)
-		goto out_master_put;
-
 	master->max_speed_hz =
 		clk_get_rate(dspi->clk) / dspi->devtype_data->max_clock_factor;
 
author maintainer
#8 lore raw

PATCH 6/63 drm/i915/userptr: reject zero user_size

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Matthew Auld <[email protected]>

commit c11c7bfd213495784b22ef82a69b6489f8d0092f upstream.

Operating on a zero sized GEM userptr object will lead to explosions.

Fixes 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")

Testcase: igt/gem_userptr_blits/input-checking

---
 drivers/gpu/drm/i915/i915_gem_userptr.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/gpu/drm/i915/i915_gem_userptr.c +3 -0
@@ -778,6 +778,9 @@ i915_gem_userptr_ioctl(struct drm_device
 			    I915_USERPTR_UNSYNCHRONIZED))
 		return -EINVAL;
 
+	if (!args->user_size)
+		return -EINVAL;
+
 	if (offset_in_page(args->user_ptr | args->user_size))
 		return -EINVAL;
 
author maintainer
#9 lore raw

PATCH 7/63 libertas: fix suspend and resume for SDIO connected cards

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel Mack <[email protected]>

commit 7444a8092906ed44c09459780c56ba57043e39b1 upstream.

Prior to commit 573185cc7e64 ("mmc: core: Invoke sdio func driver's PM callbacks from the sdio bus"), the MMC core used to call into the power management functions of SDIO clients itself and removed the card if the return code was non-zero. IOW, the mmc handled errors gracefully and didn't upchain them to the pm core.

Since this change, the mmc core relies on generic power management functions which treat all errors as a reason to cancel the suspend immediately. This causes suspend attempts to fail when the libertas driver is loaded.

To fix this, power down the card explicitly in if_sdio_suspend() when we know we're about to lose power and return success. Also set a flag in these cases, and power up the card again in if_sdio_resume().

Fixes 573185cc7e64 ("mmc: core: Invoke sdio func driver's PM callbacks from the sdio bus")
---
 drivers/net/wireless/marvell/libertas/dev.h     |    1 
 drivers/net/wireless/marvell/libertas/if_sdio.c |   30 +++++++++++++++++++-----
 2 files changed, 25 insertions(+), 6 deletions(-)
drivers/net/wireless/marvell/libertas/dev.h +1 -0
@@ -103,6 +103,7 @@ struct lbs_private {
 	u8 fw_ready;
 	u8 surpriseremoved;
 	u8 setup_fw_on_resume;
+	u8 power_up_on_resume;
 	int (*hw_host_to_card) (struct lbs_private *priv, u8 type, u8 *payload, u16 nb);
 	void (*reset_card) (struct lbs_private *priv);
 	int (*power_save) (struct lbs_private *priv);
drivers/net/wireless/marvell/libertas/if_sdio.c +24 -6
@@ -1341,15 +1341,23 @@ static void if_sdio_remove(struct sdio_f
 static int if_sdio_suspend(struct device *dev)
 {
 	struct sdio_func *func = dev_to_sdio_func(dev);
-	int ret;
 	struct if_sdio_card *card = sdio_get_drvdata(func);
+	struct lbs_private *priv = card->priv;
+	int ret;
 
 	mmc_pm_flag_t flags = sdio_get_host_pm_caps(func);
+	priv->power_up_on_resume = false;
 
 	/* If we're powered off anyway, just let the mmc layer remove the
 	 * card. */
-	if (!lbs_iface_active(card->priv))
-		return -ENOSYS;
+	if (!lbs_iface_active(priv)) {
+		if (priv->fw_ready) {
+			priv->power_up_on_resume = true;
+			if_sdio_power_off(card);
+		}
+
+		return 0;
+	}
 
 	dev_info(dev, "%s: suspend: PM flags = 0x%x\n",
 		 sdio_func_id(func), flags);
@@ -1357,9 +1365,14 @@ static int if_sdio_suspend(struct device
 	/* If we aren't being asked to wake on anything, we should bail out
 	 * and let the SD stack power down the card.
 	 */
-	if (card->priv->wol_criteria == EHS_REMOVE_WAKEUP) {
+	if (priv->wol_criteria == EHS_REMOVE_WAKEUP) {
 		dev_info(dev, "Suspend without wake params -- powering down card\n");
-		return -ENOSYS;
+		if (priv->fw_ready) {
+			priv->power_up_on_resume = true;
+			if_sdio_power_off(card);
+		}
+
+		return 0;
 	}
 
 	if (!(flags & MMC_PM_KEEP_POWER)) {
@@ -1372,7 +1385,7 @@ static int if_sdio_suspend(struct device
 	if (ret)
 		return ret;
 
-	ret = lbs_suspend(card->priv);
+	ret = lbs_suspend(priv);
 	if (ret)
 		return ret;
 
@@ -1387,6 +1400,11 @@ static int if_sdio_resume(struct device
 
 	dev_info(dev, "%s: resume: we're back\n", sdio_func_id(func));
 
+	if (card->priv->power_up_on_resume) {
+		if_sdio_power_on(card);
+		wait_event(card->pwron_waitq, card->priv->fw_ready);
+	}
+
 	ret = lbs_resume(card->priv);
 
 	return ret;
author maintainer
#10 lore raw

PATCH 8/63 mailbox: xgene-slimpro: Fix potential NULL pointer dereference

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Gustavo A. R. Silva <[email protected]>

commit 3512a18cbd8d09e22a790540cb9624c3c49827ba upstream.

There is a potential execution path in which function platform_get_resource() returns NULL. If this happens, we will end up having a NULL pointer dereference.

Fix this by replacing devm_ioremap with devm_ioremap_resource, which has the NULL check and the memory region request.

This code was detected with the help of Coccinelle.

Fixes f700e84f417b ("mailbox: Add support for APM X-Gene platform mailbox driver")
---
 drivers/mailbox/mailbox-xgene-slimpro.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/mailbox/mailbox-xgene-slimpro.c +3 -3
@@ -195,9 +195,9 @@ static int slimpro_mbox_probe(struct pla
 	platform_set_drvdata(pdev, ctx);
 
 	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	mb_base = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
-	if (!mb_base)
-		return -ENOMEM;
+	mb_base = devm_ioremap_resource(&pdev->dev, regs);
+	if (IS_ERR(mb_base))
+		return PTR_ERR(mb_base);
 
 	/* Setup mailbox links */
 	for (i = 0; i < MBOX_CNT; i++) {
author maintainer
#11 lore raw

PATCH 9/63 powerpc/fadump: handle crash memory ranges array index overflow

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hari Bathini <[email protected]>

commit 1bd6a1c4b80a28d975287630644e6b47d0f977a5 upstream.

Crash memory ranges is an array of memory ranges of the crashing kernel to be exported as a dump via /proc/vmcore file. The size of the array is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since commit 142b45a72e22 ("memblock: Add array resizing support").

On large memory systems with a few DLPAR operations, the memblock memory regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such systems, registering fadump results in crash or other system failures like below:

task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000
CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
...
NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
LR [c0000000000f9e58] resched_curr+0x138/0x160

  Call Trace:
    resched_curr+0x138/0x160 (unreliable)
    check_preempt_curr+0xc8/0xf0
    ttwu_do_wakeup+0x38/0x150
    try_to_wake_up+0x224/0x4d0
    __wake_up_common+0x94/0x100
    ep_poll_callback+0xac/0x1c0
    __wake_up_common+0x94/0x100
    __wake_up_sync_key+0x70/0xa0
    sock_def_readable+0x58/0xa0
    unix_stream_sendmsg+0x2dc/0x4c0
    sock_sendmsg+0x68/0xa0
    ___sys_sendmsg+0x2cc/0x2e0
    __sys_sendmsg+0x5c/0xc0
    SyS_socketcall+0x36c/0x3f0
    system_call+0x3c/0x100

as array index overflow is not checked for while setting up crash memory ranges causing memory corruption. To resolve this issue, dynamically allocate memory for crash memory ranges and resize it incrementally, in units of pagesize, on hitting array size limit.

Fixes 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
[mpe: Just use PAGE_SIZE directly, fixup variable placement]
---
 arch/powerpc/include/asm/fadump.h |    3 -
 arch/powerpc/kernel/fadump.c      |   91 ++++++++++++++++++++++++++++++++------
 2 files changed, 77 insertions(+), 17 deletions(-)
arch/powerpc/include/asm/fadump.h +0 -3
@@ -190,9 +190,6 @@ struct fadump_crash_info_header {
 	struct cpumask	online_mask;
 };
 
-/* Crash memory ranges */
-#define INIT_CRASHMEM_RANGES	(INIT_MEMBLOCK_REGIONS + 2)
-
 struct fad_crash_memory_ranges {
 	unsigned long long	base;
 	unsigned long long	size;
arch/powerpc/kernel/fadump.c +77 -14

167 lines not on this page · raw message

author maintainer
#12 lore raw

PATCH 10/63 powerpc/pseries: Fix endianness while restoring of r3 in MCE handler.

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mahesh Salgaonkar <[email protected]>

commit cd813e1cd7122f2c261dce5b54d1e0c97f80e1a5 upstream.

During Machine Check interrupt on pseries platform, register r3 points RTAS extended event log passed by hypervisor. Since hypervisor uses r3 to pass pointer to rtas log, it stores the original r3 value at the start of the memory (first 8 bytes) pointed by r3. Since hypervisor stores this info and rtas log is in BE format, linux should make sure to restore r3 value in correct endian format.

Without this patch when MCE handler, after recovery, returns to code that that caused the MCE may end up with Data SLB access interrupt for invalid address followed by kernel panic or hang.

Severe Machine check interrupt [Recovered]

    NIP [d00000000ca301b8]: init_module+0x1b8/0x338 [bork_kernel]
    Initiator: CPU
    Error type: SLB [Multihit]
      Effective address: d00000000ca70000
  cpu 0xa: Vector: 380 (Data SLB Access) at [c0000000fc7775b0]
      pc: c0000000009694c0: vsnprintf+0x80/0x480
      lr: c0000000009698e0: vscnprintf+0x20/0x60
      sp: c0000000fc777830
     msr: 8000000002009033
     dar: a803a30c000000d0
    current = 0xc00000000bc9ef00
    paca    = 0xc00000001eca5c00	 softe: 3	 irq_happened: 0x01
      pid   = 8860, comm = insmod
  vscnprintf+0x20/0x60
  vprintk_emit+0xb4/0x4b0
  vprintk_func+0x5c/0xd0
  printk+0x38/0x4c
  init_module+0x1c0/0x338 [bork_kernel]
  do_one_initcall+0x54/0x230
  do_init_module+0x8c/0x248
  load_module+0x12b8/0x15b0
  sys_finit_module+0xa8/0x110
  system_call+0x58/0x6c
  --- Exception: c00 (System Call) at 00007fff8bda0644
  SP (7fffdfbfe980) is in userspace

This patch fixes this issue.

Fixes a08a53ea4c97 ("powerpc/le: Enable RTAS events support")
Cc [email protected] # v3.15+
---
 arch/powerpc/platforms/pseries/ras.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/platforms/pseries/ras.c +1 -1
@@ -346,7 +346,7 @@ static struct rtas_error_log *fwnmi_get_
 	}
 
 	savep = __va(regs->gpr[3]);
-	regs->gpr[3] = savep[0];	/* restore original r3 */
+	regs->gpr[3] = be64_to_cpu(savep[0]);	/* restore original r3 */
 
 	/* If it isn't an extended log we can use the per cpu 64bit buffer */
 	h = (struct rtas_error_log *)&savep[1];
author maintainer
#13 lore raw

PATCH 11/63 powerpc/powernv/pci: Work around races in PCI bridge enabling

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Herrenschmidt <[email protected]>

commit db2173198b9513f7add8009f225afa1f1c79bcc6 upstream.

The generic code is racy when multiple children of a PCI bridge try to enable it simultaneously.

This leads to drivers trying to access a device through a not-yet-enabled bridge, and this EEH errors under various circumstances when using parallel driver probing.

There is work going on to fix that properly in the PCI core but it will take some time.

x86 gets away with it because (outside of hotplug), the BIOS enables all the bridges at boot time.

This patch does the same thing on powernv by enabling all bridges that have child devices at boot time, thus avoiding subsequent races. It's suitable for backporting to stable and distros, while the proper PCI fix will probably be significantly more invasive.

---
 arch/powerpc/platforms/powernv/pci-ioda.c |   37 ++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)
arch/powerpc/platforms/powernv/pci-ioda.c +37 -0
@@ -3124,12 +3124,49 @@ static void pnv_pci_ioda_create_dbgfs(vo
 #endif /* CONFIG_DEBUG_FS */
 }
 
+static void pnv_pci_enable_bridge(struct pci_bus *bus)
+{
+	struct pci_dev *dev = bus->self;
+	struct pci_bus *child;
+
+	/* Empty bus ? bail */
+	if (list_empty(&bus->devices))
+		return;
+
+	/*
+	 * If there's a bridge associated with that bus enable it. This works
+	 * around races in the generic code if the enabling is done during
+	 * parallel probing. This can be removed once those races have been
+	 * fixed.
+	 */
+	if (dev) {
+		int rc = pci_enable_device(dev);
+		if (rc)
+			pci_err(dev, "Error enabling bridge (%d)\n", rc);
+		pci_set_master(dev);
+	}
+
+	/* Perform the same to child busses */
+	list_for_each_entry(child, &bus->children, node)
+		pnv_pci_enable_bridge(child);
+}
+
+static void pnv_pci_enable_bridges(void)
+{
+	struct pci_controller *hose;
+
+	list_for_each_entry(hose, &hose_list, list_node)
+		pnv_pci_enable_bridge(hose->bus);
+}
+
 static void pnv_pci_ioda_fixup(void)
 {
 	pnv_pci_ioda_setup_PEs();
 	pnv_pci_ioda_setup_iommu_api();
 	pnv_pci_ioda_create_dbgfs();
 
+	pnv_pci_enable_bridges();
+
 #ifdef CONFIG_EEH
 	eeh_init();
 	eeh_addr_cache_build();
author maintainer
#14 lore raw

PATCH 12/63 cxl: Fix wrong comparison in cxl_adapter_context_get()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vaibhav Jain <[email protected]>

commit ef6cb5f1a048fdf91ccee6d63d2bfa293338502d upstream.

Function atomic_inc_unless_negative() returns a bool to indicate success/failure. However cxl_adapter_context_get() wrongly compares the return value against '>=0' which will always be true. The patch fixes this comparison to '==0' there by also fixing this compile time warning:

	drivers/misc/cxl/main.c:290 cxl_adapter_context_get()
	warn: 'atomic_inc_unless_negative(&adapter->contexts_num)' is unsigned
Fixes 70b565bbdb91 ("cxl: Prevent adapter reset if an active context exists")
---
 drivers/misc/cxl/main.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/misc/cxl/main.c +1 -1
@@ -293,7 +293,7 @@ int cxl_adapter_context_get(struct cxl *
 	int rc;
 
 	rc = atomic_inc_unless_negative(&adapter->contexts_num);
-	return rc >= 0 ? 0 : -EBUSY;
+	return rc ? 0 : -EBUSY;
 }
 
 void cxl_adapter_context_put(struct cxl *adapter)
author maintainer
#15 lore raw

PATCH 13/63 ib_srpt: Fix a use-after-free in srpt_close_ch()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bart Van Assche <[email protected]>

commit 995250959d22fc341b5424e3343b0ce5df672461 upstream.

Avoid that KASAN reports the following:

BUG: KASAN: use-after-free in srpt_close_ch+0x4f/0x1b0 [ib_srpt]
Read of size 4 at addr ffff880151180cb8 by task check/4681

CPU: 15 PID: 4681 Comm: check Not tainted 4.18.0-rc2-dbg+ #4
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
Call Trace:
 dump_stack+0xa4/0xf5
 print_address_description+0x6f/0x270
 kasan_report+0x241/0x360
 __asan_load4+0x78/0x80
 srpt_close_ch+0x4f/0x1b0 [ib_srpt]
 srpt_set_enabled+0xf7/0x1e0 [ib_srpt]
 srpt_tpg_enable_store+0xb8/0x120 [ib_srpt]
 configfs_write_file+0x14e/0x1d0 [configfs]
 __vfs_write+0xd2/0x3b0
 vfs_write+0x101/0x270
 ksys_write+0xab/0x120
 __x64_sys_write+0x43/0x50
 do_syscall_64+0x77/0x230
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes aaf45bd83eba ("IB/srpt: Detect session shutdown reliably")
---
 drivers/infiniband/ulp/srpt/ib_srpt.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/infiniband/ulp/srpt/ib_srpt.c +1 -2
@@ -1701,8 +1701,7 @@ static bool srpt_close_ch(struct srpt_rd
 	int ret;
 
 	if (!srpt_set_ch_state(ch, CH_DRAINING)) {
-		pr_debug("%s-%d: already closed\n", ch->sess_name,
-			 ch->qp->qp_num);
+		pr_debug("%s: already closed\n", ch->sess_name);
 		return false;
 	}
 
author maintainer
#16 lore raw

PATCH 14/63 RDMA/rxe: Set wqe->status correctly if an unexpected response is received

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bart Van Assche <[email protected]>

commit 61b717d041b1976530f68f8b539b2e3a7dd8e39c upstream.

Every function that returns COMPST_ERROR must set wqe->status to another value than IB_WC_SUCCESS before returning COMPST_ERROR. Fix the only code path for which this is not yet the case.

---
 drivers/infiniband/sw/rxe/rxe_comp.c |    1 +
 1 file changed, 1 insertion(+)
drivers/infiniband/sw/rxe/rxe_comp.c +1 -0
@@ -273,6 +273,7 @@ static inline enum comp_state check_ack(
 	case IB_OPCODE_RC_RDMA_READ_RESPONSE_MIDDLE:
 		if (wqe->wr.opcode != IB_WR_RDMA_READ &&
 		    wqe->wr.opcode != IB_WR_RDMA_READ_WITH_INV) {
+			wqe->status = IB_WC_FATAL_ERR;
 			return COMPST_ERROR;
 		}
 		reset_retry_counters(qp);
author maintainer
#17 lore raw

PATCH 15/63 fs/9p/xattr.c: catch the error of p9_client_clunk when setting xattr failed

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: piaojun <[email protected]>

commit 3111784bee81591ea2815011688d28b65df03627 upstream.

In my testing, v9fs_fid_xattr_set will return successfully even if the backend ext4 filesystem has no space to store xattr key-value. That will cause inconsistent behavior between front end and back end. The reason is that lsetxattr will be triggered by p9_client_clunk, and unfortunately we did not catch the error. This patch will catch the error to notify upper caller.

p9_client_clunk (in 9p)
p9_client_rpc(clnt, P9_TCLUNK, "d", fid->fid);
v9fs_clunk (in qemu)
put_fid
free_fid
v9fs_xattr_fid_clunk
v9fs_co_lsetxattr
s->ops->lsetxattr
ext4_xattr_user_set (in host ext4 filesystem)

---
 fs/9p/xattr.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
fs/9p/xattr.c +4 -2
@@ -105,7 +105,7 @@ int v9fs_fid_xattr_set(struct p9_fid *fi
 {
 	struct kvec kvec = {.iov_base = (void *)value, .iov_len = value_len};
 	struct iov_iter from;
-	int retval;
+	int retval, err;
 
 	iov_iter_kvec(&from, WRITE | ITER_KVEC, &kvec, 1, value_len);
 
@@ -126,7 +126,9 @@ int v9fs_fid_xattr_set(struct p9_fid *fi
 			 retval);
 	else
 		p9_client_write(fid, 0, &from, &retval);
-	p9_client_clunk(fid);
+	err = p9_client_clunk(fid);
+	if (!retval && err)
+		retval = err;
 	return retval;
 }
 
author maintainer
#18 lore raw

PATCH 16/63 9p/virtio: fix off-by-one error in sg list bounds check

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: jiangyiwen <[email protected]>

commit 23cba9cbde0bba05d772b335fe5f66aa82b9ad19 upstream.

Because the value of limit is VIRTQUEUE_NUM, if index is equal to limit, it will cause sg array out of bounds, so correct the judgement of BUG_ON.

---
 net/9p/trans_virtio.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
net/9p/trans_virtio.c +2 -1
@@ -189,7 +189,7 @@ static int pack_sg_list(struct scatterli
 		s = rest_of_page(data);
 		if (s > count)
 			s = count;
-		BUG_ON(index > limit);
+		BUG_ON(index >= limit);
 		/* Make sure we don't terminate early. */
 		sg_unmark_end(&sg[index]);
 		sg_set_buf(&sg[index++], data, s);
@@ -234,6 +234,7 @@ pack_sg_list_p(struct scatterlist *sg, i
 		s = PAGE_SIZE - data_off;
 		if (s > count)
 			s = count;
+		BUG_ON(index >= limit);
 		/* Make sure we don't terminate early. */
 		sg_unmark_end(&sg[index]);
 		sg_set_page(&sg[index++], pdata[i++], s, data_off);
author maintainer
#19 lore raw

PATCH 17/63 net/9p/client.c: version pointer uninitialized

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tomas Bortoli <[email protected]>

commit 7913690dcc5e18e235769fd87c34143072f5dbea upstream.

The p9_client_version() does not initialize the version pointer. If the call to p9pdu_readf() returns an error and version has not been allocated in p9pdu_readf(), then the program will jump to the "error" label and will try to free the version pointer. If version is not initialized, free() will be called with uninitialized, garbage data and will provoke a crash.

---
 net/9p/client.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/9p/client.c +1 -1
@@ -931,7 +931,7 @@ static int p9_client_version(struct p9_c
 {
 	int err = 0;
 	struct p9_req_t *req;
-	char *version;
+	char *version = NULL;
 	int msize;
 
 	p9_debug(P9_DEBUG_9P, ">>> TVERSION msize %d protocol %d\n",
author maintainer
#20 lore raw

PATCH 18/63 net/9p/trans_fd.c: fix race-condition by flushing workqueue before the kfree()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tomas Bortoli <[email protected]>

commit 430ac66eb4c5b5c4eb846b78ebf65747510b30f1 upstream.

The patch adds the flush in p9_mux_poll_stop() as it the function used by p9_conn_destroy(), in turn called by p9_fd_close() to stop the async polling associated with the data regarding the connection.

To: Eric Van Hensbergen <[email protected]>
To: Ron Minnich <[email protected]>
To: Latchesar Ionkov <[email protected]>

---
 net/9p/trans_fd.c |    2 ++
 1 file changed, 2 insertions(+)
net/9p/trans_fd.c +2 -0
@@ -181,6 +181,8 @@ static void p9_mux_poll_stop(struct p9_c
 	spin_lock_irqsave(&p9_poll_lock, flags);
 	list_del_init(&m->poll_pending_link);
 	spin_unlock_irqrestore(&p9_poll_lock, flags);
+
+	flush_work(&p9_poll_work);
 }
 
 /**
author maintainer
#21 lore raw

PATCH 19/63 dm thin: stop no_space_timeout worker when switching to write-mode

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hou Tao <[email protected]>

commit 75294442d896f2767be34f75aca7cc2b0d01301f upstream.

Now both check_for_space() and do_no_space_timeout() will read & write pool->pf.error_if_no_space. If these functions run concurrently, as shown in the following case, the default setting of "queue_if_no_space" can get lost.

precondition:
* error_if_no_space = false (aka "queue_if_no_space")
* pool is in Out-of-Data-Space (OODS) mode
* no_space_timeout worker has been queued

CPU 0: CPU 1:
// delete a thin device
process_delete_mesg()
// check_for_space() invoked by commit()
set_pool_mode(pool, PM_WRITE)

    pool->pf.error_if_no_space = \
     pt->requested_pf.error_if_no_space

				// timeout, pool is still in OODS mode
				do_no_space_timeout
				    // "queue_if_no_space" config is lost
				    pool->pf.error_if_no_space = true
    pool->pf.mode = new_mode

Fix it by stopping no_space_timeout worker when switching to write mode.

Fixes bcc696fac11f ("dm thin: stay in out-of-data-space mode once no_space_timeout expires")
---
 drivers/md/dm-thin.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/md/dm-thin.c +2 -0
@@ -2518,6 +2518,8 @@ static void set_pool_mode(struct pool *p
 	case PM_WRITE:
 		if (old_mode != new_mode)
 			notify_of_pool_mode_change(pool, "write");
+		if (old_mode == PM_OUT_OF_DATA_SPACE)
+			cancel_delayed_work_sync(&pool->no_space_timeout);
 		pool->out_of_data_space = false;
 		pool->pf.error_if_no_space = pt->requested_pf.error_if_no_space;
 		dm_pool_metadata_read_write(pool->pmd);
author maintainer
#22 lore raw

PATCH 20/63 dm cache metadata: save in-core policy_hint_size to on-disk superblock

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mike Snitzer <[email protected]>

commit fd2fa95416188a767a63979296fa3e169a9ef5ec upstream.

policy_hint_size starts as 0 during __write_initial_superblock(). It isn't until the policy is loaded that policy_hint_size is set in-core (cmd->policy_hint_size). But it never got recorded in the on-disk superblock because __commit_transaction() didn't deal with transfering the in-core cmd->policy_hint_size to the on-disk superblock.

The in-core cmd->policy_hint_size gets initialized by metadata_open()'s __begin_transaction_flags() which re-reads all superblock fields. Because the superblock's policy_hint_size was never properly stored, when the cache was created, hints_array_available() would always return false when re-activating a previously created cache. This means __load_mappings() always considered the hints invalid and never made use of the hints (these hints served to optimize).

Another detremental side-effect of this oversight is the cache_check utility would fail with: "invalid hint width: 0"

---
 drivers/md/dm-cache-metadata.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/md/dm-cache-metadata.c +2 -1
@@ -344,7 +344,7 @@ static int __write_initial_superblock(st
 	disk_super->version = cpu_to_le32(MAX_CACHE_VERSION);
 	memset(disk_super->policy_name, 0, sizeof(disk_super->policy_name));
 	memset(disk_super->policy_version, 0, sizeof(disk_super->policy_version));
-	disk_super->policy_hint_size = 0;
+	disk_super->policy_hint_size = cpu_to_le32(0);
 
 	__copy_sm_root(cmd, disk_super);
 
@@ -659,6 +659,7 @@ static int __commit_transaction(struct d
 	disk_super->policy_version[0] = cpu_to_le32(cmd->policy_version[0]);
 	disk_super->policy_version[1] = cpu_to_le32(cmd->policy_version[1]);
 	disk_super->policy_version[2] = cpu_to_le32(cmd->policy_version[2]);
+	disk_super->policy_hint_size = cpu_to_le32(cmd->policy_hint_size);
 
 	disk_super->read_hits = cpu_to_le32(cmd->stats.read_hits);
 	disk_super->read_misses = cpu_to_le32(cmd->stats.read_misses);
author maintainer
#23 lore raw

PATCH 22/63 iio: ad9523: Fix displayed phase

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lars-Peter Clausen <[email protected]>

commit 5a4e33c1c53ae7d4425f7d94e60e4458a37b349e upstream.

Fix the displayed phase for the ad9523 driver. Currently the most significant decimal place is dropped and all other digits are shifted one to the left. This is due to a multiplication by 10, which is not necessary, so remove it.

Fixes cd1678f9632 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator")
---
 drivers/iio/frequency/ad9523.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/frequency/ad9523.c +1 -1
@@ -642,7 +642,7 @@ static int ad9523_read_raw(struct iio_de
 		code = (AD9523_CLK_DIST_DIV_PHASE_REV(ret) * 3141592) /
 			AD9523_CLK_DIST_DIV_REV(ret);
 		*val = code / 1000000;
-		*val2 = (code % 1000000) * 10;
+		*val2 = code % 1000000;
 		return IIO_VAL_INT_PLUS_MICRO;
 	default:
 		return -EINVAL;
author maintainer
#24 lore raw

PATCH 23/63 iio: ad9523: Fix return value for ad952x_store()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lars-Peter Clausen <[email protected]>

commit 9a5094ca29ea9b1da301b31fd377c0c0c4c23034 upstream.

A sysfs write callback function needs to either return the number of consumed characters or an error.

The ad952x_store() function currently returns 0 if the input value was "0", this will signal that no characters have been consumed and the function will be called repeatedly in a loop indefinitely. Fix this by returning number of supplied characters to indicate that the whole input string has been consumed.

Fixes cd1678f96329 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator")
---
 drivers/iio/frequency/ad9523.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/frequency/ad9523.c +1 -1
@@ -508,7 +508,7 @@ static ssize_t ad9523_store(struct devic
 		return ret;
 
 	if (!state)
-		return 0;
+		return len;
 
 	mutex_lock(&indio_dev->mlock);
 	switch ((u32)this_attr->address) {
author maintainer
#25 lore raw

PATCH 24/63 vmw_balloon: fix inflation of 64-bit GFNs

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nadav Amit <[email protected]>

commit 09755690c6b7c1eabdc4651eb3b276f8feb1e447 upstream.

When balloon batching is not supported by the hypervisor, the guest frame number (GFN) must fit in 32-bit. However, due to a bug, this check was mistakenly ignored. In practice, when total RAM is greater than 16TB, the balloon does not work currently, making this bug unlikely to happen.

Fixes ef0f8f112984 ("VMware balloon: partially inline vmballoon_reserve_page.")
---
 drivers/misc/vmw_balloon.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)
drivers/misc/vmw_balloon.c +7 -6
@@ -450,7 +450,7 @@ static int vmballoon_send_lock_page(stru
 
 	pfn32 = (u32)pfn;
 	if (pfn32 != pfn)
-		return -1;
+		return -EINVAL;
 
 	STATS_INC(b->stats.lock[false]);
 
@@ -460,7 +460,7 @@ static int vmballoon_send_lock_page(stru
 
 	pr_debug("%s - ppn %lx, hv returns %ld\n", __func__, pfn, status);
 	STATS_INC(b->stats.lock_fail[false]);
-	return 1;
+	return -EIO;
 }
 
 static int vmballoon_send_batched_lock(struct vmballoon *b,
@@ -597,11 +597,12 @@ static int vmballoon_lock_page(struct vm
 
 	locked = vmballoon_send_lock_page(b, page_to_pfn(page), &hv_status,
 								target);
-	if (locked > 0) {
+	if (locked) {
 		STATS_INC(b->stats.refused_alloc[false]);
 
-		if (hv_status == VMW_BALLOON_ERROR_RESET ||
-				hv_status == VMW_BALLOON_ERROR_PPN_NOTNEEDED) {
+		if (locked == -EIO &&
+		    (hv_status == VMW_BALLOON_ERROR_RESET ||
+		     hv_status == VMW_BALLOON_ERROR_PPN_NOTNEEDED)) {
 			vmballoon_free_page(page, false);
 			return -EIO;
 		}
@@ -617,7 +618,7 @@ static int vmballoon_lock_page(struct vm
 		} else {
 			vmballoon_free_page(page, false);
 		}
-		return -EIO;
+		return locked;
 	}
 
 	/* track allocated page */
author maintainer
#26 lore raw

PATCH 25/63 vmw_balloon: do not use 2MB without batching

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nadav Amit <[email protected]>

commit 5081efd112560d3febb328e627176235b250d59d upstream.

If the hypervisor sets 2MB batching is on, while batching is cleared, the balloon code breaks. In this case the legacy mechanism is used with 2MB page. The VM would report a 2MB page is ballooned, and the hypervisor would only take the first 4KB.

While the hypervisor should not report such settings, make the code more robust by not enabling 2MB support without batching.

Fixes 365bd7ef7ec8e ("VMware balloon: Support 2m page ballooning.")
---
 drivers/misc/vmw_balloon.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/misc/vmw_balloon.c +7 -1
@@ -341,7 +341,13 @@ static bool vmballoon_send_start(struct
 		success = false;
 	}
 
-	if (b->capabilities & VMW_BALLOON_BATCHED_2M_CMDS)
+	/*
+	 * 2MB pages are only supported with batching. If batching is for some
+	 * reason disabled, do not use 2MB pages, since otherwise the legacy
+	 * mechanism is used with 2MB pages, causing a failure.
+	 */
+	if ((b->capabilities & VMW_BALLOON_BATCHED_2M_CMDS) &&
+	    (b->capabilities & VMW_BALLOON_BATCHED_CMDS))
 		b->supported_page_sizes = 2;
 	else
 		b->supported_page_sizes = 1;
author maintainer
#27 lore raw

PATCH 26/63 vmw_balloon: VMCI_DOORBELL_SET does not check status

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nadav Amit <[email protected]>

commit ce664331b2487a5d244a51cbdd8cb54f866fbe5d upstream.

When vmballoon_vmci_init() sets a doorbell using VMCI_DOORBELL_SET, for some reason it does not consider the status and looks at the result. However, the hypervisor does not update the result - it updates the status. This might cause VMCI doorbell not to be enabled, resulting in degraded performance.

Fixes 48e3d668b790 ("VMware balloon: Enable notification via VMCI")
---
 drivers/misc/vmw_balloon.c |   37 +++++++++++++++++++------------------
 1 file changed, 19 insertions(+), 18 deletions(-)
drivers/misc/vmw_balloon.c +19 -18
@@ -1036,29 +1036,30 @@ static void vmballoon_vmci_cleanup(struc
  */
 static int vmballoon_vmci_init(struct vmballoon *b)
 {
-	int error = 0;
+	unsigned long error, dummy;
 
-	if ((b->capabilities & VMW_BALLOON_SIGNALLED_WAKEUP_CMD) != 0) {
-		error = vmci_doorbell_create(&b->vmci_doorbell,
-				VMCI_FLAG_DELAYED_CB,
-				VMCI_PRIVILEGE_FLAG_RESTRICTED,
-				vmballoon_doorbell, b);
-
-		if (error == VMCI_SUCCESS) {
-			VMWARE_BALLOON_CMD(VMCI_DOORBELL_SET,
-					b->vmci_doorbell.context,
-					b->vmci_doorbell.resource, error);
-			STATS_INC(b->stats.doorbell_set);
-		}
-	}
+	if ((b->capabilities & VMW_BALLOON_SIGNALLED_WAKEUP_CMD) == 0)
+		return 0;
 
-	if (error != 0) {
-		vmballoon_vmci_cleanup(b);
+	error = vmci_doorbell_create(&b->vmci_doorbell, VMCI_FLAG_DELAYED_CB,
+				     VMCI_PRIVILEGE_FLAG_RESTRICTED,
+				     vmballoon_doorbell, b);
 
-		return -EIO;
-	}
+	if (error != VMCI_SUCCESS)
+		goto fail;
+
+	error = VMWARE_BALLOON_CMD(VMCI_DOORBELL_SET, b->vmci_doorbell.context,
+				   b->vmci_doorbell.resource, dummy);
+
+	STATS_INC(b->stats.doorbell_set);
+
+	if (error != VMW_BALLOON_SUCCESS)
+		goto fail;
 
 	return 0;
+fail:
+	vmballoon_vmci_cleanup(b);
+	return -EIO;
 }
 
 /*
author maintainer
#28 lore raw

PATCH 27/63 vmw_balloon: fix VMCI use when balloon built into kernel

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nadav Amit <[email protected]>

commit c3cc1b0fc27508da53fe955a3b23d03964410682 upstream.

Currently, when all modules, including VMCI and VMware balloon are built into the kernel, the initialization of the balloon happens before the VMCI is probed. As a result, the balloon fails to initialize the VMCI doorbell, which it uses to get asynchronous requests for balloon size changes.

The problem can be seen in the logs, in the form of the following message:
"vmw_balloon: failed to initialize vmci doorbell"

The driver would work correctly but slightly less efficiently, probing for requests periodically. This patch changes the balloon to be initialized using late_initcall() instead of module_init() to address this issue. It does not address a situation in which VMCI is built as a module and the balloon is built into the kernel.

Fixes 48e3d668b790 ("VMware balloon: Enable notification via VMCI")
---
 drivers/misc/vmw_balloon.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/misc/vmw_balloon.c +8 -1
@@ -1297,7 +1297,14 @@ static int __init vmballoon_init(void)
 
 	return 0;
 }
-module_init(vmballoon_init);
+
+/*
+ * Using late_initcall() instead of module_init() allows the balloon to use the
+ * VMCI doorbell even when the balloon is built into the kernel. Otherwise the
+ * VMCI is probed only after the balloon is initialized. If the balloon is used
+ * as a module, late_initcall() is equivalent to module_init().
+ */
+late_initcall(vmballoon_init);
 
 static void __exit vmballoon_exit(void)
 {
author maintainer
#29 lore raw

PATCH 28/63 rtc: omap: fix potential crash on power off

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johan Hovold <[email protected]>

commit 5c8b84f410b3819d14cb1ebf32e4b3714b5a6e0b upstream.

Do not set the system power-off callback and omap power-off rtc pointer until we're done setting up our device to avoid leaving stale pointers around after a late probe error.

Fixes 97ea1906b3c2 ("rtc: omap: Support ext_wakeup configuration")
Cc stable <[email protected]> # 4.9
Cc Marcin Niestroj <[email protected]>
Cc Tony Lindgren <[email protected]>
---
 drivers/rtc/rtc-omap.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/rtc/rtc-omap.c +7 -7
@@ -817,13 +817,6 @@ static int omap_rtc_probe(struct platfor
 			goto err;
 	}
 
-	if (rtc->is_pmic_controller) {
-		if (!pm_power_off) {
-			omap_rtc_power_off_rtc = rtc;
-			pm_power_off = omap_rtc_power_off;
-		}
-	}
-
 	/* Support ext_wakeup pinconf */
 	rtc_pinctrl_desc.name = dev_name(&pdev->dev);
 
@@ -833,6 +826,13 @@ static int omap_rtc_probe(struct platfor
 		return PTR_ERR(rtc->pctldev);
 	}
 
+	if (rtc->is_pmic_controller) {
+		if (!pm_power_off) {
+			omap_rtc_power_off_rtc = rtc;
+			pm_power_off = omap_rtc_power_off;
+		}
+	}
+
 	return 0;
 
 err:
author maintainer
#30 lore raw

PATCH 29/63 tracing: Do not call start/stop() functions when tracing_on does not change

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steven Rostedt (VMware) <[email protected]>

commit f143641bfef9a4a60c57af30de26c63057e7e695 upstream.

Currently, when one echo's in 1 into tracing_on, the current tracer's "start()" function is executed, even if tracing_on was already one. This can lead to strange side effects. One being that if the hwlat tracer is enabled, and someone does "echo 1 > tracing_on" into tracing_on, the hwlat tracer's start() function is called again which will recreate another kernel thread, and make it unable to remove the old one.

Fixes 2df8f8a6a897e ("tracing: Fix regression with irqsoff tracer and tracing_on file")
---
 kernel/trace/trace.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
kernel/trace/trace.c +3 -1
@@ -6920,7 +6920,9 @@ rb_simple_write(struct file *filp, const
 
 	if (buffer) {
 		mutex_lock(&trace_types_lock);
-		if (val) {
+		if (!!val == tracer_tracing_is_on(tr)) {
+			val = 0; /* do nothing */
+		} else if (val) {
 			tracer_tracing_on(tr);
 			if (tr->current_trace->start)
 				tr->current_trace->start(tr);
author maintainer
#31 lore raw

PATCH 30/63 tracing/blktrace: Fix to allow setting same value

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steven Rostedt (VMware) <[email protected]>

commit 757d9140072054528b13bbe291583d9823cde195 upstream.

Masami Hiramatsu reported:

Current trace-enable attribute in sysfs returns an error if user writes the same setting value as current one, e.g.

    # cat /sys/block/sda/trace/enable
    0
    # echo 0 > /sys/block/sda/trace/enable
    bash: echo: write error: Invalid argument
    # echo 1 > /sys/block/sda/trace/enable
    # echo 1 > /sys/block/sda/trace/enable
    bash: echo: write error: Device or resource busy

But this is not a preferred behavior, it should ignore if new setting is same as current one. This fixes the problem as below.

    # cat /sys/block/sda/trace/enable
    0
    # echo 0 > /sys/block/sda/trace/enable
    # echo 1 > /sys/block/sda/trace/enable
    # echo 1 > /sys/block/sda/trace/enable
Cc Ingo Molnar <[email protected]>
Cc Jens Axboe <[email protected]>
Fixes cd649b8bb830d ("blktrace: remove sysfs_blk_trace_enable_show/store()")
---
 kernel/trace/blktrace.c |    4 ++++
 1 file changed, 4 insertions(+)
kernel/trace/blktrace.c +4 -0
@@ -1720,6 +1720,10 @@ static ssize_t sysfs_blk_trace_attr_stor
 	mutex_lock(&bdev->bd_mutex);
 
 	if (attr == &dev_attr_enable) {
+		if (!!value == !!q->blk_trace) {
+			ret = 0;
+			goto out_unlock_bdev;
+		}
 		if (value)
 			ret = blk_trace_setup_queue(q, bdev);
 		else
author maintainer
#32 lore raw

PATCH 31/63 uprobes: Use synchronize_rcu() not synchronize_sched()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steven Rostedt (VMware) <[email protected]>

commit 016f8ffc48cb01d1e7701649c728c5d2e737d295 upstream.

While debugging another bug, I was looking at all the synchronize*() functions being used in kernel/trace, and noticed that trace_uprobes was using synchronize_sched(), with a comment to synchronize with {u,ret}_probe_trace_func(). When looking at those functions, the data is protected with "rcu_read_lock()" and not with "rcu_read_lock_sched()". This is using the wrong synchronize_*() function.

Fixes 70ed91c6ec7f8 ("tracing/uprobes: Support ftrace_event_file base multibuffer")
---
 kernel/trace/trace_uprobe.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/trace_uprobe.c +1 -1
@@ -969,7 +969,7 @@ probe_event_disable(struct trace_uprobe
 
 		list_del_rcu(&link->list);
 		/* synchronize with u{,ret}probe_trace_func */
-		synchronize_sched();
+		synchronize_rcu();
 		kfree(link);
 
 		if (!list_empty(&tu->tp.files))
author maintainer
#33 lore raw

PATCH 32/63 mfd: hi655x: Fix regmap area declared size for hi655x

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Rafael David Tinoco <[email protected]>

commit 6afebb70ee7a4bde106dc1a875e7ac7997248f84 upstream.

Fixes https://bugs.linaro.org/show_bug.cgi?id=3903

LTP Functional tests have caused a bad paging request when triggering the regmap_read_debugfs() logic of the device PMIC Hi6553 (reading regmap/f8000000.pmic/registers file during read_all test):

Unable to handle kernel paging request at virtual address ffff0
[ffff00000984e000] pgd=0000000077ffe803, pud=0000000077ffd803,0
Internal error: Oops: 96000007 [#1] SMP
...
Hardware name: HiKey Development Board (DT)
...
Call trace:
 regmap_mmio_read8+0x24/0x40
 regmap_mmio_read+0x48/0x70
 _regmap_bus_reg_read+0x38/0x48
 _regmap_read+0x68/0x170
 regmap_read+0x50/0x78
 regmap_read_debugfs+0x1a0/0x308
 regmap_map_read_file+0x48/0x58
 full_proxy_read+0x68/0x98
 __vfs_read+0x48/0x80
 vfs_read+0x94/0x150
 SyS_read+0x6c/0xd8
 el0_svc_naked+0x30/0x34
Code: aa1e03e0 d503201f f9400280 8b334000 (39400000)

Investigations have showed that, when triggered by debugfs read() handler, the mmio regmap logic was reading a bigger (16k) register area than the one mapped by devm_ioremap_resource() during hi655x-pmic probe time (4k).

This commit changes hi655x's max register, according to HW specs, to be the same as the one declared in the pmic device in hi6220's dts, fixing the issue.

---
 drivers/mfd/hi655x-pmic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mfd/hi655x-pmic.c +1 -1
@@ -49,7 +49,7 @@ static struct regmap_config hi655x_regma
 	.reg_bits = 32,
 	.reg_stride = HI655X_STRIDE,
 	.val_bits = 8,
-	.max_register = HI655X_BUS_ADDR(0xFFF),
+	.max_register = HI655X_BUS_ADDR(0x400) - HI655X_STRIDE,
 };
 
 static struct resource pwrkey_resources[] = {
author maintainer
#34 lore raw

PATCH 33/63 9p: fix multiple NULL-pointer-dereferences

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tomas Bortoli <[email protected]>

commit 10aa14527f458e9867cf3d2cc6b8cb0f6704448b upstream.

Added checks to prevent GPFs from raising.

---
 net/9p/trans_fd.c     |    5 ++++-
 net/9p/trans_rdma.c   |    3 +++
 net/9p/trans_virtio.c |    3 +++
 3 files changed, 10 insertions(+), 1 deletion(-)
net/9p/trans_fd.c +4 -1
@@ -939,7 +939,7 @@ p9_fd_create_tcp(struct p9_client *clien
 	if (err < 0)
 		return err;
 
-	if (valid_ipaddr4(addr) < 0)
+	if (addr == NULL || valid_ipaddr4(addr) < 0)
 		return -EINVAL;
 
 	csocket = NULL;
@@ -987,6 +987,9 @@ p9_fd_create_unix(struct p9_client *clie
 
 	csocket = NULL;
 
+	if (addr == NULL)
+		return -EINVAL;
+
 	if (strlen(addr) >= UNIX_PATH_MAX) {
 		pr_err("%s (%d): address too long: %s\n",
 		       __func__, task_pid_nr(current), addr);
net/9p/trans_rdma.c +3 -0
@@ -622,6 +622,9 @@ rdma_create_trans(struct p9_client *clie
 	struct rdma_conn_param conn_param;
 	struct ib_qp_init_attr qp_attr;
 
+	if (addr == NULL)
+		return -EINVAL;
+
 	/* Parse the transport specific mount options */
 	err = parse_opts(args, &opts);
 	if (err < 0)
net/9p/trans_virtio.c +3 -0
@@ -651,6 +651,9 @@ p9_virtio_create(struct p9_client *clien
 	int ret = -ENOENT;
 	int found = 0;
 
+	if (devname == NULL)
+		return -EINVAL;
+
 	mutex_lock(&virtio_9p_lock);
 	list_for_each_entry(chan, &virtio_chan_list, chan_list) {
 		if (!strncmp(devname, chan->tag, chan->tag_len) &&
author maintainer
#35 lore raw

PATCH 34/63 PM / sleep: wakeup: Fix build error caused by missing SRCU support

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: zhangyi (F) <[email protected]>

commit 3df6f61fff49632492490fb6e42646b803a9958a upstream.

Commit ea0212f40c6 (power: auto select CONFIG_SRCU) made the code in drivers/base/power/wakeup.c use SRCU instead of RCU, but it forgot to select CONFIG_SRCU in Kconfig, which leads to the following build error if CONFIG_SRCU is not selected somewhere else:

drivers/built-in.o: In function `wakeup_source_remove':
(.text+0x3c6fc): undefined reference to synchronize_srcu' drivers/built-in.o: In function pm_print_active_wakeup_sources':
(.text+0x3c7a8): undefined reference to __srcu_read_lock' drivers/built-in.o: In function pm_print_active_wakeup_sources':
(.text+0x3c84c): undefined reference to __srcu_read_unlock' drivers/built-in.o: In function device_wakeup_arm_wake_irqs':
(.text+0x3d1d8): undefined reference to __srcu_read_lock' drivers/built-in.o: In function device_wakeup_arm_wake_irqs':
(.text+0x3d228): undefined reference to __srcu_read_unlock' drivers/built-in.o: In function device_wakeup_disarm_wake_irqs':
(.text+0x3d24c): undefined reference to __srcu_read_lock' drivers/built-in.o: In function device_wakeup_disarm_wake_irqs':
(.text+0x3d29c): undefined reference to __srcu_read_unlock' drivers/built-in.o:(.data+0x4158): undefined reference to process_srcu'

Fix this error by selecting CONFIG_SRCU when PM_SLEEP is enabled.

Fixes ea0212f40c6 (power: auto select CONFIG_SRCU)
Cc 4.2+ <[email protected]> # 4.2+
[ rjw: Minor subject/changelog fixups ]
---
 kernel/power/Kconfig |    1 +
 1 file changed, 1 insertion(+)
kernel/power/Kconfig +1 -0
@@ -105,6 +105,7 @@ config PM_SLEEP
 	def_bool y
 	depends on SUSPEND || HIBERNATE_CALLBACKS
 	select PM
+	select SRCU
 
 config PM_SLEEP_SMP
 	def_bool y
author maintainer
#36 lore raw

PATCH 35/63 KVM: VMX: fixes for vmentry_l1d_flush module parameter

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paolo Bonzini <[email protected]>

commit 0027ff2a75f9dcf0537ac0a65c5840b0e21a4950 upstream.

Two bug fixes:

1) missing entries in the l1d_param array; this can cause a host crash if an access attempts to reach the missing entry. Future-proof the get function against any overflows as well. However, the two entries VMENTER_L1D_FLUSH_EPT_DISABLED and VMENTER_L1D_FLUSH_NOT_REQUIRED must not be accepted by the parse function, so disable them there.

2) invalid values must be rejected even if the CPU does not have the bug, so test for them before checking boot_cpu_has(X86_BUG_L1TF)

... and a small refactoring, since the .cmd field is redundant with the index in the array.

Fixes a7b9020b06ec6d7c3f3b0d4ef1a9eba12654f4f7
---
 arch/x86/kvm/vmx.c |   26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)
arch/x86/kvm/vmx.c +16 -10
@@ -198,12 +198,14 @@ static enum vmx_l1d_flush_state __read_m
 
 static const struct {
 	const char *option;
-	enum vmx_l1d_flush_state cmd;
+	bool for_parse;
 } vmentry_l1d_param[] = {
-	{"auto",	VMENTER_L1D_FLUSH_AUTO},
-	{"never",	VMENTER_L1D_FLUSH_NEVER},
-	{"cond",	VMENTER_L1D_FLUSH_COND},
-	{"always",	VMENTER_L1D_FLUSH_ALWAYS},
+	[VMENTER_L1D_FLUSH_AUTO]	 = {"auto", true},
+	[VMENTER_L1D_FLUSH_NEVER]	 = {"never", true},
+	[VMENTER_L1D_FLUSH_COND]	 = {"cond", true},
+	[VMENTER_L1D_FLUSH_ALWAYS]	 = {"always", true},
+	[VMENTER_L1D_FLUSH_EPT_DISABLED] = {"EPT disabled", false},
+	[VMENTER_L1D_FLUSH_NOT_REQUIRED] = {"not required", false},
 };
 
 #define L1D_CACHE_ORDER 4
@@ -287,8 +289,9 @@ static int vmentry_l1d_flush_parse(const
 
 	if (s) {
 		for (i = 0; i < ARRAY_SIZE(vmentry_l1d_param); i++) {
-			if (sysfs_streq(s, vmentry_l1d_param[i].option))
-				return vmentry_l1d_param[i].cmd;
+			if (vmentry_l1d_param[i].for_parse &&
+			    sysfs_streq(s, vmentry_l1d_param[i].option))
+				return i;
 		}
 	}
 	return -EINVAL;
@@ -298,13 +301,13 @@ static int vmentry_l1d_flush_set(const c
 {
 	int l1tf, ret;
 
-	if (!boot_cpu_has(X86_BUG_L1TF))
-		return 0;
-
 	l1tf = vmentry_l1d_flush_parse(s);
 	if (l1tf < 0)
 		return l1tf;
 
+	if (!boot_cpu_has(X86_BUG_L1TF))
+		return 0;
+
 	/*
 	 * Has vmx_init() run already? If not then this is the pre init
 	 * parameter parsing. In that case just store the value and let
@@ -324,6 +327,9 @@ static int vmentry_l1d_flush_set(const c
 
 static int vmentry_l1d_flush_get(char *s, const struct kernel_param *kp)
 {
+	if (WARN_ON_ONCE(l1tf_vmx_mitigation >= ARRAY_SIZE(vmentry_l1d_param)))
+		return sprintf(s, "???\n");
+
 	return sprintf(s, "%s\n", vmentry_l1d_param[l1tf_vmx_mitigation].option);
 }
 
author maintainer
#37 lore raw

PATCH 36/63 xtensa: limit offsets in __loop_cache_{all,page}

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Max Filippov <[email protected]>

commit be75de25251f7cf3e399ca1f584716a95510d24a upstream.

When building kernel for xtensa cores with big cache lines (e.g. 128 bytes or more) __loop_cache_all and __loop_cache_page may generate assembly instructions with immediate fields that are too big. This results in the following build errors:

arch/xtensa/mm/misc.S: Assembler messages:
arch/xtensa/mm/misc.S:464: Error: operand 2 of 'diwbi' has invalid value '256' arch/xtensa/mm/misc.S:464: Error: operand 2 of 'diwbi' has invalid value '384' arch/xtensa/kernel/head.S: Assembler messages:
arch/xtensa/kernel/head.S:172: Error: operand 2 of 'diu' has invalid value '256' arch/xtensa/kernel/head.S:172: Error: operand 2 of 'diu' has invalid value '384' arch/xtensa/kernel/head.S:176: Error: operand 2 of 'iiu' has invalid value '256' arch/xtensa/kernel/head.S:176: Error: operand 2 of 'iiu' has invalid value '384' arch/xtensa/kernel/head.S:255: Error: operand 2 of 'diwb' has invalid value '256' arch/xtensa/kernel/head.S:255: Error: operand 2 of 'diwb' has invalid value '384'

Add parameter max_immed to these macros and use it to limit values of immediate operands. Extract common code of these macros into the new macro __loop_cache_unroll.

---
 arch/xtensa/include/asm/cacheasm.h |   65 ++++++++++++++++++++++---------------
 1 file changed, 40 insertions(+), 25 deletions(-)
arch/xtensa/include/asm/cacheasm.h +40 -25
@@ -31,16 +31,32 @@
  *
  */
 
-	.macro	__loop_cache_all ar at insn size line_width
 
-	movi	\ar, 0
+	.macro	__loop_cache_unroll ar at insn size line_width max_immed
+
+	.if	(1 << (\line_width)) > (\max_immed)
+	.set	_reps, 1
+	.elseif	(2 << (\line_width)) > (\max_immed)
+	.set	_reps, 2
+	.else
+	.set	_reps, 4
+	.endif
+
+	__loopi	\ar, \at, \size, (_reps << (\line_width))
+	.set	_index, 0
+	.rep	_reps
+	\insn	\ar, _index << (\line_width)
+	.set	_index, _index + 1
+	.endr
+	__endla	\ar, \at, _reps << (\line_width)
+
+	.endm
+
 
-	__loopi	\ar, \at, \size, (4 << (\line_width))
-	\insn	\ar, 0 << (\line_width)
-	\insn	\ar, 1 << (\line_width)
-	\insn	\ar, 2 << (\line_width)
-	\insn	\ar, 3 << (\line_width)
-	__endla	\ar, \at, 4 << (\line_width)
+	.macro	__loop_cache_all ar at insn size line_width max_immed
+
+	movi	\ar, 0
+	__loop_cache_unroll \ar, \at, \insn, \size, \line_width, \max_immed
 
 	.endm
 
@@ -57,14 +73,9 @@
 	.endm
 
 
-	.macro	__loop_cache_page ar at insn line_width
+	.macro	__loop_cache_page ar at insn line_width max_immed
 
-	__loopi	\ar, \at, PAGE_SIZE, 4 << (\line_width)
-	\insn	\ar, 0 << (\line_width)
-	\insn	\ar, 1 << (\line_width)
-	\insn	\ar, 2 << (\line_width)
-	\insn	\ar, 3 << (\line_width)
-	__endla	\ar, \at, 4 << (\line_width)
+	__loop_cache_unroll \ar, \at, \insn, PAGE_SIZE, \line_width, \max_immed
 
 	.endm
 
@@ -72,7 +83,8 @@
 	.macro	___unlock_dcache_all ar at
 
 #if XCHAL_DCACHE_LINE_LOCKABLE && XCHAL_DCACHE_SIZE
-	__loop_cache_all \ar \at diu XCHAL_DCACHE_SIZE XCHAL_DCACHE_LINEWIDTH
+	__loop_cache_all \ar \at diu XCHAL_DCACHE_SIZE \
+		XCHAL_DCACHE_LINEWIDTH 240
 #endif
 
 	.endm
@@ -81,7 +93,8 @@
 	.macro	___unlock_icache_all ar at
 
 #if XCHAL_ICACHE_LINE_LOCKABLE && XCHAL_ICACHE_SIZE
-	__loop_cache_all \ar \at iiu XCHAL_ICACHE_SIZE XCHAL_ICACHE_LINEWIDTH
+	__loop_cache_all \ar \at iiu XCHAL_ICACHE_SIZE \
+		XCHAL_ICACHE_LINEWIDTH 240
 #endif
 
 	.endm
@@ -90,7 +103,8 @@
 	.macro	___flush_invalidate_dcache_all ar at
 
 #if XCHAL_DCACHE_SIZE
-	__loop_cache_all \ar \at diwbi XCHAL_DCACHE_SIZE XCHAL_DCACHE_LINEWIDTH
+	__loop_cache_all \ar \at diwbi XCHAL_DCACHE_SIZE \
+		XCHAL_DCACHE_LINEWIDTH 240
 #endif
 
 	.endm
@@ -99,7 +113,8 @@
 	.macro	___flush_dcache_all ar at
 
 #if XCHAL_DCACHE_SIZE
-	__loop_cache_all \ar \at diwb XCHAL_DCACHE_SIZE XCHAL_DCACHE_LINEWIDTH
+	__loop_cache_all \ar \at diwb XCHAL_DCACHE_SIZE \
+		XCHAL_DCACHE_LINEWIDTH 240
 #endif
 
 	.endm
@@ -109,7 +124,7 @@
 
 #if XCHAL_DCACHE_SIZE
 	__loop_cache_all \ar \at dii __stringify(DCACHE_WAY_SIZE) \
-			 XCHAL_DCACHE_LINEWIDTH
+			 XCHAL_DCACHE_LINEWIDTH 1020
 #endif
 
 	.endm
@@ -119,7 +134,7 @@
 
 #if XCHAL_ICACHE_SIZE
 	__loop_cache_all \ar \at iii __stringify(ICACHE_WAY_SIZE) \
-			 XCHAL_ICACHE_LINEWIDTH
+			 XCHAL_ICACHE_LINEWIDTH 1020
 #endif
 
 	.endm
@@ -166,7 +181,7 @@
 	.macro	___flush_invalidate_dcache_page ar as
 
 #if XCHAL_DCACHE_SIZE
-	__loop_cache_page \ar \as dhwbi XCHAL_DCACHE_LINEWIDTH
+	__loop_cache_page \ar \as dhwbi XCHAL_DCACHE_LINEWIDTH 1020
 #endif
 
 	.endm
@@ -175,7 +190,7 @@
 	.macro ___flush_dcache_page ar as
 
 #if XCHAL_DCACHE_SIZE
-	__loop_cache_page \ar \as dhwb XCHAL_DCACHE_LINEWIDTH
+	__loop_cache_page \ar \as dhwb XCHAL_DCACHE_LINEWIDTH 1020
 #endif
 
 	.endm
@@ -184,7 +199,7 @@
 	.macro	___invalidate_dcache_page ar as
 
 #if XCHAL_DCACHE_SIZE
-	__loop_cache_page \ar \as dhi XCHAL_DCACHE_LINEWIDTH
+	__loop_cache_page \ar \as dhi XCHAL_DCACHE_LINEWIDTH 1020
 #endif
 
 	.endm
@@ -193,7 +208,7 @@
 	.macro	___invalidate_icache_page ar as
 
 #if XCHAL_ICACHE_SIZE
-	__loop_cache_page \ar \as ihi XCHAL_ICACHE_LINEWIDTH
+	__loop_cache_page \ar \as ihi XCHAL_ICACHE_LINEWIDTH 1020
 #endif
 
 	.endm
author maintainer
#38 lore raw

PATCH 37/63 xtensa: increase ranges in ___invalidate_{i,d}cache_all

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Max Filippov <[email protected]>

commit fec3259c9f747c039f90e99570540114c8d81a14 upstream.

Cache invalidation macros use cache line size to iterate over invalidated cache lines, assuming that all cache ways are invalidated by single instruction, but xtensa ISA recommends to not assume that for future compatibility:
In some implementations all ways at index Addry-1..z are invalidated regardless of the specified way, but for future compatibility this behavior should not be assumed.

Iterate over all cache ways in ___invalidate_icache_all and ___invalidate_dcache_all.

---
 arch/xtensa/include/asm/cacheasm.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/xtensa/include/asm/cacheasm.h +2 -2
@@ -123,7 +123,7 @@
 	.macro	___invalidate_dcache_all ar at
 
 #if XCHAL_DCACHE_SIZE
-	__loop_cache_all \ar \at dii __stringify(DCACHE_WAY_SIZE) \
+	__loop_cache_all \ar \at dii XCHAL_DCACHE_SIZE \
 			 XCHAL_DCACHE_LINEWIDTH 1020
 #endif
 
@@ -133,7 +133,7 @@
 	.macro	___invalidate_icache_all ar at
 
 #if XCHAL_ICACHE_SIZE
-	__loop_cache_all \ar \at iii __stringify(ICACHE_WAY_SIZE) \
+	__loop_cache_all \ar \at iii XCHAL_ICACHE_SIZE \
 			 XCHAL_ICACHE_LINEWIDTH 1020
 #endif
 
author maintainer
#39 lore raw

PATCH 38/63 pnfs/blocklayout: off by one in bl_map_stripe()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

commit 0914bb965e38a055e9245637aed117efbe976e91 upstream.

"dev->nr_children" is the number of children which were parsed successfully in bl_parse_stripe(). It could be all of them and then, in that case, it is equal to v->stripe.volumes_count. Either way, the > should be >= so that we don't go beyond the end of what we're supposed to.

Fixes 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing")
---
 fs/nfs/blocklayout/dev.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfs/blocklayout/dev.c +1 -1
@@ -203,7 +203,7 @@ static bool bl_map_stripe(struct pnfs_bl
 	chunk = div_u64(offset, dev->chunk_size);
 	div_u64_rem(chunk, dev->nr_children, &chunk_idx);
 
-	if (chunk_idx > dev->nr_children) {
+	if (chunk_idx >= dev->nr_children) {
 		dprintk("%s: invalid chunk idx %d (%lld/%lld)\n",
 			__func__, chunk_idx, offset, dev->chunk_size);
 		/* error, should not happen */
author maintainer
#40 lore raw

PATCH 39/63 NFSv4 client live hangs after live data migration recovery

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bill Baker <[email protected]>

commit 0f90be132cbf1537d87a6a8b9e80867adac892f6 upstream.

After a live data migration event at the NFS server, the client may send I/O requests to the wrong server, causing a live hang due to repeated recovery events. On the wire, this will appear as an I/O request failing with NFS4ERR_BADSESSION, followed by successful CREATE_SESSION, repeatedly. NFS4ERR_BADSSESSION is returned because the session ID being used was issued by the other server and is not valid at the old server.

The failure is caused by async worker threads having cached the transport (xprt) in the rpc_task structure. After the migration recovery completes, the task is redispatched and the task resends the request to the wrong server based on the old value still present in tk_xprt.

The solution is to recompute the tk_xprt field of the rpc_task structure so that the request goes to the correct server.

Fixes fb43d17210ba ("SUNRPC: Use the multipath iterator to assign a ...")
---
 fs/nfs/nfs4proc.c           |    9 ++++++++-
 include/linux/sunrpc/clnt.h |    1 +
 net/sunrpc/clnt.c           |   28 ++++++++++++++++++++--------
 3 files changed, 29 insertions(+), 9 deletions(-)
fs/nfs/nfs4proc.c +8 -1
@@ -541,8 +541,15 @@ nfs4_async_handle_exception(struct rpc_t
 		ret = -EIO;
 	return ret;
 out_retry:
-	if (ret == 0)
+	if (ret == 0) {
 		exception->retry = 1;
+		/*
+		 * For NFS4ERR_MOVED, the client transport will need to
+		 * be recomputed after migration recovery has completed.
+		 */
+		if (errorcode == -NFS4ERR_MOVED)
+			rpc_task_release_transport(task);
+	}
 	return ret;
 }
 
include/linux/sunrpc/clnt.h +1 -0
@@ -155,6 +155,7 @@ int		rpc_switch_client_transport(struct
 
 void		rpc_shutdown_client(struct rpc_clnt *);
 void		rpc_release_client(struct rpc_clnt *);
+void		rpc_task_release_transport(struct rpc_task *);
 void		rpc_task_release_client(struct rpc_task *);
 
 int		rpcb_create_local(struct net *);
net/sunrpc/clnt.c +20 -8
@@ -965,10 +965,20 @@ out:
 }
 EXPORT_SYMBOL_GPL(rpc_bind_new_program);
 
+void rpc_task_release_transport(struct rpc_task *task)
+{
+	struct rpc_xprt *xprt = task->tk_xprt;
+
+	if (xprt) {
+		task->tk_xprt = NULL;
+		xprt_put(xprt);
+	}
+}
+EXPORT_SYMBOL_GPL(rpc_task_release_transport);
+
 void rpc_task_release_client(struct rpc_task *task)
 {
 	struct rpc_clnt *clnt = task->tk_client;
-	struct rpc_xprt *xprt = task->tk_xprt;
 
 	if (clnt != NULL) {
 		/* Remove from client task list */
@@ -979,12 +989,14 @@ void rpc_task_release_client(struct rpc_
 
 		rpc_release_client(clnt);
 	}
+	rpc_task_release_transport(task);
+}
 
-	if (xprt != NULL) {
-		task->tk_xprt = NULL;
-
-		xprt_put(xprt);
-	}
+static
+void rpc_task_set_transport(struct rpc_task *task, struct rpc_clnt *clnt)
+{
+	if (!task->tk_xprt)
+		task->tk_xprt = xprt_iter_get_next(&clnt->cl_xpi);
 }
 
 static
@@ -992,8 +1004,7 @@ void rpc_task_set_client(struct rpc_task
 {
 
 	if (clnt != NULL) {
-		if (task->tk_xprt == NULL)
-			task->tk_xprt = xprt_iter_get_next(&clnt->cl_xpi);
+		rpc_task_set_transport(task, clnt);
 		task->tk_client = clnt;
 		atomic_inc(&clnt->cl_count);
 		if (clnt->cl_softrtry)
@@ -1550,6 +1561,7 @@ call_start(struct rpc_task *task)
 	task->tk_msg.rpc_proc->p_count++;
 	clnt->cl_stats->rpccnt++;
 	task->tk_action = call_reserve;
+	rpc_task_set_transport(task, clnt);
 }
 
 /*
author maintainer
#41 lore raw

PATCH 40/63 ARM: tegra: Fix Tegra30 Cardhu PCA954x reset

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jon Hunter <[email protected]>

commit 6e1811900b6fe6f2b4665dba6bd6ed32c6b98575 upstream.

On all versions of Tegra30 Cardhu, the reset signal to the NXP PCA9546 I2C mux is connected to the Tegra GPIO BB0. Currently, this pin on the Tegra is not configured as a GPIO but as a special-function IO (SFIO) that is multiplexing the pin to an I2S controller. On exiting system suspend, I2C commands sent to the PCA9546 are failing because there is no ACK. Although it is not possible to see exactly what is happening to the reset during suspend, by ensuring it is configured as a GPIO and driven high, to de-assert the reset, the failures are no longer seen.

Please note that this GPIO is also used to drive the reset signal going to the camera connector on the board. However, given that there is no camera support currently for Cardhu, this should not have any impact.

Fixes 40431d16ff11 ("ARM: tegra: enable PCA9546 on Cardhu")
---
 arch/arm/boot/dts/tegra30-cardhu.dtsi |    1 +
 1 file changed, 1 insertion(+)
arch/arm/boot/dts/tegra30-cardhu.dtsi +1 -0
@@ -205,6 +205,7 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0x70>;
+			reset-gpio = <&gpio TEGRA_GPIO(BB, 0) GPIO_ACTIVE_LOW>;
 		};
 	};
 
author maintainer
#42 lore raw

PATCH 41/63 Replace magic for trusting the secondary keyring with #define

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yannik Sembritzki <[email protected]>

commit 817aef260037f33ee0f44c17fe341323d3aebd6d upstream.

Replace the use of a magic number that indicates that verify_*_signature() should use the secondary keyring with a symbol.

---
 certs/system_keyring.c                  |    3 ++-
 crypto/asymmetric_keys/pkcs7_key_type.c |    2 +-
 include/linux/verification.h            |    6 ++++++
 3 files changed, 9 insertions(+), 2 deletions(-)
certs/system_keyring.c +2 -1
@@ -14,6 +14,7 @@
 #include <linux/sched.h>
 #include <linux/cred.h>
 #include <linux/err.h>
+#include <linux/verification.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
 #include <crypto/pkcs7.h>
@@ -207,7 +208,7 @@ int verify_pkcs7_signature(const void *d
 
 	if (!trusted_keys) {
 		trusted_keys = builtin_trusted_keys;
-	} else if (trusted_keys = (void *)1UL) {
+	} else if (trusted_keys = VERIFY_USE_SECONDARY_KEYRING) {
 #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
 		trusted_keys = secondary_trusted_keys;
 #else
crypto/asymmetric_keys/pkcs7_key_type.c +1 -1
@@ -62,7 +62,7 @@ static int pkcs7_preparse(struct key_pre
 
 	return verify_pkcs7_signature(NULL, 0,
 				      prep->data, prep->datalen,
-				      (void *)1UL, usage,
+				      VERIFY_USE_SECONDARY_KEYRING, usage,
 				      pkcs7_view_content, prep);
 }
 
include/linux/verification.h +6 -0
@@ -13,6 +13,12 @@
 #define _LINUX_VERIFICATION_H
 
 /*
+ * Indicate that both builtin trusted keys and secondary trusted keys
+ * should be used.
+ */
+#define VERIFY_USE_SECONDARY_KEYRING ((struct key *)1UL)
+
+/*
  * The use to which an asymmetric key is being put.
  */
 enum key_being_used_for {
author maintainer
#43 lore raw

PATCH 42/63 Fix kexec forbidding kernels signed with keys in the secondary keyring to boot

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yannik Sembritzki <[email protected]>

commit ea93102f32244e3f45c8b26260be77ed0cc1d16c upstream.

The split of .system_keyring into .builtin_trusted_keys and .secondary_trusted_keys broke kexec, thereby preventing kernels signed by keys which are now in the secondary keyring from being kexec'd.

Fix this by passing VERIFY_USE_SECONDARY_KEYRING to verify_pefile_signature().

Fixes d3bfe84129f6 ("certs: Add a secondary system keyring that can be added to dynamically")
---
 arch/x86/kernel/kexec-bzimage64.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/kexec-bzimage64.c +1 -1
@@ -529,7 +529,7 @@ static int bzImage64_cleanup(void *loade
 static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len)
 {
 	return verify_pefile_signature(kernel, kernel_len,
-				       NULL,
+				       VERIFY_USE_SECONDARY_KEYRING,
 				       VERIFYING_KEXEC_PE_SIGNATURE);
 }
 #endif
author maintainer
#44 lore raw

PATCH 43/63 mm/tlb: Remove tlb_remove_table() non-concurrent condition

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Peter Zijlstra <[email protected]>

commit a6f572084fbee8b30f91465f4a085d7a90901c57 upstream.

Will noted that only checking mm_users is incorrect; we should also check mm_count in order to cover CPUs that have a lazy reference to this mm (and could do speculative TLB operations).

If removing this turns out to be a performance issue, we can re-instate a more complete check, but in tlb_table_flush() eliding the call_rcu_sched().

Fixes 267239116987 ("mm, powerpc: move the RCU page-table freeing into generic code")
Cc Nicholas Piggin <[email protected]>
Cc David Miller <[email protected]>
Cc Martin Schwidefsky <[email protected]>
Cc Michael Ellerman <[email protected]>
---
 mm/memory.c |    9 ---------
 1 file changed, 9 deletions(-)
mm/memory.c +0 -9
@@ -373,15 +373,6 @@ void tlb_remove_table(struct mmu_gather
 {
 	struct mmu_table_batch **batch = &tlb->batch;
 
-	/*
-	 * When there's less then two users of this mm there cannot be a
-	 * concurrent page-table walk.
-	 */
-	if (atomic_read(&tlb->mm->mm_users) < 2) {
-		__tlb_remove_table(table);
-		return;
-	}
-
 	if (*batch == NULL) {
 		*batch = (struct mmu_table_batch *)__get_free_page(GFP_NOWAIT | __GFP_NOWARN);
 		if (*batch == NULL) {
author maintainer
#45 lore raw

PATCH 44/63 iommu/vt-d: Add definitions for PFSID

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jacob Pan <[email protected]>

commit 0f725561e168485eff7277d683405c05b192f537 upstream.

When SRIOV VF device IOTLB is invalidated, we need to provide the PF source ID such that IOMMU hardware can gauge the depth of invalidation queue which is shared among VFs. This is needed when device invalidation throttle (DIT) capability is supported.

This patch adds bit definitions for checking and tracking PFSID.

---
 drivers/iommu/intel-iommu.c |    1 +
 include/linux/intel-iommu.h |    3 +++
 2 files changed, 4 insertions(+)
drivers/iommu/intel-iommu.c +1 -0
@@ -421,6 +421,7 @@ struct device_domain_info {
 	struct list_head global; /* link to global list */
 	u8 bus;			/* PCI bus number */
 	u8 devfn;		/* PCI devfn number */
+	u16 pfsid;		/* SRIOV physical function source ID */
 	u8 pasid_supported:3;
 	u8 pasid_enabled:1;
 	u8 pri_supported:1;
include/linux/intel-iommu.h +3 -0
@@ -125,6 +125,7 @@ static inline void dmar_writeq(void __io
  * Extended Capability Register
  */
 
+#define ecap_dit(e)		((e >> 41) & 0x1)
 #define ecap_pasid(e)		((e >> 40) & 0x1)
 #define ecap_pss(e)		((e >> 35) & 0x1f)
 #define ecap_eafs(e)		((e >> 34) & 0x1)
@@ -294,6 +295,7 @@ enum {
 #define QI_DEV_IOTLB_SID(sid)	((u64)((sid) & 0xffff) << 32)
 #define QI_DEV_IOTLB_QDEP(qdep)	(((qdep) & 0x1f) << 16)
 #define QI_DEV_IOTLB_ADDR(addr)	((u64)(addr) & VTD_PAGE_MASK)
+#define QI_DEV_IOTLB_PFSID(pfsid) (((u64)(pfsid & 0xf) << 12) | ((u64)(pfsid & 0xfff) << 52))
 #define QI_DEV_IOTLB_SIZE	1
 #define QI_DEV_IOTLB_MAX_INVS	32
 
@@ -318,6 +320,7 @@ enum {
 #define QI_DEV_EIOTLB_PASID(p)	(((u64)p) << 32)
 #define QI_DEV_EIOTLB_SID(sid)	((u64)((sid) & 0xffff) << 16)
 #define QI_DEV_EIOTLB_QDEP(qd)	((u64)((qd) & 0x1f) << 4)
+#define QI_DEV_EIOTLB_PFSID(pfsid) (((u64)(pfsid & 0xf) << 12) | ((u64)(pfsid & 0xfff) << 52))
 #define QI_DEV_EIOTLB_MAX_INVS	32
 
 #define QI_PGRP_IDX(idx)	(((u64)(idx)) << 55)
author maintainer
#46 lore raw

PATCH 45/63 iommu/vt-d: Fix dev iotlb pfsid use

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jacob Pan <[email protected]>

commit 1c48db44924298ad0cb5a6386b88017539be8822 upstream.

PFSID should be used in the invalidation descriptor for flushing device IOTLBs on SRIOV VFs.

---
 drivers/iommu/dmar.c        |    6 +++---
 drivers/iommu/intel-iommu.c |   17 ++++++++++++++++-
 include/linux/intel-iommu.h |    5 ++---
 3 files changed, 21 insertions(+), 7 deletions(-)
drivers/iommu/dmar.c +3 -3
@@ -1328,8 +1328,8 @@ void qi_flush_iotlb(struct intel_iommu *
 	qi_submit_sync(&desc, iommu);
 }
 
-void qi_flush_dev_iotlb(struct intel_iommu *iommu, u16 sid, u16 qdep,
-			u64 addr, unsigned mask)
+void qi_flush_dev_iotlb(struct intel_iommu *iommu, u16 sid, u16 pfsid,
+			u16 qdep, u64 addr, unsigned mask)
 {
 	struct qi_desc desc;
 
@@ -1344,7 +1344,7 @@ void qi_flush_dev_iotlb(struct intel_iom
 		qdep = 0;
 
 	desc.low = QI_DEV_IOTLB_SID(sid) | QI_DEV_IOTLB_QDEP(qdep) |
-		   QI_DIOTLB_TYPE;
+		   QI_DIOTLB_TYPE | QI_DEV_IOTLB_PFSID(pfsid);
 
 	qi_submit_sync(&desc, iommu);
 }
drivers/iommu/intel-iommu.c +16 -1
@@ -1512,6 +1512,20 @@ static void iommu_enable_dev_iotlb(struc
 		return;
 
 	pdev = to_pci_dev(info->dev);
+	/* For IOMMU that supports device IOTLB throttling (DIT), we assign
+	 * PFSID to the invalidation desc of a VF such that IOMMU HW can gauge
+	 * queue depth at PF level. If DIT is not set, PFSID will be treated as
+	 * reserved, which should be set to 0.
+	 */
+	if (!ecap_dit(info->iommu->ecap))
+		info->pfsid = 0;
+	else {
+		struct pci_dev *pf_pdev;
+
+		/* pdev will be returned if device is not a vf */
+		pf_pdev = pci_physfn(pdev);
+		info->pfsid = PCI_DEVID(pf_pdev->bus->number, pf_pdev->devfn);
+	}
 
 #ifdef CONFIG_INTEL_IOMMU_SVM
 	/* The PCIe spec, in its wisdom, declares that the behaviour of
@@ -1577,7 +1591,8 @@ static void iommu_flush_dev_iotlb(struct
 
 		sid = info->bus << 8 | info->devfn;
 		qdep = info->ats_qdep;
-		qi_flush_dev_iotlb(info->iommu, sid, qdep, addr, mask);
+		qi_flush_dev_iotlb(info->iommu, sid, info->pfsid,
+				qdep, addr, mask);
 	}
 	spin_unlock_irqrestore(&device_domain_lock, flags);
 }
include/linux/intel-iommu.h +2 -3
@@ -466,9 +466,8 @@ extern void qi_flush_context(struct inte
 			     u8 fm, u64 type);
 extern void qi_flush_iotlb(struct intel_iommu *iommu, u16 did, u64 addr,
 			  unsigned int size_order, u64 type);
-extern void qi_flush_dev_iotlb(struct intel_iommu *iommu, u16 sid, u16 qdep,
-			       u64 addr, unsigned mask);
-
+extern void qi_flush_dev_iotlb(struct intel_iommu *iommu, u16 sid, u16 pfsid,
+			u16 qdep, u64 addr, unsigned mask);
 extern int qi_submit_sync(struct qi_desc *desc, struct intel_iommu *iommu);
 
 extern int dmar_ir_support(void);
author maintainer
#47 lore raw

PATCH 46/63 osf_getdomainname(): use copy_to_user()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Al Viro <[email protected]>

commit 9ba3eb5103cf56f0daaf07de4507df76e7813ed7 upstream.

---
 arch/alpha/kernel/osf_sys.c |   23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)
arch/alpha/kernel/osf_sys.c +9 -14
@@ -561,25 +561,20 @@ SYSCALL_DEFINE0(getdtablesize)
  */
 SYSCALL_DEFINE2(osf_getdomainname, char __user *, name, int, namelen)
 {
-	unsigned len;
-	int i;
+	int len, err = 0;
+	char *kname;
 
-	if (!access_ok(VERIFY_WRITE, name, namelen))
-		return -EFAULT;
-
-	len = namelen;
-	if (len > 32)
-		len = 32;
+	if (namelen > 32)
+		namelen = 32;
 
 	down_read(&uts_sem);
-	for (i = 0; i < len; ++i) {
-		__put_user(utsname()->domainname[i], name + i);
-		if (utsname()->domainname[i] == '\0')
-			break;
-	}
+	kname = utsname()->domainname;
+	len = strnlen(kname, namelen);
+	if (copy_to_user(name, kname, min(len + 1, namelen)))
+		err = -EFAULT;
 	up_read(&uts_sem);
 
-	return 0;
+	return err;
 }
 
 /*
author maintainer
#48 lore raw

PATCH 47/63 sys: dont hold uts_sem while accessing userspace memory

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jann Horn <[email protected]>

commit 42a0cc3478584d4d63f68f2f5af021ddbea771fa upstream.

Holding uts_sem as a writer while accessing userspace memory allows a namespace admin to stall all processes that attempt to take uts_sem. Instead, move data through stack buffers and don't access userspace memory while uts_sem is held.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")
---
 arch/alpha/kernel/osf_sys.c      |   51 +++++++++-----------
 arch/sparc/kernel/sys_sparc_32.c |   22 +++++----
 arch/sparc/kernel/sys_sparc_64.c |   20 ++++----
 kernel/sys.c                     |   95 ++++++++++++++++++---------------------
 kernel/utsname_sysctl.c          |   41 ++++++++++------
 5 files changed, 119 insertions(+), 110 deletions(-)
arch/alpha/kernel/osf_sys.c +24 -27
@@ -526,24 +526,19 @@ SYSCALL_DEFINE4(osf_mount, unsigned long
 SYSCALL_DEFINE1(osf_utsname, char __user *, name)
 {
 	int error;
+	char tmp[5 * 32];
 
 	down_read(&uts_sem);
-	error = -EFAULT;
-	if (copy_to_user(name + 0, utsname()->sysname, 32))
-		goto out;
-	if (copy_to_user(name + 32, utsname()->nodename, 32))
-		goto out;
-	if (copy_to_user(name + 64, utsname()->release, 32))
-		goto out;
-	if (copy_to_user(name + 96, utsname()->version, 32))
-		goto out;
-	if (copy_to_user(name + 128, utsname()->machine, 32))
-		goto out;
+	memcpy(tmp + 0 * 32, utsname()->sysname, 32);
+	memcpy(tmp + 1 * 32, utsname()->nodename, 32);
+	memcpy(tmp + 2 * 32, utsname()->release, 32);
+	memcpy(tmp + 3 * 32, utsname()->version, 32);
+	memcpy(tmp + 4 * 32, utsname()->machine, 32);
+	up_read(&uts_sem);
 
-	error = 0;
- out:
-	up_read(&uts_sem);	
-	return error;
+	if (copy_to_user(name, tmp, sizeof(tmp)))
+		return -EFAULT;
+	return 0;
 }
 
 SYSCALL_DEFINE0(getpagesize)
@@ -563,18 +558,21 @@ SYSCALL_DEFINE2(osf_getdomainname, char
 {
 	int len, err = 0;
 	char *kname;
+	char tmp[32];
 
-	if (namelen > 32)
+	if (namelen < 0 || namelen > 32)
 		namelen = 32;
 
 	down_read(&uts_sem);
 	kname = utsname()->domainname;
 	len = strnlen(kname, namelen);
-	if (copy_to_user(name, kname, min(len + 1, namelen)))
-		err = -EFAULT;
+	len = min(len + 1, namelen);
+	memcpy(tmp, kname, len);
 	up_read(&uts_sem);
 
-	return err;
+	if (copy_to_user(name, tmp, len))
+		return -EFAULT;
+	return 0;
 }
 
 /*
@@ -736,13 +734,14 @@ SYSCALL_DEFINE3(osf_sysinfo, int, comman
 	};
 	unsigned long offset;
 	const char *res;
-	long len, err = -EINVAL;
+	long len;
+	char tmp[__NEW_UTS_LEN + 1];
 
 	offset = command-1;
 	if (offset >= ARRAY_SIZE(sysinfo_table)) {
 		/* Digital UNIX has a few unpublished interfaces here */
 		printk("sysinfo(%d)", command);
-		goto out;
+		return -EINVAL;
 	}
 
 	down_read(&uts_sem);
@@ -750,13 +749,11 @@ SYSCALL_DEFINE3(osf_sysinfo, int, comman
 	len = strlen(res)+1;
 	if ((unsigned long)len > (unsigned long)count)
 		len = count;
-	if (copy_to_user(buf, res, len))
-		err = -EFAULT;
-	else
-		err = 0;
+	memcpy(tmp, res, len);
 	up_read(&uts_sem);
- out:
-	return err;
+	if (copy_to_user(buf, tmp, len))
+		return -EFAULT;
+	return 0;
 }
 
 SYSCALL_DEFINE5(osf_getsysinfo, unsigned long, op, void __user *, buffer,
arch/sparc/kernel/sys_sparc_32.c +13 -9
@@ -201,23 +201,27 @@ SYSCALL_DEFINE5(rt_sigaction, int, sig,
 
 asmlinkage long sys_getdomainname(char __user *name, int len)
 {
- 	int nlen, err;
- 	
+	int nlen, err;
+	char tmp[__NEW_UTS_LEN + 1];
+
 	if (len < 0)
 		return -EINVAL;
 
- 	down_read(&uts_sem);
- 	
+	down_read(&uts_sem);
+
 	nlen = strlen(utsname()->domainname) + 1;
 	err = -EINVAL;
 	if (nlen > len)
-		goto out;
+		goto out_unlock;
+	memcpy(tmp, utsname()->domainname, nlen);
+
+	up_read(&uts_sem);
 
-	err = -EFAULT;
-	if (!copy_to_user(name, utsname()->domainname, nlen))
-		err = 0;
+	if (copy_to_user(name, tmp, nlen))
+		return -EFAULT;
+	return 0;
 
-out:
+out_unlock:
 	up_read(&uts_sem);
 	return err;
 }
arch/sparc/kernel/sys_sparc_64.c +12 -8
@@ -524,23 +524,27 @@ extern void check_pending(int signum);
 
 SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
 {
-        int nlen, err;
+	int nlen, err;
+	char tmp[__NEW_UTS_LEN + 1];
 
 	if (len < 0)
 		return -EINVAL;
 
- 	down_read(&uts_sem);
- 	
+	down_read(&uts_sem);
+
 	nlen = strlen(utsname()->domainname) + 1;
 	err = -EINVAL;
 	if (nlen > len)
-		goto out;
+		goto out_unlock;
+	memcpy(tmp, utsname()->domainname, nlen);
+
+	up_read(&uts_sem);
 
-	err = -EFAULT;
-	if (!copy_to_user(name, utsname()->domainname, nlen))
-		err = 0;
+	if (copy_to_user(name, tmp, nlen))
+		return -EFAULT;
+	return 0;
 
-out:
+out_unlock:
 	up_read(&uts_sem);
 	return err;
 }
kernel/sys.c +45 -50

171 lines not on this page · raw message

kernel/utsname_sysctl.c +25 -16

66 lines not on this page · raw message

author maintainer
#49 lore raw

PATCH 48/63 userns: move user access out of the mutex

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jann Horn <[email protected]>

commit 5820f140edef111a9ea2ef414ab2428b8cb805b1 upstream.

The old code would hold the userns_state_mutex indefinitely if memdup_user_nul stalled due to e.g. a userfault region. Prevent that by moving the memdup_user_nul in front of the mutex_lock().

Note: This changes the error precedence of invalid buf/count/*ppos vs map already written / capabilities missing.

Fixes 22d917d80e84 ("userns: Rework the user_namespace adding uid/gid...")
---
 kernel/user_namespace.c |   24 ++++++++++--------------
 1 file changed, 10 insertions(+), 14 deletions(-)
kernel/user_namespace.c +10 -14
@@ -649,7 +649,16 @@ static ssize_t map_write(struct file *fi
 	unsigned idx;
 	struct uid_gid_extent *extent = NULL;
 	char *kbuf = NULL, *pos, *next_line;
-	ssize_t ret = -EINVAL;
+	ssize_t ret;
+
+	/* Only allow < page size writes at the beginning of the file */
+	if ((*ppos != 0) || (count >= PAGE_SIZE))
+		return -EINVAL;
+
+	/* Slurp in the user data */
+	kbuf = memdup_user_nul(buf, count);
+	if (IS_ERR(kbuf))
+		return PTR_ERR(kbuf);
 
 	/*
 	 * The userns_state_mutex serializes all writes to any given map.
@@ -683,19 +692,6 @@ static ssize_t map_write(struct file *fi
 	if (cap_valid(cap_setid) && !file_ns_capable(file, ns, CAP_SYS_ADMIN))
 		goto out;
 
-	/* Only allow < page size writes at the beginning of the file */
-	ret = -EINVAL;
-	if ((*ppos != 0) || (count >= PAGE_SIZE))
-		goto out;
-
-	/* Slurp in the user data */
-	kbuf = memdup_user_nul(buf, count);
-	if (IS_ERR(kbuf)) {
-		ret = PTR_ERR(kbuf);
-		kbuf = NULL;
-		goto out;
-	}
-
 	/* Parse the user data */
 	ret = -EINVAL;
 	pos = kbuf;
author maintainer
#50 lore raw

PATCH 49/63 ubifs: Fix memory leak in lprobs self-check

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Richard Weinberger <[email protected]>

commit eef19816ada3abd56d9f20c88794cc2fea83ebb2 upstream.

Allocate the buffer after we return early.
Otherwise memory is being leaked.

Fixes 1e51764a3c2a ("UBIFS: add new flash file system")
---
 fs/ubifs/lprops.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
fs/ubifs/lprops.c +4 -4
@@ -1091,10 +1091,6 @@ static int scan_check_cb(struct ubifs_in
 		}
 	}
 
-	buf = __vmalloc(c->leb_size, GFP_NOFS, PAGE_KERNEL);
-	if (!buf)
-		return -ENOMEM;
-
 	/*
 	 * After an unclean unmount, empty and freeable LEBs
 	 * may contain garbage - do not scan them.
@@ -1113,6 +1109,10 @@ static int scan_check_cb(struct ubifs_in
 		return LPT_SCAN_CONTINUE;
 	}
 
+	buf = __vmalloc(c->leb_size, GFP_NOFS, PAGE_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
 	sleb = ubifs_scan(c, lnum, 0, buf, 0);
 	if (IS_ERR(sleb)) {
 		ret = PTR_ERR(sleb);
author maintainer
#51 lore raw

PATCH 50/63 Revert "UBIFS: Fix potential integer overflow in allocation"

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Richard Weinberger <[email protected]>

commit 08acbdd6fd736b90f8d725da5a0de4de2dd6de62 upstream.

This reverts commit 353748a359f1821ee934afc579cf04572406b420. It bypassed the linux-mtd review process and fixes the issue not as it should.

---
 fs/ubifs/journal.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ubifs/journal.c +1 -1
@@ -1265,7 +1265,7 @@ static int recomp_data_node(const struct
 	int err, len, compr_type, out_len;
 
 	out_len = le32_to_cpu(dn->size);
-	buf = kmalloc_array(out_len, WORST_COMPR_FACTOR, GFP_NOFS);
+	buf = kmalloc(out_len * WORST_COMPR_FACTOR, GFP_NOFS);
 	if (!buf)
 		return -ENOMEM;
 
author maintainer
#52 lore raw

PATCH 51/63 ubifs: Check data node size before truncate

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Richard Weinberger <[email protected]>

commit 95a22d2084d72ea067d8323cc85677dba5d97cae upstream.

Check whether the size is within bounds before using it. If the size is not correct, abort and dump the bad data node.

Cc Kees Cook <[email protected]>
Cc Silvio Cesare <[email protected]>
Fixes 1e51764a3c2ac ("UBIFS: add new flash file system")
---
 fs/ubifs/journal.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
fs/ubifs/journal.c +10 -1
@@ -1344,7 +1344,16 @@ int ubifs_jnl_truncate(struct ubifs_info
 		else if (err)
 			goto out_free;
 		else {
-			if (le32_to_cpu(dn->size) <= dlen)
+			int dn_len = le32_to_cpu(dn->size);
+
+			if (dn_len <= 0 || dn_len > UBIFS_BLOCK_SIZE) {
+				ubifs_err(c, "bad data node (block %u, inode %lu)",
+					  blk, inode->i_ino);
+				ubifs_dump_node(c, dn);
+				goto out_free;
+			}
+
+			if (dn_len <= dlen)
 				dlen = 0; /* Nothing to do */
 			else {
 				int compr_type = le16_to_cpu(dn->compr_type);
author maintainer
#53 lore raw

PATCH 52/63 ubifs: Fix synced_i_size calculation for xattr inodes

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Richard Weinberger <[email protected]>

commit 59965593205fa4044850d35ee3557cf0b7edcd14 upstream.

In ubifs_jnl_update() we sync parent and child inodes to the flash, in case of xattrs, the parent inode (AKA host inode) has a non-zero data_len. Therefore we need to adjust synced_i_size too.

This issue was reported by ubifs self tests unter a xattr related work
load.
UBIFS error (ubi0:0 pid 1896): dbg_check_synced_i_size: ui_size is 4, synced_i_size is 0, but inode is clean UBIFS error (ubi0:0 pid 1896): dbg_check_synced_i_size: i_ino 65, i_mode 0x81a4, i_size 4

Fixes 1e51764a3c2a ("UBIFS: add new flash file system")
---
 fs/ubifs/journal.c |    5 +++++
 1 file changed, 5 insertions(+)
fs/ubifs/journal.c +5 -0
@@ -661,6 +661,11 @@ int ubifs_jnl_update(struct ubifs_info *
 	spin_lock(&ui->ui_lock);
 	ui->synced_i_size = ui->ui_size;
 	spin_unlock(&ui->ui_lock);
+	if (xent) {
+		spin_lock(&host_ui->ui_lock);
+		host_ui->synced_i_size = host_ui->ui_size;
+		spin_unlock(&host_ui->ui_lock);
+	}
 	mark_inode_clean(c, ui);
 	mark_inode_clean(c, host_ui);
 	return 0;
author maintainer
#54 lore raw

PATCH 53/63 pwm: tiehrpwm: Fix disabling of output of PWMs

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vignesh R <[email protected]>

commit 38dabd91ff0bde33352ca3cc65ef515599b77a05 upstream.

pwm-tiehrpwm driver disables PWM output by putting it in low output state via active AQCSFRC register in ehrpwm_pwm_disable(). But, the AQCSFRC shadow register is not updated. Therefore, when shadow AQCSFRC register is re-enabled in ehrpwm_pwm_enable() (say to enable second PWM output), previous settings are lost as shadow register value is loaded into active register. This results in things like PWMA getting enabled automatically, when PWMB is enabled and vice versa. Fix this by updating AQCSFRC shadow register as well during ehrpwm_pwm_disable().

Fixes 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
---
 drivers/pwm/pwm-tiehrpwm.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/pwm/pwm-tiehrpwm.c +2 -0
@@ -382,6 +382,8 @@ static void ehrpwm_pwm_disable(struct pw
 		aqcsfrc_mask = AQCSFRC_CSFA_MASK;
 	}
 
+	/* Update shadow register first before modifying active register */
+	ehrpwm_modify(pc->mmio_base, AQCSFRC, aqcsfrc_mask, aqcsfrc_val);
 	/*
 	 * Changes to immediate action on Action Qualifier. This puts
 	 * Action Qualifier control on PWM output from next TBCLK
author maintainer
#55 lore raw

PATCH 54/63 fb: fix lost console when the user unplugs a USB adapter

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mikulas Patocka <[email protected]>

commit 8c5b044299951acd91e830a688dd920477ea1eda upstream.

I have a USB display adapter using the udlfb driver and I use it on an ARM board that doesn't have any graphics card. When I plug the adapter in, the console is properly displayed, however when I unplug and re-plug the adapter, the console is not displayed and I can't access it until I reboot the board.

The reason is this:
When the adapter is unplugged, dlfb_usb_disconnect calls unlink_framebuffer, then it waits until the reference count drops to zero and then it deallocates the framebuffer. However, the console that is attached to the framebuffer device keeps the reference count non-zero, so the framebuffer device is never destroyed. When the USB adapter is plugged again, it creates a new device /dev/fb1 and the console is not attached to it.

This patch fixes the bug by unbinding the console from unlink_framebuffer. The code to unbind the console is moved from do_unregister_framebuffer to a function unbind_console. When the console is unbound, the reference count drops to zero and the udlfb driver frees the framebuffer. When the adapter is plugged back, a new framebuffer is created and the console is attached to it.

Cc Dave Airlie <[email protected]>
Cc Bernie Thompson <[email protected]>
Cc Ladislav Michl <[email protected]>
[b.zolnierkie: preserve old behavior for do_unregister_framebuffer()]
---
 drivers/video/fbdev/core/fbmem.c |   38 ++++++++++++++++++++++++++++++++------
 1 file changed, 32 insertions(+), 6 deletions(-)
drivers/video/fbdev/core/fbmem.c +32 -6
@@ -1695,12 +1695,12 @@ static int do_register_framebuffer(struc
 	return 0;
 }
 
-static int do_unregister_framebuffer(struct fb_info *fb_info)
+static int unbind_console(struct fb_info *fb_info)
 {
 	struct fb_event event;
-	int i, ret = 0;
+	int ret;
+	int i = fb_info->node;
 
-	i = fb_info->node;
 	if (i < 0 || i >= FB_MAX || registered_fb[i] != fb_info)
 		return -EINVAL;
 
@@ -1715,17 +1715,29 @@ static int do_unregister_framebuffer(str
 	unlock_fb_info(fb_info);
 	console_unlock();
 
+	return ret;
+}
+
+static int __unlink_framebuffer(struct fb_info *fb_info);
+
+static int do_unregister_framebuffer(struct fb_info *fb_info)
+{
+	struct fb_event event;
+	int ret;
+
+	ret = unbind_console(fb_info);
+
 	if (ret)
 		return -EINVAL;
 
 	pm_vt_switch_unregister(fb_info->dev);
 
-	unlink_framebuffer(fb_info);
+	__unlink_framebuffer(fb_info);
 	if (fb_info->pixmap.addr &&
 	    (fb_info->pixmap.flags & FB_PIXMAP_DEFAULT))
 		kfree(fb_info->pixmap.addr);
 	fb_destroy_modelist(&fb_info->modelist);
-	registered_fb[i] = NULL;
+	registered_fb[fb_info->node] = NULL;
 	num_registered_fb--;
 	fb_cleanup_device(fb_info);
 	event.info = fb_info;
@@ -1738,7 +1750,7 @@ static int do_unregister_framebuffer(str
 	return 0;
 }
 
-int unlink_framebuffer(struct fb_info *fb_info)
+static int __unlink_framebuffer(struct fb_info *fb_info)
 {
 	int i;
 
@@ -1750,6 +1762,20 @@ int unlink_framebuffer(struct fb_info *f
 		device_destroy(fb_class, MKDEV(FB_MAJOR, i));
 		fb_info->dev = NULL;
 	}
+
+	return 0;
+}
+
+int unlink_framebuffer(struct fb_info *fb_info)
+{
+	int ret;
+
+	ret = __unlink_framebuffer(fb_info);
+	if (ret)
+		return ret;
+
+	unbind_console(fb_info);
+
 	return 0;
 }
 EXPORT_SYMBOL(unlink_framebuffer);
author maintainer
#56 lore raw

PATCH 55/63 udlfb: set optimal write delay

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mikulas Patocka <[email protected]>

commit bb24153a3f13dd0dbc1f8055ad97fe346d598f66 upstream.

The default delay 5 jiffies is too much when the kernel is compiled with HZ=100 - it results in jumpy cursor in Xwindow.

In order to find out the optimal delay, I benchmarked the driver on 1280x720x30fps video. I found out that with HZ=1000, 10ms is acceptable, but with HZ=250 or HZ=300, we need 4ms, so that the video is played without any frame skips.

This patch changes the delay to this value.

---
 include/video/udlfb.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/video/udlfb.h +1 -1
@@ -87,7 +87,7 @@ struct dlfb_data {
 #define MIN_RAW_PIX_BYTES	2
 #define MIN_RAW_CMD_BYTES	(RAW_HEADER_BYTES + MIN_RAW_PIX_BYTES)
 
-#define DL_DEFIO_WRITE_DELAY    5 /* fb_deferred_io.delay in jiffies */
+#define DL_DEFIO_WRITE_DELAY    msecs_to_jiffies(HZ <= 300 ? 4 : 10) /* optimal value for 720p video */
 #define DL_DEFIO_WRITE_DISABLE  (HZ*60) /* "disable" with long delay */
 
 /* remove these once align.h patch is taken into kernel */
author maintainer
#57 lore raw

PATCH 56/63 getxattr: use correct xattr length

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christian Brauner <[email protected]>

commit 82c9a927bc5df6e06b72d206d24a9d10cced4eb5 upstream.

When running in a container with a user namespace, if you call getxattr with name = "system.posix_acl_access" and size % 8 != 4, then getxattr silently skips the user namespace fixup that it normally does resulting in un-fixed-up data being returned.
This is caused by posix_acl_fix_xattr_to_user() being passed the total buffer size and not the actual size of the xattr as returned by vfs_getxattr().
This commit passes the actual length of the xattr as returned by vfs_getxattr() down.

A reproducer for the issue is:

touch acl_posix

setfacl -m user:0:rwx acl_posix

and the compile:

  #define _GNU_SOURCE
  #include <errno.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>
  #include <sys/types.h>
  #include <unistd.h>
  #include <attr/xattr.h>

  /* Run in user namespace with nsuid 0 mapped to uid != 0 on the host. */
  int main(int argc, void **argv)
  {
          ssize_t ret1, ret2;
          char buf1[128], buf2[132];
          int fret = EXIT_SUCCESS;
          char *file;
          if (argc < 2) {
                  fprintf(stderr,
                          "Please specify a file with "
                          "\"system.posix_acl_access\" permissions set\n");
                  _exit(EXIT_FAILURE);
          }
          file = argv[1];

          ret1 = getxattr(file, "system.posix_acl_access",
                          buf1, sizeof(buf1));
          if (ret1 < 0) {
                  fprintf(stderr, "%s - Failed to retrieve "
                                  "\"system.posix_acl_access\" "
                                  "from \"%s\"\n", strerror(errno), file);
                  _exit(EXIT_FAILURE);
          }

          ret2 = getxattr(file, "system.posix_acl_access",
                          buf2, sizeof(buf2));
          if (ret2 < 0) {
                  fprintf(stderr, "%s - Failed to retrieve "
                                  "\"system.posix_acl_access\" "
                                  "from \"%s\"\n", strerror(errno), file);
                  _exit(EXIT_FAILURE);
          }

          if (ret1 != ret2) {
                  fprintf(stderr, "The value of \"system.posix_acl_"
                                  "access\" for file \"%s\" changed "
                                  "between two successive calls\n", file);
                  _exit(EXIT_FAILURE);
          }

          for (ssize_t i = 0; i < ret2; i++) {
                  if (buf1[i] == buf2[i])
                          continue;

                  fprintf(stderr,
                          "Unexpected different in byte %zd: "
                          "%02x != %02x\n", i, buf1[i], buf2[i]);
                  fret = EXIT_FAILURE;
          }

          if (fret == EXIT_SUCCESS)
                  fprintf(stderr, "Test passed\n");
          else
                  fprintf(stderr, "Test failed\n");

          _exit(fret);

}
and run:

./tester acl_posix

On a non-fixed up kernel this should return something like:

  root@c1:/# ./t
  Unexpected different in byte 16: ffffffa0 != 00
  Unexpected different in byte 17: ffffff86 != 00
  Unexpected different in byte 18: 01 != 00

and on a fixed kernel:

  root@c1:~# ./t
  Test passed
---
 fs/xattr.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/xattr.c +1 -1
@@ -540,7 +540,7 @@ getxattr(struct dentry *d, const char __
 	if (error > 0) {
 		if ((strcmp(kname, XATTR_NAME_POSIX_ACL_ACCESS) == 0) ||
 		    (strcmp(kname, XATTR_NAME_POSIX_ACL_DEFAULT) == 0))
-			posix_acl_fix_xattr_to_user(kvalue, size);
+			posix_acl_fix_xattr_to_user(kvalue, error);
 		if (size && copy_to_user(value, kvalue, error))
 			error = -EFAULT;
 	} else if (error == -ERANGE && size >= XATTR_SIZE_MAX) {
author maintainer
#58 lore raw

PATCH 57/63 libnvdimm: fix ars_status output length calculation

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vishal Verma <[email protected]>

commit 286e87718103acdf85f4ed323a37e4839a8a7c05 upstream.

Commit efda1b5d87cb ("acpi, nfit, libnvdimm: fix / harden ars_status output length handling") Introduced additional hardening for ambiguity in the ACPI spec for
ars_status output sizing. However, it had a couple of cases mixed up.
Where it should have been checking for (and returning) "out_field[1] -
4" it was using "out_field[1] - 8" and vice versa.

This caused a four byte discrepancy in the buffer size passed on to the command handler, and in some cases, this caused memory corruption like:

./daxdev-errors.sh: line 76: 24104 Aborted (core dumped) ./daxdev-errors $busdev $region
malloc(): memory corruption
Program received signal SIGABRT, Aborted.
[...]

  #5  0x00007ffff7865a2e in calloc () from /lib64/libc.so.6
  #6  0x00007ffff7bc2970 in ndctl_bus_cmd_new_ars_status (ars_cap=ars_cap@entry=0x6153b0) at ars.c:136
  #7  0x0000000000401644 in check_ars_status (check=0x7fffffffdeb0, bus=0x604c20) at daxdev-errors.c:144
  #8  test_daxdev_clear_error (region_name=<optimized out>, bus_name=<optimized out>)
      at daxdev-errors.c:332
Cc Dave Jiang <[email protected]>
Cc Keith Busch <[email protected]>
Cc Lukasz Dorau <[email protected]>
Cc Dan Williams <[email protected]>
Fixes efda1b5d87cb ("acpi, nfit, libnvdimm: fix / harden ars_status output length handling")
---
 drivers/nvdimm/bus.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/nvdimm/bus.c +2 -2
@@ -748,9 +748,9 @@ u32 nd_cmd_out_size(struct nvdimm *nvdim
 		 * overshoots the remainder by 4 bytes, assume it was
 		 * including 'status'.
 		 */
-		if (out_field[1] - 8 == remainder)
+		if (out_field[1] - 4 == remainder)
 			return remainder;
-		return out_field[1] - 4;
+		return out_field[1] - 8;
 	} else if (cmd == ND_CMD_CALL) {
 		struct nd_cmd_pkg *pkg = (struct nd_cmd_pkg *) in_field;
 
author maintainer
#59 lore raw

PATCH 58/63 printk/tracing: Do not trace printk_nmi_enter()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steven Rostedt (VMware) <[email protected]>

commit d1c392c9e2a301f38998a353f467f76414e38725 upstream.

I hit the following splat in my tests:

------------[ cut here ]------------
IRQs not enabled as expected
WARNING: CPU: 3 PID: 0 at kernel/time/tick-sched.c:982 tick_nohz_idle_enter+0x44/0x8c
Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipv6
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.19.0-rc2-test+ #2
Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
EIP: tick_nohz_idle_enter+0x44/0x8c
Code: ec 05 00 00 00 75 26 83 b8 c0 05 00 00 00 75 1d 80 3d d0 36 3e c1 00

75 14 68 94 63 12 c1 c6 05 d0 36 3e c1 01 e8 04 ee f8 ff <0f> 0b 58 fa bb a0 e5 66 c1 e8 25 0f 04 00 64 03 1d 28 31 52 c1 8b
EAX: 0000001c EBX: f26e7f8c ECX: 00000006 EDX: 00000007
ESI: f26dd1c0 EDI: 00000000 EBP: f26e7f40 ESP: f26e7f38
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010296
CR0: 80050033 CR2: 0813c6b0 CR3: 2f342000 CR4: 001406f0

Call Trace:
 do_idle+0x33/0x202
 cpu_startup_entry+0x61/0x63
 start_secondary+0x18e/0x1ed
 startup_32_smp+0x164/0x168
irq event stamp: 18773830
hardirqs last  enabled at (18773829): [<c040150c>] trace_hardirqs_on_thunk+0xc/0x10
hardirqs last disabled at (18773830): [<c040151c>] trace_hardirqs_off_thunk+0xc/0x10
softirqs last  enabled at (18773824): [<c0ddaa6f>] __do_softirq+0x25f/0x2bf
softirqs last disabled at (18773767): [<c0416bbe>] call_on_stack+0x45/0x4b
---[ end trace b7c64aa79e17954a ]---

After a bit of debugging, I found what was happening. This would trigger when performing "perf" with a high NMI interrupt rate, while enabling and disabling function tracer. Ftrace uses breakpoints to convert the nops at the start of functions to calls to the function trampolines. The breakpoint traps disable interrupts and this makes calls into lockdep via the trace_hardirqs_off_thunk in the entry.S code. What happens is the following:

  do_idle {

[interrupts enabled]

<interrupt> [interrupts disabled]
TRACE_IRQS_OFF [lockdep says irqs off]
[...]
TRACE_IRQS_IRET
test if pt_regs say return to interrupts enabled [yes] TRACE_IRQS_ON [lockdep says irqs are on]

<nmi>
nmi_enter() {
printk_nmi_enter() [traced by ftrace]
[ hit ftrace breakpoint ]
<breakpoint exception>
TRACE_IRQS_OFF [lockdep says irqs off] [...]
TRACE_IRQS_IRET [return from breakpoint]
test if pt_regs say interrupts enabled [no] [iret back to interrupt]
[iret back to code]

tick_nohz_idle_enter() {

lockdep_assert_irqs_enabled() [lockdep say no!]

Although interrupts are indeed enabled, lockdep thinks it is not, and since we now do asserts via lockdep, it gives a false warning. The issue here is that printk_nmi_enter() is called before lockdep_off(), which disables lockdep (for this reason) in NMIs. By simply not allowing ftrace to see printk_nmi_enter() (via notrace annotation) we keep lockdep from getting confused.

Fixes 42a0bb3f71383 ("printk/nmi: generic solution for safe printk in NMI")
---
 kernel/printk/nmi.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/printk/nmi.c +2 -2
@@ -260,12 +260,12 @@ void __init printk_nmi_init(void)
 	printk_nmi_flush();
 }
 
-void printk_nmi_enter(void)
+void notrace printk_nmi_enter(void)
 {
 	this_cpu_write(printk_func, vprintk_nmi);
 }
 
-void printk_nmi_exit(void)
+void notrace printk_nmi_exit(void)
 {
 	this_cpu_write(printk_func, vprintk_default);
 }
author maintainer
#60 lore raw

PATCH 59/63 bcache: release dc->writeback_lock properly in bch_writeback_thread()

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shan Hai <[email protected]>

commit 3943b040f11ed0cc6d4585fd286a623ca8634547 upstream.

The writeback thread would exit with a lock held when the cache device is detached via sysfs interface, fix it by releasing the held lock before exiting the while-loop.

Fixes fadd94e05c02 (bcache: quit dc->writeback_thread when BCACHE_DEV_DETACHING is set)
---
 drivers/md/bcache/writeback.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/md/bcache/writeback.c +3 -1
@@ -456,8 +456,10 @@ static int bch_writeback_thread(void *ar
 			 * data on cache. BCACHE_DEV_DETACHING flag is set in
 			 * bch_cached_dev_detach().
 			 */
-			if (test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags))
+			if (test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags)) {
+				up_write(&dc->writeback_lock);
 				break;
+			}
 		}
 
 		up_write(&dc->writeback_lock);
author maintainer
#61 lore raw

PATCH 60/63 perf auxtrace: Fix queue resize

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Adrian Hunter <[email protected]>

commit 99cbbe56eb8bede625f410ab62ba34673ffa7d21 upstream.

When the number of queues grows beyond 32, the array of queues is resized but not all members were being copied. Fix by also copying 'tid', 'cpu' and 'set'.

Cc Jiri Olsa <[email protected]>
Fixes e502789302a6e ("perf auxtrace: Add helpers for queuing AUX area tracing data")
---
 tools/perf/util/auxtrace.c |    3 +++
 1 file changed, 3 insertions(+)
tools/perf/util/auxtrace.c +3 -0
@@ -195,6 +195,9 @@ static int auxtrace_queues__grow(struct
 	for (i = 0; i < queues->nr_queues; i++) {
 		list_splice_tail(&queues->queue_array[i].head,
 				 &queue_array[i].head);
+		queue_array[i].tid = queues->queue_array[i].tid;
+		queue_array[i].cpu = queues->queue_array[i].cpu;
+		queue_array[i].set = queues->queue_array[i].set;
 		queue_array[i].priv = queues->queue_array[i].priv;
 	}
 
author maintainer
#62 lore raw

PATCH 61/63 crypto: vmx - Fix sleep-in-atomic bugs

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ondrej Mosnacek <[email protected]>

commit 0522236d4f9c5ab2e79889cb020d1acbe5da416e upstream.

This patch fixes sleep-in-atomic bugs in AES-CBC and AES-XTS VMX implementations. The problem is that the blkcipher_* functions should not be called in atomic context.

The bugs can be reproduced via the AF_ALG interface by trying to encrypt/decrypt sufficiently large buffers (at least 64 KiB) using the VMX implementations of 'cbc(aes)' or 'xts(aes)'. Such operations then trigger BUG in crypto_yield():

[  891.863680] BUG: sleeping function called from invalid context at include/crypto/algapi.h:424
[  891.864622] in_atomic(): 1, irqs_disabled(): 0, pid: 12347, name: kcapi-enc
[  891.864739] 1 lock held by kcapi-enc/12347:
[  891.864811]  #0: 00000000f5d42c46 (sk_lock-AF_ALG){+.+.}, at: skcipher_recvmsg+0x50/0x530
[  891.865076] CPU: 5 PID: 12347 Comm: kcapi-enc Not tainted 4.19.0-0.rc0.git3.1.fc30.ppc64le #1
[  891.865251] Call Trace:
[  891.865340] [c0000003387578c0] [c000000000d67ea4] dump_stack+0xe8/0x164 (unreliable)
[  891.865511] [c000000338757910] [c000000000172a58] ___might_sleep+0x2f8/0x310
[  891.865679] [c000000338757990] [c0000000006bff74] blkcipher_walk_done+0x374/0x4a0
[  891.865825] [c0000003387579e0] [d000000007e73e70] p8_aes_cbc_encrypt+0x1c8/0x260 [vmx_crypto]
[  891.865993] [c000000338757ad0] [c0000000006c0ee0] skcipher_encrypt_blkcipher+0x60/0x80
[  891.866128] [c000000338757b10] [c0000000006ec504] skcipher_recvmsg+0x424/0x530
[  891.866283] [c000000338757bd0] [c000000000b00654] sock_recvmsg+0x74/0xa0
[  891.866403] [c000000338757c10] [c000000000b00f64] ___sys_recvmsg+0xf4/0x2f0
[  891.866515] [c000000338757d90] [c000000000b02bb8] __sys_recvmsg+0x68/0xe0
[  891.866631] [c000000338757e30] [c00000000000bbe4] system_call+0x5c/0x70
Fixes 8c755ace357c ("crypto: vmx - Adding CBC routines for VMX module")
Fixes c07f5d3da643 ("crypto: vmx - Adding support for XTS")
---
 drivers/crypto/vmx/aes_cbc.c |   30 ++++++++++++++----------------
 drivers/crypto/vmx/aes_xts.c |   21 ++++++++++++++-------
 2 files changed, 28 insertions(+), 23 deletions(-)
drivers/crypto/vmx/aes_cbc.c +14 -16
@@ -111,24 +111,23 @@ static int p8_aes_cbc_encrypt(struct blk
 		ret = crypto_blkcipher_encrypt(&fallback_desc, dst, src,
 					       nbytes);
 	} else {
-		preempt_disable();
-		pagefault_disable();
-		enable_kernel_vsx();
-
 		blkcipher_walk_init(&walk, dst, src, nbytes);
 		ret = blkcipher_walk_virt(desc, &walk);
 		while ((nbytes = walk.nbytes)) {
+			preempt_disable();
+			pagefault_disable();
+			enable_kernel_vsx();
 			aes_p8_cbc_encrypt(walk.src.virt.addr,
 					   walk.dst.virt.addr,
 					   nbytes & AES_BLOCK_MASK,
 					   &ctx->enc_key, walk.iv, 1);
+			disable_kernel_vsx();
+			pagefault_enable();
+			preempt_enable();
+
 			nbytes &= AES_BLOCK_SIZE - 1;
 			ret = blkcipher_walk_done(desc, &walk, nbytes);
 		}
-
-		disable_kernel_vsx();
-		pagefault_enable();
-		preempt_enable();
 	}
 
 	return ret;
@@ -152,24 +151,23 @@ static int p8_aes_cbc_decrypt(struct blk
 		ret = crypto_blkcipher_decrypt(&fallback_desc, dst, src,
 					       nbytes);
 	} else {
-		preempt_disable();
-		pagefault_disable();
-		enable_kernel_vsx();
-
 		blkcipher_walk_init(&walk, dst, src, nbytes);
 		ret = blkcipher_walk_virt(desc, &walk);
 		while ((nbytes = walk.nbytes)) {
+			preempt_disable();
+			pagefault_disable();
+			enable_kernel_vsx();
 			aes_p8_cbc_encrypt(walk.src.virt.addr,
 					   walk.dst.virt.addr,
 					   nbytes & AES_BLOCK_MASK,
 					   &ctx->dec_key, walk.iv, 0);
+			disable_kernel_vsx();
+			pagefault_enable();
+			preempt_enable();
+
 			nbytes &= AES_BLOCK_SIZE - 1;
 			ret = blkcipher_walk_done(desc, &walk, nbytes);
 		}
-
-		disable_kernel_vsx();
-		pagefault_enable();
-		preempt_enable();
 	}
 
 	return ret;
drivers/crypto/vmx/aes_xts.c +14 -7
@@ -123,32 +123,39 @@ static int p8_aes_xts_crypt(struct blkci
 		ret = enc ? crypto_blkcipher_encrypt(&fallback_desc, dst, src, nbytes) :
                             crypto_blkcipher_decrypt(&fallback_desc, dst, src, nbytes);
 	} else {
+		blkcipher_walk_init(&walk, dst, src, nbytes);
+
+		ret = blkcipher_walk_virt(desc, &walk);
+
 		preempt_disable();
 		pagefault_disable();
 		enable_kernel_vsx();
 
-		blkcipher_walk_init(&walk, dst, src, nbytes);
-
-		ret = blkcipher_walk_virt(desc, &walk);
 		iv = walk.iv;
 		memset(tweak, 0, AES_BLOCK_SIZE);
 		aes_p8_encrypt(iv, tweak, &ctx->tweak_key);
 
+		disable_kernel_vsx();
+		pagefault_enable();
+		preempt_enable();
+
 		while ((nbytes = walk.nbytes)) {
+			preempt_disable();
+			pagefault_disable();
+			enable_kernel_vsx();
 			if (enc)
 				aes_p8_xts_encrypt(walk.src.virt.addr, walk.dst.virt.addr,
 						nbytes & AES_BLOCK_MASK, &ctx->enc_key, NULL, tweak);
 			else
 				aes_p8_xts_decrypt(walk.src.virt.addr, walk.dst.virt.addr,
 						nbytes & AES_BLOCK_MASK, &ctx->dec_key, NULL, tweak);
+			disable_kernel_vsx();
+			pagefault_enable();
+			preempt_enable();
 
 			nbytes &= AES_BLOCK_SIZE - 1;
 			ret = blkcipher_walk_done(desc, &walk, nbytes);
 		}
-
-		disable_kernel_vsx();
-		pagefault_enable();
-		preempt_enable();
 	}
 	return ret;
 }
author maintainer
#63 lore raw

PATCH 63/63 fs/quota: Fix spectre gadget in do_quotactl

In reply to Greg Kroah-Hartman

4.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jeremy Cline <[email protected]>

commit 7b6924d94a60c6b8c1279ca003e8744e6cd9e8b1 upstream.

'type' is user-controlled, so sanitize it after the bounds check to avoid using it in speculative execution. This covers the following potential gadgets detected with the help of smatch:

* fs/ext4/super.c:5741 ext4_quota_read() warn: potential spectre issue 'sb_dqopt(sb)->files' [r]
* fs/ext4/super.c:5778 ext4_quota_write() warn: potential spectre issue 'sb_dqopt(sb)->files' [r]
* fs/f2fs/super.c:1552 f2fs_quota_read() warn: potential spectre issue 'sb_dqopt(sb)->files' [r]
* fs/f2fs/super.c:1608 f2fs_quota_write() warn: potential spectre issue 'sb_dqopt(sb)->files' [r]
* fs/quota/dquot.c:412 mark_info_dirty() warn: potential spectre issue 'sb_dqopt(sb)->info' [w]
* fs/quota/dquot.c:933 dqinit_needed() warn: potential spectre issue 'dquots' [r]
* fs/quota/dquot.c:2112 dquot_commit_info() warn: potential spectre issue 'dqopt->ops' [r]
* fs/quota/dquot.c:2362 vfs_load_quota_inode() warn: potential spectre issue 'dqopt->files' [w] (local cap)
* fs/quota/dquot.c:2369 vfs_load_quota_inode() warn: potential spectre issue 'dqopt->ops' [w] (local cap)
* fs/quota/dquot.c:2370 vfs_load_quota_inode() warn: potential spectre issue 'dqopt->info' [w] (local cap)
* fs/quota/quota.c:110 quota_getfmt() warn: potential spectre issue 'sb_dqopt(sb)->info' [r]
* fs/quota/quota_v2.c:84 v2_check_quota_file() warn: potential spectre issue 'quota_magics' [w]
* fs/quota/quota_v2.c:85 v2_check_quota_file() warn: potential spectre issue 'quota_versions' [w]
* fs/quota/quota_v2.c:96 v2_read_file_info() warn: potential spectre issue 'dqopt->info' [r]
* fs/quota/quota_v2.c:172 v2_write_file_info() warn: potential spectre issue 'dqopt->info' [r]

Additionally, a quick inspection indicates there are array accesses with 'type' in quota_on() and quota_off() functions which are also addressed by this.

---
 fs/quota/quota.c |    2 ++
 1 file changed, 2 insertions(+)
fs/quota/quota.c +2 -0
@@ -17,6 +17,7 @@
 #include <linux/quotaops.h>
 #include <linux/types.h>
 #include <linux/writeback.h>
+#include <linux/nospec.h>
 
 static int check_quotactl_permission(struct super_block *sb, int type, int cmd,
 				     qid_t id)
@@ -706,6 +707,7 @@ static int do_quotactl(struct super_bloc
 
 	if (type >= (XQM_COMMAND(cmd) ? XQM_MAXQUOTAS : MAXQUOTAS))
 		return -EINVAL;
+	type = array_index_nospec(type, MAXQUOTAS);
 	/*
 	 * Quota not supported on this fs? Check this before s_quota_types
 	 * since they needn't be set if quota is not supported at all.
#64 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 151 pass: 149 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:

	total: 301 pass: 285 fail: 16
Failed tests:
	powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs
	powerpc:pseries:pseries_defconfig:initrd
	powerpc:pseries:pseries_defconfig:scsi:rootfs
	powerpc:pseries:pseries_defconfig:mmc:rootfs
	powerpc:pseries:pseries_defconfig:nvme:rootfs
	powerpc:pseries:pseries_defconfig:little:initrd
	powerpc:pseries:pseries_defconfig:little:scsi:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs
	powerpc:pseries:pseries_defconfig:little:mmc:rootfs
	powerpc:pseries:pseries_defconfig:little:nvme:rootfs
	powerpc:powernv:powernv_defconfig:initrd

Details are available at https://kerneltests.org/builders/.

Guenter

author maintainer
#65 lore raw
Quoted 35 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 151 pass: 149 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:

	total: 301 pass: 285 fail: 16
Failed tests:
	powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs
	powerpc:pseries:pseries_defconfig:initrd
	powerpc:pseries:pseries_defconfig:scsi:rootfs
	powerpc:pseries:pseries_defconfig:mmc:rootfs
	powerpc:pseries:pseries_defconfig:nvme:rootfs
	powerpc:pseries:pseries_defconfig:little:initrd
	powerpc:pseries:pseries_defconfig:little:scsi:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs
	powerpc:pseries:pseries_defconfig:little:mmc:rootfs
	powerpc:pseries:pseries_defconfig:little:nvme:rootfs
	powerpc:powernv:powernv_defconfig:initrd
Quoted 1 line

Details are available at https://kerneltests.org/builders/.

I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of warnings for power that I don't think were caused by these series, I don't know if they have always been there or not.

thanks,

greg k-h

#66 lore raw
Quoted 36 lines · Greg Kroah-Hartman
Quoted 35 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 151 pass: 149 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:

	total: 301 pass: 285 fail: 16
Failed tests:
	powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs
	powerpc:pseries:pseries_defconfig:initrd
	powerpc:pseries:pseries_defconfig:scsi:rootfs
	powerpc:pseries:pseries_defconfig:mmc:rootfs
	powerpc:pseries:pseries_defconfig:nvme:rootfs
	powerpc:pseries:pseries_defconfig:little:initrd
	powerpc:pseries:pseries_defconfig:little:scsi:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs
	powerpc:pseries:pseries_defconfig:little:mmc:rootfs
	powerpc:pseries:pseries_defconfig:little:nvme:rootfs
	powerpc:powernv:powernv_defconfig:initrd
Quoted 6 lines
Quoted 1 line

Details are available at https://kerneltests.org/builders/.

I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of warnings for power that I don't think were caused by these series, I don't know if they have always been there or not.

The warnings in the assembler file have been fixed with commit 8a583c0a8d31 ("powerpc: Fix invalid use of register expressions"). It is not marked for stable, and does not cause actual failures, so I would not bother applying it.

Most of the "may be used uninitialized" warnings are still reported in ToT.

You missed this one in v4.9.y:

arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges':
/opt/buildbot/slave/stable-queue-4.9/build/arch/powerpc/kernel/fadump.c:738:2: error: implicit declaration of function 'kfree'

Other kernels build fine so far. Builds are still ongoing, but the ppc problems are fixed in those.

Guenter

author maintainer
#67 lore raw
Quoted 44 lines · Guenter Roeck
Quoted 36 lines · Greg Kroah-Hartman
Quoted 35 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 151 pass: 149 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:

	total: 301 pass: 285 fail: 16
Failed tests:
	powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs
	powerpc:pseries:pseries_defconfig:initrd
	powerpc:pseries:pseries_defconfig:scsi:rootfs
	powerpc:pseries:pseries_defconfig:mmc:rootfs
	powerpc:pseries:pseries_defconfig:nvme:rootfs
	powerpc:pseries:pseries_defconfig:little:initrd
	powerpc:pseries:pseries_defconfig:little:scsi:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs
	powerpc:pseries:pseries_defconfig:little:mmc:rootfs
	powerpc:pseries:pseries_defconfig:little:nvme:rootfs
	powerpc:powernv:powernv_defconfig:initrd
Quoted 6 lines
Quoted 1 line

Details are available at https://kerneltests.org/builders/.

I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of warnings for power that I don't think were caused by these series, I don't know if they have always been there or not.

Quoted 4 lines

The warnings in the assembler file have been fixed with commit 8a583c0a8d31 ("powerpc: Fix invalid use of register expressions"). It is not marked for stable, and does not cause actual failures, so I would not bother applying it.

Ok, if it's not bothering you, that's fine with me.

thanks for testing all of these and letting me know.

greg k-h

#68 lore raw
In reply to Greg Kroah-Hartman
Quoted 36 lines · Greg Kroah-Hartman
Quoted 35 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 151 pass: 149 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:

	total: 301 pass: 285 fail: 16
Failed tests:
	powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs
	powerpc:pseries:pseries_defconfig:initrd
	powerpc:pseries:pseries_defconfig:scsi:rootfs
	powerpc:pseries:pseries_defconfig:mmc:rootfs
	powerpc:pseries:pseries_defconfig:nvme:rootfs
	powerpc:pseries:pseries_defconfig:little:initrd
	powerpc:pseries:pseries_defconfig:little:scsi:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs
	powerpc:pseries:pseries_defconfig:little:mmc:rootfs
	powerpc:pseries:pseries_defconfig:little:nvme:rootfs
	powerpc:powernv:powernv_defconfig:initrd
Quoted 6 lines
Quoted 1 line

Details are available at https://kerneltests.org/builders/.

I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of warnings for power that I don't think were caused by these series, I don't know if they have always been there or not.

For v4.9.125-65-g0f793f1ec4f3:

Build results:

	total: 151 pass: 150 fail: 1
Failed builds:
	powerpc:allmodconfig
Qemu test results:
	total: 301 pass: 301 fail: 0

arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:738:2: error: implicit declaration of function 'kfree'

arch/powerpc/kernel/fadump.c: In function 'allocate_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:757:14: error: implicit declaration of function 'krealloc'

Guenter

author maintainer
#69 lore raw
Quoted 53 lines · Guenter Roeck
Quoted 36 lines · Greg Kroah-Hartman
Quoted 35 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 151 pass: 149 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:

	total: 301 pass: 285 fail: 16
Failed tests:
	powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs
	powerpc:pseries:pseries_defconfig:initrd
	powerpc:pseries:pseries_defconfig:scsi:rootfs
	powerpc:pseries:pseries_defconfig:mmc:rootfs
	powerpc:pseries:pseries_defconfig:nvme:rootfs
	powerpc:pseries:pseries_defconfig:little:initrd
	powerpc:pseries:pseries_defconfig:little:scsi:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs
	powerpc:pseries:pseries_defconfig:little:mmc:rootfs
	powerpc:pseries:pseries_defconfig:little:nvme:rootfs
	powerpc:powernv:powernv_defconfig:initrd
Quoted 6 lines
Quoted 1 line

Details are available at https://kerneltests.org/builders/.

I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of warnings for power that I don't think were caused by these series, I don't know if they have always been there or not.

For v4.9.125-65-g0f793f1ec4f3:

Build results:

	total: 151 pass: 150 fail: 1
Failed builds:
	powerpc:allmodconfig
Qemu test results:
	total: 301 pass: 301 fail: 0
Quoted 5 lines

arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:738:2: error: implicit declaration of function 'kfree'

arch/powerpc/kernel/fadump.c: In function 'allocate_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:757:14: error: implicit declaration of function 'krealloc'

Oops, forgot to fix that one. Shoould now be resolved.

greg k-h

#70 lore raw
Quoted 54 lines · Greg Kroah-Hartman
Quoted 53 lines · Guenter Roeck
Quoted 36 lines · Greg Kroah-Hartman
Quoted 35 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 151 pass: 149 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:

	total: 301 pass: 285 fail: 16
Failed tests:
	powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs
	powerpc:pseries:pseries_defconfig:initrd
	powerpc:pseries:pseries_defconfig:scsi:rootfs
	powerpc:pseries:pseries_defconfig:mmc:rootfs
	powerpc:pseries:pseries_defconfig:nvme:rootfs
	powerpc:pseries:pseries_defconfig:little:initrd
	powerpc:pseries:pseries_defconfig:little:scsi:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs
	powerpc:pseries:pseries_defconfig:little:mmc:rootfs
	powerpc:pseries:pseries_defconfig:little:nvme:rootfs
	powerpc:powernv:powernv_defconfig:initrd
Quoted 6 lines
Quoted 1 line

Details are available at https://kerneltests.org/builders/.

I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of warnings for power that I don't think were caused by these series, I don't know if they have always been there or not.

For v4.9.125-65-g0f793f1ec4f3:

Build results:

	total: 151 pass: 150 fail: 1
Failed builds:
	powerpc:allmodconfig
Qemu test results:
	total: 301 pass: 301 fail: 0
Quoted 8 lines
Quoted 5 lines

arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:738:2: error: implicit declaration of function 'kfree'

arch/powerpc/kernel/fadump.c: In function 'allocate_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:757:14: error: implicit declaration of function 'krealloc'

Oops, forgot to fix that one. Shoould now be resolved.

Did you push your change ? My builders didn't pick it up.

Guenter

author maintainer
#71 lore raw
Quoted 58 lines · Guenter Roeck
Quoted 57 lines · Greg Kroah-Hartman
Quoted 56 lines · Guenter Roeck
Quoted 36 lines · Greg Kroah-Hartman
Quoted 35 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 151 pass: 149 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:

	total: 301 pass: 285 fail: 16
Failed tests:
	powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs
	powerpc:pseries:pseries_defconfig:initrd
	powerpc:pseries:pseries_defconfig:scsi:rootfs
	powerpc:pseries:pseries_defconfig:mmc:rootfs
	powerpc:pseries:pseries_defconfig:nvme:rootfs
	powerpc:pseries:pseries_defconfig:little:initrd
	powerpc:pseries:pseries_defconfig:little:scsi:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs
	powerpc:pseries:pseries_defconfig:little:mmc:rootfs
	powerpc:pseries:pseries_defconfig:little:nvme:rootfs
	powerpc:powernv:powernv_defconfig:initrd
Quoted 6 lines
Quoted 1 line

Details are available at https://kerneltests.org/builders/.

I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of warnings for power that I don't think were caused by these series, I don't know if they have always been there or not.

For v4.9.125-65-g0f793f1ec4f3:

Build results:

	total: 151 pass: 150 fail: 1
Failed builds:
	powerpc:allmodconfig
Qemu test results:
	total: 301 pass: 301 fail: 0

arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:738:2: error: implicit declaration of function 'kfree'

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

arch/powerpc/kernel/fadump.c: In function 'allocate_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:757:14: error: implicit declaration of function 'krealloc'

Oops, forgot to fix that one. Shoould now be resolved.

Did you push your change ? My builders didn't pick it up.

Yes, I pushed out the "real" 4.9.125 release with the fix in it.

thanks,

greg k-h

#72 lore raw
Quoted 62 lines · Greg Kroah-Hartman
Quoted 61 lines · Guenter Roeck
Quoted 60 lines · Greg Kroah-Hartman
Quoted 58 lines · Guenter Roeck
Quoted 36 lines · Greg Kroah-Hartman
Quoted 35 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 151 pass: 149 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:

	total: 301 pass: 285 fail: 16
Failed tests:
	powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs
	powerpc:pseries:pseries_defconfig:initrd
	powerpc:pseries:pseries_defconfig:scsi:rootfs
	powerpc:pseries:pseries_defconfig:mmc:rootfs
	powerpc:pseries:pseries_defconfig:nvme:rootfs
	powerpc:pseries:pseries_defconfig:little:initrd
	powerpc:pseries:pseries_defconfig:little:scsi:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs
	powerpc:pseries:pseries_defconfig:little:mmc:rootfs
	powerpc:pseries:pseries_defconfig:little:nvme:rootfs
	powerpc:powernv:powernv_defconfig:initrd
Quoted 6 lines
Quoted 1 line

Details are available at https://kerneltests.org/builders/.

I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of warnings for power that I don't think were caused by these series, I don't know if they have always been there or not.

For v4.9.125-65-g0f793f1ec4f3:

Build results:

	total: 151 pass: 150 fail: 1
Failed builds:
	powerpc:allmodconfig
Qemu test results:
	total: 301 pass: 301 fail: 0

arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:738:2: error: implicit declaration of function 'kfree'

arch/powerpc/kernel/fadump.c: In function 'allocate_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:757:14: error: implicit declaration of function 'krealloc'

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Oops, forgot to fix that one. Shoould now be resolved.

Did you push your change ? My builders didn't pick it up.

Yes, I pushed out the "real" 4.9.125 release with the fix in it.

You mean 4.9.126. But you didn't push the update to linux-stable-rc, which is why my builders don't see it.

Guenter

author maintainer
#73 lore raw
Quoted 66 lines · Guenter Roeck
Quoted 65 lines · Greg Kroah-Hartman
Quoted 64 lines · Guenter Roeck
Quoted 62 lines · Greg Kroah-Hartman
Quoted 53 lines · Guenter Roeck
Quoted 36 lines · Greg Kroah-Hartman
Quoted 35 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 151 pass: 149 fail: 2

Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:

	total: 301 pass: 285 fail: 16
Failed tests:
	powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs
	powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs
	powerpc:pseries:pseries_defconfig:initrd
	powerpc:pseries:pseries_defconfig:scsi:rootfs
	powerpc:pseries:pseries_defconfig:mmc:rootfs
	powerpc:pseries:pseries_defconfig:nvme:rootfs
	powerpc:pseries:pseries_defconfig:little:initrd
	powerpc:pseries:pseries_defconfig:little:scsi:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs
	powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs
	powerpc:pseries:pseries_defconfig:little:mmc:rootfs
	powerpc:pseries:pseries_defconfig:little:nvme:rootfs
	powerpc:powernv:powernv_defconfig:initrd
Quoted 6 lines
Quoted 1 line

Details are available at https://kerneltests.org/builders/.

I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of warnings for power that I don't think were caused by these series, I don't know if they have always been there or not.

For v4.9.125-65-g0f793f1ec4f3:

Build results:

	total: 151 pass: 150 fail: 1
Failed builds:
	powerpc:allmodconfig
Qemu test results:
	total: 301 pass: 301 fail: 0
Quoted 5 lines

arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:738:2: error: implicit declaration of function 'kfree'

arch/powerpc/kernel/fadump.c: In function 'allocate_crash_memory_ranges':
arch/powerpc/kernel/fadump.c:757:14: error: implicit declaration of function 'krealloc'

Oops, forgot to fix that one. Shoould now be resolved.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

Did you push your change ? My builders didn't pick it up.

Yes, I pushed out the "real" 4.9.125 release with the fix in it.

You mean 4.9.126. But you didn't push the update to linux-stable-rc, which is why my builders don't see it.

Ugh, you are right, now updated, sorry for the confusion.

greg k-h

#74 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.126-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.9.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.9.126-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 189fbc4d1993bdac9e743e81f3907d6f16cc1f1b
git describe: v4.9.124-172-g189fbc4d1993
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.124-172-g189fbc4d1993

No regressions (compared to build v4.9.124-108-g31b3687b22c5)

Boards, architectures and test suites:
-------------------------------------

dragonboard-410c - arm64
* boot - pass: 21,
* kselftest - pass: 47, skip: 50, fail: 11
* libhugetlbfs - pass: 89, skip: 1, fail: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 80, skip: 1,
* ltp-cve-tests - pass: 26, skip: 9,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60, skip: 6,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1012, skip: 137,
* ltp-timers-tests - pass: 13,

hi6220-hikey - arm64
* boot - pass: 21,
* kselftest - pass: 48, skip: 44, fail: 11
* libhugetlbfs - pass: 89, skip: 1, fail: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 80, skip: 1,
* ltp-cve-tests - pass: 27, skip: 8,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60, skip: 6,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1011, skip: 138,
* ltp-timers-tests - pass: 13,

i386
* boot - pass: 22,
* kselftest - pass: 71, skip: 45, fail: 14
* libhugetlbfs - pass: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 79, skip: 1,
* ltp-cve-tests - pass: 27, skip: 4, fail: 3
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60, skip: 6,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 1,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 8,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-open-posix-tests - pass: 1682, skip: 46, fail: 5
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1085, skip: 59, fail: 2
* ltp-timers-tests - pass: 13,

juno-r2 - arm64
* boot - pass: 22,
* kselftest - pass: 51, skip: 46, fail: 12
* libhugetlbfs - pass: 89, skip: 1, fail: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 80, skip: 1,
* ltp-cve-tests - pass: 26, skip: 9,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60, skip: 6,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-open-posix-tests - pass: 1689, skip: 41, fail: 5
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1012, skip: 137,
* ltp-timers-tests - pass: 13,

qemu_arm
* boot - pass: 21,
* kselftest - pass: 48, skip: 53, fail: 7
* libhugetlbfs - pass: 86, skip: 1, fail: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 79, skip: 2,
* ltp-cve-tests - pass: 23, skip: 12,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 5,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 8, skip: 6,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1050, skip: 99,
* ltp-timers-tests - pass: 13,

qemu_arm64
* boot - pass: 21,
* kselftest - pass: 49, skip: 51, fail: 11
* libhugetlbfs - pass: 89, skip: 1, fail: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 80, skip: 1,
* ltp-cve-tests - pass: 25, skip: 10,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60, skip: 6,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 8, skip: 6,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 988, skip: 161,
* ltp-timers-tests - pass: 13,

qemu_i386
* boot - pass: 21,
* kselftest - pass: 70, skip: 47, fail: 14
* libhugetlbfs - pass: 86, skip: 1, fail: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 80, skip: 1,
* ltp-cve-tests - pass: 29, skip: 4, fail: 2
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60, skip: 6,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1058, skip: 91,
* ltp-timers-tests - pass: 13,

qemu_x86_64
* boot - pass: 21,
* kselftest - pass: 64, skip: 53, fail: 9
* libhugetlbfs - pass: 89, skip: 1, fail: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 80, skip: 1,
* ltp-cve-tests - pass: 30, skip: 5,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60, skip: 6,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 994, skip: 155,
* ltp-timers-tests - pass: 13,

x15 - arm
* boot - pass: 22,
* kselftest - pass: 50, skip: 48, fail: 8
* libhugetlbfs - pass: 86, skip: 1, fail: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 79, skip: 2,
* ltp-cve-tests - pass: 25, skip: 10,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 5,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-open-posix-tests - pass: 1690, skip: 40, fail: 5
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1071, skip: 78,
* ltp-timers-tests - pass: 13,

x86_64
* boot - pass: 24,
* kselftest - pass: 66, skip: 48, fail: 9
* kselftest-vsyscall-mode-native - pass: 64, skip: 48, fail: 10
* kselftest-vsyscall-mode-none - pass: 65, skip: 48, fail: 9
* libhugetlbfs - pass: 89, skip: 1, fail: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 80, skip: 1,
* ltp-cve-tests - pass: 30, skip: 5,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 5,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-open-posix-tests - pass: 1686, skip: 44, fail: 5
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 118,
* ltp-timers-tests - pass: 13,

Signature · 2 lines
Linaro QA (BETA)
https://qa-reports.linaro.org
#75 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.126-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.9.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah