2020-04-11 12:15:38

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 00/38] 4.14.176-rc1 review

This is the start of the stable review cycle for the 4.14.176 release.
There are 38 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.14.176-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.14.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>
Linux 4.14.176-rc1

Hans Verkuil <[email protected]>
drm_dp_mst_topology: fix broken drm_dp_sideband_parse_remote_dpcd_read()

Roger Quadros <[email protected]>
usb: dwc3: don't set gadget->is_otg flag

Chris Lew <[email protected]>
rpmsg: glink: Remove chunk size word align warning

Arun KS <[email protected]>
arm64: Fix size of __early_cpu_boot_status

Rob Clark <[email protected]>
drm/msm: stop abusing dma_map/unmap for cache

Taniya Das <[email protected]>
clk: qcom: rcg: Return failure for RCG update

Dan Williams <[email protected]>
acpi/nfit: Fix bus command validation

Qiujun Huang <[email protected]>
fbcon: fix null-ptr-deref in fbcon_switch

Avihai Horon <[email protected]>
RDMA/cm: Update num_paths in cma_resolve_iboe_route error flow

Qiujun Huang <[email protected]>
Bluetooth: RFCOMM: fix ODEBUG bug in rfcomm_dev_ioctl

Ilya Dryomov <[email protected]>
ceph: canonicalize server path in place

Xiubo Li <[email protected]>
ceph: remove the extra slashes in the server path

Kaike Wan <[email protected]>
IB/hfi1: Fix memory leaks in sysfs registration and unregistration

Kaike Wan <[email protected]>
IB/hfi1: Call kobject_put() when kobject_init_and_add() fails

Paul Cercueil <[email protected]>
ASoC: jz4740-i2s: Fix divider written at incorrect offset in register

Martin Kaiser <[email protected]>
hwrng: imx-rngc - fix an error path

David Ahern <[email protected]>
tools/accounting/getdelays.c: fix netlink attribute length

Jason A. Donenfeld <[email protected]>
random: always use batched entropy for get_random_u{32,64}

Petr Machata <[email protected]>
mlxsw: spectrum_flower: Do not stop at FLOW_ACTION_VLAN_MANGLE

Richard Palethorpe <[email protected]>
slcan: Don't transmit uninitialized stack data in padding

Jisheng Zhang <[email protected]>
net: stmmac: dwmac1000: fix out-of-bounds mac address reg setting

Oleksij Rempel <[email protected]>
net: phy: micrel: kszphy_resume(): add delay after genphy_resume() before accessing PHY registers

Florian Fainelli <[email protected]>
net: dsa: bcm_sf2: Ensure correct sub-node is parsed

Jarod Wilson <[email protected]>
ipv6: don't auto-add link-local address to lag ports

Randy Dunlap <[email protected]>
mm: mempolicy: require at least one nodeid for MPOL_PREFERRED

Daniel Jordan <[email protected]>
padata: always acquire cpu_hotplug_lock before pinst->lock

Eugene Syromiatnikov <[email protected]>
coresight: do not use the BIT() macro in the UAPI header

Kishon Vijay Abraham I <[email protected]>
misc: pci_endpoint_test: Fix to support > 10 pci-endpoint-test devices

Keith Busch <[email protected]>
blk-mq: Allow blocking queue tag iter callbacks

Jianchao Wang <[email protected]>
blk-mq: sync the update nr_hw_queues with blk_mq_queue_tag_busy_iter

Lucas Stach <[email protected]>
drm/etnaviv: replace MMU flush marker with flush sequence

Len Brown <[email protected]>
tools/power turbostat: Fix gcc build warnings

Eugeniy Paltsev <[email protected]>
initramfs: restore default compression behavior

Gerd Hoffmann <[email protected]>
drm/bochs: downgrade pci_request_region failure from error to warning

Marcelo Ricardo Leitner <[email protected]>
sctp: fix possibly using a bad saddr with a given dst

Qiujun Huang <[email protected]>
sctp: fix refcount bug in sctp_wfree

William Dauchy <[email protected]>
net, ip_tunnel: fix interface lookup with no key

Qian Cai <[email protected]>
ipv4: fix a RCU-list lock in fib_triestat_seq_show


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

Diffstat:

