[PATCH 4.19 00/54] 4.19.115-rc1 review

[PATCH 4.19 00/54] 4.19.115-rc1 review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 4.19.115 release.
There are 54 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 Mon, 13 Apr 2020 11:51:28 +0000.
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.19.115-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.19.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 4.19.115-rc1

Hans Verkuil <hans.verkuil@cisco.com>
    drm_dp_mst_topology: fix broken drm_dp_sideband_parse_remote_dpcd_read()

Roger Quadros <rogerq@ti.com>
    usb: dwc3: don't set gadget->is_otg flag

Chris Lew <clew@codeaurora.org>
    rpmsg: glink: Remove chunk size word align warning

Arun KS <arunks@codeaurora.org>
    arm64: Fix size of __early_cpu_boot_status

Rob Clark <robdclark@chromium.org>
    drm/msm: stop abusing dma_map/unmap for cache

Taniya Das <tdas@codeaurora.org>
    clk: qcom: rcg: Return failure for RCG update

Qiujun Huang <hqjagain@gmail.com>
    fbcon: fix null-ptr-deref in fbcon_switch

Avihai Horon <avihaih@mellanox.com>
    RDMA/cm: Update num_paths in cma_resolve_iboe_route error flow

Qiujun Huang <hqjagain@gmail.com>
    Bluetooth: RFCOMM: fix ODEBUG bug in rfcomm_dev_ioctl

Jason Gunthorpe <jgg@ziepe.ca>
    RDMA/cma: Teach lockdep about the order of rtnl and lock

Jason Gunthorpe <jgg@ziepe.ca>
    RDMA/ucma: Put a lock around every call to the rdma_cm layer

Ilya Dryomov <idryomov@gmail.com>
    ceph: canonicalize server path in place

Xiubo Li <xiubli@redhat.com>
    ceph: remove the extra slashes in the server path

Kaike Wan <kaike.wan@intel.com>
    IB/hfi1: Fix memory leaks in sysfs registration and unregistration

Kaike Wan <kaike.wan@intel.com>
    IB/hfi1: Call kobject_put() when kobject_init_and_add() fails

Paul Cercueil <paul@crapouillou.net>
    ASoC: jz4740-i2s: Fix divider written at incorrect offset in register

Martin Kaiser <martin@kaiser.cx>
    hwrng: imx-rngc - fix an error path

David Ahern <dsahern@kernel.org>
    tools/accounting/getdelays.c: fix netlink attribute length

Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    usb: dwc3: gadget: Wrap around when skip TRBs

Jason A. Donenfeld <Jason@zx2c4.com>
    random: always use batched entropy for get_random_u{32,64}

Petr Machata <petrm@mellanox.com>
    mlxsw: spectrum_flower: Do not stop at FLOW_ACTION_VLAN_MANGLE

Richard Palethorpe <rpalethorpe@suse.com>
    slcan: Don't transmit uninitialized stack data in padding

Jisheng Zhang <Jisheng.Zhang@synaptics.com>
    net: stmmac: dwmac1000: fix out-of-bounds mac address reg setting

Oleksij Rempel <o.rempel@pengutronix.de>
    net: phy: micrel: kszphy_resume(): add delay after genphy_resume() before accessing PHY registers

Florian Fainelli <f.fainelli@gmail.com>
    net: dsa: bcm_sf2: Ensure correct sub-node is parsed

Florian Fainelli <f.fainelli@gmail.com>
    net: dsa: bcm_sf2: Do not register slave MDIO bus with OF

Jarod Wilson <jarod@redhat.com>
    ipv6: don't auto-add link-local address to lag ports

Randy Dunlap <rdunlap@infradead.org>
    mm: mempolicy: require at least one nodeid for MPOL_PREFERRED

Sam Protsenko <semen.protsenko@linaro.org>
    include/linux/notifier.h: SRCU: fix ctags

Miklos Szeredi <mszeredi@redhat.com>
    bitops: protect variables in set_mask_bits() macro

Daniel Jordan <daniel.m.jordan@oracle.com>
    padata: always acquire cpu_hotplug_lock before pinst->lock

Amritha Nambiar <amritha.nambiar@intel.com>
    net: Fix Tx hash bound checking

David Howells <dhowells@redhat.com>
    rxrpc: Fix sendmsg(MSG_WAITALL) handling

Geoffrey Allott <geoffrey@allott.email>
    ALSA: hda/ca0132 - Add Recon3Di quirk to handle integrated sound on EVGA X99 Classified motherboard

Hans de Goede <hdegoede@redhat.com>
    power: supply: axp288_charger: Add special handling for HP Pavilion x2 10

Hans de Goede <hdegoede@redhat.com>
    extcon: axp288: Add wakeup support

Alexander Usyskin <alexander.usyskin@intel.com>
    mei: me: add cedar fork device ids

Eugene Syromiatnikov <esyr@redhat.com>
    coresight: do not use the BIT() macro in the UAPI header

Kishon Vijay Abraham I <kishon@ti.com>
    misc: pci_endpoint_test: Avoid using module parameter to determine irqtype

Kishon Vijay Abraham I <kishon@ti.com>
    misc: pci_endpoint_test: Fix to support > 10 pci-endpoint-test devices

YueHaibing <yuehaibing@huawei.com>
    misc: rtsx: set correct pcr_ops for rts522A

Sean Young <sean@mess.org>
    media: rc: IR signal for Panasonic air conditioner too long

Lucas Stach <l.stach@pengutronix.de>
    drm/etnaviv: replace MMU flush marker with flush sequence

Len Brown <len.brown@intel.com>
    tools/power turbostat: Fix missing SYS_LPI counter on some Chromebooks

Len Brown <len.brown@intel.com>
    tools/power turbostat: Fix gcc build warnings

James Zhu <James.Zhu@amd.com>
    drm/amdgpu: fix typo for vcn1 idle check

Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
    initramfs: restore default compression behavior

Gerd Hoffmann <kraxel@redhat.com>
    drm/bochs: downgrade pci_request_region failure from error to warning

Mario Kleiner <mario.kleiner.de@gmail.com>
    drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017

Prabhath Sajeepa <psajeepa@purestorage.com>
    nvme-rdma: Avoid double freeing of async event data

Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    sctp: fix possibly using a bad saddr with a given dst

Qiujun Huang <hqjagain@gmail.com>
    sctp: fix refcount bug in sctp_wfree

William Dauchy <w.dauchy@criteo.com>
    net, ip_tunnel: fix interface lookup with no key

Qian Cai <cai@lca.pw>
    ipv4: fix a RCU-list lock in fib_triestat_seq_show


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

Diffstat:

 Makefile                                           |  4 +-
 arch/arm64/kernel/head.S                           |  2 +-
 drivers/char/hw_random/imx-rngc.c                  |  4 +-
 drivers/char/random.c                              | 20 ++------
 drivers/clk/qcom/clk-rcg2.c                        |  2 +-
 drivers/extcon/extcon-axp288.c                     | 32 ++++++++++++
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c              |  2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   | 11 +++++
 drivers/gpu/drm/bochs/bochs_hw.c                   |  6 +--
 drivers/gpu/drm/drm_dp_mst_topology.c              |  1 +
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c           | 10 ++--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h              |  1 +
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c              |  6 +--
 drivers/gpu/drm/etnaviv/etnaviv_mmu.h              |  2 +-
 drivers/gpu/drm/msm/msm_gem.c                      |  4 +-
 drivers/infiniband/core/cma.c                      | 14 ++++++
 drivers/infiniband/core/ucma.c                     | 49 ++++++++++++++++++-
 drivers/infiniband/hw/hfi1/sysfs.c                 | 26 +++++++---
 drivers/media/rc/lirc_dev.c                        |  2 +-
 drivers/misc/cardreader/rts5227.c                  |  1 +
 drivers/misc/mei/hw-me-regs.h                      |  2 +
 drivers/misc/mei/pci-me.c                          |  2 +
 drivers/misc/pci_endpoint_test.c                   | 14 ++++--
 drivers/net/can/slcan.c                            |  4 +-
 drivers/net/dsa/bcm_sf2.c                          |  9 +++-
 .../net/ethernet/mellanox/mlxsw/spectrum_flower.c  |  8 +--
 .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   |  2 +-
 drivers/net/phy/micrel.c                           |  7 +++
 drivers/nvme/host/rdma.c                           |  8 +--
 drivers/power/supply/axp288_charger.c              | 57 +++++++++++++++++++++-
 drivers/rpmsg/qcom_glink_native.c                  |  3 --
 drivers/usb/dwc3/gadget.c                          |  3 +-
 drivers/video/fbdev/core/fbcon.c                   |  3 ++
 fs/ceph/super.c                                    | 56 +++++++++++++--------
 fs/ceph/super.h                                    |  2 +-
 include/linux/bitops.h                             | 14 +++---
 include/linux/notifier.h                           |  3 +-
 include/uapi/linux/coresight-stm.h                 |  6 ++-
 kernel/padata.c                                    |  4 +-
 mm/mempolicy.c                                     |  6 ++-
 net/bluetooth/rfcomm/tty.c                         |  4 +-
 net/core/dev.c                                     |  2 +
 net/ipv4/fib_trie.c                                |  3 ++
 net/ipv4/ip_tunnel.c                               |  6 +--
 net/ipv6/addrconf.c                                |  4 ++
 net/rxrpc/sendmsg.c                                |  4 +-
 net/sctp/ipv6.c                                    | 20 +++++---
 net/sctp/protocol.c                                | 28 +++++++----
 net/sctp/socket.c                                  | 31 +++++++++---
 sound/pci/hda/patch_ca0132.c                       |  1 +
 sound/soc/jz4740/jz4740-i2s.c                      |  2 +-
 tools/accounting/getdelays.c                       |  2 +-
 tools/power/x86/turbostat/turbostat.c              | 27 +++++-----
 usr/Kconfig                                        | 22 ++++-----
 54 files changed, 409 insertions(+), 159 deletions(-)

[PATCH 4.19 01/54] ipv4: fix a RCU-list lock in fib_triestat_seq_show

[Greg Kroah-Hartman]

From: Qian Cai <cai@lca.pw>

[ Upstream commit fbe4e0c1b298b4665ee6915266c9d6c5b934ef4a ]

fib_triestat_seq_show() calls hlist_for_each_entry_rcu(tb, head,
tb_hlist) without rcu_read_lock() will trigger a warning,

 net/ipv4/fib_trie.c:2579 RCU-list traversed in non-reader section!!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 1 lock held by proc01/115277:
  #0: c0000014507acf00 (&p->lock){+.+.}-{3:3}, at: seq_read+0x58/0x670

 Call Trace:
  dump_stack+0xf4/0x164 (unreliable)
  lockdep_rcu_suspicious+0x140/0x164
  fib_triestat_seq_show+0x750/0x880
  seq_read+0x1a0/0x670
  proc_reg_read+0x10c/0x1b0
  __vfs_read+0x3c/0x70
  vfs_read+0xac/0x170
  ksys_read+0x7c/0x140
  system_call+0x5c/0x68

Fix it by adding a pair of rcu_read_lock/unlock() and use
cond_resched_rcu() to avoid the situation where walking of a large
number of items  may prevent scheduling for a long time.

Signed-off-by: Qian Cai <cai@lca.pw>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv4/fib_trie.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2337,6 +2337,7 @@ static int fib_triestat_seq_show(struct
 		   " %zd bytes, size of tnode: %zd bytes.\n",
 		   LEAF_SIZE, TNODE_SIZE(0));
 
+	rcu_read_lock();
 	for (h = 0; h < FIB_TABLE_HASHSZ; h++) {
 		struct hlist_head *head = &net->ipv4.fib_table_hash[h];
 		struct fib_table *tb;
@@ -2356,7 +2357,9 @@ static int fib_triestat_seq_show(struct
 			trie_show_usage(seq, t->stats);
 #endif
 		}
+		cond_resched_rcu();
 	}
+	rcu_read_unlock();
 
 	return 0;
 }

[PATCH 4.19 02/54] net, ip_tunnel: fix interface lookup with no key

[Greg Kroah-Hartman]

From: William Dauchy <w.dauchy@criteo.com>

[ Upstream commit 25629fdaff2ff509dd0b3f5ff93d70a75e79e0a1 ]

when creating a new ipip interface with no local/remote configuration,
the lookup is done with TUNNEL_NO_KEY flag, making it impossible to
match the new interface (only possible match being fallback or metada
case interface); e.g: `ip link add tunl1 type ipip dev eth0`

To fix this case, adding a flag check before the key comparison so we
permit to match an interface with no local/remote config; it also avoids
breaking possible userland tools relying on TUNNEL_NO_KEY flag and
uninitialised key.

context being on my side, I'm creating an extra ipip interface attached
to the physical one, and moving it to a dedicated namespace.

Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
Signed-off-by: William Dauchy <w.dauchy@criteo.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv4/ip_tunnel.c |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -155,11 +155,8 @@ struct ip_tunnel *ip_tunnel_lookup(struc
 			cand = t;
 	}
 