Makefile | 4 +-
arch/arm64/kernel/head.S | 2 +-
block/blk-mq-tag.c | 9 +++-
block/blk-mq.c | 4 ++
drivers/acpi/nfit/core.c | 24 +++++-----
drivers/char/hw_random/imx-rngc.c | 4 +-
drivers/char/random.c | 20 ++------
drivers/clk/qcom/clk-rcg2.c | 2 +-
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.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 1 +
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 8 ++--
drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 4 +-
drivers/infiniband/core/cma.c | 1 +
drivers/infiniband/hw/hfi1/sysfs.c | 26 +++++++---
drivers/misc/pci_endpoint_test.c | 2 +-
drivers/net/can/slcan.c | 4 +-
drivers/net/dsa/bcm_sf2.c | 7 ++-
.../net/ethernet/mellanox/mlxsw/spectrum_flower.c | 8 ++--
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +-
drivers/net/phy/micrel.c | 7 +++
drivers/rpmsg/qcom_glink_native.c | 3 --
drivers/usb/dwc3/gadget.c | 1 -
drivers/video/fbdev/core/fbcon.c | 3 ++
fs/ceph/super.c | 56 ++++++++++++++--------
fs/ceph/super.h | 2 +-
include/uapi/linux/coresight-stm.h | 6 ++-
kernel/padata.c | 4 +-
mm/mempolicy.c | 6 ++-
net/bluetooth/rfcomm/tty.c | 4 +-
net/ipv4/fib_trie.c | 3 ++
net/ipv4/ip_tunnel.c | 6 +--
net/ipv6/addrconf.c | 4 ++
net/sctp/ipv6.c | 20 +++++---
net/sctp/protocol.c | 28 +++++++----
net/sctp/socket.c | 31 ++++++++----
sound/soc/jz4740/jz4740-i2s.c | 2 +-
tools/accounting/getdelays.c | 2 +-
tools/power/x86/turbostat/turbostat.c | 4 +-
usr/Kconfig | 22 ++++-----
43 files changed, 227 insertions(+), 140 deletions(-)



2020-04-11 12:15:47

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 15/38] ipv6: dont auto-add link-local address to lag ports

From: Jarod Wilson <[email protected]>

[ 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 <[email protected]>
CC: Stephen Hemminger <[email protected]>
CC: Marcelo Ricardo Leitner <[email protected]>
CC: [email protected]
Signed-off-by: Jarod Wilson <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/addrconf.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3175,6 +3175,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) {


2020-04-11 12:15:48

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 32/38] acpi/nfit: Fix bus command validation

From: Dan Williams <[email protected]>

commit ebe9f6f19d80d8978d16078dff3d5bd93ad8d102 upstream.

Commit 11189c1089da "acpi/nfit: Fix command-supported detection" broke
ND_CMD_CALL for bus-level commands. The "func = cmd" assumption is only
valid for:

ND_CMD_ARS_CAP
ND_CMD_ARS_START
ND_CMD_ARS_STATUS
ND_CMD_CLEAR_ERROR

The function number otherwise needs to be pulled from the command
payload for:

NFIT_CMD_TRANSLATE_SPA
NFIT_CMD_ARS_INJECT_SET
NFIT_CMD_ARS_INJECT_CLEAR
NFIT_CMD_ARS_INJECT_GET

Update cmd_to_func() for the bus case and call it in the common path.

Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection")
Cc: <[email protected]>
Reviewed-by: Vishal Verma <[email protected]>
Reported-by: Grzegorz Burzynski <[email protected]>
Tested-by: Jeff Moyer <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>


---
drivers/acpi/nfit/core.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)

--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -214,7 +214,7 @@ static int cmd_to_func(struct nfit_mem *
if (call_pkg) {
int i;

- if (nfit_mem->family != call_pkg->nd_family)
+ if (nfit_mem && nfit_mem->family != call_pkg->nd_family)
return -ENOTTY;

for (i = 0; i < ARRAY_SIZE(call_pkg->nd_reserved2); i++)
@@ -223,6 +223,10 @@ static int cmd_to_func(struct nfit_mem *
return call_pkg->nd_command;
}

+ /* In the !call_pkg case, bus commands == bus functions */
+ if (!nfit_mem)
+ return cmd;
+
/* Linux ND commands == NVDIMM_FAMILY_INTEL function numbers */
if (nfit_mem->family == NVDIMM_FAMILY_INTEL)
return cmd;
@@ -238,6 +242,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_desc
unsigned int cmd, void *buf, unsigned int buf_len, int *cmd_rc)
{
struct acpi_nfit_desc *acpi_desc = to_acpi_nfit_desc(nd_desc);
+ struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
union acpi_object in_obj, in_buf, *out_obj;
const struct nd_cmd_desc *desc = NULL;
struct device *dev = acpi_desc->dev;
@@ -252,18 +257,18 @@ int acpi_nfit_ctl(struct nvdimm_bus_desc
if (cmd_rc)
*cmd_rc = -EINVAL;

+ if (cmd == ND_CMD_CALL)
+ call_pkg = buf;
+ func = cmd_to_func(nfit_mem, cmd, call_pkg);
+ if (func < 0)
+ return func;
+
if (nvdimm) {
- struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
struct acpi_device *adev = nfit_mem->adev;

if (!adev)
return -ENOTTY;

- if (cmd == ND_CMD_CALL)
- call_pkg = buf;
- func = cmd_to_func(nfit_mem, cmd, call_pkg);
- if (func < 0)
- return func;
dimm_name = nvdimm_name(nvdimm);
cmd_name = nvdimm_cmd_name(cmd);
cmd_mask = nvdimm_cmd_mask(nvdimm);
@@ -274,12 +279,9 @@ int acpi_nfit_ctl(struct nvdimm_bus_desc
} else {
struct acpi_device *adev = to_acpi_dev(acpi_desc);

- func = cmd;
cmd_name = nvdimm_bus_cmd_name(cmd);
cmd_mask = nd_desc->cmd_mask;
- dsm_mask = cmd_mask;
- if (cmd == ND_CMD_CALL)
- dsm_mask = nd_desc->bus_dsm_mask;
+ dsm_mask = nd_desc->bus_dsm_mask;
desc = nd_cmd_bus_desc(cmd);
guid = to_nfit_uuid(NFIT_DEV_BUS);
handle = adev->handle;


2020-04-11 12:16:01

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 23/38] hwrng: imx-rngc - fix an error path

From: Martin Kaiser <[email protected]>

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: [email protected]
Fixes: 1d5449445bd0 ("hwrng: mx-rngc - add a driver for Freescale RNGC")
Reviewed-by: PrasannaKumar Muralidharan <[email protected]>
Signed-off-by: Martin Kaiser <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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
@@ -110,8 +110,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;
}


2020-04-11 12:16:02

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 04/38] sctp: fix possibly using a bad saddr with a given dst

From: Marcelo Ricardo Leitner <[email protected]>

[ 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 <[email protected]>
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Tested-by: Xin Long <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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
@@ -235,7 +235,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;
@@ -245,7 +246,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;
@@ -271,8 +272,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);
@@ -295,6 +299,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;
}
}
@@ -333,6 +339,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;
}

@@ -346,6 +354,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();

@@ -354,14 +364,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
@@ -435,14 +435,15 @@ 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;
union sctp_addr *daddr = &t->ipaddr;
union sctp_addr dst_saddr;

- 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;
@@ -460,8 +461,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.
@@ -524,27 +528,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


2020-04-11 12:16:03

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 21/38] random: always use batched entropy for get_random_u{32,64}

From: Jason A. Donenfeld <[email protected]>

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 <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2193,11 +2193,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),
@@ -2210,15 +2210,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);
@@ -2243,9 +2234,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);


2020-04-11 12:16:16

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 37/38] usb: dwc3: dont set gadget->is_otg flag

From: Roger Quadros <[email protected]>

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 <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/dwc3/gadget.c | 1 -
1 file changed, 1 deletion(-)

--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3257,7 +3257,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


2020-04-11 12:16:40

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 05/38] drm/bochs: downgrade pci_request_region failure from error to warning

From: Gerd Hoffmann <[email protected]>

[ 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 <[email protected]>
Signed-off-by: Gerd Hoffmann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
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



2020-04-11 12:16:45

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 08/38] drm/etnaviv: replace MMU flush marker with flush sequence