-	if (flags & TUNNEL_NO_KEY)
-		goto skip_key_lookup;
-
 	hlist_for_each_entry_rcu(t, head, hash_node) {
-		if (t->parms.i_key != key ||
+		if ((!(flags & TUNNEL_NO_KEY) && t->parms.i_key != key) ||
 		    t->parms.iph.saddr != 0 ||
 		    t->parms.iph.daddr != 0 ||
 		    !(t->dev->flags & IFF_UP))
@@ -171,7 +168,6 @@ struct ip_tunnel *ip_tunnel_lookup(struc
 			cand = t;
 	}
 
-skip_key_lookup:
 	if (cand)
 		return cand;
 

[PATCH 4.19 03/54] sctp: fix refcount bug in sctp_wfree

[Greg Kroah-Hartman]

From: Qiujun Huang <hqjagain@gmail.com>

[ Upstream commit 5c3e82fe159622e46e91458c1a6509c321a62820 ]

We should iterate over the datamsgs to move
all chunks(skbs) to newsk.

The following case cause the bug:
for the trouble SKB, it was in outq->transmitted list

sctp_outq_sack
        sctp_check_transmitted
                SKB was moved to outq->sacked list
        then throw away the sack queue
                SKB was deleted from outq->sacked
(but it was held by datamsg at sctp_datamsg_to_asoc
So, sctp_wfree was not called here)

then migrate happened

        sctp_for_each_tx_datachunk(
        sctp_clear_owner_w);
        sctp_assoc_migrate();
        sctp_for_each_tx_datachunk(
        sctp_set_owner_w);
SKB was not in the outq, and was not changed to newsk

finally

__sctp_outq_teardown
        sctp_chunk_put (for another skb)
                sctp_datamsg_put
                        __kfree_skb(msg->frag_list)
                                sctp_wfree (for SKB)
	SKB->sk was still oldsk (skb->sk != asoc->base.sk).

Reported-and-tested-by: syzbot+cea71eec5d6de256d54d@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
Acked-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/sctp/socket.c |   31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -165,29 +165,44 @@ static void sctp_clear_owner_w(struct sc
 	skb_orphan(chunk->skb);
 }
 
+#define traverse_and_process()	\
+do {				\
+	msg = chunk->msg;	\
+	if (msg == prev_msg)	\
+		continue;	\
+	list_for_each_entry(c, &msg->chunks, frag_list) {	\
+		if ((clear && asoc->base.sk == c->skb->sk) ||	\
+		    (!clear && asoc->base.sk != c->skb->sk))	\
+			cb(c);	\
+	}			\
+	prev_msg = msg;		\
+} while (0)
+
 static void sctp_for_each_tx_datachunk(struct sctp_association *asoc,
+				       bool clear,
 				       void (*cb)(struct sctp_chunk *))
 
 {
+	struct sctp_datamsg *msg, *prev_msg = NULL;
 	struct sctp_outq *q = &asoc->outqueue;
+	struct sctp_chunk *chunk, *c;
 	struct sctp_transport *t;
-	struct sctp_chunk *chunk;
 
 	list_for_each_entry(t, &asoc->peer.transport_addr_list, transports)
 		list_for_each_entry(chunk, &t->transmitted, transmitted_list)
-			cb(chunk);
+			traverse_and_process();
 
 	list_for_each_entry(chunk, &q->retransmit, transmitted_list)
-		cb(chunk);
+		traverse_and_process();
 
 	list_for_each_entry(chunk, &q->sacked, transmitted_list)
-		cb(chunk);
+		traverse_and_process();
 
 	list_for_each_entry(chunk, &q->abandoned, transmitted_list)
-		cb(chunk);
+		traverse_and_process();
 
 	list_for_each_entry(chunk, &q->out_chunk_list, list)
-		cb(chunk);
+		traverse_and_process();
 }
 
 static void sctp_for_each_rx_skb(struct sctp_association *asoc, struct sock *sk,
@@ -8899,9 +8914,9 @@ static void sctp_sock_migrate(struct soc
 	 * paths won't try to lock it and then oldsk.
 	 */
 	lock_sock_nested(newsk, SINGLE_DEPTH_NESTING);
-	sctp_for_each_tx_datachunk(assoc, sctp_clear_owner_w);
+	sctp_for_each_tx_datachunk(assoc, true, sctp_clear_owner_w);
 	sctp_assoc_migrate(assoc, newsk);
-	sctp_for_each_tx_datachunk(assoc, sctp_set_owner_w);
+	sctp_for_each_tx_datachunk(assoc, false, sctp_set_owner_w);
 
 	/* If the association on the newsk is already closed before accept()
 	 * is called, set RCV_SHUTDOWN flag.

[PATCH 4.19 04/54] sctp: fix possibly using a bad saddr with a given dst

[Greg Kroah-Hartman]

From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

[ Upstream commit 582eea230536a6f104097dd46205822005d5fe3a ]

Under certain circumstances, depending on the order of addresses on the
interfaces, it could be that sctp_v[46]_get_dst() would return a dst
with a mismatched struct flowi.

For example, if when walking through the bind addresses and the first
one is not a match, it saves the dst as a fallback (added in
410f03831c07), but not the flowi. Then if the next one is also not a
match, the previous dst will be returned but with the flowi information
for the 2nd address, which is wrong.

The fix is to use a locally stored flowi that can be used for such
attempts, and copy it to the parameter only in case it is a possible
match, together with the corresponding dst entry.

The patch updates IPv6 code mostly just to be in sync. Even though the issue
is also present there, it fallback is not expected to work with IPv6.

Fixes: 410f03831c07 ("sctp: add routing output fallback")
Reported-by: Jin Meng <meng.a.jin@nokia-sbell.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Tested-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/sctp/ipv6.c     |   20 ++++++++++++++------
 net/sctp/protocol.c |   28 +++++++++++++++++++---------
 2 files changed, 33 insertions(+), 15 deletions(-)

--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -240,7 +240,8 @@ static void sctp_v6_get_dst(struct sctp_
 {
 	struct sctp_association *asoc = t->asoc;
 	struct dst_entry *dst = NULL;
-	struct flowi6 *fl6 = &fl->u.ip6;
+	struct flowi _fl;
+	struct flowi6 *fl6 = &_fl.u.ip6;
 	struct sctp_bind_addr *bp;
 	struct ipv6_pinfo *np = inet6_sk(sk);
 	struct sctp_sockaddr_entry *laddr;
@@ -250,7 +251,7 @@ static void sctp_v6_get_dst(struct sctp_
 	enum sctp_scope scope;
 	__u8 matchlen = 0;
 
-	memset(fl6, 0, sizeof(struct flowi6));
+	memset(&_fl, 0, sizeof(_fl));
 	fl6->daddr = daddr->v6.sin6_addr;
 	fl6->fl6_dport = daddr->v6.sin6_port;
 	fl6->flowi6_proto = IPPROTO_SCTP;
@@ -288,8 +289,11 @@ static void sctp_v6_get_dst(struct sctp_
 	rcu_read_unlock();
 
 	dst = ip6_dst_lookup_flow(sk, fl6, final_p);
-	if (!asoc || saddr)
+	if (!asoc || saddr) {
+		t->dst = dst;
+		memcpy(fl, &_fl, sizeof(_fl));
 		goto out;
+	}
 
 	bp = &asoc->base.bind_addr;
 	scope = sctp_scope(daddr);
@@ -312,6 +316,8 @@ static void sctp_v6_get_dst(struct sctp_
 			if ((laddr->a.sa.sa_family == AF_INET6) &&
 			    (sctp_v6_cmp_addr(&dst_saddr, &laddr->a))) {
 				rcu_read_unlock();
+				t->dst = dst;
+				memcpy(fl, &_fl, sizeof(_fl));
 				goto out;
 			}
 		}
@@ -350,6 +356,8 @@ static void sctp_v6_get_dst(struct sctp_
 			if (!IS_ERR_OR_NULL(dst))
 				dst_release(dst);
 			dst = bdst;
+			t->dst = dst;
+			memcpy(fl, &_fl, sizeof(_fl));
 			break;
 		}
 
@@ -363,6 +371,8 @@ static void sctp_v6_get_dst(struct sctp_
 			dst_release(dst);
 		dst = bdst;
 		matchlen = bmatchlen;
+		t->dst = dst;
+		memcpy(fl, &_fl, sizeof(_fl));
 	}
 	rcu_read_unlock();
 
@@ -371,14 +381,12 @@ out:
 		struct rt6_info *rt;
 
 		rt = (struct rt6_info *)dst;
-		t->dst = dst;
 		t->dst_cookie = rt6_get_cookie(rt);
 		pr_debug("rt6_dst:%pI6/%d rt6_src:%pI6\n",
 			 &rt->rt6i_dst.addr, rt->rt6i_dst.plen,
-			 &fl6->saddr);
+			 &fl->u.ip6.saddr);
 	} else {
 		t->dst = NULL;
-
 		pr_debug("no route\n");
 	}
 }
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -424,7 +424,8 @@ static void sctp_v4_get_dst(struct sctp_
 {
 	struct sctp_association *asoc = t->asoc;
 	struct rtable *rt;
-	struct flowi4 *fl4 = &fl->u.ip4;
+	struct flowi _fl;
+	struct flowi4 *fl4 = &_fl.u.ip4;
 	struct sctp_bind_addr *bp;
 	struct sctp_sockaddr_entry *laddr;
 	struct dst_entry *dst = NULL;
@@ -434,7 +435,7 @@ static void sctp_v4_get_dst(struct sctp_
 
 	if (t->dscp & SCTP_DSCP_SET_MASK)
 		tos = t->dscp & SCTP_DSCP_VAL_MASK;
-	memset(fl4, 0x0, sizeof(struct flowi4));
+	memset(&_fl, 0x0, sizeof(_fl));
 	fl4->daddr  = daddr->v4.sin_addr.s_addr;
 	fl4->fl4_dport = daddr->v4.sin_port;
 	fl4->flowi4_proto = IPPROTO_SCTP;
@@ -453,8 +454,11 @@ static void sctp_v4_get_dst(struct sctp_
 		 &fl4->saddr);
 
 	rt = ip_route_output_key(sock_net(sk), fl4);
-	if (!IS_ERR(rt))
+	if (!IS_ERR(rt)) {
 		dst = &rt->dst;
+		t->dst = dst;
+		memcpy(fl, &_fl, sizeof(_fl));
+	}
 
 	/* If there is no association or if a source address is passed, no
 	 * more validation is required.
@@ -517,27 +521,33 @@ static void sctp_v4_get_dst(struct sctp_
 		odev = __ip_dev_find(sock_net(sk), laddr->a.v4.sin_addr.s_addr,
 				     false);
 		if (!odev || odev->ifindex != fl4->flowi4_oif) {
-			if (!dst)
+			if (!dst) {
 				dst = &rt->dst;
-			else
+				t->dst = dst;
+				memcpy(fl, &_fl, sizeof(_fl));
+			} else {
 				dst_release(&rt->dst);
+			}
 			continue;
 		}
 
 		dst_release(dst);
 		dst = &rt->dst;
+		t->dst = dst;
+		memcpy(fl, &_fl, sizeof(_fl));
 		break;
 	}
 
 out_unlock:
 	rcu_read_unlock();
 out:
-	t->dst = dst;
-	if (dst)
+	if (dst) {
 		pr_debug("rt_dst:%pI4, rt_src:%pI4\n",
-			 &fl4->daddr, &fl4->saddr);
-	else
+			 &fl->u.ip4.daddr, &fl->u.ip4.saddr);
+	} else {
+		t->dst = NULL;
 		pr_debug("no route\n");
+	}
 }
 
 /* For v4, the source address is cached in the route entry(dst). So no need

[PATCH 4.19 05/54] nvme-rdma: Avoid double freeing of async event data

[Greg Kroah-Hartman]

From: Prabhath Sajeepa <psajeepa@purestorage.com>

[ Upstream commit 9134ae2a2546cb96abddcd4469a79c77ee3a4480 ]

The timeout of identify cmd, which is invoked as part of admin queue
creation, can result in freeing of async event data both in
nvme_rdma_timeout handler and error handling path of
nvme_rdma_configure_admin queue thus causing NULL pointer reference.
Call Trace:
 ? nvme_rdma_setup_ctrl+0x223/0x800 [nvme_rdma]
 nvme_rdma_create_ctrl+0x2ba/0x3f7 [nvme_rdma]
 nvmf_dev_write+0xa54/0xcc6 [nvme_fabrics]
 __vfs_write+0x1b/0x40
 vfs_write+0xb2/0x1b0
 ksys_write+0x61/0xd0
 __x64_sys_write+0x1a/0x20
 do_syscall_64+0x60/0x1e0
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Reviewed-by: Roland Dreier <roland@purestorage.com>
Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Prabhath Sajeepa <psajeepa@purestorage.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/nvme/host/rdma.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index e4f167e35353f..9711bfbdf4316 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -815,9 +815,11 @@ out_free_tagset:
 	if (new)
 		nvme_rdma_free_tagset(&ctrl->ctrl, ctrl->ctrl.admin_tagset);
 out_free_async_qe:
-	nvme_rdma_free_qe(ctrl->device->dev, &ctrl->async_event_sqe,
-		sizeof(struct nvme_command), DMA_TO_DEVICE);
-	ctrl->async_event_sqe.data = NULL;
+	if (ctrl->async_event_sqe.data) {
+		nvme_rdma_free_qe(ctrl->device->dev, &ctrl->async_event_sqe,
+			sizeof(struct nvme_command), DMA_TO_DEVICE);
+		ctrl->async_event_sqe.data = NULL;
+	}
 out_free_queue:
 	nvme_rdma_free_queue(&ctrl->queues[0]);
 	return error;
-- 
2.20.1

[PATCH 4.19 06/54] drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017

[Greg Kroah-Hartman]

From: Mario Kleiner <mario.kleiner.de@gmail.com>

[ Upstream commit dec9de2ada523b344eb2428abfedf9d6cd0a0029 ]

This fixes a problem found on the MacBookPro 2017 Retina panel:

The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2
aka 0xc), but the DP_MAX_LINK_RATE dpcd register only reports
2.7 Gbps (multiplier value 0xa) as possible, in direct
contradiction of what the firmware successfully set up.

This restricts the panel to 8 bpc, not providing the full
color depth of the panel on Linux <= 5.5. Additionally, commit
'4a8ca46bae8a ("drm/amd/display: Default max bpc to 16 for eDP")'
introduced into Linux 5.6-rc1 will unclamp panel depth to
its full 10 bpc, thereby requiring a eDP bandwidth for all
modes that exceeds the bandwidth available and causes all modes
to fail validation -> No modes for the laptop panel -> failure
to set any mode -> Panel goes dark.

This patch adds a quirk specific to the MBP 2017 15" Retina
panel to override reported max link rate to the correct maximum
of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display
precision.

Please apply for Linux 5.6+ to avoid regressing Apple MBP panel
support.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 122249da03ab7..a4928854a3de5 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -2440,6 +2440,17 @@ static bool retrieve_link_cap(struct dc_link *link)
 		sink_id.ieee_device_id,
 		sizeof(sink_id.ieee_device_id));
 
+	/* Quirk Apple MBP 2017 15" Retina panel: Wrong DP_MAX_LINK_RATE */
+	{
+		uint8_t str_mbp_2017[] = { 101, 68, 21, 101, 98, 97 };
+
+		if ((link->dpcd_caps.sink_dev_id == 0x0010fa) &&
+		    !memcmp(link->dpcd_caps.sink_dev_id_str, str_mbp_2017,
+			    sizeof(str_mbp_2017))) {
+			link->reported_link_cap.link_rate = 0x0c;
+		}
+	}
+
 	core_link_read_dpcd(
 		link,
 		DP_SINK_HW_REVISION_START,
-- 
2.20.1

[PATCH 4.19 07/54] drm/bochs: downgrade pci_request_region failure from error to warning

[Greg Kroah-Hartman]

From: Gerd Hoffmann <kraxel@redhat.com>

[ Upstream commit 8c34cd1a7f089dc03933289c5d4a4d1489549828 ]

Shutdown of firmware framebuffer has a bunch of problems.  Because
of this the framebuffer region might still be reserved even after
drm_fb_helper_remove_conflicting_pci_framebuffers() returned.

Don't consider pci_request_region() failure for the framebuffer
region as fatal error to workaround this issue.

Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kraxel@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/bochs/bochs_hw.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index a39b0343c197d..401c218567af9 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -97,10 +97,8 @@ int bochs_hw_init(struct drm_device *dev, uint32_t flags)
 		size = min(size, mem);
 	}
 
-	if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
-		DRM_ERROR("Cannot request framebuffer\n");
-		return -EBUSY;
-	}
+	if (pci_request_region(pdev, 0, "bochs-drm") != 0)
+		DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
 
 	bochs->fb_map = ioremap(addr, size);
 	if (bochs->fb_map == NULL) {
-- 
2.20.1

[PATCH 4.19 08/54] initramfs: restore default compression behavior

[Greg Kroah-Hartman]

From: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>

[ Upstream commit 785d74ec3bbf26ac7f6e92e6e96a259aec0f107a ]

Even though INITRAMFS_SOURCE kconfig option isn't set in most of
defconfigs it is used (set) extensively by various build systems.
Commit f26661e12765 ("initramfs: make initramfs compression choice
non-optional") has changed default compression mode. Previously we
compress initramfs using available compression algorithm. Now
we don't use any compression at all by default.
It significantly increases the image size in case of build system
chooses embedded initramfs. Initially I faced with this issue while
using buildroot.

As of today it's not possible to set preferred compression mode
in target defconfig as this option depends on INITRAMFS_SOURCE
being set. Modification of all build systems either doesn't look
like good option.

Let's instead rewrite initramfs compression mode choices list
the way that "INITRAMFS_COMPRESSION_NONE" will be the last option
in the list. In that case it will be chosen only if all other
options (which implements any compression) are not available.

Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 usr/Kconfig | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/usr/Kconfig b/usr/Kconfig
index 43658b8a975e5..8b4826de1189f 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -131,17 +131,6 @@ choice
 
 	  If in doubt, select 'None'
 
-config INITRAMFS_COMPRESSION_NONE
-	bool "None"
-	help
-	  Do not compress the built-in initramfs at all. This may sound wasteful
-	  in space, but, you should be aware that the built-in initramfs will be
-	  compressed at a later stage anyways along with the rest of the kernel,
-	  on those architectures that support this. However, not compressing the
-	  initramfs may lead to slightly higher memory consumption during a
-	  short time at boot, while both the cpio image and the unpacked
-	  filesystem image will be present in memory simultaneously
-
 config INITRAMFS_COMPRESSION_GZIP
 	bool "Gzip"
 	depends on RD_GZIP
@@ -214,6 +203,17 @@ config INITRAMFS_COMPRESSION_LZ4
 	  If you choose this, keep in mind that most distros don't provide lz4
 	  by default which could cause a build failure.
 
+config INITRAMFS_COMPRESSION_NONE
+	bool "None"
+	help
+	  Do not compress the built-in initramfs at all. This may sound wasteful
+	  in space, but, you should be aware that the built-in initramfs will be
+	  compressed at a later stage anyways along with the rest of the kernel,
+	  on those architectures that support this. However, not compressing the
+	  initramfs may lead to slightly higher memory consumption during a
+	  short time at boot, while both the cpio image and the unpacked
+	  filesystem image will be present in memory simultaneously
+
 endchoice
 
 config INITRAMFS_COMPRESSION
-- 
2.20.1

[PATCH 4.19 09/54] drm/amdgpu: fix typo for vcn1 idle check

[Greg Kroah-Hartman]

From: James Zhu <James.Zhu@amd.com>

[ Upstream commit acfc62dc68770aa665cc606891f6df7d6d1e52c0 ]

fix typo for vcn1 idle check

Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index 4f8f3bb218320..a54f8943ffa34 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -857,7 +857,7 @@ static int vcn_v1_0_set_clockgating_state(void *handle,
 
 	if (enable) {
 		/* wait for STATUS to clear */
-		if (vcn_v1_0_is_idle(handle))
+		if (!vcn_v1_0_is_idle(handle))
 			return -EBUSY;
 		vcn_v1_0_enable_clock_gating(adev);
 	} else {
-- 
2.20.1

[PATCH 4.19 10/54] tools/power turbostat: Fix gcc build warnings

[Greg Kroah-Hartman]

From: Len Brown <len.brown@intel.com>

[ Upstream commit d8d005ba6afa502ca37ced5782f672c4d2fc1515 ]

Warning: ‘__builtin_strncpy’ specified bound 20 equals destination size
	[-Wstringop-truncation]

reduce param to strncpy, to guarantee that a null byte is always copied
into destination buffer.

Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 tools/power/x86/turbostat/turbostat.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c
index 02d123871ef95..fb665fdc722a4 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -5144,9 +5144,9 @@ int add_counter(unsigned int msr_num, char *path, char *name,
 	}
 
 	msrp->msr_num = msr_num;
-	strncpy(msrp->name, name, NAME_BYTES);
+	strncpy(msrp->name, name, NAME_BYTES - 1);
 	if (path)
-		strncpy(msrp->path, path, PATH_BYTES);
+		strncpy(msrp->path, path, PATH_BYTES - 1);
 	msrp->width = width;
 	msrp->type = type;
 	msrp->format = format;
-- 
2.20.1

[PATCH 4.19 11/54] tools/power turbostat: Fix missing SYS_LPI counter on some Chromebooks

[Greg Kroah-Hartman]

From: Len Brown <len.brown@intel.com>

[ Upstream commit 1f81c5efc020314b2db30d77efe228b7e117750d ]

Some Chromebook BIOS' do not export an ACPI LPIT, which is how
Linux finds the residency counter for CPU and SYSTEM low power states,
that is exports in /sys/devices/system/cpu/cpuidle/*residency_us

When these sysfs attributes are missing, check the debugfs attrubte
from the pmc_core driver, which accesses the same counter value.

Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 tools/power/x86/turbostat/turbostat.c |   23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -299,6 +299,10 @@ int *irqs_per_cpu;		/* indexed by cpu_nu
 
 void setup_all_buffers(void);
 
+char *sys_lpi_file;
+char *sys_lpi_file_sysfs = "/sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us";
+char *sys_lpi_file_debugfs = "/sys/kernel/debug/pmc_core/slp_s0_residency_usec";
+
 int cpu_is_not_present(int cpu)
 {
 	return !CPU_ISSET_S(cpu, cpu_present_setsize, cpu_present_set);
@@ -2844,8 +2848,6 @@ int snapshot_gfx_mhz(void)
  *
  * record snapshot of
  * /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
- *
- * return 1 if config change requires a restart, else return 0
  */
 int snapshot_cpu_lpi_us(void)
 {
@@ -2865,17 +2867,14 @@ int snapshot_cpu_lpi_us(void)
 /*
  * snapshot_sys_lpi()
  *
- * record snapshot of
- * /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
- *
- * return 1 if config change requires a restart, else return 0
+ * record snapshot of sys_lpi_file
  */
 int snapshot_sys_lpi_us(void)
 {
 	FILE *fp;
 	int retval;
 
-	fp = fopen_or_die("/sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us", "r");
+	fp = fopen_or_die(sys_lpi_file, "r");
 
 	retval = fscanf(fp, "%lld", &cpuidle_cur_sys_lpi_us);
 	if (retval != 1)
@@ -4743,10 +4742,16 @@ void process_cpuid()
 	else
 		BIC_NOT_PRESENT(BIC_CPU_LPI);
 
-	if (!access("/sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us", R_OK))
+	if (!access(sys_lpi_file_sysfs, R_OK)) {
+		sys_lpi_file = sys_lpi_file_sysfs;
 		BIC_PRESENT(BIC_SYS_LPI);
-	else
+	} else if (!access(sys_lpi_file_debugfs, R_OK)) {
+		sys_lpi_file = sys_lpi_file_debugfs;
+		BIC_PRESENT(BIC_SYS_LPI);
+	} else {
+		sys_lpi_file_sysfs = NULL;
 		BIC_NOT_PRESENT(BIC_SYS_LPI);
+	}
 
 	if (!quiet)
 		decode_misc_feature_control();

[PATCH 4.19 12/54] drm/etnaviv: replace MMU flush marker with flush sequence

[Greg Kroah-Hartman]

From: Lucas Stach <l.stach@pengutronix.de>

commit 4900dda90af2cb13bc1d4c12ce94b98acc8fe64e upstream.

If a MMU is shared between multiple GPUs, all of them need to flush their
TLBs, so a single marker that gets reset on the first flush won't do.
Replace the flush marker with a sequence number, so that it's possible to
check if the TLB is in sync with the current page table state for each GPU.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c |   10 ++++++----
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h    |    1 +
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c    |    6 +++---
 drivers/gpu/drm/etnaviv/etnaviv_mmu.h    |    2 +-
 4 files changed, 11 insertions(+), 8 deletions(-)

--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -311,6 +311,8 @@ void etnaviv_buffer_queue(struct etnaviv
 	u32 return_target, return_dwords;
 	u32 link_target, link_dwords;
 	bool switch_context = gpu->exec_state != exec_state;
+	unsigned int new_flush_seq = READ_ONCE(gpu->mmu->flush_seq);
+	bool need_flush = gpu->flush_seq != new_flush_seq;
 
 	lockdep_assert_held(&gpu->lock);
 
@@ -325,14 +327,14 @@ void etnaviv_buffer_queue(struct etnaviv
 	 * need to append a mmu flush load state, followed by a new
 	 * link to this buffer - a total of four additional words.
 	 */
-	if (gpu->mmu->need_flush || switch_context) {
+	if (need_flush || switch_context) {
 		u32 target, extra_dwords;
 
 		/* link command */
 		extra_dwords = 1;
 
 		/* flush command */
-		if (gpu->mmu->need_flush) {
+		if (need_flush) {
 			if (gpu->mmu->version == ETNAVIV_IOMMU_V1)
 				extra_dwords += 1;
 			else
@@ -345,7 +347,7 @@ void etnaviv_buffer_queue(struct etnaviv
 
 		target = etnaviv_buffer_reserve(gpu, buffer, extra_dwords);
 
-		if (gpu->mmu->need_flush) {
+		if (need_flush) {
 			/* Add the MMU flush */
 			if (gpu->mmu->version == ETNAVIV_IOMMU_V1) {
 				CMD_LOAD_STATE(buffer, VIVS_GL_FLUSH_MMU,
@@ -365,7 +367,7 @@ void etnaviv_buffer_queue(struct etnaviv
 					SYNC_RECIPIENT_PE);
 			}
 
-			gpu->mmu->need_flush = false;
+			gpu->flush_seq = new_flush_seq;
 		}
 
 		if (switch_context) {
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -139,6 +139,7 @@ struct etnaviv_gpu {
 
 	struct etnaviv_iommu *mmu;
 	struct etnaviv_cmdbuf_suballoc *cmdbuf_suballoc;
+	unsigned int flush_seq;
 
 	/* Power Control: */
 	struct clk *clk_bus;
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -261,7 +261,7 @@ int etnaviv_iommu_map_gem(struct etnaviv
 	}
 
 	list_add_tail(&mapping->mmu_node, &mmu->mappings);
-	mmu->need_flush = true;
+	mmu->flush_seq++;
 unlock:
 	mutex_unlock(&mmu->lock);
 
@@ -280,7 +280,7 @@ void etnaviv_iommu_unmap_gem(struct etna
 		etnaviv_iommu_remove_mapping(mmu, mapping);
 
 	list_del(&mapping->mmu_node);
-	mmu->need_flush = true;
+	mmu->flush_seq++;
 	mutex_unlock(&mmu->lock);
 }
 
@@ -357,7 +357,7 @@ int etnaviv_iommu_get_suballoc_va(struct
 			mutex_unlock(&mmu->lock);
 			return ret;
 		}
-		gpu->mmu->need_flush = true;
+		mmu->flush_seq++;
 		mutex_unlock(&mmu->lock);
 
 		*iova = (u32)vram_node->start;
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
@@ -48,7 +48,7 @@ struct etnaviv_iommu {
 	struct mutex lock;
 	struct list_head mappings;
 	struct drm_mm mm;
-	bool need_flush;
+	unsigned int flush_seq;
 };
 
 struct etnaviv_gem_object;

[PATCH 4.19 13/54] media: rc: IR signal for Panasonic air conditioner too long

[Greg Kroah-Hartman]

From: Sean Young <sean@mess.org>

commit 5c4c8b4a999019f19e770cb55cbacb89c95897bd upstream.

The IR signal to control the Panasonic ACXA75C00600 air conditioner has
439 pulse/spaces. Increase limit to make it possible to transmit signal.

Reported-by: Takashi Kanamaru <neuralassembly@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/rc/lirc_dev.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -29,7 +29,7 @@
 #include "rc-core-priv.h"
 #include <uapi/linux/lirc.h>
 
-#define LIRCBUF_SIZE	256
+#define LIRCBUF_SIZE	1024
 
 static dev_t lirc_base_dev;
 

[PATCH 4.19 14/54] misc: rtsx: set correct pcr_ops for rts522A

[Greg Kroah-Hartman]

From: YueHaibing <yuehaibing@huawei.com>

commit 10cea23b6aae15e8324f4101d785687f2c514fe5 upstream.

rts522a should use rts522a_pcr_ops, which is
diffrent with rts5227 in phy/hw init setting.

Fixes: ce6a5acc9387 ("mfd: rtsx: Add support for rts522A")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200326032618.20472-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/cardreader/rts5227.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/misc/cardreader/rts5227.c
+++ b/drivers/misc/cardreader/rts5227.c
@@ -369,6 +369,7 @@ static const struct pcr_ops rts522a_pcr_
 void rts522a_init_params(struct rtsx_pcr *pcr)
 {
 	rts5227_init_params(pcr);
+	pcr->ops = &rts522a_pcr_ops;
 	pcr->tx_initial_phase = SET_CLOCK_PHASE(20, 20, 11);
 	pcr->reg_pm_ctrl3 = RTS522A_PM_CTRL3;
 }

[PATCH 4.19 15/54] misc: pci_endpoint_test: Fix to support > 10 pci-endpoint-test devices

[Greg Kroah-Hartman]

From: Kishon Vijay Abraham I <kishon@ti.com>

commit 6b443e5c80b67a7b8a85b33d052d655ef9064e90 upstream.

Adding more than 10 pci-endpoint-test devices results in
"kobject_add_internal failed for pci-endpoint-test.1 with -EEXIST, don't
try to register things with the same name in the same directory". This
is because commit 2c156ac71c6b ("misc: Add host side PCI driver for PCI
test function device") limited the length of the "name" to 20 characters.
Change the length of the name to 24 in order to support upto 10000
pci-endpoint-test devices.

Fixes: 2c156ac71c6b ("misc: Add host side PCI driver for PCI test function device")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/pci_endpoint_test.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -636,7 +636,7 @@ static int pci_endpoint_test_probe(struc
 {
 	int err;
 	int id;
-	char name[20];
+	char name[24];
 	enum pci_barno bar;
 	void __iomem *base;
 	struct device *dev = &pdev->dev;

[PATCH 4.19 16/54] misc: pci_endpoint_test: Avoid using module parameter to determine irqtype

[Greg Kroah-Hartman]

From: Kishon Vijay Abraham I <kishon@ti.com>

commit b2ba9225e0313b1de631a44b7b48c109032bffec upstream.

commit e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands")
uses module parameter 'irqtype' in pci_endpoint_test_set_irq()
to check if IRQ vectors of a particular type (MSI or MSI-X or
LEGACY) is already allocated. However with multi-function devices,
'irqtype' will not correctly reflect the IRQ type of the PCI device.

Fix it here by adding 'irqtype' for each PCI device to show the
IRQ type of a particular PCI device.

Fixes: e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/pci_endpoint_test.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -104,6 +104,7 @@ struct pci_endpoint_test {
 	struct completion irq_raised;
 	int		last_irq;
 	int		num_irqs;
+	int		irq_type;
 	/* mutex to protect the ioctls */
 	struct mutex	mutex;
 	struct miscdevice miscdev;
@@ -163,6 +164,7 @@ static void pci_endpoint_test_free_irq_v
 	struct pci_dev *pdev = test->pdev;
 
 	pci_free_irq_vectors(pdev);
+	test->irq_type = IRQ_TYPE_UNDEFINED;
 }
 
 static bool pci_endpoint_test_alloc_irq_vectors(struct pci_endpoint_test *test,
@@ -197,6 +199,8 @@ static bool pci_endpoint_test_alloc_irq_
 		irq = 0;
 		res = false;
 	}
+
+	test->irq_type = type;
 	test->num_irqs = irq;
 
 	return res;
@@ -336,6 +340,7 @@ static bool pci_endpoint_test_copy(struc
 	dma_addr_t orig_dst_phys_addr;
 	size_t offset;
 	size_t alignment = test->alignment;
+	int irq_type = test->irq_type;
 	u32 src_crc32;
 	u32 dst_crc32;
 
@@ -432,6 +437,7 @@ static bool pci_endpoint_test_write(stru
 	dma_addr_t orig_phys_addr;
 	size_t offset;
 	size_t alignment = test->alignment;
+	int irq_type = test->irq_type;
 	u32 crc32;
 
 	if (size > SIZE_MAX - alignment)
@@ -500,6 +506,7 @@ static bool pci_endpoint_test_read(struc
 	dma_addr_t orig_phys_addr;
 	size_t offset;
 	size_t alignment = test->alignment;
+	int irq_type = test->irq_type;
 	u32 crc32;
 
 	if (size > SIZE_MAX - alignment)
@@ -561,7 +568,7 @@ static bool pci_endpoint_test_set_irq(st
 		return false;
 	}
 
-	if (irq_type == req_irq_type)
+	if (test->irq_type == req_irq_type)
 		return true;
 
 	pci_endpoint_test_release_irq(test);
@@ -573,12 +580,10 @@ static bool pci_endpoint_test_set_irq(st
 	if (!pci_endpoint_test_request_irq(test))
 		goto err;
 
-	irq_type = req_irq_type;
 	return true;
 
 err:
 	pci_endpoint_test_free_irq_vectors(test);
-	irq_type = IRQ_TYPE_UNDEFINED;
 	return false;
 }
 
@@ -655,6 +660,7 @@ static int pci_endpoint_test_probe(struc
 	test->test_reg_bar = 0;
 	test->alignment = 0;
 	test->pdev = pdev;
+	test->irq_type = IRQ_TYPE_UNDEFINED;
 
 	if (no_msi)
 		irq_type = IRQ_TYPE_LEGACY;

[PATCH 4.19 17/54] coresight: do not use the BIT() macro in the UAPI header

[Greg Kroah-Hartman]

From: Eugene Syromiatnikov <esyr@redhat.com>

commit 9b6eaaf3db5e5888df7bca7fed7752a90f7fd871 upstream.

The BIT() macro definition is not available for the UAPI headers
(moreover, it can be defined differently in the user space); replace
its usage with the _BITUL() macro that is defined in <linux/const.h>.

Fixes: 237483aa5cf4 ("coresight: stm: adding driver for CoreSight STM component")
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324042213.GA10452@asgard.redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 include/uapi/linux/coresight-stm.h |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/include/uapi/linux/coresight-stm.h
+++ b/include/uapi/linux/coresight-stm.h
@@ -2,8 +2,10 @@
 #ifndef __UAPI_CORESIGHT_STM_H_
 #define __UAPI_CORESIGHT_STM_H_
 
-#define STM_FLAG_TIMESTAMPED   BIT(3)
-#define STM_FLAG_GUARANTEED    BIT(7)
+#include <linux/const.h>
+
+#define STM_FLAG_TIMESTAMPED   _BITUL(3)
+#define STM_FLAG_GUARANTEED    _BITUL(7)
 
 /*
  * The CoreSight STM supports guaranteed and invariant timing

[PATCH 4.19 18/54] mei: me: add cedar fork device ids

[Greg Kroah-Hartman]

From: Alexander Usyskin <alexander.usyskin@intel.com>

commit 99397d33b763dc554d118aaa38cc5abc6ce985de upstream.

Add Cedar Fork (CDF) device ids, those belongs to the cannon point family.

Cc: <stable@vger.kernel.org>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20200324210730.17672-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/mei/hw-me-regs.h |    2 ++
 drivers/misc/mei/pci-me.c     |    2 ++
 2 files changed, 4 insertions(+)

--- a/drivers/misc/mei/hw-me-regs.h
+++ b/drivers/misc/mei/hw-me-regs.h
@@ -147,6 +147,8 @@
 #define MEI_DEV_ID_CMP_H      0x06e0  /* Comet Lake H */
 #define MEI_DEV_ID_CMP_H_3    0x06e4  /* Comet Lake H 3 (iTouch) */
 
+#define MEI_DEV_ID_CDF        0x18D3  /* Cedar Fork */
+
 #define MEI_DEV_ID_ICP_LP     0x34E0  /* Ice Lake Point LP */
 
 #define MEI_DEV_ID_TGP_LP     0xA0E0  /* Tiger Lake Point LP */
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -118,6 +118,8 @@ static const struct pci_device_id mei_me
 	{MEI_PCI_DEVICE(MEI_DEV_ID_MCC, MEI_ME_PCH12_CFG)},
 	{MEI_PCI_DEVICE(MEI_DEV_ID_MCC_4, MEI_ME_PCH8_CFG)},
 
+	{MEI_PCI_DEVICE(MEI_DEV_ID_CDF, MEI_ME_PCH8_CFG)},
+
 	/* required last entry */
 	{0, }
 };

[PATCH 4.19 19/54] extcon: axp288: Add wakeup support

[Greg Kroah-Hartman]

From: Hans de Goede <hdegoede@redhat.com>

commit 9c94553099efb2ba873cbdddfd416a8a09d0e5f1 upstream.

On devices with an AXP288, we need to wakeup from suspend when a charger
is plugged in, so that we can do charger-type detection and so that the
axp288-charger driver, which listens for our extcon events, can configure
the input-current-limit accordingly.

Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/extcon/extcon-axp288.c |   32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -428,9 +428,40 @@ static int axp288_extcon_probe(struct pl
 	/* Start charger cable type detection */
 	axp288_extcon_enable(info);
 
+	device_init_wakeup(dev, true);
+	platform_set_drvdata(pdev, info);
+
+	return 0;
+}
+
+static int __maybe_unused axp288_extcon_suspend(struct device *dev)
+{
+	struct axp288_extcon_info *info = dev_get_drvdata(dev);
+
+	if (device_may_wakeup(dev))
+		enable_irq_wake(info->irq[VBUS_RISING_IRQ]);
+
 	return 0;
 }
 
+static int __maybe_unused axp288_extcon_resume(struct device *dev)
+{
+	struct axp288_extcon_info *info = dev_get_drvdata(dev);
+
+	/*
+	 * Wakeup when a charger is connected to do charger-type
+	 * connection and generate an extcon event which makes the
+	 * axp288 charger driver set the input current limit.
+	 */
+	if (device_may_wakeup(dev))
+		disable_irq_wake(info->irq[VBUS_RISING_IRQ]);
+
+	return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(axp288_extcon_pm_ops, axp288_extcon_suspend,
+			 axp288_extcon_resume);
+
 static const struct platform_device_id axp288_extcon_table[] = {
 	{ .name = "axp288_extcon" },
 	{},
@@ -442,6 +473,7 @@ static struct platform_driver axp288_ext
 	.id_table = axp288_extcon_table,
 	.driver = {
 		.name = "axp288_extcon",
+		.pm = &axp288_extcon_pm_ops,
 	},
 };
 

[PATCH 4.19 20/54] power: supply: axp288_charger: Add special handling for HP Pavilion x2 10

[Greg Kroah-Hartman]

From: Hans de Goede <hdegoede@redhat.com>

commit 9c80662a74cd2a5d1113f5c69d027face963a556 upstream.

Some HP Pavilion x2 10 models use an AXP288 for charging and fuel-gauge.
We use a native power_supply / PMIC driver in this case, because on most
models with an AXP288 the ACPI AC / Battery code is either completely
missing or relies on custom / proprietary ACPI OpRegions which Linux
does not implement.

The native drivers mostly work fine, but there are 2 problems:

1. These model uses a Type-C connector for charging which the AXP288 does
not support. As long as a Type-A charger (which uses the USB data pins for
charger type detection) is used everything is fine. But if a Type-C
charger is used (such as the charger shipped with the device) then the
charger is not recognized.

So we end up slowly discharging the device even though a charger is
connected, because we are limiting the current from the charger to 500mA.
To make things worse this happens with the device's official charger.

Looking at the ACPI tables HP has "solved" the problem of the AXP288 not
being able to recognize Type-C chargers by simply always programming the
input-current-limit at 3000mA and relying on a Vhold setting of 4.7V
(normally 4.4V) to limit the current intake if the charger cannot handle
this.

2. If no charger is connected when the machine boots then it boots with the
vbus-path disabled. On other devices this is done when a 5V boost converter
is active to avoid the PMIC trying to charge from the 5V boost output.
This is done when an OTG host cable is inserted and the ID pin on the
micro-B receptacle is pulled low, the ID pin has an ACPI event handler
associated with it which re-enables the vbus-path when the ID pin is pulled
high when the OTG cable is removed. The Type-C connector has no ID pin,
there is no ID pin handler and there appears to be no 5V boost converter,
so we end up not charging because the vbus-path is disabled, until we
unplug the charger which automatically clears the vbus-path disable bit and
then on the second plug-in of the adapter we start charging.

The HP Pavilion x2 10 models with an AXP288 do have mostly working ACPI
AC / Battery code which does not rely on custom / proprietary ACPI
OpRegions. So one possible solution would be to blacklist the AXP288
native power_supply drivers and add the HP Pavilion x2 10 with AXP288
DMI ids to the list of devices which should use the ACPI AC / Battery
code even though they have an AXP288 PMIC. This would require changes to
4 files: drivers/acpi/ac.c, drivers/power/supply/axp288_charger.c,
drivers/acpi/battery.c and drivers/power/supply/axp288_fuel_gauge.c.

Beside needing adding the same DMI matches to 4 different files, this
approach also triggers problem 2. from above, but then when suspended,
during suspend the machine will not wakeup because the vbus path is
disabled by the AML code when not charging, so the Vbus low-to-high
IRQ is not triggered, the CPU never wakes up and the device does not
charge even though the user likely things it is charging, esp. since
the charge status LED is directly coupled to an adapter being plugged
in and does not reflect actual charging.

This could be worked by enabling vbus-path explicitly from say the
axp288_charger driver's suspend handler.

So neither situation is ideal, in both cased we need to explicitly enable
the vbus-path to work around different variants of problem 2 above, this
requires a quirk in the axp288_charger code.

If we go the route of using the ACPI AC / Battery drivers then we need
modifications to 3 other drivers; and we need to partially disable the
axp288_charger code, while at the same time keeping it around to enable
vbus-path on suspend.

OTOH we can copy the hardcoding of 3A input-current-limit (we never touch
Vhold, so that would stay at 4.7V) to the axp288_charger code, which needs
changes regardless, then we concentrate all special handling of this
interesting device model in the axp288_charger code. That is what this
commit does.

Cc: stable@vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1791098
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/power/supply/axp288_charger.c |   57 +++++++++++++++++++++++++++++++++-
 1 file changed, 56 insertions(+), 1 deletion(-)

--- a/drivers/power/supply/axp288_charger.c
+++ b/drivers/power/supply/axp288_charger.c
@@ -28,6 +28,7 @@
 #include <linux/property.h>
 #include <linux/mfd/axp20x.h>
 #include <linux/extcon.h>
+#include <linux/dmi.h>
 
 #define PS_STAT_VBUS_TRIGGER		(1 << 0)
 #define PS_STAT_BAT_CHRG_DIR		(1 << 2)
@@ -552,6 +553,49 @@ out:
 	return IRQ_HANDLED;
 }
 
+/*
+ * The HP Pavilion x2 10 series comes in a number of variants:
+ * Bay Trail SoC    + AXP288 PMIC, DMI_BOARD_NAME: "815D"
+ * Cherry Trail SoC + AXP288 PMIC, DMI_BOARD_NAME: "813E"
+ * Cherry Trail SoC + TI PMIC,     DMI_BOARD_NAME: "827C" or "82F4"
+ *
+ * The variants with the AXP288 PMIC are all kinds of special:
+ *
+ * 1. All variants use a Type-C connector which the AXP288 does not support, so
+ * when using a Type-C charger it is not recognized. Unlike most AXP288 devices,
+ * this model actually has mostly working ACPI AC / Battery code, the ACPI code
+ * "solves" this by simply setting the input_current_limit to 3A.
+ * There are still some issues with the ACPI code, so we use this native driver,
+ * and to solve the charging not working (500mA is not enough) issue we hardcode
+ * the 3A input_current_limit like the ACPI code does.
+ *
+ * 2. If no charger is connected the machine boots with the vbus-path disabled.
+ * Normally this is done when a 5V boost converter is active to avoid the PMIC
+ * trying to charge from the 5V boost converter's output. This is done when
+ * an OTG host cable is inserted and the ID pin on the micro-B receptacle is
+ * pulled low and the ID pin has an ACPI event handler associated with it
+ * which re-enables the vbus-path when the ID pin is pulled high when the
+ * OTG host cable is removed. The Type-C connector has no ID pin, there is
+ * no ID pin handler and there appears to be no 5V boost converter, so we
+ * end up not charging because the vbus-path is disabled, until we unplug
+ * the charger which automatically clears the vbus-path disable bit and then
+ * on the second plug-in of the adapter we start charging. To solve the not
+ * charging on first charger plugin we unconditionally enable the vbus-path at
+ * probe on this model, which is safe since there is no 5V boost converter.
+ */
+static const struct dmi_system_id axp288_hp_x2_dmi_ids[] = {
+	{
+		/*
+		 * Bay Trail model has "Hewlett-Packard" as sys_vendor, Cherry
+		 * Trail model has "HP", so we only match on product_name.
+		 */
+		.matches = {
+			DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion x2 Detachable"),
+		},
+	},
+	{} /* Terminating entry */
+};
+
 static void axp288_charger_extcon_evt_worker(struct work_struct *work)
 {
 	struct axp288_chrg_info *info =
@@ -575,7 +619,11 @@ static void axp288_charger_extcon_evt_wo
 	}
 
 	/* Determine cable/charger type */
-	if (extcon_get_state(edev, EXTCON_CHG_USB_SDP) > 0) {
+	if (dmi_check_system(axp288_hp_x2_dmi_ids)) {
+		/* See comment above axp288_hp_x2_dmi_ids declaration */
+		dev_dbg(&info->pdev->dev, "HP X2 with Type-C, setting inlmt to 3A\n");
+		current_limit = 3000000;
+	} else if (extcon_get_state(edev, EXTCON_CHG_USB_SDP) > 0) {
 		dev_dbg(&info->pdev->dev, "USB SDP charger is connected\n");
 		current_limit = 500000;
 	} else if (extcon_get_state(edev, EXTCON_CHG_USB_CDP) > 0) {
@@ -692,6 +740,13 @@ static int charger_init_hw_regs(struct a
 		return ret;
 	}
 
+	if (dmi_check_system(axp288_hp_x2_dmi_ids)) {
+		/* See comment above axp288_hp_x2_dmi_ids declaration */
+		ret = axp288_charger_vbus_path_select(info, true);
+		if (ret < 0)
+			return ret;
+	}
+
 	/* Read current charge voltage and current limit */
 	ret = regmap_read(info->regmap, AXP20X_CHRG_CTRL1, &val);
 	if (ret < 0) {

[PATCH 4.19 21/54] ALSA: hda/ca0132 - Add Recon3Di quirk to handle integrated sound on EVGA X99 Classified motherboard

[Greg Kroah-Hartman]

From: Geoffrey Allott <geoffrey@allott.email>

commit e9097e47e349b747dee50f935216de0ffb662962 upstream.

I have a system which has an EVGA X99 Classified motherboard. The pin
assignments for the HD Audio controller are not correct under Linux.
Windows 10 works fine and informs me that it's using the Recon3Di
driver, and on Linux, `cat
/sys/class/sound/card0/device/subsystem_{vendor,device}` yields

0x3842
0x1038

This patch adds a corresponding entry to the quirk list.

Signed-off-by: Geoffrey Allott <geoffrey@allott.email>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/a6cd56b678c00ce2db3685e4278919f2584f8244.camel@allott.email
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/pci/hda/patch_ca0132.c |    1 +
 1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_ca0132.c
+++ b/sound/pci/hda/patch_ca0132.c
@@ -1069,6 +1069,7 @@ static const struct snd_pci_quirk ca0132
 	SND_PCI_QUIRK(0x1458, 0xA016, "Recon3Di", QUIRK_R3DI),
 	SND_PCI_QUIRK(0x1458, 0xA026, "Gigabyte G1.Sniper Z97", QUIRK_R3DI),
 	SND_PCI_QUIRK(0x1458, 0xA036, "Gigabyte GA-Z170X-Gaming 7", QUIRK_R3DI),
+	SND_PCI_QUIRK(0x3842, 0x1038, "EVGA X99 Classified", QUIRK_R3DI),
 	SND_PCI_QUIRK(0x1102, 0x0013, "Recon3D", QUIRK_R3D),
 	{}
 };

[PATCH 4.19 22/54] rxrpc: Fix sendmsg(MSG_WAITALL) handling

[Greg Kroah-Hartman]

From: David Howells <dhowells@redhat.com>

commit 498b577660f08cef5d9e78e0ed6dcd4c0939e98c upstream.

Fix the handling of sendmsg() with MSG_WAITALL for userspace to round the
timeout for when a signal occurs up to at least two jiffies as a 1 jiffy
timeout may end up being effectively 0 if jiffies wraps at the wrong time.

Fixes: bc5e3a546d55 ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/rxrpc/sendmsg.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -62,8 +62,8 @@ static int rxrpc_wait_for_tx_window_noni
 
 	rtt = READ_ONCE(call->peer->rtt);
 	rtt2 = nsecs_to_jiffies64(rtt) * 2;
-	if (rtt2 < 1)
-		rtt2 = 1;
+	if (rtt2 < 2)
+		rtt2 = 2;
 
 	timeout = rtt2;
 	tx_start = READ_ONCE(call->tx_hard_ack);

[PATCH 4.19 23/54] net: Fix Tx hash bound checking

[Greg Kroah-Hartman]

From: Amritha Nambiar <amritha.nambiar@intel.com>

commit 6e11d1578fba8d09d03a286740ffcf336d53928c upstream.

Fixes the lower and upper bounds when there are multiple TCs and
traffic is on the the same TC on the same device.

The lower bound is represented by 'qoffset' and the upper limit for
hash value is 'qcount + qoffset'. This gives a clean Rx to Tx queue
mapping when there are multiple TCs, as the queue indices for upper TCs
will be offset by 'qoffset'.

v2: Fixed commit description based on comments.

Fixes: 1b837d489e06 ("net: Revoke export for __skb_tx_hash, update it to just be static skb_tx_hash")
Fixes: eadec877ce9c ("net: Add support for subordinate traffic classes to netdev_pick_tx")
Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/core/dev.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2854,6 +2854,8 @@ static u16 skb_tx_hash(const struct net_
 
 	if (skb_rx_queue_recorded(skb)) {
 		hash = skb_get_rx_queue(skb);
+		if (hash >= qoffset)
+			hash -= qoffset;
 		while (unlikely(hash >= qcount))
 			hash -= qcount;
 		return hash + qoffset;

[PATCH 4.19 24/54] padata: always acquire cpu_hotplug_lock before pinst->lock

[Greg Kroah-Hartman]

From: Daniel Jordan <daniel.m.jordan@oracle.com>

commit 38228e8848cd7dd86ccb90406af32de0cad24be3 upstream.

lockdep complains when padata's paths to update cpumasks via CPU hotplug
and sysfs are both taken:

  # echo 0 > /sys/devices/system/cpu/cpu1/online
  # echo ff > /sys/kernel/pcrypt/pencrypt/parallel_cpumask

  ======================================================
  WARNING: possible circular locking dependency detected
  5.4.0-rc8-padata-cpuhp-v3+ #1 Not tainted
  ------------------------------------------------------
  bash/205 is trying to acquire lock:
  ffffffff8286bcd0 (cpu_hotplug_lock.rw_sem){++++}, at: padata_set_cpumask+0x2b/0x120

  but task is already holding lock:
  ffff8880001abfa0 (&pinst->lock){+.+.}, at: padata_set_cpumask+0x26/0x120

  which lock already depends on the new lock.

padata doesn't take cpu_hotplug_lock and pinst->lock in a consistent
order.  Which should be first?  CPU hotplug calls into padata with
cpu_hotplug_lock already held, so it should have priority.

Fixes: 6751fb3c0e0c ("padata: Use get_online_cpus/put_online_cpus")
Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/padata.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -671,8 +671,8 @@ int padata_set_cpumask(struct padata_ins
 	struct cpumask *serial_mask, *parallel_mask;
 	int err = -EINVAL;
 
-	mutex_lock(&pinst->lock);
 	get_online_cpus();
+	mutex_lock(&pinst->lock);
 
 	switch (cpumask_type) {
 	case PADATA_CPU_PARALLEL:
@@ -690,8 +690,8 @@ int padata_set_cpumask(struct padata_ins
 	err =  __padata_set_cpumasks(pinst, parallel_mask, serial_mask);
 
 out:
-	put_online_cpus();
 	mutex_unlock(&pinst->lock);
+	put_online_cpus();
 
 	return err;
 }

[PATCH 4.19 25/54] bitops: protect variables in set_mask_bits() macro

[Greg Kroah-Hartman]

From: Miklos Szeredi <mszeredi@redhat.com>

commit 18127429a854e7607b859484880b8e26cee9ddab upstream.

Unprotected naming of local variables within the set_mask_bits() can easily
lead to using the wrong scope.

Noticed this when "set_mask_bits(&foo->bar, 0, mask)" behaved as no-op.

Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Fixes: 00a1a053ebe5 ("ext4: atomically set inode->i_flags in ext4_set_inode_flags()")
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 include/linux/bitops.h |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -236,17 +236,17 @@ static __always_inline void __assign_bit
 #ifdef __KERNEL__
 
 #ifndef set_mask_bits
-#define set_mask_bits(ptr, _mask, _bits)	\
+#define set_mask_bits(ptr, mask, bits)	\
 ({								\
-	const typeof(*ptr) mask = (_mask), bits = (_bits);	\
-	typeof(*ptr) old, new;					\
+	const typeof(*(ptr)) mask__ = (mask), bits__ = (bits);	\
+	typeof(*(ptr)) old__, new__;				\
 								\
 	do {							\
-		old = READ_ONCE(*ptr);			\
-		new = (old & ~mask) | bits;			\
-	} while (cmpxchg(ptr, old, new) != old);		\
+		old__ = READ_ONCE(*(ptr));			\
+		new__ = (old__ & ~mask__) | bits__;		\
+	} while (cmpxchg(ptr, old__, new__) != old__);		\
 								\
-	new;							\
+	new__;							\
 })
 #endif
 

[PATCH 4.19 26/54] include/linux/notifier.h: SRCU: fix ctags

[Greg Kroah-Hartman]

From: Sam Protsenko <semen.protsenko@linaro.org>

commit 94e297c50b529f5d01cfd1dbc808d61e95180ab7 upstream.

ctags indexing ("make tags" command) throws this warning:

    ctags: Warning: include/linux/notifier.h:125:
    null expansion of name pattern "\1"

This is the result of DEFINE_PER_CPU() macro expansion.  Fix that by
getting rid of line break.

Similar fix was already done in commit 25528213fe9f ("tags: Fix
DEFINE_PER_CPU expansions"), but this one probably wasn't noticed.

Link: http://lkml.kernel.org/r/20181030202808.28027-1-semen.protsenko@linaro.org
Fixes: 9c80172b902d ("kernel/SRCU: provide a static initializer")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 include/linux/notifier.h |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -122,8 +122,7 @@ extern void srcu_init_notifier_head(stru
 
 #ifdef CONFIG_TREE_SRCU
 #define _SRCU_NOTIFIER_HEAD(name, mod)				\
-	static DEFINE_PER_CPU(struct srcu_data,			\
-			name##_head_srcu_data);			\
+	static DEFINE_PER_CPU(struct srcu_data, name##_head_srcu_data); \
 	mod struct srcu_notifier_head name =			\
 			SRCU_NOTIFIER_INIT(name, name##_head_srcu_data)
 

[PATCH 4.19 27/54] mm: mempolicy: require at least one nodeid for MPOL_PREFERRED

[Greg Kroah-Hartman]

From: Randy Dunlap <rdunlap@infradead.org>

commit aa9f7d5172fac9bf1f09e678c35e287a40a7b7dd upstream.

Using an empty (malformed) nodelist that is not caught during mount option
parsing leads to a stack-out-of-bounds access.

The option string that was used was: "mpol=prefer:,".  However,
MPOL_PREFERRED requires a single node number, which is not being provided
here.

Add a check that 'nodes' is not empty after parsing for MPOL_PREFERRED's
nodeid.

Fixes: 095f1fc4ebf3 ("mempolicy: rework shmem mpol parsing and display")
Reported-by: Entropy Moe <3ntr0py1337@gmail.com>
Reported-by: syzbot+b055b1a6b2b958707a21@syzkaller.appspotmail.com
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: syzbot+b055b1a6b2b958707a21@syzkaller.appspotmail.com
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Link: http://lkml.kernel.org/r/89526377-7eb6-b662-e1d8-4430928abde9@infradead.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/mempolicy.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2832,7 +2832,9 @@ int mpol_parse_str(char *str, struct mem
 	switch (mode) {
 	case MPOL_PREFERRED:
 		/*
-		 * Insist on a nodelist of one node only
+		 * Insist on a nodelist of one node only, although later
+		 * we use first_node(nodes) to grab a single node, so here
+		 * nodelist (or nodes) cannot be empty.
 		 */
 		if (nodelist) {
 			char *rest = nodelist;
@@ -2840,6 +2842,8 @@ int mpol_parse_str(char *str, struct mem
 				rest++;
 			if (*rest)
 				goto out;
+			if (nodes_empty(nodes))
+				goto out;
 		}
 		break;
 	case MPOL_INTERLEAVE:

[PATCH 4.19 28/54] ipv6: dont auto-add link-local address to lag ports

[Greg Kroah-Hartman]

From: Jarod Wilson <jarod@redhat.com>

[ Upstream commit 744fdc8233f6aa9582ce08a51ca06e59796a3196 ]

Bonding slave and team port devices should not have link-local addresses
automatically added to them, as it can interfere with openvswitch being
able to properly add tc ingress.

Basic reproducer, courtesy of Marcelo:

$ ip link add name bond0 type bond
$ ip link set dev ens2f0np0 master bond0
$ ip link set dev ens2f1np2 master bond0
$ ip link set dev bond0 up
$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens2f0np0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
mq master bond0 state UP group default qlen 1000
    link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff
5: ens2f1np2: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc
mq master bond0 state DOWN group default qlen 1000
    link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff
11: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP group default qlen 1000
    link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20f:53ff:fe2f:ea40/64 scope link
       valid_lft forever preferred_lft forever

(above trimmed to relevant entries, obviously)

$ sysctl net.ipv6.conf.ens2f0np0.addr_gen_mode=0
net.ipv6.conf.ens2f0np0.addr_gen_mode = 0
$ sysctl net.ipv6.conf.ens2f1np2.addr_gen_mode=0
net.ipv6.conf.ens2f1np2.addr_gen_mode = 0

$ ip a l ens2f0np0
2: ens2f0np0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
mq master bond0 state UP group default qlen 1000
    link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20f:53ff:fe2f:ea40/64 scope link tentative
       valid_lft forever preferred_lft forever
$ ip a l ens2f1np2
5: ens2f1np2: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc
mq master bond0 state DOWN group default qlen 1000
    link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20f:53ff:fe2f:ea40/64 scope link tentative
       valid_lft forever preferred_lft forever

Looks like addrconf_sysctl_addr_gen_mode() bypasses the original "is
this a slave interface?" check added by commit c2edacf80e15, and
results in an address getting added, while w/the proposed patch added,
no address gets added. This simply adds the same gating check to another
code path, and thus should prevent the same devices from erroneously
obtaining an ipv6 link-local address.

Fixes: d35a00b8e33d ("net/ipv6: allow sysctl to change link-local address generation mode")
Reported-by: Moshe Levi <moshele@mellanox.com>
CC: Stephen Hemminger <stephen@networkplumber.org>
CC: Marcelo Ricardo Leitner <mleitner@redhat.com>
CC: netdev@vger.kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv6/addrconf.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3241,6 +3241,10 @@ static void addrconf_addr_gen(struct ine
 	if (netif_is_l3_master(idev->dev))
 		return;
 
+	/* no link local addresses on devices flagged as slaves */
+	if (idev->dev->flags & IFF_SLAVE)
+		return;
+
 	ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0);
 
 	switch (idev->cnf.addr_gen_mode) {

[PATCH 4.19 29/54] net: dsa: bcm_sf2: Do not register slave MDIO bus with OF

[Greg Kroah-Hartman]

From: Florian Fainelli <f.fainelli@gmail.com>

[ Upstream commit 536fab5bf5826404534a6c271f622ad2930d9119 ]

We were registering our slave MDIO bus with OF and doing so with
assigning the newly created slave_mii_bus of_node to the master MDIO bus
controller node. This is a bad thing to do for a number of reasons:

- we are completely lying about the slave MII bus is arranged and yet we
  still want to control which MDIO devices it probes. It was attempted
  before to play tricks with the bus_mask to perform that:
  https://www.spinics.net/lists/netdev/msg429420.html but the approach
  was rightfully rejected

- the device_node reference counting is messed up and we are effectively
  doing a double probe on the devices we already probed using the
  master, this messes up all resources reference counts (such as clocks)

The proper fix for this as indicated by David in his reply to the
thread above is to use a platform data style registration so as to
control exactly which devices we probe:
https://www.spinics.net/lists/netdev/msg430083.html

By using mdiobus_register(), our slave_mii_bus->phy_mask value is used
as intended, and all the PHY addresses that must be redirected towards
our slave MDIO bus is happening while other addresses get redirected
towards the master MDIO bus.

Fixes: 461cd1b03e32 ("net: dsa: bcm_sf2: Register our slave MDIO bus")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/dsa/bcm_sf2.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -461,7 +461,7 @@ static int bcm_sf2_mdio_register(struct
 	priv->slave_mii_bus->parent = ds->dev->parent;
 	priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
 
-	err = of_mdiobus_register(priv->slave_mii_bus, dn);
+	err = mdiobus_register(priv->slave_mii_bus);
 	if (err && dn)
 		of_node_put(dn);
 

[PATCH 4.19 30/54] net: dsa: bcm_sf2: Ensure correct sub-node is parsed

[Greg Kroah-Hartman]

From: Florian Fainelli <f.fainelli@gmail.com>

[ Upstream commit afa3b592953bfaecfb4f2f335ec5f935cff56804 ]

When the bcm_sf2 was converted into a proper platform device driver and
used the new dsa_register_switch() interface, we would still be parsing
the legacy DSA node that contained all the port information since the
platform firmware has intentionally maintained backward and forward
compatibility to client programs. Ensure that we do parse the correct
node, which is "ports" per the revised DSA binding.

Fixes: d9338023fb8e ("net: dsa: bcm_sf2: Make it a real platform device driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/dsa/bcm_sf2.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1014,6 +1014,7 @@ static int bcm_sf2_sw_probe(struct platf
 	const struct bcm_sf2_of_data *data;
 	struct b53_platform_data *pdata;
 	struct dsa_switch_ops *ops;
+	struct device_node *ports;
 	struct bcm_sf2_priv *priv;
 	struct b53_device *dev;
 	struct dsa_switch *ds;
@@ -1077,7 +1078,11 @@ static int bcm_sf2_sw_probe(struct platf
 	set_bit(0, priv->cfp.used);
 	set_bit(0, priv->cfp.unique);
 
-	bcm_sf2_identify_ports(priv, dn->child);
+	ports = of_find_node_by_name(dn, "ports");
+	if (ports) {
+		bcm_sf2_identify_ports(priv, ports);
+		of_node_put(ports);
+	}
 
 	priv->irq0 = irq_of_parse_and_map(dn, 0);
 	priv->irq1 = irq_of_parse_and_map(dn, 1);

[PATCH 4.19 31/54] net: phy: micrel: kszphy_resume(): add delay after genphy_resume() before accessing PHY registers

[Greg Kroah-Hartman]

From: Oleksij Rempel <o.rempel@pengutronix.de>

[ Upstream commit 6110dff776f7fa65c35850ef65b41d3b39e2fac2 ]

After the power-down bit is cleared, the chip internally triggers a
global reset. According to the KSZ9031 documentation, we have to wait at
least 1ms for the reset to finish.

If the chip is accessed during reset, read will return 0xffff, while
write will be ignored. Depending on the system performance and MDIO bus
speed, we may or may not run in to this issue.

This bug was discovered on an iMX6QP system with KSZ9031 PHY and
attached PHY interrupt line. If IRQ was used, the link status update was
lost. In polling mode, the link status update was always correct.

The investigation showed, that during a read-modify-write access, the
read returned 0xffff (while the chip was still in reset) and
corresponding write hit the chip _after_ reset and triggered (due to the
0xffff) another reset in an undocumented bit (register 0x1f, bit 1),
resulting in the next write being lost due to the new reset cycle.

This patch fixes the issue by adding a 1...2 ms sleep after the
genphy_resume().

Fixes: 836384d2501d ("net: phy: micrel: Add specific suspend")
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/phy/micrel.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -29,6 +29,7 @@
 #include <linux/micrel_phy.h>
 #include <linux/of.h>
 #include <linux/clk.h>
+#include <linux/delay.h>
 
 /* Operation Mode Strap Override */
 #define MII_KSZPHY_OMSO				0x16
@@ -738,6 +739,12 @@ static int kszphy_resume(struct phy_devi
 
 	genphy_resume(phydev);
 
+	/* After switching from power-down to normal mode, an internal global
+	 * reset is automatically generated. Wait a minimum of 1 ms before
+	 * read/write access to the PHY registers.
+	 */
+	usleep_range(1000, 2000);
+
 	ret = kszphy_config_reset(phydev);
 	if (ret)
 		return ret;

[PATCH 4.19 32/54] net: stmmac: dwmac1000: fix out-of-bounds mac address reg setting

[Greg Kroah-Hartman]

From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>

[ Upstream commit 3e1221acf6a8f8595b5ce354bab4327a69d54d18 ]

Commit 9463c4455900 ("net: stmmac: dwmac1000: Clear unused address
entries") cleared the unused mac address entries, but introduced an
out-of bounds mac address register programming bug -- After setting
the secondary unicast mac addresses, the "reg" value has reached
netdev_uc_count() + 1, thus we should only clear address entries
if (addr < perfect_addr_number)

Fixes: 9463c4455900 ("net: stmmac: dwmac1000: Clear unused address entries")
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -218,7 +218,7 @@ static void dwmac1000_set_filter(struct
 			reg++;
 		}
 
-		while (reg <= perfect_addr_number) {
+		while (reg < perfect_addr_number) {
 			writel(0, ioaddr + GMAC_ADDR_HIGH(reg));
 			writel(0, ioaddr + GMAC_ADDR_LOW(reg));
 			reg++;

[PATCH 4.19 33/54] slcan: Dont transmit uninitialized stack data in padding

[Greg Kroah-Hartman]

From: Richard Palethorpe <rpalethorpe@suse.com>

[ Upstream commit b9258a2cece4ec1f020715fe3554bc2e360f6264 ]

struct can_frame contains some padding which is not explicitly zeroed in
slc_bump. This uninitialized data will then be transmitted if the stack
initialization hardening feature is not enabled (CONFIG_INIT_STACK_ALL).

This commit just zeroes the whole struct including the padding.

Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
Fixes: a1044e36e457 ("can: add slcan driver for serial/USB-serial CAN adapters")
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: linux-can@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: security@kernel.org
Cc: wg@grandegger.com
Cc: mkl@pengutronix.de
Cc: davem@davemloft.net
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/can/slcan.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/drivers/net/can/slcan.c
+++ b/drivers/net/can/slcan.c
@@ -147,7 +147,7 @@ static void slc_bump(struct slcan *sl)
 	u32 tmpid;
 	char *cmd = sl->rbuff;
 
-	cf.can_id = 0;
+	memset(&cf, 0, sizeof(cf));
 
 	switch (*cmd) {
 	case 'r':
@@ -186,8 +186,6 @@ static void slc_bump(struct slcan *sl)
 	else
 		return;
 
-	*(u64 *) (&cf.data) = 0; /* clear payload */
-
 	/* RTR frames may have a dlc > 0 but they never have any data bytes */
 	if (!(cf.can_id & CAN_RTR_FLAG)) {
 		for (i = 0; i < cf.can_dlc; i++) {

[PATCH 4.19 34/54] mlxsw: spectrum_flower: Do not stop at FLOW_ACTION_VLAN_MANGLE

[Greg Kroah-Hartman]

From: Petr Machata <petrm@mellanox.com>

[ Upstream commit ccfc569347f870830e7c7cf854679a06cf9c45b5 ]

The handler for FLOW_ACTION_VLAN_MANGLE ends by returning whatever the
lower-level function that it calls returns. If there are more actions lined
up after this action, those are never offloaded. Fix by only bailing out
when the called function returns an error.

Fixes: a150201a70da ("mlxsw: spectrum: Add support for vlan modify TC action")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_flower.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_flower.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_flower.c
@@ -98,9 +98,11 @@ static int mlxsw_sp_flower_parse_actions
 			u8 prio = tcf_vlan_push_prio(a);
 			u16 vid = tcf_vlan_push_vid(a);
 
-			return mlxsw_sp_acl_rulei_act_vlan(mlxsw_sp, rulei,
-							   action, vid,
-							   proto, prio, extack);
+			err = mlxsw_sp_acl_rulei_act_vlan(mlxsw_sp, rulei,
+							  action, vid,
+							  proto, prio, extack);
+			if (err)
+				return err;
 		} else {
 			NL_SET_ERR_MSG_MOD(extack, "Unsupported action");
 			dev_err(mlxsw_sp->bus_info->dev, "Unsupported action\n");

[PATCH 4.19 35/54] random: always use batched entropy for get_random_u{32,64}

[Greg Kroah-Hartman]

From: Jason A. Donenfeld <Jason@zx2c4.com>

commit 69efea712f5b0489e67d07565aad5c94e09a3e52 upstream.

It turns out that RDRAND is pretty slow. Comparing these two
constructions:

  for (i = 0; i < CHACHA_BLOCK_SIZE; i += sizeof(ret))
    arch_get_random_long(&ret);

and

  long buf[CHACHA_BLOCK_SIZE / sizeof(long)];
  extract_crng((u8 *)buf);

it amortizes out to 352 cycles per long for the top one and 107 cycles
per long for the bottom one, on Coffee Lake Refresh, Intel Core i9-9880H.

And importantly, the top one has the drawback of not benefiting from the
real rng, whereas the bottom one has all the nice benefits of using our
own chacha rng. As get_random_u{32,64} gets used in more places (perhaps
beyond what it was originally intended for when it was introduced as
get_random_{int,long} back in the md5 monstrosity era), it seems like it
might be a good thing to strengthen its posture a tiny bit. Doing this
should only be stronger and not any weaker because that pool is already
initialized with a bunch of rdrand data (when available). This way, we
get the benefits of the hardware rng as well as our own rng.

Another benefit of this is that we no longer hit pitfalls of the recent
stream of AMD bugs in RDRAND. One often used code pattern for various
things is:

  do {
  	val = get_random_u32();
  } while (hash_table_contains_key(val));

That recent AMD bug rendered that pattern useless, whereas we're really
very certain that chacha20 output will give pretty distributed numbers,
no matter what.

So, this simplification seems better both from a security perspective
and from a performance perspective.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200221201037.30231-1-Jason@zx2c4.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/char/random.c |   20 ++++----------------
 1 file changed, 4 insertions(+), 16 deletions(-)

--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2280,11 +2280,11 @@ struct batched_entropy {
 
 /*
  * Get a random word for internal kernel use only. The quality of the random
- * number is either as good as RDRAND or as good as /dev/urandom, with the
- * goal of being quite fast and not depleting entropy. In order to ensure
+ * number is good as /dev/urandom, but there is no backtrack protection, with
+ * the goal of being quite fast and not depleting entropy. In order to ensure
  * that the randomness provided by this function is okay, the function
- * wait_for_random_bytes() should be called and return 0 at least once
- * at any point prior.
+ * wait_for_random_bytes() should be called and return 0 at least once at any
+ * point prior.
  */
 static DEFINE_PER_CPU(struct batched_entropy, batched_entropy_u64) = {
 	.batch_lock	= __SPIN_LOCK_UNLOCKED(batched_entropy_u64.lock),
@@ -2297,15 +2297,6 @@ u64 get_random_u64(void)
 	struct batched_entropy *batch;
 	static void *previous;
 
-#if BITS_PER_LONG == 64
-	if (arch_get_random_long((unsigned long *)&ret))
-		return ret;
-#else
-	if (arch_get_random_long((unsigned long *)&ret) &&
-	    arch_get_random_long((unsigned long *)&ret + 1))
-	    return ret;
-#endif
-
 	warn_unseeded_randomness(&previous);
 
 	batch = raw_cpu_ptr(&batched_entropy_u64);
@@ -2330,9 +2321,6 @@ u32 get_random_u32(void)
 	struct batched_entropy *batch;
 	static void *previous;
 
-	if (arch_get_random_int(&ret))
-		return ret;
-
 	warn_unseeded_randomness(&previous);
 
 	batch = raw_cpu_ptr(&batched_entropy_u32);

[PATCH 4.19 36/54] usb: dwc3: gadget: Wrap around when skip TRBs

[Greg Kroah-Hartman]

From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>

commit 2dedea035ae82c5af0595637a6eda4655532b21e upstream.

When skipping TRBs, we need to account for wrapping around the ring
buffer and not modifying some invalid TRBs. Without this fix, dwc3 won't
be able to check for available TRBs.

Cc: stable <stable@vger.kernel.org>
Fixes: 7746a8dfb3f9 ("usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs()")
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/dwc3/gadget.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1369,7 +1369,7 @@ static void dwc3_gadget_ep_skip_trbs(str
 	for (i = 0; i < req->num_trbs; i++) {
 		struct dwc3_trb *trb;
 
-		trb = req->trb + i;
+		trb = &dep->trb_pool[dep->trb_dequeue];
 		trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
 		dwc3_ep_inc_deq(dep);
 	}

[PATCH 4.19 37/54] tools/accounting/getdelays.c: fix netlink attribute length

[Greg Kroah-Hartman]

From: David Ahern <dsahern@kernel.org>

commit 4054ab64e29bb05b3dfe758fff3c38a74ba753bb upstream.

A recent change to the netlink code: 6e237d099fac ("netlink: Relax attr
validation for fixed length types") logs a warning when programs send
messages with invalid attributes (e.g., wrong length for a u32).  Yafang
reported this error message for tools/accounting/getdelays.c.

send_cmd() is wrongly adding 1 to the attribute length.  As noted in
include/uapi/linux/netlink.h nla_len should be NLA_HDRLEN + payload
length, so drop the +1.

Fixes: 9e06d3f9f6b1 ("per task delay accounting taskstats interface: documentation fix")
Reported-by: Yafang Shao <laoar.shao@gmail.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Yafang Shao <laoar.shao@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Shailabh Nagar <nagar@watson.ibm.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200327173111.63922-1-dsahern@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 tools/accounting/getdelays.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/accounting/getdelays.c
+++ b/tools/accounting/getdelays.c
@@ -136,7 +136,7 @@ static int send_cmd(int sd, __u16 nlmsg_
 	msg.g.version = 0x1;
 	na = (struct nlattr *) GENLMSG_DATA(&msg);
 	na->nla_type = nla_type;
-	na->nla_len = nla_len + 1 + NLA_HDRLEN;
+	na->nla_len = nla_len + NLA_HDRLEN;
 	memcpy(NLA_DATA(na), nla_data, nla_len);
 	msg.n.nlmsg_len += NLMSG_ALIGN(na->nla_len);
 

[PATCH 4.19 38/54] hwrng: imx-rngc - fix an error path

[Greg Kroah-Hartman]

From: Martin Kaiser <martin@kaiser.cx>

commit 47a1f8e8b3637ff5f7806587883d7d94068d9ee8 upstream.

Make sure that the rngc interrupt is masked if the rngc self test fails.
Self test failure means that probe fails as well. Interrupts should be
masked in this case, regardless of the error.

Cc: stable@vger.kernel.org
Fixes: 1d5449445bd0 ("hwrng: mx-rngc - add a driver for Freescale RNGC")
Reviewed-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/char/hw_random/imx-rngc.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/char/hw_random/imx-rngc.c
+++ b/drivers/char/hw_random/imx-rngc.c
@@ -111,8 +111,10 @@ static int imx_rngc_self_test(struct imx
 		return -ETIMEDOUT;
 	}
 
-	if (rngc->err_reg != 0)
+	if (rngc->err_reg != 0) {
+		imx_rngc_irq_mask_clear(rngc);
 		return -EIO;
+	}
 
 	return 0;
 }

[PATCH 4.19 39/54] ASoC: jz4740-i2s: Fix divider written at incorrect offset in register

[Greg Kroah-Hartman]

From: Paul Cercueil <paul@crapouillou.net>

commit 9401d5aa328e64617d87abd59af1c91cace4c3e4 upstream.

The 4-bit divider value was written at offset 8, while the jz4740
programming manual locates it at offset 0.

Fixes: 26b0aad80a86 ("ASoC: jz4740: Add dynamic sampling rate support to jz4740-i2s")
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200306222931.39664-2-paul@crapouillou.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/soc/jz4740/jz4740-i2s.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/jz4740/jz4740-i2s.c
+++ b/sound/soc/jz4740/jz4740-i2s.c
@@ -92,7 +92,7 @@
 #define JZ_AIC_I2S_STATUS_BUSY BIT(2)
 
 #define JZ_AIC_CLK_DIV_MASK 0xf
-#define I2SDIV_DV_SHIFT 8
+#define I2SDIV_DV_SHIFT 0
 #define I2SDIV_DV_MASK (0xf << I2SDIV_DV_SHIFT)
 #define I2SDIV_IDV_SHIFT 8
 #define I2SDIV_IDV_MASK (0xf << I2SDIV_IDV_SHIFT)

[PATCH 4.19 40/54] IB/hfi1: Call kobject_put() when kobject_init_and_add() fails

[Greg Kroah-Hartman]

From: Kaike Wan <kaike.wan@intel.com>

commit dfb5394f804ed4fcea1fc925be275a38d66712ab upstream.

When kobject_init_and_add() returns an error in the function
hfi1_create_port_files(), the function kobject_put() is not called for the
corresponding kobject, which potentially leads to memory leak.

This patch fixes the issue by calling kobject_put() even if
kobject_init_and_add() fails.

Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200326163813.21129.44280.stgit@awfm-01.aw.intel.com
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/hw/hfi1/sysfs.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

--- a/drivers/infiniband/hw/hfi1/sysfs.c
+++ b/drivers/infiniband/hw/hfi1/sysfs.c
@@ -670,7 +670,11 @@ int hfi1_create_port_files(struct ib_dev
 		dd_dev_err(dd,
 			   "Skipping sc2vl sysfs info, (err %d) port %u\n",
 			   ret, port_num);
-		goto bail;
+		/*
+		 * Based on the documentation for kobject_init_and_add(), the
+		 * caller should call kobject_put even if this call fails.
+		 */
+		goto bail_sc2vl;
 	}
 	kobject_uevent(&ppd->sc2vl_kobj, KOBJ_ADD);
 
@@ -680,7 +684,7 @@ int hfi1_create_port_files(struct ib_dev
 		dd_dev_err(dd,
 			   "Skipping sl2sc sysfs info, (err %d) port %u\n",
 			   ret, port_num);
-		goto bail_sc2vl;
+		goto bail_sl2sc;
 	}
 	kobject_uevent(&ppd->sl2sc_kobj, KOBJ_ADD);
 
@@ -690,7 +694,7 @@ int hfi1_create_port_files(struct ib_dev
 		dd_dev_err(dd,
 			   "Skipping vl2mtu sysfs info, (err %d) port %u\n",
 			   ret, port_num);
-		goto bail_sl2sc;
+		goto bail_vl2mtu;
 	}
 	kobject_uevent(&ppd->vl2mtu_kobj, KOBJ_ADD);
 
@@ -700,7 +704,7 @@ int hfi1_create_port_files(struct ib_dev
 		dd_dev_err(dd,
 			   "Skipping Congestion Control sysfs info, (err %d) port %u\n",
 			   ret, port_num);
-		goto bail_vl2mtu;
+		goto bail_cc;
 	}
 
 	kobject_uevent(&ppd->pport_cc_kobj, KOBJ_ADD);
@@ -738,7 +742,6 @@ bail_sl2sc:
 	kobject_put(&ppd->sl2sc_kobj);
 bail_sc2vl:
 	kobject_put(&ppd->sc2vl_kobj);
-bail:
 	return ret;
 }
 

[PATCH 4.19 41/54] IB/hfi1: Fix memory leaks in sysfs registration and unregistration

[Greg Kroah-Hartman]

From: Kaike Wan <kaike.wan@intel.com>

commit 5c15abc4328ad696fa61e2f3604918ed0c207755 upstream.

When the hfi1 driver is unloaded, kmemleak will report the following
issue:

unreferenced object 0xffff8888461a4c08 (size 8):
comm "kworker/0:0", pid 5, jiffies 4298601264 (age 2047.134s)
hex dump (first 8 bytes):
73 64 6d 61 30 00 ff ff sdma0...
backtrace:
[<00000000311a6ef5>] kvasprintf+0x62/0xd0
[<00000000ade94d9f>] kobject_set_name_vargs+0x1c/0x90
[<0000000060657dbb>] kobject_init_and_add+0x5d/0xb0
[<00000000346fe72b>] 0xffffffffa0c5ecba
[<000000006cfc5819>] 0xffffffffa0c866b9
[<0000000031c65580>] 0xffffffffa0c38e87
[<00000000e9739b3f>] local_pci_probe+0x41/0x80
[<000000006c69911d>] work_for_cpu_fn+0x16/0x20
[<00000000601267b5>] process_one_work+0x171/0x380
[<0000000049a0eefa>] worker_thread+0x1d1/0x3f0
[<00000000909cf2b9>] kthread+0xf8/0x130
[<0000000058f5f874>] ret_from_fork+0x35/0x40

This patch fixes the issue by:

- Releasing dd->per_sdma[i].kobject in hfi1_unregister_sysfs().
  - This will fix the memory leak.

- Calling kobject_put() to unwind operations only for those entries in
   dd->per_sdma[] whose operations have succeeded (including the current
   one that has just failed) in hfi1_verbs_register_sysfs().

Cc: <stable@vger.kernel.org>
Fixes: 0cb2aa690c7e ("IB/hfi1: Add sysfs interface for affinity setup")
Link: https://lore.kernel.org/r/20200326163807.21129.27371.stgit@awfm-01.aw.intel.com
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/hw/hfi1/sysfs.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

--- a/drivers/infiniband/hw/hfi1/sysfs.c
+++ b/drivers/infiniband/hw/hfi1/sysfs.c
@@ -861,8 +861,13 @@ bail:
 	for (i = 0; i < ARRAY_SIZE(hfi1_attributes); ++i)
 		device_remove_file(&dev->dev, hfi1_attributes[i]);
 
-	for (i = 0; i < dd->num_sdma; i++)
-		kobject_del(&dd->per_sdma[i].kobj);
+	/*
+	 * The function kobject_put() will call kobject_del() if the kobject
+	 * has been added successfully. The sysfs files created under the
+	 * kobject directory will also be removed during the process.
+	 */
+	for (; i >= 0; i--)
+		kobject_put(&dd->per_sdma[i].kobj);
 
 	return ret;
 }
@@ -875,6 +880,10 @@ void hfi1_verbs_unregister_sysfs(struct
 	struct hfi1_pportdata *ppd;
 	int i;
 
+	/* Unwind operations in hfi1_verbs_register_sysfs() */
+	for (i = 0; i < dd->num_sdma; i++)
+		kobject_put(&dd->per_sdma[i].kobj);
+
 	for (i = 0; i < dd->num_pports; i++) {
 		ppd = &dd->pport[i];
 

[PATCH 4.19 42/54] ceph: remove the extra slashes in the server path

[Greg Kroah-Hartman]

From: Xiubo Li <xiubli@redhat.com>

commit 4fbc0c711b2464ee1551850b85002faae0b775d5 upstream.

It's possible to pass the mount helper a server path that has more
than one contiguous slash character. For example:

  $ mount -t ceph 192.168.195.165:40176:/// /mnt/cephfs/

In the MDS server side the extra slashes of the server path will be
treated as snap dir, and then we can get the following debug logs:

  ceph:  mount opening path //
  ceph:  open_root_inode opening '//'
  ceph:  fill_trace 0000000059b8a3bc is_dentry 0 is_target 1
  ceph:  alloc_inode 00000000dc4ca00b
  ceph:  get_inode created new inode 00000000dc4ca00b 1.ffffffffffffffff ino 1
  ceph:  get_inode on 1=1.ffffffffffffffff got 00000000dc4ca00b

And then when creating any new file or directory under the mount
point, we can hit the following BUG_ON in ceph_fill_trace():

  BUG_ON(ceph_snap(dir) != dvino.snap);

Have the client ignore the extra slashes in the server path when
mounting. This will also canonicalize the path, so that identical mounts
can be consilidated.

1) "//mydir1///mydir//"
2) "/mydir1/mydir"
3) "/mydir1/mydir/"

Regardless of the internal treatment of these paths, the kernel still
stores the original string including the leading '/' for presentation
to userland.

URL: https://tracker.ceph.com/issues/42771
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 fs/ceph/super.c |  120 +++++++++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 101 insertions(+), 19 deletions(-)

--- a/fs/ceph/super.c
+++ b/fs/ceph/super.c
@@ -105,7 +105,6 @@ static int ceph_statfs(struct dentry *de
 	return 0;
 }
 
-
 static int ceph_sync_fs(struct super_block *sb, int wait)
 {
 	struct ceph_fs_client *fsc = ceph_sb_to_client(sb);
@@ -399,6 +398,73 @@ static int strcmp_null(const char *s1, c
 	return strcmp(s1, s2);
 }
 
+/**
+ * path_remove_extra_slash - Remove the extra slashes in the server path
+ * @server_path: the server path and could be NULL
+ *
+ * Return NULL if the path is NULL or only consists of "/", or a string
+ * without any extra slashes including the leading slash(es) and the
+ * slash(es) at the end of the server path, such as:
+ * "//dir1////dir2///" --> "dir1/dir2"
+ */
+static char *path_remove_extra_slash(const char *server_path)
+{
+	const char *path = server_path;
+	const char *cur, *end;
+	char *buf, *p;
+	int len;
+
+	/* if the server path is omitted */
+	if (!path)
+		return NULL;
+
+	/* remove all the leading slashes */
+	while (*path == '/')
+		path++;
+
+	/* if the server path only consists of slashes */
+	if (*path == '\0')
+		return NULL;
+
+	len = strlen(path);
+
+	buf = kmalloc(len + 1, GFP_KERNEL);
+	if (!buf)
+		return ERR_PTR(-ENOMEM);
+
+	end = path + len;
+	p = buf;
+	do {
+		cur = strchr(path, '/');
+		if (!cur)
+			cur = end;
+
+		len = cur - path;
+
+		/* including one '/' */
+		if (cur != end)
+			len += 1;
+
+		memcpy(p, path, len);
+		p += len;
+
+		while (cur <= end && *cur == '/')
+			cur++;
+		path = cur;
+	} while (path < end);
+
+	*p = '\0';
+
+	/*
+	 * remove the last slash if there has and just to make sure that
+	 * we will get something like "dir1/dir2"
+	 */
+	if (*(--p) == '/')
+		*p = '\0';
+
+	return buf;
+}
+
 static int compare_mount_options(struct ceph_mount_options *new_fsopt,
 				 struct ceph_options *new_opt,
 				 struct ceph_fs_client *fsc)
@@ -406,6 +472,7 @@ static int compare_mount_options(struct
 	struct ceph_mount_options *fsopt1 = new_fsopt;
 	struct ceph_mount_options *fsopt2 = fsc->mount_options;
 	int ofs = offsetof(struct ceph_mount_options, snapdir_name);
+	char *p1, *p2;
 	int ret;
 
 	ret = memcmp(fsopt1, fsopt2, ofs);
@@ -418,9 +485,21 @@ static int compare_mount_options(struct
 	ret = strcmp_null(fsopt1->mds_namespace, fsopt2->mds_namespace);
 	if (ret)
 		return ret;
-	ret = strcmp_null(fsopt1->server_path, fsopt2->server_path);
+
+	p1 = path_remove_extra_slash(fsopt1->server_path);
+	if (IS_ERR(p1))
+		return PTR_ERR(p1);
+	p2 = path_remove_extra_slash(fsopt2->server_path);
+	if (IS_ERR(p2)) {
+		kfree(p1);
+		return PTR_ERR(p2);
+	}
+	ret = strcmp_null(p1, p2);
+	kfree(p1);
+	kfree(p2);
 	if (ret)
 		return ret;
+
 	ret = strcmp_null(fsopt1->fscache_uniq, fsopt2->fscache_uniq);
 	if (ret)
 		return ret;
@@ -476,12 +555,14 @@ static int parse_mount_options(struct ce
 	 */
 	dev_name_end = strchr(dev_name, '/');
 	if (dev_name_end) {
-		if (strlen(dev_name_end) > 1) {
-			fsopt->server_path = kstrdup(dev_name_end, GFP_KERNEL);
-			if (!fsopt->server_path) {
-				err = -ENOMEM;
-				goto out;
-			}
+		/*
+		 * The server_path will include the whole chars from userland
+		 * including the leading '/'.
+		 */
+		fsopt->server_path = kstrdup(dev_name_end, GFP_KERNEL);
+		if (!fsopt->server_path) {
+			err = -ENOMEM;
+			goto out;
 		}
 	} else {
 		dev_name_end = dev_name + strlen(dev_name);
@@ -810,7 +891,6 @@ static void destroy_caches(void)
 	ceph_fscache_unregister();
 }
 
-
 /*
  * ceph_umount_begin - initiate forced umount.  Tear down down the
  * mount, skipping steps that may hang while waiting for server(s).
@@ -897,9 +977,6 @@ out:
 	return root;
 }
 
-
-
-
 /*
  * mount: join the ceph cluster, and open root directory.
  */
@@ -913,7 +990,7 @@ static struct dentry *ceph_real_mount(st
 	mutex_lock(&fsc->client->mount_mutex);
 
 	if (!fsc->sb->s_root) {
-		const char *path;
+		const char *path, *p;
 		err = __ceph_open_session(fsc->client, started);
 		if (err < 0)
 			goto out;
@@ -925,19 +1002,24 @@ static struct dentry *ceph_real_mount(st
 				goto out;
 		}
 
-		if (!fsc->mount_options->server_path) {
-			path = "";
-			dout("mount opening path \\t\n");
-		} else {
-			path = fsc->mount_options->server_path + 1;
-			dout("mount opening path %s\n", path);
+		p = path_remove_extra_slash(fsc->mount_options->server_path);
+		if (IS_ERR(p)) {
+			err = PTR_ERR(p);
+			goto out;
 		}
+		/* if the server path is omitted or just consists of '/' */
+		if (!p)
+			path = "";
+		else
+			path = p;
+		dout("mount opening path '%s'\n", path);
 
 		err = ceph_fs_debugfs_init(fsc);
 		if (err < 0)
 			goto out;
 
 		root = open_root_dentry(fsc, path, started);
+		kfree(p);
 		if (IS_ERR(root)) {
 			err = PTR_ERR(root);
 			goto out;

[PATCH 4.19 43/54] ceph: canonicalize server path in place

[Greg Kroah-Hartman]

From: Ilya Dryomov <idryomov@gmail.com>

commit b27a939e8376a3f1ed09b9c33ef44d20f18ec3d0 upstream.

syzbot reported that 4fbc0c711b24 ("ceph: remove the extra slashes in
the server path") had caused a regression where an allocation could be
done under a spinlock -- compare_mount_options() is called by sget_fc()
with sb_lock held.

We don't really need the supplied server path, so canonicalize it
in place and compare it directly.  To make this work, the leading
slash is kept around and the logic in ceph_real_mount() to skip it
is restored.  CEPH_MSG_CLIENT_SESSION now reports the same (i.e.
canonicalized) path, with the leading slash of course.

Fixes: 4fbc0c711b24 ("ceph: remove the extra slashes in the server path")
Reported-by: syzbot+98704a51af8e3d9425a9@syzkaller.appspotmail.com
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 fs/ceph/super.c |  118 ++++++++++++--------------------------------------------
 fs/ceph/super.h |    2 
 2 files changed, 28 insertions(+), 92 deletions(-)

--- a/fs/ceph/super.c
+++ b/fs/ceph/super.c
@@ -205,6 +205,26 @@ static match_table_t fsopt_tokens = {
 	{-1, NULL}
 };
 
+/*
+ * Remove adjacent slashes and then the trailing slash, unless it is
+ * the only remaining character.
+ *
+ * E.g. "//dir1////dir2///" --> "/dir1/dir2", "///" --> "/".
+ */
+static void canonicalize_path(char *path)
+{
+	int i, j = 0;
+
+	for (i = 0; path[i] != '\0'; i++) {
+		if (path[i] != '/' || j < 1 || path[j - 1] != '/')
+			path[j++] = path[i];
+	}
+
+	if (j > 1 && path[j - 1] == '/')
+		j--;
+	path[j] = '\0';
+}
+
 static int parse_fsopt_token(char *c, void *private)
 {
 	struct ceph_mount_options *fsopt = private;
@@ -398,73 +418,6 @@ static int strcmp_null(const char *s1, c
 	return strcmp(s1, s2);
 }
 
-/**
- * path_remove_extra_slash - Remove the extra slashes in the server path
- * @server_path: the server path and could be NULL
- *
- * Return NULL if the path is NULL or only consists of "/", or a string
- * without any extra slashes including the leading slash(es) and the
- * slash(es) at the end of the server path, such as:
- * "//dir1////dir2///" --> "dir1/dir2"
- */
-static char *path_remove_extra_slash(const char *server_path)
-{
-	const char *path = server_path;
-	const char *cur, *end;
-	char *buf, *p;
-	int len;
-
-	/* if the server path is omitted */
-	if (!path)
-		return NULL;
-
-	/* remove all the leading slashes */
-	while (*path == '/')
-		path++;
-
-	/* if the server path only consists of slashes */
-	if (*path == '\0')
-		return NULL;
-
-	len = strlen(path);
-
-	buf = kmalloc(len + 1, GFP_KERNEL);
-	if (!buf)
-		return ERR_PTR(-ENOMEM);
-
-	end = path + len;
-	p = buf;
-	do {
-		cur = strchr(path, '/');
-		if (!cur)
-			cur = end;
-
-		len = cur - path;
-
-		/* including one '/' */
-		if (cur != end)
-			len += 1;
-
-		memcpy(p, path, len);
-		p += len;
-
-		while (cur <= end && *cur == '/')
-			cur++;
-		path = cur;
-	} while (path < end);
-
-	*p = '\0';
-
-	/*
-	 * remove the last slash if there has and just to make sure that
-	 * we will get something like "dir1/dir2"
-	 */
-	if (*(--p) == '/')
-		*p = '\0';
-
-	return buf;
-}
-
 static int compare_mount_options(struct ceph_mount_options *new_fsopt,
 				 struct ceph_options *new_opt,
 				 struct ceph_fs_client *fsc)
@@ -472,7 +425,6 @@ static int compare_mount_options(struct
 	struct ceph_mount_options *fsopt1 = new_fsopt;
 	struct ceph_mount_options *fsopt2 = fsc->mount_options;
 	int ofs = offsetof(struct ceph_mount_options, snapdir_name);
-	char *p1, *p2;
 	int ret;
 
 	ret = memcmp(fsopt1, fsopt2, ofs);
@@ -482,21 +434,12 @@ static int compare_mount_options(struct
 	ret = strcmp_null(fsopt1->snapdir_name, fsopt2->snapdir_name);
 	if (ret)
 		return ret;
+
 	ret = strcmp_null(fsopt1->mds_namespace, fsopt2->mds_namespace);
 	if (ret)
 		return ret;
 
-	p1 = path_remove_extra_slash(fsopt1->server_path);
-	if (IS_ERR(p1))
-		return PTR_ERR(p1);
-	p2 = path_remove_extra_slash(fsopt2->server_path);
-	if (IS_ERR(p2)) {
-		kfree(p1);
-		return PTR_ERR(p2);
-	}
-	ret = strcmp_null(p1, p2);
-	kfree(p1);
-	kfree(p2);
+	ret = strcmp_null(fsopt1->server_path, fsopt2->server_path);
 	if (ret)
 		return ret;
 
@@ -564,6 +507,8 @@ static int parse_mount_options(struct ce
 			err = -ENOMEM;
 			goto out;
 		}
+
+		canonicalize_path(fsopt->server_path);
 	} else {
 		dev_name_end = dev_name + strlen(dev_name);
 	}
@@ -990,7 +935,9 @@ static struct dentry *ceph_real_mount(st
 	mutex_lock(&fsc->client->mount_mutex);
 
 	if (!fsc->sb->s_root) {
-		const char *path, *p;
+		const char *path = fsc->mount_options->server_path ?
+				     fsc->mount_options->server_path + 1 : "";
+
 		err = __ceph_open_session(fsc->client, started);
 		if (err < 0)
 			goto out;
@@ -1002,16 +949,6 @@ static struct dentry *ceph_real_mount(st
 				goto out;
 		}
 
-		p = path_remove_extra_slash(fsc->mount_options->server_path);
-		if (IS_ERR(p)) {
-			err = PTR_ERR(p);
-			goto out;
-		}
-		/* if the server path is omitted or just consists of '/' */
-		if (!p)
-			path = "";
-		else
-			path = p;
 		dout("mount opening path '%s'\n", path);
 
 		err = ceph_fs_debugfs_init(fsc);
@@ -1019,7 +956,6 @@ static struct dentry *ceph_real_mount(st
 			goto out;
 
 		root = open_root_dentry(fsc, path, started);
-		kfree(p);
 		if (IS_ERR(root)) {
 			err = PTR_ERR(root);
 			goto out;
--- a/fs/ceph/super.h
+++ b/fs/ceph/super.h
@@ -86,7 +86,7 @@ struct ceph_mount_options {
 
 	char *snapdir_name;   /* default ".snap" */
 	char *mds_namespace;  /* default NULL */
-	char *server_path;    /* default  "/" */
+	char *server_path;    /* default NULL (means "/") */
 	char *fscache_uniq;   /* default NULL */
 };
 

[PATCH 4.19 44/54] RDMA/ucma: Put a lock around every call to the rdma_cm layer

[Greg Kroah-Hartman]

From: Jason Gunthorpe <jgg@mellanox.com>

commit 7c11910783a1ea17e88777552ef146cace607b3c upstream.

The rdma_cm must be used single threaded.

This appears to be a bug in the design, as it does have lots of locking
that seems like it should allow concurrency. However, when it is all said
and done every single place that uses the cma_exch() scheme is broken, and
all the unlocked reads from the ucma of the cm_id data are wrong too.

syzkaller has been finding endless bugs related to this.

Fixing this in any elegant way is some enormous amount of work. Take a
very big hammer and put a mutex around everything to do with the
ucma_context at the top of every syscall.

Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
Link: https://lore.kernel.org/r/20200218210432.GA31966@ziepe.ca
Reported-by: syzbot+adb15cf8c2798e4e0db4@syzkaller.appspotmail.com
Reported-by: syzbot+e5579222b6a3edd96522@syzkaller.appspotmail.com
Reported-by: syzbot+4b628fcc748474003457@syzkaller.appspotmail.com
Reported-by: syzbot+29ee8f76017ce6cf03da@syzkaller.appspotmail.com
Reported-by: syzbot+6956235342b7317ec564@syzkaller.appspotmail.com
Reported-by: syzbot+b358909d8d01556b790b@syzkaller.appspotmail.com
Reported-by: syzbot+6b46b135602a3f3ac99e@syzkaller.appspotmail.com
Reported-by: syzbot+8458d13b13562abf6b77@syzkaller.appspotmail.com
Reported-by: syzbot+bd034f3fdc0402e942ed@syzkaller.appspotmail.com
Reported-by: syzbot+c92378b32760a4eef756@syzkaller.appspotmail.com
Reported-by: syzbot+68b44a1597636e0b342c@syzkaller.appspotmail.com
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/core/ucma.c |   49 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 47 insertions(+), 2 deletions(-)

--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -89,6 +89,7 @@ struct ucma_context {
 
 	struct ucma_file	*file;
 	struct rdma_cm_id	*cm_id;
+	struct mutex		mutex;
 	u64			uid;
 
 	struct list_head	list;
@@ -215,6 +216,7 @@ static struct ucma_context *ucma_alloc_c
 	init_completion(&ctx->comp);
 	INIT_LIST_HEAD(&ctx->mc_list);
 	ctx->file = file;
+	mutex_init(&ctx->mutex);
 
 	mutex_lock(&mut);
 	ctx->id = idr_alloc(&ctx_idr, ctx, 0, 0, GFP_KERNEL);
@@ -596,6 +598,7 @@ static int ucma_free_ctx(struct ucma_con
 	}
 
 	events_reported = ctx->events_reported;
+	mutex_destroy(&ctx->mutex);
 	kfree(ctx);
 	return events_reported;
 }
@@ -665,7 +668,10 @@ static ssize_t ucma_bind_ip(struct ucma_
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 
+	mutex_lock(&ctx->mutex);
 	ret = rdma_bind_addr(ctx->cm_id, (struct sockaddr *) &cmd.addr);
+	mutex_unlock(&ctx->mutex);
+
 	ucma_put_ctx(ctx);
 	return ret;
 }
@@ -688,7 +694,9 @@ static ssize_t ucma_bind(struct ucma_fil
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 
+	mutex_lock(&ctx->mutex);
 	ret = rdma_bind_addr(ctx->cm_id, (struct sockaddr *) &cmd.addr);
+	mutex_unlock(&ctx->mutex);
 	ucma_put_ctx(ctx);
 	return ret;
 }
@@ -712,8 +720,10 @@ static ssize_t ucma_resolve_ip(struct uc
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 
+	mutex_lock(&ctx->mutex);
 	ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr,
 				(struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms);
+	mutex_unlock(&ctx->mutex);
 	ucma_put_ctx(ctx);
 	return ret;
 }
@@ -738,8 +748,10 @@ static ssize_t ucma_resolve_addr(struct
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 
+	mutex_lock(&ctx->mutex);
 	ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr,
 				(struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms);
+	mutex_unlock(&ctx->mutex);
 	ucma_put_ctx(ctx);
 	return ret;
 }
@@ -759,7 +771,9 @@ static ssize_t ucma_resolve_route(struct
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 
+	mutex_lock(&ctx->mutex);
 	ret = rdma_resolve_route(ctx->cm_id, cmd.timeout_ms);
+	mutex_unlock(&ctx->mutex);
 	ucma_put_ctx(ctx);
 	return ret;
 }
@@ -848,6 +862,7 @@ static ssize_t ucma_query_route(struct u
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 
+	mutex_lock(&ctx->mutex);
 	memset(&resp, 0, sizeof resp);
 	addr = (struct sockaddr *) &ctx->cm_id->route.addr.src_addr;
 	memcpy(&resp.src_addr, addr, addr->sa_family == AF_INET ?
@@ -871,6 +886,7 @@ static ssize_t ucma_query_route(struct u
 		ucma_copy_iw_route(&resp, &ctx->cm_id->route);
 
 out:
+	mutex_unlock(&ctx->mutex);
 	if (copy_to_user(u64_to_user_ptr(cmd.response),
 			 &resp, sizeof(resp)))
 		ret = -EFAULT;
@@ -1022,6 +1038,7 @@ static ssize_t ucma_query(struct ucma_fi
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 
+	mutex_lock(&ctx->mutex);
 	switch (cmd.option) {
 	case RDMA_USER_CM_QUERY_ADDR:
 		ret = ucma_query_addr(ctx, response, out_len);
@@ -1036,6 +1053,7 @@ static ssize_t ucma_query(struct ucma_fi
 		ret = -ENOSYS;
 		break;
 	}
+	mutex_unlock(&ctx->mutex);
 
 	ucma_put_ctx(ctx);
 	return ret;
@@ -1076,7 +1094,9 @@ static ssize_t ucma_connect(struct ucma_
 		return PTR_ERR(ctx);
 
 	ucma_copy_conn_param(ctx->cm_id, &conn_param, &cmd.conn_param);
+	mutex_lock(&ctx->mutex);
 	ret = rdma_connect(ctx->cm_id, &conn_param);
+	mutex_unlock(&ctx->mutex);
 	ucma_put_ctx(ctx);
 	return ret;
 }
@@ -1097,7 +1117,9 @@ static ssize_t ucma_listen(struct ucma_f
 
 	ctx->backlog = cmd.backlog > 0 && cmd.backlog < max_backlog ?
 		       cmd.backlog : max_backlog;
+	mutex_lock(&ctx->mutex);
 	ret = rdma_listen(ctx->cm_id, ctx->backlog);
+	mutex_unlock(&ctx->mutex);
 	ucma_put_ctx(ctx);
 	return ret;
 }
@@ -1120,13 +1142,17 @@ static ssize_t ucma_accept(struct ucma_f
 	if (cmd.conn_param.valid) {
 		ucma_copy_conn_param(ctx->cm_id, &conn_param, &cmd.conn_param);
 		mutex_lock(&file->mut);
+		mutex_lock(&ctx->mutex);
 		ret = __rdma_accept(ctx->cm_id, &conn_param, NULL);
+		mutex_unlock(&ctx->mutex);
 		if (!ret)
 			ctx->uid = cmd.uid;
 		mutex_unlock(&file->mut);
-	} else
+	} else {
+		mutex_lock(&ctx->mutex);
 		ret = __rdma_accept(ctx->cm_id, NULL, NULL);
-
+		mutex_unlock(&ctx->mutex);
+	}
 	ucma_put_ctx(ctx);
 	return ret;
 }
@@ -1145,7 +1171,9 @@ static ssize_t ucma_reject(struct ucma_f
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 
+	mutex_lock(&ctx->mutex);
 	ret = rdma_reject(ctx->cm_id, cmd.private_data, cmd.private_data_len);
+	mutex_unlock(&ctx->mutex);
 	ucma_put_ctx(ctx);
 	return ret;
 }
@@ -1164,7 +1192,9 @@ static ssize_t ucma_disconnect(struct uc
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 
+	mutex_lock(&ctx->mutex);
 	ret = rdma_disconnect(ctx->cm_id);
+	mutex_unlock(&ctx->mutex);
 	ucma_put_ctx(ctx);
 	return ret;
 }
@@ -1195,7 +1225,9 @@ static ssize_t ucma_init_qp_attr(struct
 	resp.qp_attr_mask = 0;
 	memset(&qp_attr, 0, sizeof qp_attr);
 	qp_attr.qp_state = cmd.qp_state;
+	mutex_lock(&ctx->mutex);
 	ret = rdma_init_qp_attr(ctx->cm_id, &qp_attr, &resp.qp_attr_mask);
+	mutex_unlock(&ctx->mutex);
 	if (ret)
 		goto out;
 
@@ -1274,9 +1306,13 @@ static int ucma_set_ib_path(struct ucma_
 		struct sa_path_rec opa;
 
 		sa_convert_path_ib_to_opa(&opa, &sa_path);
+		mutex_lock(&ctx->mutex);
 		ret = rdma_set_ib_path(ctx->cm_id, &opa);
+		mutex_unlock(&ctx->mutex);
 	} else {
+		mutex_lock(&ctx->mutex);
 		ret = rdma_set_ib_path(ctx->cm_id, &sa_path);
+		mutex_unlock(&ctx->mutex);
 	}
 	if (ret)
 		return ret;
@@ -1309,7 +1345,9 @@ static int ucma_set_option_level(struct
 
 	switch (level) {
 	case RDMA_OPTION_ID:
+		mutex_lock(&ctx->mutex);
 		ret = ucma_set_option_id(ctx, optname, optval, optlen);
+		mutex_unlock(&ctx->mutex);
 		break;
 	case RDMA_OPTION_IB:
 		ret = ucma_set_option_ib(ctx, optname, optval, optlen);
@@ -1369,8 +1407,10 @@ static ssize_t ucma_notify(struct ucma_f
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 
+	mutex_lock(&ctx->mutex);
 	if (ctx->cm_id->device)
 		ret = rdma_notify(ctx->cm_id, (enum ib_event_type)cmd.event);
+	mutex_unlock(&ctx->mutex);
 
 	ucma_put_ctx(ctx);
 	return ret;
@@ -1413,8 +1453,10 @@ static ssize_t ucma_process_join(struct
 	mc->join_state = join_state;
 	mc->uid = cmd->uid;
 	memcpy(&mc->addr, addr, cmd->addr_size);
+	mutex_lock(&ctx->mutex);
 	ret = rdma_join_multicast(ctx->cm_id, (struct sockaddr *)&mc->addr,
 				  join_state, mc);
+	mutex_unlock(&ctx->mutex);
 	if (ret)
 		goto err2;
 
@@ -1518,7 +1560,10 @@ static ssize_t ucma_leave_multicast(stru
 		goto out;
 	}
 
+	mutex_lock(&mc->ctx->mutex);
 	rdma_leave_multicast(mc->ctx->cm_id, (struct sockaddr *) &mc->addr);
+	mutex_unlock(&mc->ctx->mutex);
+
 	mutex_lock(&mc->ctx->file->mut);
 	ucma_cleanup_mc_events(mc);
 	list_del(&mc->list);

[PATCH 4.19 45/54] RDMA/cma: Teach lockdep about the order of rtnl and lock

[Greg Kroah-Hartman]

From: Jason Gunthorpe <jgg@mellanox.com>

commit 32ac9e4399b12d3e54d312a0e0e30ed5cd19bd4e upstream.

This lock ordering only happens when bonding is enabled and a certain
bonding related event fires. However, since it can happen this is a global
restriction on lock ordering.

Teach lockdep about the order directly and unconditionally so bugs here
are found quickly.

See https://syzkaller.appspot.com/bug?extid=55de90ab5f44172b0c90

Link: https://lore.kernel.org/r/20200227203651.GA27185@ziepe.ca
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/core/cma.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -4635,6 +4635,19 @@ static int __init cma_init(void)
 {
 	int ret;
 
+	/*
+	 * There is a rare lock ordering dependency in cma_netdev_callback()
+	 * that only happens when bonding is enabled. Teach lockdep that rtnl
+	 * must never be nested under lock so it can find these without having
+	 * to test with bonding.
+	 */
+	if (IS_ENABLED(CONFIG_LOCKDEP)) {
+		rtnl_lock();
+		mutex_lock(&lock);
+		mutex_unlock(&lock);
+		rtnl_unlock();
+	}
+
 	cma_wq = alloc_ordered_workqueue("rdma_cm", WQ_MEM_RECLAIM);
 	if (!cma_wq)
 		return -ENOMEM;

[PATCH 4.19 46/54] Bluetooth: RFCOMM: fix ODEBUG bug in rfcomm_dev_ioctl

[Greg Kroah-Hartman]

From: Qiujun Huang <hqjagain@gmail.com>

commit 71811cac8532b2387b3414f7cd8fe9e497482864 upstream.

Needn't call 'rfcomm_dlc_put' here, because 'rfcomm_dlc_exists' didn't
increase dlc->refcnt.

Reported-by: syzbot+4496e82090657320efc6@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
Suggested-by: Hillf Danton <hdanton@sina.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/bluetooth/rfcomm/tty.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -413,10 +413,8 @@ static int __rfcomm_create_dev(struct so
 		dlc = rfcomm_dlc_exists(&req.src, &req.dst, req.channel);
 		if (IS_ERR(dlc))
 			return PTR_ERR(dlc);
-		else if (dlc) {
-			rfcomm_dlc_put(dlc);
+		if (dlc)
 			return -EBUSY;
-		}
 		dlc = rfcomm_dlc_alloc(GFP_KERNEL);
 		if (!dlc)
 			return -ENOMEM;

[PATCH 4.19 47/54] RDMA/cm: Update num_paths in cma_resolve_iboe_route error flow

[Greg Kroah-Hartman]

From: Avihai Horon <avihaih@mellanox.com>

commit 987914ab841e2ec281a35b54348ab109b4c0bb4e upstream.

After a successful allocation of path_rec, num_paths is set to 1, but any
error after such allocation will leave num_paths uncleared.

This causes to de-referencing a NULL pointer later on. Hence, num_paths
needs to be set back to 0 if such an error occurs.

The following crash from syzkaller revealed it.

  kasan: CONFIG_KASAN_INLINE enabled
  kasan: GPF could be caused by NULL-ptr deref or user memory access
  general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
  CPU: 0 PID: 357 Comm: syz-executor060 Not tainted 4.18.0+ #311
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
  rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
  RIP: 0010:ib_copy_path_rec_to_user+0x94/0x3e0
  Code: f1 f1 f1 f1 c7 40 0c 00 00 f4 f4 65 48 8b 04 25 28 00 00 00 48 89
  45 c8 31 c0 e8 d7 60 24 ff 48 8d 7b 4c 48 89 f8 48 c1 e8 03 <42> 0f b6
  14 30 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
  RSP: 0018:ffff88006586f980 EFLAGS: 00010207
  RAX: 0000000000000009 RBX: 0000000000000000 RCX: 1ffff1000d5fe475
  RDX: ffff8800621e17c0 RSI: ffffffff820d45f9 RDI: 000000000000004c
  RBP: ffff88006586fa50 R08: ffffed000cb0df73 R09: ffffed000cb0df72
  R10: ffff88006586fa70 R11: ffffed000cb0df73 R12: 1ffff1000cb0df30
  R13: ffff88006586fae8 R14: dffffc0000000000 R15: ffff88006aff2200
  FS: 00000000016fc880(0000) GS:ffff88006d000000(0000)
  knlGS:0000000000000000
  CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000020000040 CR3: 0000000063fec000 CR4: 00000000000006b0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
  ? ib_copy_path_rec_from_user+0xcc0/0xcc0
  ? __mutex_unlock_slowpath+0xfc/0x670
  ? wait_for_completion+0x3b0/0x3b0
  ? ucma_query_route+0x818/0xc60
  ucma_query_route+0x818/0xc60
  ? ucma_listen+0x1b0/0x1b0
  ? sched_clock_cpu+0x18/0x1d0
  ? sched_clock_cpu+0x18/0x1d0
  ? ucma_listen+0x1b0/0x1b0
  ? ucma_write+0x292/0x460
  ucma_write+0x292/0x460
  ? ucma_close_id+0x60/0x60
  ? sched_clock_cpu+0x18/0x1d0
  ? sched_clock_cpu+0x18/0x1d0
  __vfs_write+0xf7/0x620
  ? ucma_close_id+0x60/0x60
  ? kernel_read+0x110/0x110
  ? time_hardirqs_on+0x19/0x580
  ? lock_acquire+0x18b/0x3a0
  ? finish_task_switch+0xf3/0x5d0
  ? _raw_spin_unlock_irq+0x29/0x40
  ? _raw_spin_unlock_irq+0x29/0x40
  ? finish_task_switch+0x1be/0x5d0
  ? __switch_to_asm+0x34/0x70
  ? __switch_to_asm+0x40/0x70
  ? security_file_permission+0x172/0x1e0
  vfs_write+0x192/0x460
  ksys_write+0xc6/0x1a0
  ? __ia32_sys_read+0xb0/0xb0
  ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe
  ? do_syscall_64+0x1d/0x470
  do_syscall_64+0x9e/0x470
  entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fixes: 3c86aa70bf67 ("RDMA/cm: Add RDMA CM support for IBoE devices")
Link: https://lore.kernel.org/r/20200318101741.47211-1-leon@kernel.org
Signed-off-by: Avihai Horon <avihaih@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/core/cma.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -2753,6 +2753,7 @@ static int cma_resolve_iboe_route(struct
 err2:
 	kfree(route->path_rec);
 	route->path_rec = NULL;
+	route->num_paths = 0;
 err1:
 	kfree(work);
 	return ret;

[PATCH 4.19 48/54] fbcon: fix null-ptr-deref in fbcon_switch

[Greg Kroah-Hartman]

From: Qiujun Huang <hqjagain@gmail.com>

commit b139f8b00db4a8ea75a4174346eafa48041aa489 upstream.

Set logo_shown to FBCON_LOGO_CANSHOW when the vc was deallocated.

syzkaller report: https://lkml.org/lkml/2020/3/27/403
general protection fault, probably for non-canonical address
0xdffffc000000006c: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000360-0x0000000000000367]
RIP: 0010:fbcon_switch+0x28f/0x1740
drivers/video/fbdev/core/fbcon.c:2260

Call Trace:
redraw_screen+0x2a8/0x770 drivers/tty/vt/vt.c:1008
vc_do_resize+0xfe7/0x1360 drivers/tty/vt/vt.c:1295
fbcon_init+0x1221/0x1ab0 drivers/video/fbdev/core/fbcon.c:1219
visual_init+0x305/0x5c0 drivers/tty/vt/vt.c:1062
do_bind_con_driver+0x536/0x890 drivers/tty/vt/vt.c:3542
do_take_over_console+0x453/0x5b0 drivers/tty/vt/vt.c:4122
do_fbcon_takeover+0x10b/0x210 drivers/video/fbdev/core/fbcon.c:588
fbcon_fb_registered+0x26b/0x340 drivers/video/fbdev/core/fbcon.c:3259
do_register_framebuffer drivers/video/fbdev/core/fbmem.c:1664 [inline]
register_framebuffer+0x56e/0x980 drivers/video/fbdev/core/fbmem.c:1832
dlfb_usb_probe.cold+0x1743/0x1ba3 drivers/video/fbdev/udlfb.c:1735
usb_probe_interface+0x310/0x800 drivers/usb/core/driver.c:374

accessing vc_cons[logo_shown].d->vc_top causes the bug.

Reported-by: syzbot+732528bae351682f1f27@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200329085647.25133-1-hqjagain@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/video/fbdev/core/fbcon.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1243,6 +1243,9 @@ finished:
 	if (!con_is_bound(&fb_con))
 		fbcon_exit();
 
+	if (vc->vc_num == logo_shown)
+		logo_shown = FBCON_LOGO_CANSHOW;
+
 	return;
 }
 

[PATCH 4.19 49/54] clk: qcom: rcg: Return failure for RCG update

[Greg Kroah-Hartman]

From: Taniya Das <tdas@codeaurora.org>

commit 21ea4b62e1f3dc258001a68da98c9663a9dbd6c7 upstream.

In case of update config failure, return -EBUSY, so that consumers could
handle the failure gracefully.

Signed-off-by: Taniya Das <tdas@codeaurora.org>
Link: https://lkml.kernel.org/r/1557339895-21952-2-git-send-email-tdas@codeaurora.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/clk/qcom/clk-rcg2.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -105,7 +105,7 @@ static int update_config(struct clk_rcg2
 	}
 
 	WARN(1, "%s: rcg didn't update its configuration.", name);
-	return 0;
+	return -EBUSY;
 }
 
 static int clk_rcg2_set_parent(struct clk_hw *hw, u8 index)

[PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache

[Greg Kroah-Hartman]

From: Rob Clark <robdclark@chromium.org>

commit 0036bc73ccbe7e600a3468bf8e8879b122252274 upstream.

Recently splats like this started showing up:

   WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451 __iommu_dma_unmap+0xb8/0xc0
   Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo cfg80211 videobuf2_vmalloc videobuf2_memops vide
   CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: G        W         5.2.0-rc5-next-20190619+ #2317
   Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
   Workqueue: msm msm_gem_free_work [msm]
   pstate: 80c00005 (Nzcv daif +PAN +UAO)
   pc : __iommu_dma_unmap+0xb8/0xc0
   lr : __iommu_dma_unmap+0x54/0xc0
   sp : ffff0000119abce0
   x29: ffff0000119abce0 x28: 0000000000000000
   x27: ffff8001f9946648 x26: ffff8001ec271068
   x25: 0000000000000000 x24: ffff8001ea3580a8
   x23: ffff8001f95ba010 x22: ffff80018e83ba88
   x21: ffff8001e548f000 x20: fffffffffffff000
   x19: 0000000000001000 x18: 00000000c00001fe
   x17: 0000000000000000 x16: 0000000000000000
   x15: ffff000015b70068 x14: 0000000000000005
   x13: 0003142cc1be1768 x12: 0000000000000001
   x11: ffff8001f6de9100 x10: 0000000000000009
   x9 : ffff000015b78000 x8 : 0000000000000000
   x7 : 0000000000000001 x6 : fffffffffffff000
   x5 : 0000000000000fff x4 : ffff00001065dbc8
   x3 : 000000000000000d x2 : 0000000000001000
   x1 : fffffffffffff000 x0 : 0000000000000000
   Call trace:
    __iommu_dma_unmap+0xb8/0xc0
    iommu_dma_unmap_sg+0x98/0xb8
    put_pages+0x5c/0xf0 [msm]
    msm_gem_free_work+0x10c/0x150 [msm]
    process_one_work+0x1e0/0x330
    worker_thread+0x40/0x438
    kthread+0x12c/0x130
    ret_from_fork+0x10/0x18
   ---[ end trace afc0dc5ab81a06bf ]---

Not quite sure what triggered that, but we really shouldn't be abusing
dma_{map,unmap}_sg() for cache maint.

Cc: Stephen Boyd <sboyd@kernel.org>
Tested-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdclark@gmail.com
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/msm/msm_gem.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -108,7 +108,7 @@ static struct page **get_pages(struct dr
 		 * because display controller, GPU, etc. are not coherent:
 		 */
 		if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
-			dma_map_sg(dev->dev, msm_obj->sgt->sgl,
+			dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl,
 					msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
 	}
 
@@ -138,7 +138,7 @@ static void put_pages(struct drm_gem_obj
 			 * GPU, etc. are not coherent:
 			 */
 			if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
-				dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
+				dma_sync_sg_for_cpu(obj->dev->dev, msm_obj->sgt->sgl,
 					     msm_obj->sgt->nents,
 					     DMA_BIDIRECTIONAL);
 

[PATCH 4.19 51/54] arm64: Fix size of __early_cpu_boot_status

[Greg Kroah-Hartman]

From: Arun KS <arunks@codeaurora.org>

commit 61cf61d81e326163ce1557ceccfca76e11d0e57c upstream.

__early_cpu_boot_status is of type long. Use quad
assembler directive to allocate proper size.

Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Arun KS <arunks@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm64/kernel/head.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -667,7 +667,7 @@ ENTRY(__boot_cpu_mode)
  * with MMU turned off.
  */
 ENTRY(__early_cpu_boot_status)
-	.long 	0
+	.quad 	0
 
 	.popsection
 

[PATCH 4.19 52/54] rpmsg: glink: Remove chunk size word align warning

[Greg Kroah-Hartman]

From: Chris Lew <clew@codeaurora.org>

commit f0beb4ba9b185d497c8efe7b349363700092aee0 upstream.

It is possible for the chunk sizes coming from the non RPM remote procs
to not be word aligned. Remove the alignment warning and continue to
read from the FIFO so execution is not stalled.

Signed-off-by: Chris Lew <clew@codeaurora.org>
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/rpmsg/qcom_glink_native.c |    3 ---
 1 file changed, 3 deletions(-)

--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -813,9 +813,6 @@ static int qcom_glink_rx_data(struct qco
 		return -EAGAIN;
 	}
 
-	if (WARN(chunk_size % 4, "Incoming data must be word aligned\n"))
-		return -EINVAL;
-
 	rcid = le16_to_cpu(hdr.msg.param1);
 	spin_lock_irqsave(&glink->idr_lock, flags);
 	channel = idr_find(&glink->rcids, rcid);

[PATCH 4.19 53/54] usb: dwc3: dont set gadget->is_otg flag

[Greg Kroah-Hartman]

From: Roger Quadros <rogerq@ti.com>

commit c09b73cfac2a9317f1104169045c519c6021aa1d upstream.

This reverts
commit 6a4290cc28be1 ("usb: dwc3: gadget: set the OTG flag in dwc3 gadget driver.")

We don't yet support any of the OTG mechanisms (HNP/SRP/ADP)
and are not setting gadget->otg_caps, so don't set gadget->is_otg
flag.

If we do then we end up publishing a OTG1.0 descriptor in
the gadget descriptor which causes device enumeration to fail
if we are connected to a host with CONFIG_USB_OTG enabled.

Host side log without this patch

[   96.720453] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[   96.901391] usb 1-1: Dual-Role OTG device on non-HNP port
[   96.907552] usb 1-1: set a_alt_hnp_support failed: -32
[   97.060447] usb 1-1: new high-speed USB device number 3 using xhci-hcd
[   97.241378] usb 1-1: Dual-Role OTG device on non-HNP port
[   97.247536] usb 1-1: set a_alt_hnp_support failed: -32
[   97.253606] usb usb1-port1: attempt power cycle
[   97.960449] usb 1-1: new high-speed USB device number 4 using xhci-hcd
[   98.141383] usb 1-1: Dual-Role OTG device on non-HNP port
[   98.147540] usb 1-1: set a_alt_hnp_support failed: -32
[   98.300453] usb 1-1: new high-speed USB device number 5 using xhci-hcd
[   98.481391] usb 1-1: Dual-Role OTG device on non-HNP port
[   98.487545] usb 1-1: set a_alt_hnp_support failed: -32
[   98.493532] usb usb1-port1: unable to enumerate USB device

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/usb/dwc3/gadget.c |    1 -
 1 file changed, 1 deletion(-)

--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3166,7 +3166,6 @@ int dwc3_gadget_init(struct dwc3 *dwc)
 	dwc->gadget.speed		= USB_SPEED_UNKNOWN;
 	dwc->gadget.sg_supported	= true;
 	dwc->gadget.name		= "dwc3-gadget";
-	dwc->gadget.is_otg		= dwc->dr_mode == USB_DR_MODE_OTG;
 
 	/*
 	 * FIXME We might be setting max_speed to <SUPER, however versions

[PATCH 4.19 54/54] drm_dp_mst_topology: fix broken drm_dp_sideband_parse_remote_dpcd_read()

[Greg Kroah-Hartman]

From: Hans Verkuil <hans.verkuil@cisco.com>

commit a4c30a4861c54af78c4eb8b7855524c1a96d9f80 upstream.

When parsing the reply of a DP_REMOTE_DPCD_READ DPCD command the
result is wrong due to a missing idx increment.

This was never noticed since DP_REMOTE_DPCD_READ is currently not
used, but if you enable it, then it is all wrong.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e72ddac2-1dc0-100a-d816-9ac98ac009dd@xs4all.nl
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/drm_dp_mst_topology.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -439,6 +439,7 @@ static bool drm_dp_sideband_parse_remote
 	if (idx > raw->curlen)
 		goto fail_len;
 	repmsg->u.remote_dpcd_read_ack.num_bytes = raw->msg[idx];
+	idx++;
 	if (idx > raw->curlen)
 		goto fail_len;
 

Re: [PATCH 4.19 03/54] sctp: fix refcount bug in sctp_wfree

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

Hi!

> The following case cause the bug:
> for the trouble SKB, it was in outq->transmitted list

Ok... but this is one hell of "interesting" code.

> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -165,29 +165,44 @@ static void sctp_clear_owner_w(struct sc
>  	skb_orphan(chunk->skb);
>  }
>  
> +#define traverse_and_process()	\
> +do {				\
> +	msg = chunk->msg;	\
> +	if (msg == prev_msg)	\
> +		continue;	\
> +	list_for_each_entry(c, &msg->chunks, frag_list) {	\
> +		if ((clear && asoc->base.sk == c->skb->sk) ||	\
> +		    (!clear && asoc->base.sk != c->skb->sk))	\
> +			cb(c);	\
> +	}			\
> +	prev_msg = msg;		\
> +} while (0)

Should this be function?

Do you see how it does "continue"? But the do {} while(0) wrapper eats
the continue. "break" would be more clear here, but they are really
equivalent due to way this macro is used.

It is just very, very confusing.

Best regards,
								Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH 4.19 03/54] sctp: fix refcount bug in sctp_wfree

[Marcelo Ricardo Leitner]

On Sat, Apr 11, 2020 at 08:28:13PM +0200, Pavel Machek wrote:
> Hi!
> 
> > The following case cause the bug:
> > for the trouble SKB, it was in outq->transmitted list
> 
> Ok... but this is one hell of "interesting" code.
> 
> > --- a/net/sctp/socket.c
> > +++ b/net/sctp/socket.c
> > @@ -165,29 +165,44 @@ static void sctp_clear_owner_w(struct sc
> >  	skb_orphan(chunk->skb);
> >  }
> >  
> > +#define traverse_and_process()	\
> > +do {				\
> > +	msg = chunk->msg;	\
> > +	if (msg == prev_msg)	\
> > +		continue;	\
> > +	list_for_each_entry(c, &msg->chunks, frag_list) {	\
> > +		if ((clear && asoc->base.sk == c->skb->sk) ||	\
> > +		    (!clear && asoc->base.sk != c->skb->sk))	\
> > +			cb(c);	\
> > +	}			\
> > +	prev_msg = msg;		\
> > +} while (0)
> 
> Should this be function?
> 
> Do you see how it does "continue"? But the do {} while(0) wrapper eats
> the continue. "break" would be more clear here, but they are really
> equivalent due to way this macro is used.
> 
> It is just very, very confusing.

Agree. The 'continue' itself slipped in on a refactoring and I didn't
notice the confusing aspect of it. Initially, the code was written
without the macro, and the continue refererred to the outter
list_for_each_entry().

  Marcelo

Re: [PATCH 4.19 00/54] 4.19.115-rc1 review

[Guenter Roeck]

On 4/11/20 5:08 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.115 release.
> There are 54 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 Mon, 13 Apr 2020 11:51:28 +0000.
> Anything received after that time might be too late.
> 

Build results:
	total: 155 pass: 155 fail: 0
Qemu test results:
	total: 418 pass: 418 fail: 0

Guenter

Re: [PATCH 4.19 00/54] 4.19.115-rc1 review

[Naresh Kamboju]

On Sat, 11 Apr 2020 at 17:45, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.19.115 release.
> There are 54 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 Mon, 13 Apr 2020 11:51:28 +0000.
> 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.19.115-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.19.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.19.115-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 3b903e5affcf69ffcfc0ebb8c3f2c016b646682d
git describe: v4.19.114-55-g3b903e5affcf
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.114-55-g3b903e5affcf


No regressions (compared to build v4.19.114)


No fixes (compared to build v4.19.114)

Ran 22940 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- x15 - arm
- x86_64
- x86-kasan

Test Suites
-----------
* install-android-platform-tools-r2800
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-ipc-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-io-tests
* ltp-math-tests
* ltp-sched-tests
* network-basic-tests
* v4l2-compliance
* ltp-fs-tests
* ltp-open-posix-tests
* kselftest
* perf
* spectre-meltdown-checker-test
* build
* install-android-platform-tools-r2600

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 4.19 19/54] extcon: axp288: Add wakeup support

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]

Hi!

> commit 9c94553099efb2ba873cbdddfd416a8a09d0e5f1 upstream.
> 
> On devices with an AXP288, we need to wakeup from suspend when a charger
> is plugged in, so that we can do charger-type detection and so that the
> axp288-charger driver, which listens for our extcon events, can configure
> the input-current-limit accordingly.

Will it do the same on charger disconnect?

Is that a tiny bit anti-social? I suspend a machine, unplug a charger,
put it into a bag.. but machine is now running.

On some machines (sharp zaurus) we catch such wakeups, do whatever
charging magic we need to do, and put machine back to sleep, so that
user does not see the wakeups (and so that we don't drain the
battery).

Best regards,
								Pavel
> --- a/drivers/extcon/extcon-axp288.c
> +++ b/drivers/extcon/extcon-axp288.c
> @@ -428,9 +428,40 @@ static int axp288_extcon_probe(struct pl
>  	/* Start charger cable type detection */
>  	axp288_extcon_enable(info);
>  
> +	device_init_wakeup(dev, true);
> +	platform_set_drvdata(pdev, info);
> +
> +	return 0;
> +}
> +
> +static int __maybe_unused axp288_extcon_suspend(struct device *dev)
> +{
> +	struct axp288_extcon_info *info = dev_get_drvdata(dev);
> +
> +	if (device_may_wakeup(dev))
> +		enable_irq_wake(info->irq[VBUS_RISING_IRQ]);
> +
>  	return 0;
>  }
>  
> +static int __maybe_unused axp288_extcon_resume(struct device *dev)
> +{
> +	struct axp288_extcon_info *info = dev_get_drvdata(dev);
> +
> +	/*
> +	 * Wakeup when a charger is connected to do charger-type
> +	 * connection and generate an extcon event which makes the
> +	 * axp288 charger driver set the input current limit.
> +	 */
> +	if (device_may_wakeup(dev))
> +		disable_irq_wake(info->irq[VBUS_RISING_IRQ]);
> +
> +	return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(axp288_extcon_pm_ops, axp288_extcon_suspend,
> +			 axp288_extcon_resume);
> +
>  static const struct platform_device_id axp288_extcon_table[] = {
>  	{ .name = "axp288_extcon" },
>  	{},
> @@ -442,6 +473,7 @@ static struct platform_driver axp288_ext
>  	.id_table = axp288_extcon_table,
>  	.driver = {
>  		.name = "axp288_extcon",
> +		.pm = &axp288_extcon_pm_ops,
>  	},
>  };
>  
> 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH 4.19 20/54] power: supply: axp288_charger: Add special handling for HP Pavilion x2 10

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

On Sat 2020-04-11 14:09:02, Greg Kroah-Hartman wrote:
> From: Hans de Goede <hdegoede@redhat.com>
> 
> commit 9c80662a74cd2a5d1113f5c69d027face963a556 upstream.
> 
> Some HP Pavilion x2 10 models use an AXP288 for charging and fuel-gauge.
> We use a native power_supply / PMIC driver in this case, because on most
> models with an AXP288 the ACPI AC / Battery code is either completely
> missing or relies on custom / proprietary ACPI OpRegions which Linux
> does not implement.
> 
> The native drivers mostly work fine, but there are 2 problems:
> 
> 1. These model uses a Type-C connector for charging which the AXP288 does
> not support. As long as a Type-A charger (which uses the USB data pins for
> charger type detection) is used everything is fine. But if a Type-C
> charger is used (such as the charger shipped with the device) then the
> charger is not recognized.
> 
> So we end up slowly discharging the device even though a charger is
> connected, because we are limiting the current from the charger to 500mA.
> To make things worse this happens with the device's official charger.
> 
> Looking at the ACPI tables HP has "solved" the problem of the AXP288 not
> being able to recognize Type-C chargers by simply always programming the
> input-current-limit at 3000mA and relying on a Vhold setting of 4.7V
> (normally 4.4V) to limit the current intake if the charger cannot handle
> this.

Hmm.. Drawing 3A from port designed for .5A... is not that a bit
dangerous? It is certainly against the specs.

I believe it will work okay 90% of time, but maybe something overheats
or some fuse trips in the remaining cases. I believe I've seen fuse
triping on USB port of my home router..

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

RE: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache

[nobuhiro1.iwamatsu]

Hi,

> -----Original Message-----
> From: stable-owner@vger.kernel.org [mailto:stable-owner@vger.kernel.org] On Behalf Of Greg Kroah-Hartman
> Sent: Saturday, April 11, 2020 9:10 PM
> To: linux-kernel@vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; stable@vger.kernel.org; Stephen Boyd <sboyd@kernel.org>; Stephen
> Boyd <swboyd@chromium.org>; Jordan Crouse <jcrouse@codeaurora.org>; Rob Clark <robdclark@chromium.org>; Sean Paul
> <seanpaul@chromium.org>; Lee Jones <lee.jones@linaro.org>
> Subject: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache
> 
> From: Rob Clark <robdclark@chromium.org>
> 
> commit 0036bc73ccbe7e600a3468bf8e8879b122252274 upstream.
> 
> Recently splats like this started showing up:
> 
>    WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451 __iommu_dma_unmap+0xb8/0xc0
>    Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo cfg80211 videobuf2_vmalloc videobuf2_memops
> vide
>    CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: G        W         5.2.0-rc5-next-20190619+ #2317
>    Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
>    Workqueue: msm msm_gem_free_work [msm]
>    pstate: 80c00005 (Nzcv daif +PAN +UAO)
>    pc : __iommu_dma_unmap+0xb8/0xc0
>    lr : __iommu_dma_unmap+0x54/0xc0
>    sp : ffff0000119abce0
>    x29: ffff0000119abce0 x28: 0000000000000000
>    x27: ffff8001f9946648 x26: ffff8001ec271068
>    x25: 0000000000000000 x24: ffff8001ea3580a8
>    x23: ffff8001f95ba010 x22: ffff80018e83ba88
>    x21: ffff8001e548f000 x20: fffffffffffff000
>    x19: 0000000000001000 x18: 00000000c00001fe
>    x17: 0000000000000000 x16: 0000000000000000
>    x15: ffff000015b70068 x14: 0000000000000005
>    x13: 0003142cc1be1768 x12: 0000000000000001
>    x11: ffff8001f6de9100 x10: 0000000000000009
>    x9 : ffff000015b78000 x8 : 0000000000000000
>    x7 : 0000000000000001 x6 : fffffffffffff000
>    x5 : 0000000000000fff x4 : ffff00001065dbc8
>    x3 : 000000000000000d x2 : 0000000000001000
>    x1 : fffffffffffff000 x0 : 0000000000000000
>    Call trace:
>     __iommu_dma_unmap+0xb8/0xc0
>     iommu_dma_unmap_sg+0x98/0xb8
>     put_pages+0x5c/0xf0 [msm]
>     msm_gem_free_work+0x10c/0x150 [msm]
>     process_one_work+0x1e0/0x330
>     worker_thread+0x40/0x438
>     kthread+0x12c/0x130
>     ret_from_fork+0x10/0x18
>    ---[ end trace afc0dc5ab81a06bf ]---
> 
> Not quite sure what triggered that, but we really shouldn't be abusing
> dma_{map,unmap}_sg() for cache maint.
> 
> Cc: Stephen Boyd <sboyd@kernel.org>
> Tested-by: Stephen Boyd <swboyd@chromium.org>
> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
> Signed-off-by: Rob Clark <robdclark@chromium.org>
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Link: https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdclark@gmail.com
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This commit also requires the following commits:

commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c
Author: Rob Clark <robdclark@chromium.org>
Date:   Tue Jul 30 14:46:28 2019 -0700

    drm/msm: Use the correct dma_sync calls in msm_gem
    
    [subject was: drm/msm: shake fist angrily at dma-mapping]
    
    So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
    it falls appart with dma direct ops.  The problem is that, depending on
    display generation, we can have either set of dma ops (mdp4 and dpu have
    iommu wired to mdss node, which maps to toplevel drm device, but mdp5
    has iommu wired up to the mdp sub-node within mdss).
    
    Fixes this splat on mdp5 devices:
    
       Unable to handle kernel paging request at virtual address ffffffff80000000
       Mem abort info:
         ESR = 0x96000144
         Exception class = DABT (current EL), IL = 32 bits
         SET = 0, FnV = 0
         EA = 0, S1PTW = 0
       Data abort info:
         ISV = 0, ISS = 0x00000144
         CM = 1, WnR = 1
       swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000810e4000
       [ffffffff80000000] pgd=0000000000000000
       Internal error: Oops: 96000144 [#1] SMP
       Modules linked in: btqcomsmd btqca bluetooth cfg80211 ecdh_generic ecc rfkill libarc4 panel_simple msm wcnss_ctrl qrtr_smd drm_kms_helper venus_enc venus_dec videobuf2_dma_sg videobuf2_memops drm venus_core ipv6 qrtr qcom_wcnss_pil v4l2_mem2mem qcom_sysmon videobuf2_v4l2 qmi_helpers videobuf2_common crct10dif_ce mdt_loader qcom_common videodev qcom_glink_smem remoteproc bmc150_accel_i2c bmc150_magn_i2c bmc150_accel_core bmc150_magn snd_soc_lpass_apq8016 snd_soc_msm8916_analog mms114 mc nf_defrag_ipv6 snd_soc_lpass_cpu snd_soc_apq8016_sbc industrialio_triggered_buffer kfifo_buf snd_soc_lpass_platform snd_soc_msm8916_digital drm_panel_orientation_quirks
       CPU: 2 PID: 33 Comm: kworker/2:1 Not tainted 5.3.0-rc2 #1
       Hardware name: Samsung Galaxy A5U (EUR) (DT)
       Workqueue: events deferred_probe_work_func
       pstate: 80000005 (Nzcv daif -PAN -UAO)
       pc : __clean_dcache_area_poc+0x20/0x38
       lr : arch_sync_dma_for_device+0x28/0x30
       sp : ffff0000115736a0
       x29: ffff0000115736a0 x28: 0000000000000001
       x27: ffff800074830800 x26: ffff000011478000
       x25: 0000000000000000 x24: 0000000000000001
       x23: ffff000011478a98 x22: ffff800009fd1c10
       x21: 0000000000000001 x20: ffff800075ad0a00
       x19: 0000000000000000 x18: ffff0000112b2000
       x17: 0000000000000000 x16: 0000000000000000
       x15: 00000000fffffff0 x14: ffff000011455d70
       x13: 0000000000000000 x12: 0000000000000028
       x11: 0000000000000001 x10: ffff00001106c000
       x9 : ffff7e0001d6b380 x8 : 0000000000001000
       x7 : ffff7e0001d6b380 x6 : ffff7e0001d6b382
       x5 : 0000000000000000 x4 : 0000000000001000
       x3 : 000000000000003f x2 : 0000000000000040
       x1 : ffffffff80001000 x0 : ffffffff80000000
       Call trace:
        __clean_dcache_area_poc+0x20/0x38
        dma_direct_sync_sg_for_device+0xb8/0xe8
        get_pages+0x22c/0x250 [msm]
        msm_gem_get_and_pin_iova+0xdc/0x168 [msm]
        ...
    
    Fixes the combination of two patches:
    
    Fixes: 0036bc73ccbe (drm/msm: stop abusing dma_map/unmap for cache)
    Fixes: 449fa54d6815 (dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device)
    Tested-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    [seanpaul changed subject to something more desriptive]
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190730214633.17820-1-robdclark@gmail.com


And this commit requires not only 4.19 but also 4.9 and 4.14.
Please apply this.

Best regards,
  Nobuhiro 

> 
> ---
>  drivers/gpu/drm/msm/msm_gem.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -108,7 +108,7 @@ static struct page **get_pages(struct dr
>  		 * because display controller, GPU, etc. are not coherent:
>  		 */
>  		if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
> -			dma_map_sg(dev->dev, msm_obj->sgt->sgl,
> +			dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl,
>  					msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
>  	}
> 
> @@ -138,7 +138,7 @@ static void put_pages(struct drm_gem_obj
>  			 * GPU, etc. are not coherent:
>  			 */
>  			if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
> -				dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
> +				dma_sync_sg_for_cpu(obj->dev->dev, msm_obj->sgt->sgl,
>  					     msm_obj->sgt->nents,
>  					     DMA_BIDIRECTIONAL);
> 
> 

Re: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache

[Greg KH]

On Mon, Apr 13, 2020 at 05:03:26AM +0000, nobuhiro1.iwamatsu@toshiba.co.jp wrote:
> Hi,
> 
> > -----Original Message-----
> > From: stable-owner@vger.kernel.org [mailto:stable-owner@vger.kernel.org] On Behalf Of Greg Kroah-Hartman
> > Sent: Saturday, April 11, 2020 9:10 PM
> > To: linux-kernel@vger.kernel.org
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; stable@vger.kernel.org; Stephen Boyd <sboyd@kernel.org>; Stephen
> > Boyd <swboyd@chromium.org>; Jordan Crouse <jcrouse@codeaurora.org>; Rob Clark <robdclark@chromium.org>; Sean Paul
> > <seanpaul@chromium.org>; Lee Jones <lee.jones@linaro.org>
> > Subject: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache
> > 
> > From: Rob Clark <robdclark@chromium.org>
> > 
> > commit 0036bc73ccbe7e600a3468bf8e8879b122252274 upstream.
> > 
> > Recently splats like this started showing up:
> > 
> >    WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451 __iommu_dma_unmap+0xb8/0xc0
> >    Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo cfg80211 videobuf2_vmalloc videobuf2_memops
> > vide
> >    CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: G        W         5.2.0-rc5-next-20190619+ #2317
> >    Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
> >    Workqueue: msm msm_gem_free_work [msm]
> >    pstate: 80c00005 (Nzcv daif +PAN +UAO)
> >    pc : __iommu_dma_unmap+0xb8/0xc0
> >    lr : __iommu_dma_unmap+0x54/0xc0
> >    sp : ffff0000119abce0
> >    x29: ffff0000119abce0 x28: 0000000000000000
> >    x27: ffff8001f9946648 x26: ffff8001ec271068
> >    x25: 0000000000000000 x24: ffff8001ea3580a8
> >    x23: ffff8001f95ba010 x22: ffff80018e83ba88
> >    x21: ffff8001e548f000 x20: fffffffffffff000
> >    x19: 0000000000001000 x18: 00000000c00001fe
> >    x17: 0000000000000000 x16: 0000000000000000
> >    x15: ffff000015b70068 x14: 0000000000000005
> >    x13: 0003142cc1be1768 x12: 0000000000000001
> >    x11: ffff8001f6de9100 x10: 0000000000000009
> >    x9 : ffff000015b78000 x8 : 0000000000000000
> >    x7 : 0000000000000001 x6 : fffffffffffff000
> >    x5 : 0000000000000fff x4 : ffff00001065dbc8
> >    x3 : 000000000000000d x2 : 0000000000001000
> >    x1 : fffffffffffff000 x0 : 0000000000000000
> >    Call trace:
> >     __iommu_dma_unmap+0xb8/0xc0
> >     iommu_dma_unmap_sg+0x98/0xb8
> >     put_pages+0x5c/0xf0 [msm]
> >     msm_gem_free_work+0x10c/0x150 [msm]
> >     process_one_work+0x1e0/0x330
> >     worker_thread+0x40/0x438
> >     kthread+0x12c/0x130
> >     ret_from_fork+0x10/0x18
> >    ---[ end trace afc0dc5ab81a06bf ]---
> > 
> > Not quite sure what triggered that, but we really shouldn't be abusing
> > dma_{map,unmap}_sg() for cache maint.
> > 
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Tested-by: Stephen Boyd <swboyd@chromium.org>
> > Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
> > Signed-off-by: Rob Clark <robdclark@chromium.org>
> > Signed-off-by: Sean Paul <seanpaul@chromium.org>
> > Link: https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdclark@gmail.com
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> This commit also requires the following commits:
> 
> commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c
> Author: Rob Clark <robdclark@chromium.org>
> Date:   Tue Jul 30 14:46:28 2019 -0700
> 
>     drm/msm: Use the correct dma_sync calls in msm_gem
>     
>     [subject was: drm/msm: shake fist angrily at dma-mapping]
>     
>     So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
>     it falls appart with dma direct ops.  The problem is that, depending on
>     display generation, we can have either set of dma ops (mdp4 and dpu have
>     iommu wired to mdss node, which maps to toplevel drm device, but mdp5
>     has iommu wired up to the mdp sub-node within mdss).
>     
>     Fixes this splat on mdp5 devices:
>     
>        Unable to handle kernel paging request at virtual address ffffffff80000000
>        Mem abort info:
>          ESR = 0x96000144
>          Exception class = DABT (current EL), IL = 32 bits
>          SET = 0, FnV = 0
>          EA = 0, S1PTW = 0
>        Data abort info:
>          ISV = 0, ISS = 0x00000144
>          CM = 1, WnR = 1
>        swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000810e4000
>        [ffffffff80000000] pgd=0000000000000000
>        Internal error: Oops: 96000144 [#1] SMP
>        Modules linked in: btqcomsmd btqca bluetooth cfg80211 ecdh_generic ecc rfkill libarc4 panel_simple msm wcnss_ctrl qrtr_smd drm_kms_helper venus_enc venus_dec videobuf2_dma_sg videobuf2_memops drm venus_core ipv6 qrtr qcom_wcnss_pil v4l2_mem2mem qcom_sysmon videobuf2_v4l2 qmi_helpers videobuf2_common crct10dif_ce mdt_loader qcom_common videodev qcom_glink_smem remoteproc bmc150_accel_i2c bmc150_magn_i2c bmc150_accel_core bmc150_magn snd_soc_lpass_apq8016 snd_soc_msm8916_analog mms114 mc nf_defrag_ipv6 snd_soc_lpass_cpu snd_soc_apq8016_sbc industrialio_triggered_buffer kfifo_buf snd_soc_lpass_platform snd_soc_msm8916_digital drm_panel_orientation_quirks
>        CPU: 2 PID: 33 Comm: kworker/2:1 Not tainted 5.3.0-rc2 #1
>        Hardware name: Samsung Galaxy A5U (EUR) (DT)
>        Workqueue: events deferred_probe_work_func
>        pstate: 80000005 (Nzcv daif -PAN -UAO)
>        pc : __clean_dcache_area_poc+0x20/0x38
>        lr : arch_sync_dma_for_device+0x28/0x30
>        sp : ffff0000115736a0
>        x29: ffff0000115736a0 x28: 0000000000000001
>        x27: ffff800074830800 x26: ffff000011478000
>        x25: 0000000000000000 x24: 0000000000000001
>        x23: ffff000011478a98 x22: ffff800009fd1c10
>        x21: 0000000000000001 x20: ffff800075ad0a00
>        x19: 0000000000000000 x18: ffff0000112b2000
>        x17: 0000000000000000 x16: 0000000000000000
>        x15: 00000000fffffff0 x14: ffff000011455d70
>        x13: 0000000000000000 x12: 0000000000000028
>        x11: 0000000000000001 x10: ffff00001106c000
>        x9 : ffff7e0001d6b380 x8 : 0000000000001000
>        x7 : ffff7e0001d6b380 x6 : ffff7e0001d6b382
>        x5 : 0000000000000000 x4 : 0000000000001000
>        x3 : 000000000000003f x2 : 0000000000000040
>        x1 : ffffffff80001000 x0 : ffffffff80000000
>        Call trace:
>         __clean_dcache_area_poc+0x20/0x38
>         dma_direct_sync_sg_for_device+0xb8/0xe8
>         get_pages+0x22c/0x250 [msm]
>         msm_gem_get_and_pin_iova+0xdc/0x168 [msm]
>         ...
>     
>     Fixes the combination of two patches:
>     
>     Fixes: 0036bc73ccbe (drm/msm: stop abusing dma_map/unmap for cache)
>     Fixes: 449fa54d6815 (dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device)
>     Tested-by: Stephan Gerhold <stephan@gerhold.net>
>     Signed-off-by: Rob Clark <robdclark@chromium.org>
>     [seanpaul changed subject to something more desriptive]
>     Signed-off-by: Sean Paul <seanpaul@chromium.org>
>     Link: https://patchwork.freedesktop.org/patch/msgid/20190730214633.17820-1-robdclark@gmail.com
> 
> 
> And this commit requires not only 4.19 but also 4.9 and 4.14.
> Please apply this.

Now queued up, thanks!

greg k-h

RE: [PATCH 4.19 00/54] 4.19.115-rc1 review

[Chris Paterson]

Hello Greg,

> From: stable-owner@vger.kernel.org <stable-owner@vger.kernel.org> On
> Behalf Of Greg Kroah-Hartman
> Sent: 11 April 2020 13:09
> 
> This is the start of the stable review cycle for the 4.19.115 release.
> There are 54 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 Mon, 13 Apr 2020 11:51:28 +0000.
> Anything received after that time might be too late.

No build/boot issues seen for CIP configs for Linux 4.19.115-rc1 (3b903e5affcf).

Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/134988024
GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml

Kind regards, Chris

> 
> The whole patch series can be found in one patch at:
> 	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-
> 4.19.115-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.19.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -------------
> Pseudo-Shortlog of commits:
> 
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Linux 4.19.115-rc1
> 
> Hans Verkuil <hans.verkuil@cisco.com>
>     drm_dp_mst_topology: fix broken
> drm_dp_sideband_parse_remote_dpcd_read()
> 
> Roger Quadros <rogerq@ti.com>
>     usb: dwc3: don't set gadget->is_otg flag
> 
> Chris Lew <clew@codeaurora.org>
>     rpmsg: glink: Remove chunk size word align warning
> 
> Arun KS <arunks@codeaurora.org>
>     arm64: Fix size of __early_cpu_boot_status
> 
> Rob Clark <robdclark@chromium.org>
>     drm/msm: stop abusing dma_map/unmap for cache
> 
> Taniya Das <tdas@codeaurora.org>
>     clk: qcom: rcg: Return failure for RCG update
> 
> Qiujun Huang <hqjagain@gmail.com>
>     fbcon: fix null-ptr-deref in fbcon_switch
> 
> Avihai Horon <avihaih@mellanox.com>
>     RDMA/cm: Update num_paths in cma_resolve_iboe_route error flow
> 
> Qiujun Huang <hqjagain@gmail.com>
>     Bluetooth: RFCOMM: fix ODEBUG bug in rfcomm_dev_ioctl
> 
> Jason Gunthorpe <jgg@ziepe.ca>
>     RDMA/cma: Teach lockdep about the order of rtnl and lock
> 
> Jason Gunthorpe <jgg@ziepe.ca>
>     RDMA/ucma: Put a lock around every call to the rdma_cm layer
> 
> Ilya Dryomov <idryomov@gmail.com>
>     ceph: canonicalize server path in place
> 
> Xiubo Li <xiubli@redhat.com>
>     ceph: remove the extra slashes in the server path
> 
> Kaike Wan <kaike.wan@intel.com>
>     IB/hfi1: Fix memory leaks in sysfs registration and unregistration
> 
> Kaike Wan <kaike.wan@intel.com>
>     IB/hfi1: Call kobject_put() when kobject_init_and_add() fails
> 
> Paul Cercueil <paul@crapouillou.net>
>     ASoC: jz4740-i2s: Fix divider written at incorrect offset in register
> 
> Martin Kaiser <martin@kaiser.cx>
>     hwrng: imx-rngc - fix an error path
> 
> David Ahern <dsahern@kernel.org>
>     tools/accounting/getdelays.c: fix netlink attribute length
> 
> Thinh Nguyen <Thinh.Nguyen@synopsys.com>
>     usb: dwc3: gadget: Wrap around when skip TRBs
> 
> Jason A. Donenfeld <Jason@zx2c4.com>
>     random: always use batched entropy for get_random_u{32,64}
> 
> Petr Machata <petrm@mellanox.com>
>     mlxsw: spectrum_flower: Do not stop at FLOW_ACTION_VLAN_MANGLE
> 
> Richard Palethorpe <rpalethorpe@suse.com>
>     slcan: Don't transmit uninitialized stack data in padding
> 
> Jisheng Zhang <Jisheng.Zhang@synaptics.com>
>     net: stmmac: dwmac1000: fix out-of-bounds mac address reg setting
> 
> Oleksij Rempel <o.rempel@pengutronix.de>
>     net: phy: micrel: kszphy_resume(): add delay after genphy_resume() before
> accessing PHY registers
> 
> Florian Fainelli <f.fainelli@gmail.com>
>     net: dsa: bcm_sf2: Ensure correct sub-node is parsed
> 
> Florian Fainelli <f.fainelli@gmail.com>
>     net: dsa: bcm_sf2: Do not register slave MDIO bus with OF
> 
> Jarod Wilson <jarod@redhat.com>
>     ipv6: don't auto-add link-local address to lag ports
> 
> Randy Dunlap <rdunlap@infradead.org>
>     mm: mempolicy: require at least one nodeid for MPOL_PREFERRED
> 
> Sam Protsenko <semen.protsenko@linaro.org>
>     include/linux/notifier.h: SRCU: fix ctags
> 
> Miklos Szeredi <mszeredi@redhat.com>
>     bitops: protect variables in set_mask_bits() macro
> 
> Daniel Jordan <daniel.m.jordan@oracle.com>
>     padata: always acquire cpu_hotplug_lock before pinst->lock
> 
> Amritha Nambiar <amritha.nambiar@intel.com>
>     net: Fix Tx hash bound checking
> 
> David Howells <dhowells@redhat.com>
>     rxrpc: Fix sendmsg(MSG_WAITALL) handling
> 
> Geoffrey Allott <geoffrey@allott.email>
>     ALSA: hda/ca0132 - Add Recon3Di quirk to handle integrated sound on EVGA
> X99 Classified motherboard
> 
> Hans de Goede <hdegoede@redhat.com>
>     power: supply: axp288_charger: Add special handling for HP Pavilion x2 10
> 
> Hans de Goede <hdegoede@redhat.com>
>     extcon: axp288: Add wakeup support
> 
> Alexander Usyskin <alexander.usyskin@intel.com>
>     mei: me: add cedar fork device ids
> 
> Eugene Syromiatnikov <esyr@redhat.com>
>     coresight: do not use the BIT() macro in the UAPI header
> 
> Kishon Vijay Abraham I <kishon@ti.com>
>     misc: pci_endpoint_test: Avoid using module parameter to determine irqtype
> 
> Kishon Vijay Abraham I <kishon@ti.com>
>     misc: pci_endpoint_test: Fix to support > 10 pci-endpoint-test devices
> 
> YueHaibing <yuehaibing@huawei.com>
>     misc: rtsx: set correct pcr_ops for rts522A
> 
> Sean Young <sean@mess.org>
>     media: rc: IR signal for Panasonic air conditioner too long
> 
> Lucas Stach <l.stach@pengutronix.de>
>     drm/etnaviv: replace MMU flush marker with flush sequence
> 
> Len Brown <len.brown@intel.com>
>     tools/power turbostat: Fix missing SYS_LPI counter on some Chromebooks
> 
> Len Brown <len.brown@intel.com>
>     tools/power turbostat: Fix gcc build warnings
> 
> James Zhu <James.Zhu@amd.com>
>     drm/amdgpu: fix typo for vcn1 idle check
> 
> Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
>     initramfs: restore default compression behavior
> 
> Gerd Hoffmann <kraxel@redhat.com>
>     drm/bochs: downgrade pci_request_region failure from error to warning
> 
> Mario Kleiner <mario.kleiner.de@gmail.com>
>     drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017
> 
> Prabhath Sajeepa <psajeepa@purestorage.com>
>     nvme-rdma: Avoid double freeing of async event data
> 
> Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
>     sctp: fix possibly using a bad saddr with a given dst
> 
> Qiujun Huang <hqjagain@gmail.com>
>     sctp: fix refcount bug in sctp_wfree
> 
> William Dauchy <w.dauchy@criteo.com>
>     net, ip_tunnel: fix interface lookup with no key
> 
> Qian Cai <cai@lca.pw>
>     ipv4: fix a RCU-list lock in fib_triestat_seq_show
> 
> 
> -------------
> 
> Diffstat:
> 
>  Makefile                                           |  4 +-
>  arch/arm64/kernel/head.S                           |  2 +-
>  drivers/char/hw_random/imx-rngc.c                  |  4 +-
>  drivers/char/random.c                              | 20 ++------
>  drivers/clk/qcom/clk-rcg2.c                        |  2 +-
>  drivers/extcon/extcon-axp288.c                     | 32 ++++++++++++
>  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c              |  2 +-
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   | 11 +++++
>  drivers/gpu/drm/bochs/bochs_hw.c                   |  6 +--
>  drivers/gpu/drm/drm_dp_mst_topology.c              |  1 +
>  drivers/gpu/drm/etnaviv/etnaviv_buffer.c           | 10 ++--
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h              |  1 +
>  drivers/gpu/drm/etnaviv/etnaviv_mmu.c              |  6 +--
>  drivers/gpu/drm/etnaviv/etnaviv_mmu.h              |  2 +-
>  drivers/gpu/drm/msm/msm_gem.c                      |  4 +-
>  drivers/infiniband/core/cma.c                      | 14 ++++++
>  drivers/infiniband/core/ucma.c                     | 49 ++++++++++++++++++-
>  drivers/infiniband/hw/hfi1/sysfs.c                 | 26 +++++++---
>  drivers/media/rc/lirc_dev.c                        |  2 +-
>  drivers/misc/cardreader/rts5227.c                  |  1 +
>  drivers/misc/mei/hw-me-regs.h                      |  2 +
>  drivers/misc/mei/pci-me.c                          |  2 +
>  drivers/misc/pci_endpoint_test.c                   | 14 ++++--
>  drivers/net/can/slcan.c                            |  4 +-
>  drivers/net/dsa/bcm_sf2.c                          |  9 +++-
>  .../net/ethernet/mellanox/mlxsw/spectrum_flower.c  |  8 +--
>  .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   |  2 +-
>  drivers/net/phy/micrel.c                           |  7 +++
>  drivers/nvme/host/rdma.c                           |  8 +--
>  drivers/power/supply/axp288_charger.c              | 57 +++++++++++++++++++++-
>  drivers/rpmsg/qcom_glink_native.c                  |  3 --
>  drivers/usb/dwc3/gadget.c                          |  3 +-
>  drivers/video/fbdev/core/fbcon.c                   |  3 ++
>  fs/ceph/super.c                                    | 56 +++++++++++++--------
>  fs/ceph/super.h                                    |  2 +-
>  include/linux/bitops.h                             | 14 +++---
>  include/linux/notifier.h                           |  3 +-
>  include/uapi/linux/coresight-stm.h                 |  6 ++-
>  kernel/padata.c                                    |  4 +-
>  mm/mempolicy.c                                     |  6 ++-
>  net/bluetooth/rfcomm/tty.c                         |  4 +-
>  net/core/dev.c                                     |  2 +
>  net/ipv4/fib_trie.c                                |  3 ++
>  net/ipv4/ip_tunnel.c                               |  6 +--
>  net/ipv6/addrconf.c                                |  4 ++
>  net/rxrpc/sendmsg.c                                |  4 +-
>  net/sctp/ipv6.c                                    | 20 +++++---
>  net/sctp/protocol.c                                | 28 +++++++----
>  net/sctp/socket.c                                  | 31 +++++++++---
>  sound/pci/hda/patch_ca0132.c                       |  1 +
>  sound/soc/jz4740/jz4740-i2s.c                      |  2 +-
>  tools/accounting/getdelays.c                       |  2 +-
>  tools/power/x86/turbostat/turbostat.c              | 27 +++++-----
>  usr/Kconfig                                        | 22 ++++-----
>  54 files changed, 409 insertions(+), 159 deletions(-)
> 

Re: [PATCH 4.19 00/54] 4.19.115-rc1 review

[Greg Kroah-Hartman]

On Mon, Apr 13, 2020 at 07:42:37PM +0000, Chris Paterson wrote:
> Hello Greg,
> 
> > From: stable-owner@vger.kernel.org <stable-owner@vger.kernel.org> On
> > Behalf Of Greg Kroah-Hartman
> > Sent: 11 April 2020 13:09
> > 
> > This is the start of the stable review cycle for the 4.19.115 release.
> > There are 54 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 Mon, 13 Apr 2020 11:51:28 +0000.
> > Anything received after that time might be too late.
> 
> No build/boot issues seen for CIP configs for Linux 4.19.115-rc1 (3b903e5affcf).
> 
> Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/134988024
> GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
> 
> Kind regards, Chris

Thanks for  testing two of these and letting me know.

greg k-h

Re: [PATCH 4.19 00/54] 4.19.115-rc1 review

[Jon Hunter]

On 11/04/2020 13:08, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.115 release.
> There are 54 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 Mon, 13 Apr 2020 11:51:28 +0000.
> 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.19.115-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.19.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v4.19:
    11 builds:	11 pass, 0 fail
    22 boots:	22 pass, 0 fail
    32 tests:	32 pass, 0 fail

Linux version:	4.19.115-rc1-g3b903e5affcf
Boards tested:	tegra124-jetson-tk1, tegra186-p2771-0000,
                tegra194-p2972-0000, tegra20-ventana,
                tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

-- 
nvpublic

Re: [PATCH 4.19 00/54] 4.19.115-rc1 review

[Jon Hunter]

On 11/04/2020 13:08, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.115 release.
> There are 54 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 Mon, 13 Apr 2020 11:51:28 +0000.
> 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.19.115-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.19.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v4.19:
    11 builds:	11 pass, 0 fail
    22 boots:	22 pass, 0 fail
    32 tests:	32 pass, 0 fail

Linux version:	4.19.115-rc1-g3b903e5affcf
Boards tested:	tegra124-jetson-tk1, tegra186-p2771-0000,
                tegra194-p2972-0000, tegra20-ventana,
                tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

-- 
nvpublic

Re: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache

[Naresh Kamboju]

On Mon, 13 Apr 2020 at 13:56, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Apr 13, 2020 at 05:03:26AM +0000, nobuhiro1.iwamatsu@toshiba.co.jp wrote:
> > Hi,
> >
> > > -----Original Message-----
> > > From: stable-owner@vger.kernel.org [mailto:stable-owner@vger.kernel.org] On Behalf Of Greg Kroah-Hartman
> > > Sent: Saturday, April 11, 2020 9:10 PM
> > > To: linux-kernel@vger.kernel.org
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; stable@vger.kernel.org; Stephen Boyd <sboyd@kernel.org>; Stephen
> > > Boyd <swboyd@chromium.org>; Jordan Crouse <jcrouse@codeaurora.org>; Rob Clark <robdclark@chromium.org>; Sean Paul
> > > <seanpaul@chromium.org>; Lee Jones <lee.jones@linaro.org>
> > > Subject: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache
> > >
> > > From: Rob Clark <robdclark@chromium.org>
> > >
> > > commit 0036bc73ccbe7e600a3468bf8e8879b122252274 upstream.
> > >
> > > Recently splats like this started showing up:
> > >
> > >    WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451 __iommu_dma_unmap+0xb8/0xc0
> > >    Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo cfg80211 videobuf2_vmalloc videobuf2_memops
> > > vide
> > >    CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: G        W         5.2.0-rc5-next-20190619+ #2317
> > >    Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
> > >    Workqueue: msm msm_gem_free_work [msm]
> > >    pstate: 80c00005 (Nzcv daif +PAN +UAO)
> > >    pc : __iommu_dma_unmap+0xb8/0xc0
> > >    lr : __iommu_dma_unmap+0x54/0xc0
> > >    sp : ffff0000119abce0
> > >    x29: ffff0000119abce0 x28: 0000000000000000
> > >    x27: ffff8001f9946648 x26: ffff8001ec271068
> > >    x25: 0000000000000000 x24: ffff8001ea3580a8
> > >    x23: ffff8001f95ba010 x22: ffff80018e83ba88
> > >    x21: ffff8001e548f000 x20: fffffffffffff000
> > >    x19: 0000000000001000 x18: 00000000c00001fe
> > >    x17: 0000000000000000 x16: 0000000000000000
> > >    x15: ffff000015b70068 x14: 0000000000000005
> > >    x13: 0003142cc1be1768 x12: 0000000000000001
> > >    x11: ffff8001f6de9100 x10: 0000000000000009
> > >    x9 : ffff000015b78000 x8 : 0000000000000000
> > >    x7 : 0000000000000001 x6 : fffffffffffff000
> > >    x5 : 0000000000000fff x4 : ffff00001065dbc8
> > >    x3 : 000000000000000d x2 : 0000000000001000
> > >    x1 : fffffffffffff000 x0 : 0000000000000000
> > >    Call trace:
> > >     __iommu_dma_unmap+0xb8/0xc0
> > >     iommu_dma_unmap_sg+0x98/0xb8
> > >     put_pages+0x5c/0xf0 [msm]
> > >     msm_gem_free_work+0x10c/0x150 [msm]
> > >     process_one_work+0x1e0/0x330
> > >     worker_thread+0x40/0x438
> > >     kthread+0x12c/0x130
> > >     ret_from_fork+0x10/0x18
> > >    ---[ end trace afc0dc5ab81a06bf ]---
> > >
> > > Not quite sure what triggered that, but we really shouldn't be abusing
> > > dma_{map,unmap}_sg() for cache maint.
> > >
> > > Cc: Stephen Boyd <sboyd@kernel.org>
> > > Tested-by: Stephen Boyd <swboyd@chromium.org>
> > > Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
> > > Signed-off-by: Rob Clark <robdclark@chromium.org>
> > > Signed-off-by: Sean Paul <seanpaul@chromium.org>
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdclark@gmail.com
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > This commit also requires the following commits:
> >
> > commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c
> > Author: Rob Clark <robdclark@chromium.org>
> > Date:   Tue Jul 30 14:46:28 2019 -0700
> >
> >     drm/msm: Use the correct dma_sync calls in msm_gem
> >
> >     [subject was: drm/msm: shake fist angrily at dma-mapping]
> >
> >     So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
> >     it falls appart with dma direct ops.  The problem is that, depending on
> >     display generation, we can have either set of dma ops (mdp4 and dpu have
> >     iommu wired to mdss node, which maps to toplevel drm device, but mdp5
> >     has iommu wired up to the mdp sub-node within mdss).
> >
> >     Fixes this splat on mdp5 devices:
> >
> >        Unable to handle kernel paging request at virtual address ffffffff80000000
> >        Mem abort info:
> >          ESR = 0x96000144
> >          Exception class = DABT (current EL), IL = 32 bits
> >          SET = 0, FnV = 0
> >          EA = 0, S1PTW = 0
> >        Data abort info:
> >          ISV = 0, ISS = 0x00000144
> >          CM = 1, WnR = 1
> >        swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000810e4000
> >        [ffffffff80000000] pgd=0000000000000000
> >        Internal error: Oops: 96000144 [#1] SMP
> >        Modules linked in: btqcomsmd btqca bluetooth cfg80211 ecdh_generic ecc rfkill libarc4 panel_simple msm wcnss_ctrl qrtr_smd drm_kms_helper venus_enc venus_dec videobuf2_dma_sg videobuf2_memops drm venus_core ipv6 qrtr qcom_wcnss_pil v4l2_mem2mem qcom_sysmon videobuf2_v4l2 qmi_helpers videobuf2_common crct10dif_ce mdt_loader qcom_common videodev qcom_glink_smem remoteproc bmc150_accel_i2c bmc150_magn_i2c bmc150_accel_core bmc150_magn snd_soc_lpass_apq8016 snd_soc_msm8916_analog mms114 mc nf_defrag_ipv6 snd_soc_lpass_cpu snd_soc_apq8016_sbc industrialio_triggered_buffer kfifo_buf snd_soc_lpass_platform snd_soc_msm8916_digital drm_panel_orientation_quirks
> >        CPU: 2 PID: 33 Comm: kworker/2:1 Not tainted 5.3.0-rc2 #1
> >        Hardware name: Samsung Galaxy A5U (EUR) (DT)
> >        Workqueue: events deferred_probe_work_func
> >        pstate: 80000005 (Nzcv daif -PAN -UAO)
> >        pc : __clean_dcache_area_poc+0x20/0x38
> >        lr : arch_sync_dma_for_device+0x28/0x30


We have noticed this problem on stable-rc 4.19.118-rc1 running on arm64
qualcomm dragonboard-410c device while booting.

[    5.474942] msm 1a00000.mdss: A306: using IOMMU
[    5.483399] Unable to handle kernel paging request at virtual
address ffffffff80000000
[    5.487564] Mem abort info:
[    5.498182]   ESR = 0x96000144
[    5.507101]   SET = 0, FnV = 0
[    5.507114]   EA = 0, S1PTW = 0
[    5.509154] Data abort info:
[    5.512253]   ISV = 0, ISS = 0x00000144
[    5.515376]   CM = 1, WnR = 1
[    5.518877] swapper pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
[    5.522072] [ffffffff80000000] pgd=0000000000000000
[    5.528819] Internal error: Oops: 96000144 [#1] PREEMPT SMP
[    5.533491] Modules linked in: msm(+) crc32_ce adv7511 cec
mdt_loader drm_kms_helper drm drm_panel_orientation_quirks fuse
[    5.539057] Process systemd-udevd (pid: 2807, stack limit =
0x(____ptrval____))
[    5.550162] CPU: 0 PID: 2807 Comm: systemd-udevd Not tainted
4.19.118-rc1-00065-gb5f03cd61ab6 #1
[    5.557366] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[    5.566392] pstate: 80000005 (Nzcv daif -PAN -UAO)
[    5.573079] pc : __clean_dcache_area_poc+0x20/0x38
[    5.577676] lr : __swiotlb_sync_sg_for_device+0x74/0xa0
[    5.582447] sp : ffff00000dcab490
[    5.587567] x29: ffff00000dcab490 x28: 0000000000000001
[    5.591043] x27: ffff000000d97e40 x26: ffff80003bb9e000
[    5.596423] x25: ffff80003c14c410 x24: ffff000009066178
[    5.601717] x23: ffff80003c14c810 x22: 0000000000000000
[    5.607013] x21: 0000000000000001 x20: 0000000000000001
[    5.612308] x19: ffff80003634cf80 x18: 0000000000000400
[    5.617603] x17: 0000000000000000 x16: 0000000000000000
[    5.622899] x15: 0000000000000400 x14: 0000000000000400
[    5.628194] x13: 0000000000000001 x12: 0000000000000000
[    5.633489] x11: 0000800036c50000 x10: ffff80003639fba8
[    5.638783] x9 : 0000000000001000 x8 : ffff7e0000e7c080
[    5.644079] x7 : 0000000000000001 x6 : 0000000000000000
[    5.649375] x5 : 0000000000000000 x4 : ffffffff80000000
[    5.654669] x3 : 000000000000003f x2 : 0000000000000040
[    5.659964] x1 : ffffffff80001000 x0 : ffffffff80000000
[    5.665260] Call trace:
[    5.670556]  __clean_dcache_area_poc+0x20/0x38
[    5.672850]  get_pages+0x1cc/0x240 [msm]
[    5.677355]  msm_gem_get_iova+0x94/0x138 [msm]
[    5.681428]  _msm_gem_kernel_new+0x40/0xb0 [msm]
[    5.685679]  msm_gem_kernel_new+0x10/0x18 [msm]
[    5.690452]  msm_gpu_init+0x300/0x568 [msm]
[    5.694698]  adreno_gpu_init+0x14c/0x268 [msm]
[    5.698861]  a3xx_gpu_init+0x7c/0x108 [msm]
[    5.703375]  adreno_bind+0x144/0x238 [msm]
[    5.707365]  component_bind_all+0x110/0x270
[    5.711627]  msm_drm_bind+0x104/0x760 [msm]
[    5.715609]  try_to_bring_up_master+0x14c/0x1a8
[    5.719775]  component_master_add_with_match+0xc0/0x100
[    5.724388]  msm_pdev_probe+0x280/0x320 [msm]
[    5.729499]  platform_drv_probe+0x50/0xa0
[    5.734010]  really_probe+0x1f4/0x290
[    5.738003]  driver_probe_device+0x54/0xe8
[    5.741649]  __driver_attach+0xe0/0xe8
[    5.745644]  bus_for_each_dev+0x70/0xb8
[    5.749374]  driver_attach+0x20/0x28
[    5.753108]  bus_add_driver+0x1a0/0x210
[    5.756927]  driver_register+0x60/0x110
[    5.760485]  __platform_driver_register+0x44/0x50
[    5.764407]  msm_drm_register+0x54/0x68 [msm]
[    5.769169]  do_one_initcall+0x54/0x154
[    5.773509]  do_init_module+0x54/0x1c8
[    5.777152]  load_module+0x1bf4/0x2190
[    5.780972]  __se_sys_finit_module+0xb8/0xc8
[    5.784706]  __arm64_sys_finit_module+0x18/0x20
[    5.789135]  el0_svc_common+0x70/0x168
[    5.793385]  el0_svc_handler+0x2c/0x80
[    5.797204]  el0_svc+0x8/0xc
[    5.800939] Code: 9ac32042 8b010001 d1000443 8a230000 (d50b7e20)
[    5.803980] ---[ end trace 004276cd8aee46e8 ]---

Ref:
Full test logs.
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.117-65-gb5f03cd61ab6/testrun/1387563/log
https://lkft.validation.linaro.org/scheduler/job/1387568#L3575

kernel configs link,
https://builds.tuxbuild.com/TcvobwCBir3uhOd2MA-ndw/kernel.config

--
Linaro LKFT
https://lkft.linaro.org

RE: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache

[nobuhiro1.iwamatsu]

Hi,

Thanks for your report.

> -----Original Message-----
> From: Naresh Kamboju [mailto:naresh.kamboju@linaro.org]
> Sent: Thursday, April 23, 2020 5:24 AM
> To: Greg KH <gregkh@linuxfoundation.org>
> Cc: iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ) <nobuhiro1.iwamatsu@toshiba.co.jp>; open list
> <linux-kernel@vger.kernel.org>; linux- stable <stable@vger.kernel.org>; Stephen Boyd <sboyd@kernel.org>;
> swboyd@chromium.org; jcrouse@codeaurora.org; Rob Clark <robdclark@chromium.org>; seanpaul@chromium.org; Lee Jones
> <lee.jones@linaro.org>; lkft-triage@lists.linaro.org
> Subject: Re: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache
> 
> On Mon, 13 Apr 2020 at 13:56, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Apr 13, 2020 at 05:03:26AM +0000, nobuhiro1.iwamatsu@toshiba.co.jp wrote:
> > > Hi,
> > >
> > > > -----Original Message-----
> > > > From: stable-owner@vger.kernel.org [mailto:stable-owner@vger.kernel.org] On Behalf Of Greg Kroah-Hartman
> > > > Sent: Saturday, April 11, 2020 9:10 PM
> > > > To: linux-kernel@vger.kernel.org
> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; stable@vger.kernel.org; Stephen Boyd <sboyd@kernel.org>;
> Stephen
> > > > Boyd <swboyd@chromium.org>; Jordan Crouse <jcrouse@codeaurora.org>; Rob Clark <robdclark@chromium.org>; Sean
> Paul
> > > > <seanpaul@chromium.org>; Lee Jones <lee.jones@linaro.org>
> > > > Subject: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache
> > > >
> > > > From: Rob Clark <robdclark@chromium.org>
> > > >
> > > > commit 0036bc73ccbe7e600a3468bf8e8879b122252274 upstream.
> > > >
> > > > Recently splats like this started showing up:
> > > >
> > > >    WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451 __iommu_dma_unmap+0xb8/0xc0
> > > >    Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo cfg80211 videobuf2_vmalloc
> videobuf2_memops
> > > > vide
> > > >    CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: G        W         5.2.0-rc5-next-20190619+ #2317
> > > >    Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
> > > >    Workqueue: msm msm_gem_free_work [msm]
> > > >    pstate: 80c00005 (Nzcv daif +PAN +UAO)
> > > >    pc : __iommu_dma_unmap+0xb8/0xc0
> > > >    lr : __iommu_dma_unmap+0x54/0xc0
> > > >    sp : ffff0000119abce0
> > > >    x29: ffff0000119abce0 x28: 0000000000000000
> > > >    x27: ffff8001f9946648 x26: ffff8001ec271068
> > > >    x25: 0000000000000000 x24: ffff8001ea3580a8
> > > >    x23: ffff8001f95ba010 x22: ffff80018e83ba88
> > > >    x21: ffff8001e548f000 x20: fffffffffffff000
> > > >    x19: 0000000000001000 x18: 00000000c00001fe
> > > >    x17: 0000000000000000 x16: 0000000000000000
> > > >    x15: ffff000015b70068 x14: 0000000000000005
> > > >    x13: 0003142cc1be1768 x12: 0000000000000001
> > > >    x11: ffff8001f6de9100 x10: 0000000000000009
> > > >    x9 : ffff000015b78000 x8 : 0000000000000000
> > > >    x7 : 0000000000000001 x6 : fffffffffffff000
> > > >    x5 : 0000000000000fff x4 : ffff00001065dbc8
> > > >    x3 : 000000000000000d x2 : 0000000000001000
> > > >    x1 : fffffffffffff000 x0 : 0000000000000000
> > > >    Call trace:
> > > >     __iommu_dma_unmap+0xb8/0xc0
> > > >     iommu_dma_unmap_sg+0x98/0xb8
> > > >     put_pages+0x5c/0xf0 [msm]
> > > >     msm_gem_free_work+0x10c/0x150 [msm]
> > > >     process_one_work+0x1e0/0x330
> > > >     worker_thread+0x40/0x438
> > > >     kthread+0x12c/0x130
> > > >     ret_from_fork+0x10/0x18
> > > >    ---[ end trace afc0dc5ab81a06bf ]---
> > > >
> > > > Not quite sure what triggered that, but we really shouldn't be abusing
> > > > dma_{map,unmap}_sg() for cache maint.
> > > >
> > > > Cc: Stephen Boyd <sboyd@kernel.org>
> > > > Tested-by: Stephen Boyd <swboyd@chromium.org>
> > > > Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
> > > > Signed-off-by: Rob Clark <robdclark@chromium.org>
> > > > Signed-off-by: Sean Paul <seanpaul@chromium.org>
> > > > Link: https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdclark@gmail.com
> > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >
> > > This commit also requires the following commits:
> > >
> > > commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c
> > > Author: Rob Clark <robdclark@chromium.org>
> > > Date:   Tue Jul 30 14:46:28 2019 -0700
> > >
> > >     drm/msm: Use the correct dma_sync calls in msm_gem
> > >
> > >     [subject was: drm/msm: shake fist angrily at dma-mapping]
> > >
> > >     So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
> > >     it falls appart with dma direct ops.  The problem is that, depending on
> > >     display generation, we can have either set of dma ops (mdp4 and dpu have
> > >     iommu wired to mdss node, which maps to toplevel drm device, but mdp5
> > >     has iommu wired up to the mdp sub-node within mdss).
> > >
> > >     Fixes this splat on mdp5 devices:
> > >
> > >        Unable to handle kernel paging request at virtual address ffffffff80000000
> > >        Mem abort info:
> > >          ESR = 0x96000144
> > >          Exception class = DABT (current EL), IL = 32 bits
> > >          SET = 0, FnV = 0
> > >          EA = 0, S1PTW = 0
> > >        Data abort info:
> > >          ISV = 0, ISS = 0x00000144
> > >          CM = 1, WnR = 1
> > >        swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000810e4000
> > >        [ffffffff80000000] pgd=0000000000000000
> > >        Internal error: Oops: 96000144 [#1] SMP
> > >        Modules linked in: btqcomsmd btqca bluetooth cfg80211 ecdh_generic ecc rfkill libarc4 panel_simple msm
> wcnss_ctrl qrtr_smd drm_kms_helper venus_enc venus_dec videobuf2_dma_sg videobuf2_memops drm venus_core ipv6 qrtr
> qcom_wcnss_pil v4l2_mem2mem qcom_sysmon videobuf2_v4l2 qmi_helpers videobuf2_common crct10dif_ce mdt_loader
> qcom_common videodev qcom_glink_smem remoteproc bmc150_accel_i2c bmc150_magn_i2c bmc150_accel_core bmc150_magn
> snd_soc_lpass_apq8016 snd_soc_msm8916_analog mms114 mc nf_defrag_ipv6 snd_soc_lpass_cpu snd_soc_apq8016_sbc
> industrialio_triggered_buffer kfifo_buf snd_soc_lpass_platform snd_soc_msm8916_digital drm_panel_orientation_quirks
> > >        CPU: 2 PID: 33 Comm: kworker/2:1 Not tainted 5.3.0-rc2 #1
> > >        Hardware name: Samsung Galaxy A5U (EUR) (DT)
> > >        Workqueue: events deferred_probe_work_func
> > >        pstate: 80000005 (Nzcv daif -PAN -UAO)
> > >        pc : __clean_dcache_area_poc+0x20/0x38
> > >        lr : arch_sync_dma_for_device+0x28/0x30
> 
> 
> We have noticed this problem on stable-rc 4.19.118-rc1 running on arm64
> qualcomm dragonboard-410c device while booting.
> 
> [    5.474942] msm 1a00000.mdss: A306: using IOMMU
> [    5.483399] Unable to handle kernel paging request at virtual
> address ffffffff80000000
> [    5.487564] Mem abort info:
> [    5.498182]   ESR = 0x96000144
> [    5.507101]   SET = 0, FnV = 0
> [    5.507114]   EA = 0, S1PTW = 0
> [    5.509154] Data abort info:
> [    5.512253]   ISV = 0, ISS = 0x00000144
> [    5.515376]   CM = 1, WnR = 1
> [    5.518877] swapper pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
> [    5.522072] [ffffffff80000000] pgd=0000000000000000
> [    5.528819] Internal error: Oops: 96000144 [#1] PREEMPT SMP
> [    5.533491] Modules linked in: msm(+) crc32_ce adv7511 cec
> mdt_loader drm_kms_helper drm drm_panel_orientation_quirks fuse
> [    5.539057] Process systemd-udevd (pid: 2807, stack limit =
> 0x(____ptrval____))
> [    5.550162] CPU: 0 PID: 2807 Comm: systemd-udevd Not tainted
> 4.19.118-rc1-00065-gb5f03cd61ab6 #1
> [    5.557366] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
> [    5.566392] pstate: 80000005 (Nzcv daif -PAN -UAO)
> [    5.573079] pc : __clean_dcache_area_poc+0x20/0x38
> [    5.577676] lr : __swiotlb_sync_sg_for_device+0x74/0xa0
> [    5.582447] sp : ffff00000dcab490
> [    5.587567] x29: ffff00000dcab490 x28: 0000000000000001
> [    5.591043] x27: ffff000000d97e40 x26: ffff80003bb9e000
> [    5.596423] x25: ffff80003c14c410 x24: ffff000009066178
> [    5.601717] x23: ffff80003c14c810 x22: 0000000000000000
> [    5.607013] x21: 0000000000000001 x20: 0000000000000001
> [    5.612308] x19: ffff80003634cf80 x18: 0000000000000400
> [    5.617603] x17: 0000000000000000 x16: 0000000000000000
> [    5.622899] x15: 0000000000000400 x14: 0000000000000400
> [    5.628194] x13: 0000000000000001 x12: 0000000000000000
> [    5.633489] x11: 0000800036c50000 x10: ffff80003639fba8
> [    5.638783] x9 : 0000000000001000 x8 : ffff7e0000e7c080
> [    5.644079] x7 : 0000000000000001 x6 : 0000000000000000
> [    5.649375] x5 : 0000000000000000 x4 : ffffffff80000000
> [    5.654669] x3 : 000000000000003f x2 : 0000000000000040
> [    5.659964] x1 : ffffffff80001000 x0 : ffffffff80000000
> [    5.665260] Call trace:
> [    5.670556]  __clean_dcache_area_poc+0x20/0x38
> [    5.672850]  get_pages+0x1cc/0x240 [msm]
> [    5.677355]  msm_gem_get_iova+0x94/0x138 [msm]
> [    5.681428]  _msm_gem_kernel_new+0x40/0xb0 [msm]
> [    5.685679]  msm_gem_kernel_new+0x10/0x18 [msm]
> [    5.690452]  msm_gpu_init+0x300/0x568 [msm]
> [    5.694698]  adreno_gpu_init+0x14c/0x268 [msm]
> [    5.698861]  a3xx_gpu_init+0x7c/0x108 [msm]
> [    5.703375]  adreno_bind+0x144/0x238 [msm]
> [    5.707365]  component_bind_all+0x110/0x270
> [    5.711627]  msm_drm_bind+0x104/0x760 [msm]
> [    5.715609]  try_to_bring_up_master+0x14c/0x1a8
> [    5.719775]  component_master_add_with_match+0xc0/0x100
> [    5.724388]  msm_pdev_probe+0x280/0x320 [msm]
> [    5.729499]  platform_drv_probe+0x50/0xa0
> [    5.734010]  really_probe+0x1f4/0x290
> [    5.738003]  driver_probe_device+0x54/0xe8
> [    5.741649]  __driver_attach+0xe0/0xe8
> [    5.745644]  bus_for_each_dev+0x70/0xb8
> [    5.749374]  driver_attach+0x20/0x28
> [    5.753108]  bus_add_driver+0x1a0/0x210
> [    5.756927]  driver_register+0x60/0x110
> [    5.760485]  __platform_driver_register+0x44/0x50
> [    5.764407]  msm_drm_register+0x54/0x68 [msm]
> [    5.769169]  do_one_initcall+0x54/0x154
> [    5.773509]  do_init_module+0x54/0x1c8
> [    5.777152]  load_module+0x1bf4/0x2190
> [    5.780972]  __se_sys_finit_module+0xb8/0xc8
> [    5.784706]  __arm64_sys_finit_module+0x18/0x20
> [    5.789135]  el0_svc_common+0x70/0x168
> [    5.793385]  el0_svc_handler+0x2c/0x80
> [    5.797204]  el0_svc+0x8/0xc
> [    5.800939] Code: 9ac32042 8b010001 d1000443 8a230000 (d50b7e20)
> [    5.803980] ---[ end trace 004276cd8aee46e8 ]---
> 
> Ref:
> Full test logs.
> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.117-65-gb5f03cd61ab6/testrun/1387563/log
> https://lkft.validation.linaro.org/scheduler/job/1387568#L3575
> 
> kernel configs link,
> https://builds.tuxbuild.com/TcvobwCBir3uhOd2MA-ndw/kernel.config

I think the following patch is needed for this.

9f614197c744002f9968e82c649fdf7fe778e1e7
3de433c5b38af49a5fc7602721e2ab5d39f1e69c

But I have no environment to check this now.

Best regards,
  Nobuhiro
> 
> --
> Linaro LKFT
> https://lkft.linaro.org

Re: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache

[Naresh Kamboju]

On Thu, 23 Apr 2020 at 05:03, <nobuhiro1.iwamatsu@toshiba.co.jp> wrote:
<trim>
>
> I think the following patch is needed for this.
>
> 9f614197c744002f9968e82c649fdf7fe778e1e7
> 3de433c5b38af49a5fc7602721e2ab5d39f1e69c
>
> But I have no environment to check this now.

The above suggested two patches already in stable-rc 4.19 branch
but i still notice Internal error: Oops: 96000144 [#1] PREEMPT SMP
on arm64 qualcomm dragonboard-410c device while booting.

[    7.906343] msm 1a00000.mdss: bound 1a98000.dsi (ops dsi_ops [msm])
[    7.912697] adreno 1c00000.gpu: 1c00000.gpu supply vdd not found,
using dummy regulator
[    7.918567] adreno 1c00000.gpu: Linked as a consumer to regulator.0
[    7.926521] adreno 1c00000.gpu: 1c00000.gpu supply vddcx not found,
using dummy regulator
[    7.932759] msm 1a00000.mdss: A306: using IOMMU
[    7.941207] Unable to handle kernel paging request at virtual
address ffffffff80000000
[    7.945375] Mem abort info:
[    7.953353]   ESR = 0x96000144
[    7.956034]   Exception class = DABT (current EL), IL = 32 bits
[    7.970501]   EA = 0, S1PTW = 0
[    7.970516] Data abort info:
[    7.972485]   ISV = 0, ISS = 0x00000144
[    7.975577]   CM = 1, WnR = 1
[    7.979169] swapper pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
[    7.982295] [ffffffff80000000] pgd=0000000000000000
[    7.989099] Internal error: Oops: 96000144 [#1] PREEMPT SMP
[    7.993802] Modules linked in: msm(+) crc32_ce adv7511 cec
mdt_loader drm_kms_helper drm drm_panel_orientation_quirks fuse
[    7.999367] Process systemd-udevd (pid: 2849, stack limit =
0x(____ptrval____))
[    8.010474] CPU: 1 PID: 2849 Comm: systemd-udevd Not tainted
4.19.125-rc1-00077-g0708fb235b9c #1
[    8.017677] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[    8.026703] pstate: 80000005 (Nzcv daif -PAN -UAO)
[    8.033390] pc : __clean_dcache_area_poc+0x20/0x38
[    8.037998] lr : __swiotlb_sync_sg_for_device+0x74/0xa0
[    8.038001] sp : ffff00000e313490
[    8.038004] x29: ffff00000e313490 x28: 0000000000000001
[    8.038009] x27: ffff000000d56e40 x26: ffff800036301000
[    8.038013] x25: ffff80003c108410 x24: ffff000009069998
[    8.038018] x23: ffff80003c108810 x22: 0000000000000000
[    8.038023] x21: 0000000000000001 x20: 0000000000000001
[    8.038027] x19: ffff80003acd4480 x18: ffff0000092298c8
[    8.038032] x17: 0000000000000000 x16: 0000000000000000
[    8.038036] x15: 0000000000000010 x14: ffffffffffffffff
[    8.038042] x13: ffff0000893987d7 x12: 0000000000000000
[    8.038046] x11: 0000800036c56000 x10: ffff8000362ef368
[    8.038050] x9 : 0000000000001000 x8 : ffff7e0000e71640
[    8.038055] x7 : 0000000000000001 x6 : 0000000000000000
[    8.038059] x5 : 0000000000000000 x4 : ffffffff80000000
[    8.038064] x3 : 000000000000003f x2 : 0000000000000040
[    8.038068] x1 : ffffffff80001000 x0 : ffffffff80000000
[    8.038072] Call trace:
[    8.038078]  __clean_dcache_area_poc+0x20/0x38
[    8.038204]  get_pages+0x1cc/0x240 [msm]
[    8.038327]  msm_gem_get_iova+0x94/0x138 [msm]
[    8.141741]  _msm_gem_kernel_new+0x40/0xb0 [msm]
[    8.145989]  msm_gem_kernel_new+0x10/0x18 [msm]
[    8.150759]  msm_gpu_init+0x300/0x568 [msm]
[    8.155004]  adreno_gpu_init+0x14c/0x268 [msm]
[    8.159171]  a3xx_gpu_init+0x7c/0x108 [msm]
[    8.163682]  adreno_bind+0x144/0x238 [msm]
[    8.167676]  component_bind_all+0x110/0x278
[    8.171939]  msm_drm_bind+0x104/0x760 [msm]
[    8.175921]  try_to_bring_up_master+0x14c/0x1b0
[    8.180086]  component_master_add_with_match+0xc0/0x100
[    8.184697]  msm_pdev_probe+0x280/0x320 [msm]
[    8.189810]  platform_drv_probe+0x50/0xa0
[    8.194322]  really_probe+0x1f4/0x290
[    8.198314]  driver_probe_device+0x54/0xe8
[    8.201960]  __driver_attach+0xe0/0xe8
[    8.205952]  bus_for_each_dev+0x70/0xb8
[    8.209685]  driver_attach+0x20/0x28
[    8.213417]  bus_add_driver+0x1a0/0x210
[    8.217237]  driver_register+0x60/0x110
[    8.220797]  __platform_driver_register+0x44/0x50
[    8.224717]  msm_drm_register+0x54/0x68 [msm]
[    8.229479]  do_one_initcall+0x54/0x154
[    8.233819]  do_init_module+0x54/0x1c8
[    8.237463]  load_module+0x1bf4/0x2190
[    8.241282]  __se_sys_finit_module+0xb8/0xc8
[    8.245016]  __arm64_sys_finit_module+0x18/0x20
[    8.249445]  el0_svc_common+0x70/0x168
[    8.253695]  el0_svc_handler+0x2c/0x80
[    8.257514]  el0_svc+0x8/0xc
[    8.261250] Code: 9ac32042 8b010001 d1000443 8a230000 (d50b7e20)
[    8.264290] ---[ end trace 2effae58ca65f06b ]---

on stable-rc 4.19 branch git log show this info,
$ git log  --oneline drivers/gpu/drm/msm/msm_gem.c | head
05fe33cad985 drm/msm: Use the correct dma_sync calls harder
39718d086d9b drm/msm: Use the correct dma_sync calls in msm_gem
9c23e00804f8 drm/msm: stop abusing dma_map/unmap for cache
a5f74ec7d3cb gpu: drm: msm: Change return type to vm_fault_t
3976626ea3d2 drm/msm: Fix possible null dereference on failure of get_pages()
d71b6bd80d96 drm/msm/dsi: fix direct caller of msm_gem_free_object()
dc9a9b32053e drm/msm: Replace gem_object deprecated functions
62e3a3e342af drm/msm: fix leak in failed get_pages
7a88cbd8d65d Backmerge tag 'v4.14-rc7' into drm-next
fad33f4b1073 drm/msm: add special _get_vaddr_active() for cmdstream dumps

link to full boot log,
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.124-77-g0708fb235b9c/testrun/1450572/log
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.124-77-g0708fb235b9c/testrun/1450572

Kernel config:
https://builds.tuxbuild.com/Xp5Fh9e52QxohQeW6nazPA/kernel.config

>
> Best regards,
>   Nobuhiro
> >
> > --
> > Linaro LKFT
> > https://lkft.linaro.org

Re: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache

[Rob Clark]

On Tue, May 26, 2020 at 7:33 AM Naresh Kamboju
<naresh.kamboju@linaro.org> wrote:
>
> On Thu, 23 Apr 2020 at 05:03, <nobuhiro1.iwamatsu@toshiba.co.jp> wrote:
> <trim>
> >
> > I think the following patch is needed for this.
> >
> > 9f614197c744002f9968e82c649fdf7fe778e1e7
> > 3de433c5b38af49a5fc7602721e2ab5d39f1e69c
> >
> > But I have no environment to check this now.
>
> The above suggested two patches already in stable-rc 4.19 branch
> but i still notice Internal error: Oops: 96000144 [#1] PREEMPT SMP
> on arm64 qualcomm dragonboard-410c device while booting.
>
> [    7.906343] msm 1a00000.mdss: bound 1a98000.dsi (ops dsi_ops [msm])
> [    7.912697] adreno 1c00000.gpu: 1c00000.gpu supply vdd not found,
> using dummy regulator
> [    7.918567] adreno 1c00000.gpu: Linked as a consumer to regulator.0
> [    7.926521] adreno 1c00000.gpu: 1c00000.gpu supply vddcx not found,
> using dummy regulator
> [    7.932759] msm 1a00000.mdss: A306: using IOMMU
> [    7.941207] Unable to handle kernel paging request at virtual
> address ffffffff80000000
> [    7.945375] Mem abort info:
> [    7.953353]   ESR = 0x96000144
> [    7.956034]   Exception class = DABT (current EL), IL = 32 bits
> [    7.970501]   EA = 0, S1PTW = 0
> [    7.970516] Data abort info:
> [    7.972485]   ISV = 0, ISS = 0x00000144
> [    7.975577]   CM = 1, WnR = 1
> [    7.979169] swapper pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
> [    7.982295] [ffffffff80000000] pgd=0000000000000000
> [    7.989099] Internal error: Oops: 96000144 [#1] PREEMPT SMP
> [    7.993802] Modules linked in: msm(+) crc32_ce adv7511 cec
> mdt_loader drm_kms_helper drm drm_panel_orientation_quirks fuse
> [    7.999367] Process systemd-udevd (pid: 2849, stack limit =
> 0x(____ptrval____))
> [    8.010474] CPU: 1 PID: 2849 Comm: systemd-udevd Not tainted
> 4.19.125-rc1-00077-g0708fb235b9c #1
> [    8.017677] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
> [    8.026703] pstate: 80000005 (Nzcv daif -PAN -UAO)
> [    8.033390] pc : __clean_dcache_area_poc+0x20/0x38
> [    8.037998] lr : __swiotlb_sync_sg_for_device+0x74/0xa0
> [    8.038001] sp : ffff00000e313490
> [    8.038004] x29: ffff00000e313490 x28: 0000000000000001
> [    8.038009] x27: ffff000000d56e40 x26: ffff800036301000
> [    8.038013] x25: ffff80003c108410 x24: ffff000009069998
> [    8.038018] x23: ffff80003c108810 x22: 0000000000000000
> [    8.038023] x21: 0000000000000001 x20: 0000000000000001
> [    8.038027] x19: ffff80003acd4480 x18: ffff0000092298c8
> [    8.038032] x17: 0000000000000000 x16: 0000000000000000
> [    8.038036] x15: 0000000000000010 x14: ffffffffffffffff
> [    8.038042] x13: ffff0000893987d7 x12: 0000000000000000
> [    8.038046] x11: 0000800036c56000 x10: ffff8000362ef368
> [    8.038050] x9 : 0000000000001000 x8 : ffff7e0000e71640
> [    8.038055] x7 : 0000000000000001 x6 : 0000000000000000
> [    8.038059] x5 : 0000000000000000 x4 : ffffffff80000000
> [    8.038064] x3 : 000000000000003f x2 : 0000000000000040
> [    8.038068] x1 : ffffffff80001000 x0 : ffffffff80000000
> [    8.038072] Call trace:
> [    8.038078]  __clean_dcache_area_poc+0x20/0x38
> [    8.038204]  get_pages+0x1cc/0x240 [msm]
> [    8.038327]  msm_gem_get_iova+0x94/0x138 [msm]
> [    8.141741]  _msm_gem_kernel_new+0x40/0xb0 [msm]
> [    8.145989]  msm_gem_kernel_new+0x10/0x18 [msm]
> [    8.150759]  msm_gpu_init+0x300/0x568 [msm]
> [    8.155004]  adreno_gpu_init+0x14c/0x268 [msm]
> [    8.159171]  a3xx_gpu_init+0x7c/0x108 [msm]
> [    8.163682]  adreno_bind+0x144/0x238 [msm]
> [    8.167676]  component_bind_all+0x110/0x278
> [    8.171939]  msm_drm_bind+0x104/0x760 [msm]
> [    8.175921]  try_to_bring_up_master+0x14c/0x1b0
> [    8.180086]  component_master_add_with_match+0xc0/0x100
> [    8.184697]  msm_pdev_probe+0x280/0x320 [msm]
> [    8.189810]  platform_drv_probe+0x50/0xa0
> [    8.194322]  really_probe+0x1f4/0x290
> [    8.198314]  driver_probe_device+0x54/0xe8
> [    8.201960]  __driver_attach+0xe0/0xe8
> [    8.205952]  bus_for_each_dev+0x70/0xb8
> [    8.209685]  driver_attach+0x20/0x28
> [    8.213417]  bus_add_driver+0x1a0/0x210
> [    8.217237]  driver_register+0x60/0x110
> [    8.220797]  __platform_driver_register+0x44/0x50
> [    8.224717]  msm_drm_register+0x54/0x68 [msm]
> [    8.229479]  do_one_initcall+0x54/0x154
> [    8.233819]  do_init_module+0x54/0x1c8
> [    8.237463]  load_module+0x1bf4/0x2190
> [    8.241282]  __se_sys_finit_module+0xb8/0xc8
> [    8.245016]  __arm64_sys_finit_module+0x18/0x20
> [    8.249445]  el0_svc_common+0x70/0x168
> [    8.253695]  el0_svc_handler+0x2c/0x80
> [    8.257514]  el0_svc+0x8/0xc
> [    8.261250] Code: 9ac32042 8b010001 d1000443 8a230000 (d50b7e20)
> [    8.264290] ---[ end trace 2effae58ca65f06b ]---
>
> on stable-rc 4.19 branch git log show this info,
> $ git log  --oneline drivers/gpu/drm/msm/msm_gem.c | head
> 05fe33cad985 drm/msm: Use the correct dma_sync calls harder
> 39718d086d9b drm/msm: Use the correct dma_sync calls in msm_gem
> 9c23e00804f8 drm/msm: stop abusing dma_map/unmap for cache
> a5f74ec7d3cb gpu: drm: msm: Change return type to vm_fault_t
> 3976626ea3d2 drm/msm: Fix possible null dereference on failure of get_pages()
> d71b6bd80d96 drm/msm/dsi: fix direct caller of msm_gem_free_object()
> dc9a9b32053e drm/msm: Replace gem_object deprecated functions
> 62e3a3e342af drm/msm: fix leak in failed get_pages
> 7a88cbd8d65d Backmerge tag 'v4.14-rc7' into drm-next
> fad33f4b1073 drm/msm: add special _get_vaddr_active() for cmdstream dumps
>
> link to full boot log,
> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.124-77-g0708fb235b9c/testrun/1450572/log
> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.124-77-g0708fb235b9c/testrun/1450572
>
> Kernel config:
> https://builds.tuxbuild.com/Xp5Fh9e52QxohQeW6nazPA/kernel.config

I suspect there is some difference between qcom_iommu and arm-smmu?
Maybe qcom_iommu (esp. back in v4.19) is missing something for
automatic hookup of iommu-dma-ops?

All the ugliness around dma-sync is related to trying to avoid using
dma_map_*/dma_unmap_* when arm-smmu is in use (and the iommu dma-ops
are installed, since they end up fighting w/ drm/msm's direct use of
it's iommus).  It looks like we are going to finally get a way to
solve this uglyness a bit better once some arm-smmu patches[1] land in
v5.8.  I suppose that doesn't really help v4.19.

But taking a step back, I'm not entirely sure whether this was a
problem yet on v4.19.  Presumably dropping these would make db410c
(qcom_iommu) work:

  05fe33cad985 drm/msm: Use the correct dma_sync calls harder
  39718d086d9b drm/msm: Use the correct dma_sync calls in msm_gem
  9c23e00804f8 drm/msm: stop abusing dma_map/unmap for cache

What I'm not entirely sure of (v4.19 seems so long ago now) is whether
that would cause problems for db820c (arm-smmu)?  Looks like the first
of those patches landed around v5.4, so presumably the problem it was
meant to workaround started happening sometime after v4.19?

BR,
-R

[1] https://lkml.org/lkml/2020/4/20/1142

> >
> > Best regards,
> >   Nobuhiro
> > >
> > > --
> > > Linaro LKFT
> > > https://lkft.linaro.org