From: Lucas Stach <[email protected]>

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 <[email protected]>
Reviewed-by: Philipp Zabel <[email protected]>
Reviewed-by: Guido Günther <[email protected]>
Signed-off-by: Robert Beckett <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -258,6 +258,8 @@ void etnaviv_buffer_queue(struct etnaviv
unsigned int waitlink_offset = buffer->user_size - 16;
u32 return_target, return_dwords;
u32 link_target, link_dwords;
+ unsigned int new_flush_seq = READ_ONCE(gpu->mmu->flush_seq);
+ bool need_flush = gpu->flush_seq != new_flush_seq;

if (drm_debug & DRM_UT_DRIVER)
etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
@@ -270,14 +272,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 || gpu->switch_context) {
+ if (need_flush || gpu->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
@@ -290,7 +292,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,
@@ -310,7 +312,7 @@ void etnaviv_buffer_queue(struct etnaviv
SYNC_RECIPIENT_PE);
}

- gpu->mmu->need_flush = false;
+ gpu->flush_seq = new_flush_seq;
}

if (gpu->switch_context) {
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1353,7 +1353,7 @@ int etnaviv_gpu_submit(struct etnaviv_gp
gpu->active_fence = submit->fence->seqno;

if (gpu->lastctx != cmdbuf->ctx) {
- gpu->mmu->need_flush = true;
+ gpu->mmu->flush_seq++;
gpu->switch_context = true;
gpu->lastctx = cmdbuf->ctx;
}
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -138,6 +138,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
@@ -132,7 +132,7 @@ static int etnaviv_iommu_find_iova(struc
*/
if (mmu->last_iova) {
mmu->last_iova = 0;
- mmu->need_flush = true;
+ mmu->flush_seq++;
continue;
}

@@ -246,7 +246,7 @@ int etnaviv_iommu_map_gem(struct etnaviv
}

list_add_tail(&mapping->mmu_node, &mmu->mappings);
- mmu->need_flush = true;
+ mmu->flush_seq++;
mutex_unlock(&mmu->lock);

return ret;
@@ -264,7 +264,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);
}

@@ -346,7 +346,7 @@ int etnaviv_iommu_get_suballoc_va(struct
return ret;
}
mmu->last_iova = vram_node->start + size;
- 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
@@ -44,7 +44,7 @@ struct etnaviv_iommu {
struct list_head mappings;
struct drm_mm mm;
u32 last_iova;
- bool need_flush;
+ unsigned int flush_seq;
};

struct etnaviv_gem_object;


2020-04-11 12:16:56

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 38/38] drm_dp_mst_topology: fix broken drm_dp_sideband_parse_remote_dpcd_read()

From: Hans Verkuil <[email protected]>

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 <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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
@@ -433,6 +433,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;



2020-04-11 12:28:48

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 09/38] blk-mq: sync the update nr_hw_queues with blk_mq_queue_tag_busy_iter

From: Jianchao Wang <[email protected]>

commit f5bbbbe4d63577026f908a809f22f5fd5a90ea1f upstream.

For blk-mq, part_in_flight/rw will invoke blk_mq_in_flight/rw to
account the inflight requests. It will access the queue_hw_ctx and
nr_hw_queues w/o any protection. When updating nr_hw_queues and
blk_mq_in_flight/rw occur concurrently, panic comes up.

Before update nr_hw_queues, the q will be frozen. So we could use
q_usage_counter to avoid the race. percpu_ref_is_zero is used here
so that we will not miss any in-flight request. The access to
nr_hw_queues and queue_hw_ctx in blk_mq_queue_tag_busy_iter are
under rcu critical section, __blk_mq_update_nr_hw_queues could use
synchronize_rcu to ensure the zeroed q_usage_counter to be globally
visible.

Signed-off-by: Jianchao Wang <[email protected]>
Reviewed-by: Ming Lei <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Cc: Giuliano Procida <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
block/blk-mq-tag.c | 14 +++++++++++++-
block/blk-mq.c | 4 ++++
2 files changed, 17 insertions(+), 1 deletion(-)

--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -334,6 +334,18 @@ void blk_mq_queue_tag_busy_iter(struct r
struct blk_mq_hw_ctx *hctx;
int i;

+ /*
+ * __blk_mq_update_nr_hw_queues will update the nr_hw_queues and
+ * queue_hw_ctx after freeze the queue. So we could use q_usage_counter
+ * to avoid race with it. __blk_mq_update_nr_hw_queues will users
+ * synchronize_rcu to ensure all of the users go out of the critical
+ * section below and see zeroed q_usage_counter.
+ */
+ rcu_read_lock();
+ if (percpu_ref_is_zero(&q->q_usage_counter)) {
+ rcu_read_unlock();
+ return;
+ }

queue_for_each_hw_ctx(q, hctx, i) {
struct blk_mq_tags *tags = hctx->tags;
@@ -349,7 +361,7 @@ void blk_mq_queue_tag_busy_iter(struct r
bt_for_each(hctx, &tags->breserved_tags, fn, priv, true);
bt_for_each(hctx, &tags->bitmap_tags, fn, priv, false);
}
-
+ rcu_read_unlock();
}

static int bt_alloc(struct sbitmap_queue *bt, unsigned int depth,
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2748,6 +2748,10 @@ static void __blk_mq_update_nr_hw_queues

list_for_each_entry(q, &set->tag_list, tag_set_list)
blk_mq_unfreeze_queue(q);
+ /*
+ * Sync with blk_mq_queue_tag_busy_iter.
+ */
+ synchronize_rcu();
}

void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_queues)


2020-04-11 12:29:07

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 30/38] RDMA/cm: Update num_paths in cma_resolve_iboe_route error flow

From: Avihai Horon <[email protected]>

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/[email protected]
Signed-off-by: Avihai Horon <[email protected]>
Reviewed-by: Maor Gottlieb <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -2661,6 +2661,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;


2020-04-11 12:29:22

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 25/38] IB/hfi1: Call kobject_put() when kobject_init_and_add() fails

From: Kaike Wan <[email protected]>

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: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Mike Marciniszyn <[email protected]>
Signed-off-by: Kaike Wan <[email protected]>
Signed-off-by: Dennis Dalessandro <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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;
}



2020-04-11 12:29:27

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 19/38] slcan: Dont transmit uninitialized stack data in padding

From: Richard Palethorpe <[email protected]>

[ 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 <[email protected]>
Fixes: a1044e36e457 ("can: add slcan driver for serial/USB-serial CAN adapters")
Reviewed-by: Kees Cook <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Acked-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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++) {


2020-04-11 12:29:31

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 06/38] initramfs: restore default compression behavior

From: Eugeniy Paltsev <[email protected]>

[ 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 <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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



2020-04-11 12:29:41

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 12/38] coresight: do not use the BIT() macro in the UAPI header

From: Eugene Syromiatnikov <[email protected]>

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 <[email protected]>
Cc: stable <[email protected]>
Reviewed-by: Mathieu Poirier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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


2020-04-11 12:29:42

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 10/38] blk-mq: Allow blocking queue tag iter callbacks

From: Keith Busch <[email protected]>

commit 530ca2c9bd6949c72c9b5cfc330cb3dbccaa3f5b upstream.

A recent commit runs tag iterator callbacks under the rcu read lock,
but existing callbacks do not satisfy the non-blocking requirement.
The commit intended to prevent an iterator from accessing a queue that's
being modified. This patch fixes the original issue by taking a queue
reference instead of reading it, which allows callbacks to make blocking
calls.

Fixes: f5bbbbe4d6357 ("blk-mq: sync the update nr_hw_queues with blk_mq_queue_tag_busy_iter")
Acked-by: Jianchao Wang <[email protected]>
Signed-off-by: Keith Busch <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Giuliano Procida <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
block/blk-mq-tag.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)

--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -336,16 +336,11 @@ void blk_mq_queue_tag_busy_iter(struct r

/*
* __blk_mq_update_nr_hw_queues will update the nr_hw_queues and
- * queue_hw_ctx after freeze the queue. So we could use q_usage_counter
- * to avoid race with it. __blk_mq_update_nr_hw_queues will users
- * synchronize_rcu to ensure all of the users go out of the critical
- * section below and see zeroed q_usage_counter.
+ * queue_hw_ctx after freeze the queue, so we use q_usage_counter
+ * to avoid race with it.
*/
- rcu_read_lock();
- if (percpu_ref_is_zero(&q->q_usage_counter)) {
- rcu_read_unlock();
+ if (!percpu_ref_tryget(&q->q_usage_counter))
return;
- }

queue_for_each_hw_ctx(q, hctx, i) {
struct blk_mq_tags *tags = hctx->tags;
@@ -361,7 +356,7 @@ void blk_mq_queue_tag_busy_iter(struct r
bt_for_each(hctx, &tags->breserved_tags, fn, priv, true);
bt_for_each(hctx, &tags->bitmap_tags, fn, priv, false);
}
- rcu_read_unlock();
+ blk_queue_exit(q);
}

static int bt_alloc(struct sbitmap_queue *bt, unsigned int depth,


2020-04-11 12:29:56

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 36/38] rpmsg: glink: Remove chunk size word align warning

From: Chris Lew <[email protected]>

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 <[email protected]>
Signed-off-by: Arun Kumar Neelakantam <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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
@@ -811,9 +811,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);


2020-04-11 12:30:01

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 07/38] tools/power turbostat: Fix gcc build warnings

From: Len Brown <[email protected]>

[ 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 <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
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 19e345cf8193e..0692f2efc25ef 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -4650,9 +4650,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



2020-04-11 12:30:18

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 33/38] clk: qcom: rcg: Return failure for RCG update

From: Taniya Das <[email protected]>

commit 21ea4b62e1f3dc258001a68da98c9663a9dbd6c7 upstream.

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

Signed-off-by: Taniya Das <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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
@@ -112,7 +112,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)


2020-04-11 12:30:25

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 03/38] sctp: fix refcount bug in sctp_wfree

From: Qiujun Huang <[email protected]>

[ 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: [email protected]
Signed-off-by: Qiujun Huang <[email protected]>
Acked-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sctp/socket.c | 31 +++++++++++++++++++++++--------
1 file changed, 23 insertions(+), 8 deletions(-)

--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -175,29 +175,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();
}

/* Verify that this is a valid address. */
@@ -8280,9 +8295,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.


2020-04-11 12:30:36

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 24/38] ASoC: jz4740-i2s: Fix divider written at incorrect offset in register

From: Paul Cercueil <[email protected]>

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 <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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)


2020-04-11 12:30:39

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 20/38] mlxsw: spectrum_flower: Do not stop at FLOW_ACTION_VLAN_MANGLE

From: Petr Machata <[email protected]>

[ 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 <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Signed-off-by: Ido Schimmel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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
@@ -112,9 +112,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);
+ err = mlxsw_sp_acl_rulei_act_vlan(mlxsw_sp, rulei,
+ action, vid,
+ proto, prio);
+ if (err)
+ return err;
} else {
dev_err(mlxsw_sp->bus_info->dev, "Unsupported action\n");
return -EOPNOTSUPP;


2020-04-11 12:30:49

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 14/38] mm: mempolicy: require at least one nodeid for MPOL_PREFERRED

From: Randy Dunlap <[email protected]>

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 <[email protected]>
Reported-by: [email protected]
Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Tested-by: [email protected]
Cc: Lee Schermerhorn <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2748,7 +2748,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;
@@ -2756,6 +2758,8 @@ int mpol_parse_str(char *str, struct mem
rest++;
if (*rest)
goto out;
+ if (nodes_empty(nodes))
+ goto out;
}
break;
case MPOL_INTERLEAVE:


2020-04-11 12:30:54

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.14 11/38] misc: pci_endpoint_test: Fix to support > 10 pci-endpoint-test devices

From: Kishon Vijay Abraham I <[email protected]>

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 <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Cc: [email protected] # v4.14+
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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
@@ -466,7 +466,7 @@ static int pci_endpoint_test_probe(struc
int err;
int irq = 0;
int id;
- char name[20];
+ char name[24];
enum pci_barno bar;
void __iomem *base;
struct device *dev = &pdev->dev;


2020-04-11 20:40:04

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/38] 4.14.176-rc1 review

On 4/11/20 5:08 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.176 release.
> There are 38 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: 171 pass: 171 fail: 0
Qemu test results:
total: 405 pass: 405 fail: 0

Guenter


2020-04-12 08:52:36

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/38] 4.14.176-rc1 review

On Sat, 11 Apr 2020 at 17:45, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.14.176 release.
> There are 38 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.14.176-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.14.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.14.176-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 42fb2965c7ca26057bc47af5ef45f170bbf2cade
git describe: v4.14.175-39-g42fb2965c7ca
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.175-39-g42fb2965c7ca


No regressions (compared to build v4.14.175)

No fixes (compared to build v4.14.175)


Ran 32276 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
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* libhugetlbfs
* linux-log-parser
* ltp-commands-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-sched-tests
* ltp-syscalls-tests
* perf
* v4l2-compliance
* kvm-unit-tests
* 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-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* network-basic-tests
* ltp-open-posix-tests
* spectre-meltdown-checker-test
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

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

2020-04-13 06:05:47

by Nobuhiro Iwamatsu

[permalink] [raw]
Subject: RE: [PATCH 4.14 36/38] rpmsg: glink: Remove chunk size word align warning

Hi,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Greg Kroah-Hartman
> Sent: Saturday, April 11, 2020 9:09 PM
> To: [email protected]
> Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Chris Lew <[email protected]>; Arun
> Kumar Neelakantam <[email protected]>; Bjorn Andersson <[email protected]>; Lee Jones
> <[email protected]>
> Subject: [PATCH 4.14 36/38] rpmsg: glink: Remove chunk size word align warning
>
> From: Chris Lew <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Arun Kumar Neelakantam <[email protected]>
> Signed-off-by: Bjorn Andersson <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>

This commit also seems to require the following commits:

commit 928002a5e9dab2ddc1a0fe3e00739e89be30dc6b
Author: Arun Kumar Neelakantam <[email protected]>
Date: Wed Oct 3 17:08:20 2018 +0530

rpmsg: glink: smem: Support rx peak for size less than 4 bytes

The current rx peak function fails to read the data if size is
less than 4bytes.

Use memcpy_fromio to support data reads of size less than 4 bytes.

Cc: [email protected]
Fixes: f0beb4ba9b18 ("rpmsg: glink: Remove chunk size word align warning")
Signed-off-by: Arun Kumar Neelakantam <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>

This fixes commit need to apply 4.19.

Best regards,
Nobuhiro

>
> ---
> 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
> @@ -811,9 +811,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);
>

2020-04-13 09:34:29

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 4.14 36/38] rpmsg: glink: Remove chunk size word align warning

On Mon, Apr 13, 2020 at 05:16:05AM +0000, [email protected] wrote:
> Hi,
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of Greg Kroah-Hartman
> > Sent: Saturday, April 11, 2020 9:09 PM
> > To: [email protected]
> > Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Chris Lew <[email protected]>; Arun
> > Kumar Neelakantam <[email protected]>; Bjorn Andersson <[email protected]>; Lee Jones
> > <[email protected]>
> > Subject: [PATCH 4.14 36/38] rpmsg: glink: Remove chunk size word align warning
> >
> > From: Chris Lew <[email protected]>
> >
> > 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 <[email protected]>
> > Signed-off-by: Arun Kumar Neelakantam <[email protected]>
> > Signed-off-by: Bjorn Andersson <[email protected]>
> > Signed-off-by: Lee Jones <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> This commit also seems to require the following commits:
>
> commit 928002a5e9dab2ddc1a0fe3e00739e89be30dc6b
> Author: Arun Kumar Neelakantam <[email protected]>
> Date: Wed Oct 3 17:08:20 2018 +0530
>
> rpmsg: glink: smem: Support rx peak for size less than 4 bytes
>
> The current rx peak function fails to read the data if size is
> less than 4bytes.
>
> Use memcpy_fromio to support data reads of size less than 4 bytes.
>
> Cc: [email protected]
> Fixes: f0beb4ba9b18 ("rpmsg: glink: Remove chunk size word align warning")
> Signed-off-by: Arun Kumar Neelakantam <[email protected]>
> Signed-off-by: Bjorn Andersson <[email protected]>
>
> This fixes commit need to apply 4.19.

This fix is already in 4.19.y, so it's only needed for 4.14.y at this
point in time, thanks!

greg k-h

2020-04-14 15:17:28

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 4.14 00/38] 4.14.176-rc1 review


On 11/04/2020 13:08, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.176 release.
> There are 38 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.14.176-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v4.14:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
24 tests: 24 pass, 0 fail

Linux version: 4.14.176-rc1-g42fb2965c7ca
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

--
nvpublic