* [PATCH 5.1 01/70] ethtool: fix potential userspace buffer overflow
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 02/70] Fix memory leak in sctp_process_init Greg Kroah-Hartman
` (73 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vivien Didelot, Michal Kubecek,
David S. Miller
From: Vivien Didelot <vivien.didelot@gmail.com>
[ Upstream commit 0ee4e76937d69128a6a66861ba393ebdc2ffc8a2 ]
ethtool_get_regs() allocates a buffer of size ops->get_regs_len(),
and pass it to the kernel driver via ops->get_regs() for filling.
There is no restriction about what the kernel drivers can or cannot do
with the open ethtool_regs structure. They usually set regs->version
and ignore regs->len or set it to the same size as ops->get_regs_len().
But if userspace allocates a smaller buffer for the registers dump,
we would cause a userspace buffer overflow in the final copy_to_user()
call, which uses the regs.len value potentially reset by the driver.
To fix this, make this case obvious and store regs.len before calling
ops->get_regs(), to only copy as much data as requested by userspace,
up to the value returned by ops->get_regs_len().
While at it, remove the redundant check for non-null regbuf.
Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
Reviewed-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/ethtool.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1358,13 +1358,16 @@ static int ethtool_get_regs(struct net_d
if (!regbuf)
return -ENOMEM;
+ if (regs.len < reglen)
+ reglen = regs.len;
+
ops->get_regs(dev, ®s, regbuf);
ret = -EFAULT;
if (copy_to_user(useraddr, ®s, sizeof(regs)))
goto out;
useraddr += offsetof(struct ethtool_regs, data);
- if (regbuf && copy_to_user(useraddr, regbuf, regs.len))
+ if (copy_to_user(useraddr, regbuf, reglen))
goto out;
ret = 0;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 02/70] Fix memory leak in sctp_process_init
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 01/70] ethtool: fix potential userspace buffer overflow Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 03/70] ipv4: not do cache for local delivery if bc_forwarding is enabled Greg Kroah-Hartman
` (72 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Neil Horman,
syzbot+f7e9153b037eac9b1df8, Marcelo Ricardo Leitner,
David S. Miller, netdev
From: Neil Horman <nhorman@tuxdriver.com>
[ Upstream commit 0a8dd9f67cd0da7dc284f48b032ce00db1a68791 ]
syzbot found the following leak in sctp_process_init
BUG: memory leak
unreferenced object 0xffff88810ef68400 (size 1024):
comm "syz-executor273", pid 7046, jiffies 4294945598 (age 28.770s)
hex dump (first 32 bytes):
1d de 28 8d de 0b 1b e3 b5 c2 f9 68 fd 1a 97 25 ..(........h...%
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000a02cebbd>] kmemleak_alloc_recursive include/linux/kmemleak.h:55
[inline]
[<00000000a02cebbd>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<00000000a02cebbd>] slab_alloc mm/slab.c:3326 [inline]
[<00000000a02cebbd>] __do_kmalloc mm/slab.c:3658 [inline]
[<00000000a02cebbd>] __kmalloc_track_caller+0x15d/0x2c0 mm/slab.c:3675
[<000000009e6245e6>] kmemdup+0x27/0x60 mm/util.c:119
[<00000000dfdc5d2d>] kmemdup include/linux/string.h:432 [inline]
[<00000000dfdc5d2d>] sctp_process_init+0xa7e/0xc20
net/sctp/sm_make_chunk.c:2437
[<00000000b58b62f8>] sctp_cmd_process_init net/sctp/sm_sideeffect.c:682
[inline]
[<00000000b58b62f8>] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1384
[inline]
[<00000000b58b62f8>] sctp_side_effects net/sctp/sm_sideeffect.c:1194
[inline]
[<00000000b58b62f8>] sctp_do_sm+0xbdc/0x1d60 net/sctp/sm_sideeffect.c:1165
[<0000000044e11f96>] sctp_assoc_bh_rcv+0x13c/0x200
net/sctp/associola.c:1074
[<00000000ec43804d>] sctp_inq_push+0x7f/0xb0 net/sctp/inqueue.c:95
[<00000000726aa954>] sctp_backlog_rcv+0x5e/0x2a0 net/sctp/input.c:354
[<00000000d9e249a8>] sk_backlog_rcv include/net/sock.h:950 [inline]
[<00000000d9e249a8>] __release_sock+0xab/0x110 net/core/sock.c:2418
[<00000000acae44fa>] release_sock+0x37/0xd0 net/core/sock.c:2934
[<00000000963cc9ae>] sctp_sendmsg+0x2c0/0x990 net/sctp/socket.c:2122
[<00000000a7fc7565>] inet_sendmsg+0x64/0x120 net/ipv4/af_inet.c:802
[<00000000b732cbd3>] sock_sendmsg_nosec net/socket.c:652 [inline]
[<00000000b732cbd3>] sock_sendmsg+0x54/0x70 net/socket.c:671
[<00000000274c57ab>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2292
[<000000008252aedb>] __sys_sendmsg+0x80/0xf0 net/socket.c:2330
[<00000000f7bf23d1>] __do_sys_sendmsg net/socket.c:2339 [inline]
[<00000000f7bf23d1>] __se_sys_sendmsg net/socket.c:2337 [inline]
[<00000000f7bf23d1>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2337
[<00000000a8b4131f>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:3
The problem was that the peer.cookie value points to an skb allocated
area on the first pass through this function, at which point it is
overwritten with a heap allocated value, but in certain cases, where a
COOKIE_ECHO chunk is included in the packet, a second pass through
sctp_process_init is made, where the cookie value is re-allocated,
leaking the first allocation.
Fix is to always allocate the cookie value, and free it when we are done
using it.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: syzbot+f7e9153b037eac9b1df8@syzkaller.appspotmail.com
CC: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: netdev@vger.kernel.org
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sctp/sm_make_chunk.c | 13 +++----------
net/sctp/sm_sideeffect.c | 5 +++++
2 files changed, 8 insertions(+), 10 deletions(-)
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -2329,7 +2329,6 @@ int sctp_process_init(struct sctp_associ
union sctp_addr addr;
struct sctp_af *af;
int src_match = 0;
- char *cookie;
/* We must include the address that the INIT packet came from.
* This is the only address that matters for an INIT packet.
@@ -2433,14 +2432,6 @@ int sctp_process_init(struct sctp_associ
/* Peer Rwnd : Current calculated value of the peer's rwnd. */
asoc->peer.rwnd = asoc->peer.i.a_rwnd;
- /* Copy cookie in case we need to resend COOKIE-ECHO. */
- cookie = asoc->peer.cookie;
- if (cookie) {
- asoc->peer.cookie = kmemdup(cookie, asoc->peer.cookie_len, gfp);
- if (!asoc->peer.cookie)
- goto clean_up;
- }
-
/* RFC 2960 7.2.1 The initial value of ssthresh MAY be arbitrarily
* high (for example, implementations MAY use the size of the receiver
* advertised window).
@@ -2609,7 +2600,9 @@ do_addr_param:
case SCTP_PARAM_STATE_COOKIE:
asoc->peer.cookie_len =
ntohs(param.p->length) - sizeof(struct sctp_paramhdr);
- asoc->peer.cookie = param.cookie->body;
+ asoc->peer.cookie = kmemdup(param.cookie->body, asoc->peer.cookie_len, gfp);
+ if (!asoc->peer.cookie)
+ retval = 0;
break;
case SCTP_PARAM_HEARTBEAT_INFO:
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -898,6 +898,11 @@ static void sctp_cmd_new_state(struct sc
asoc->rto_initial;
}
+ if (sctp_state(asoc, ESTABLISHED)) {
+ kfree(asoc->peer.cookie);
+ asoc->peer.cookie = NULL;
+ }
+
if (sctp_state(asoc, ESTABLISHED) ||
sctp_state(asoc, CLOSED) ||
sctp_state(asoc, SHUTDOWN_RECEIVED)) {
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 03/70] ipv4: not do cache for local delivery if bc_forwarding is enabled
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 01/70] ethtool: fix potential userspace buffer overflow Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 02/70] Fix memory leak in sctp_process_init Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 04/70] ipv6: fix the check before getting the cookie in rt6_get_cookie Greg Kroah-Hartman
` (71 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jianlin Shi, Xin Long, David S. Miller
From: Xin Long <lucien.xin@gmail.com>
[ Upstream commit 0a90478b93a46bdcd56ba33c37566a993e455d54 ]
With the topo:
h1 ---| rp1 |
| route rp3 |--- h3 (192.168.200.1)
h2 ---| rp2 |
If rp1 bc_forwarding is set while rp2 bc_forwarding is not, after
doing "ping 192.168.200.255" on h1, then ping 192.168.200.255 on
h2, and the packets can still be forwared.
This issue was caused by the input route cache. It should only do
the cache for either bc forwarding or local delivery. Otherwise,
local delivery can use the route cache for bc forwarding of other
interfaces.
This patch is to fix it by not doing cache for local delivery if
all.bc_forwarding is enabled.
Note that we don't fix it by checking route cache local flag after
rt_cache_valid() in "local_input:" and "ip_mkroute_input", as the
common route code shouldn't be touched for bc_forwarding.
Fixes: 5cbf777cfdf6 ("route: add support for directed broadcast forwarding")
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-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/ipv4/route.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1954,7 +1954,7 @@ static int ip_route_input_slow(struct sk
u32 itag = 0;
struct rtable *rth;
struct flowi4 fl4;
- bool do_cache;
+ bool do_cache = true;
/* IP on this device is disabled. */
@@ -2031,6 +2031,9 @@ static int ip_route_input_slow(struct sk
if (res->type == RTN_BROADCAST) {
if (IN_DEV_BFORWARD(in_dev))
goto make_route;
+ /* not do cache if bc_forwarding is enabled */
+ if (IPV4_DEVCONF_ALL(net, BC_FORWARDING))
+ do_cache = false;
goto brd_input;
}
@@ -2068,16 +2071,13 @@ brd_input:
RT_CACHE_STAT_INC(in_brd);
local_input:
- do_cache = false;
- if (res->fi) {
- if (!itag) {
- rth = rcu_dereference(FIB_RES_NH(*res).nh_rth_input);
- if (rt_cache_valid(rth)) {
- skb_dst_set_noref(skb, &rth->dst);
- err = 0;
- goto out;
- }
- do_cache = true;
+ do_cache &= res->fi && !itag;
+ if (do_cache) {
+ rth = rcu_dereference(FIB_RES_NH(*res).nh_rth_input);
+ if (rt_cache_valid(rth)) {
+ skb_dst_set_noref(skb, &rth->dst);
+ err = 0;
+ goto out;
}
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 04/70] ipv6: fix the check before getting the cookie in rt6_get_cookie
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 03/70] ipv4: not do cache for local delivery if bc_forwarding is enabled Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 05/70] net: ethernet: ti: cpsw_ethtool: fix ethtool ring param set Greg Kroah-Hartman
` (70 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jianlin Shi, Xin Long, David S. Miller
From: Xin Long <lucien.xin@gmail.com>
[ Upstream commit b7999b07726c16974ba9ca3bb9fe98ecbec5f81c ]
In Jianlin's testing, netperf was broken with 'Connection reset by peer',
as the cookie check failed in rt6_check() and ip6_dst_check() always
returned NULL.
It's caused by Commit 93531c674315 ("net/ipv6: separate handling of FIB
entries from dst based routes"), where the cookie can be got only when
'c1'(see below) for setting dst_cookie whereas rt6_check() is called
when !'c1' for checking dst_cookie, as we can see in ip6_dst_check().
Since in ip6_dst_check() both rt6_dst_from_check() (c1) and rt6_check()
(!c1) will check the 'from' cookie, this patch is to remove the c1 check
in rt6_get_cookie(), so that the dst_cookie can always be set properly.
c1:
(rt->rt6i_flags & RTF_PCPU || unlikely(!list_empty(&rt->rt6i_uncached)))
Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes")
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-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>
---
include/net/ip6_fib.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -259,8 +259,7 @@ static inline u32 rt6_get_cookie(const s
rcu_read_lock();
from = rcu_dereference(rt->from);
- if (from && (rt->rt6i_flags & RTF_PCPU ||
- unlikely(!list_empty(&rt->rt6i_uncached))))
+ if (from)
fib6_get_cookie_safe(from, &cookie);
rcu_read_unlock();
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 05/70] net: ethernet: ti: cpsw_ethtool: fix ethtool ring param set
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 04/70] ipv6: fix the check before getting the cookie in rt6_get_cookie Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 06/70] net: mvpp2: Use strscpy to handle stat strings Greg Kroah-Hartman
` (69 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ivan Khoronzhuk, Grygorii Strashko,
David S. Miller
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
[ Upstream commit 09faf5a7d7c0bcb07faba072f611937af9dd5788 ]
Fix ability to set RX descriptor number, the reason - initially
"tx_max_pending" was set incorrectly, but the issue appears after
adding sanity check, so fix is for "sanity" patch.
Fixes: 37e2d99b59c476 ("ethtool: Ensure new ring parameters are within bounds during SRINGPARAM")
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/ti/cpsw.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -3130,6 +3130,7 @@ static void cpsw_get_ringparam(struct ne
struct cpsw_common *cpsw = priv->cpsw;
/* not supported */
+ ering->tx_max_pending = descs_pool_size - CPSW_MAX_QUEUES;
ering->tx_max_pending = 0;
ering->tx_pending = cpdma_get_num_tx_descs(cpsw->dma);
ering->rx_max_pending = descs_pool_size - CPSW_MAX_QUEUES;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 06/70] net: mvpp2: Use strscpy to handle stat strings
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 05/70] net: ethernet: ti: cpsw_ethtool: fix ethtool ring param set Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 07/70] net: rds: fix memory leak in rds_ib_flush_mr_pool Greg Kroah-Hartman
` (68 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Maxime Chevallier, David S. Miller
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
[ Upstream commit d37acd5aa99c57505b64913e0e2624ec3daed8c5 ]
Use a safe strscpy call to copy the ethtool stat strings into the
relevant buffers, instead of a memcpy that will be accessing
out-of-bound data.
Fixes: 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1304,8 +1304,8 @@ static void mvpp2_ethtool_get_strings(st
int i;
for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_regs); i++)
- memcpy(data + i * ETH_GSTRING_LEN,
- &mvpp2_ethtool_regs[i].string, ETH_GSTRING_LEN);
+ strscpy(data + i * ETH_GSTRING_LEN,
+ mvpp2_ethtool_regs[i].string, ETH_GSTRING_LEN);
}
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 07/70] net: rds: fix memory leak in rds_ib_flush_mr_pool
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 06/70] net: mvpp2: Use strscpy to handle stat strings Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 08/70] net: sfp: read eeprom in maximum 16 byte increments Greg Kroah-Hartman
` (67 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zhu Yanjun, Santosh Shilimkar,
David S. Miller
From: Zhu Yanjun <yanjun.zhu@oracle.com>
[ Upstream commit 85cb928787eab6a2f4ca9d2a798b6f3bed53ced1 ]
When the following tests last for several hours, the problem will occur.
Server:
rds-stress -r 1.1.1.16 -D 1M
Client:
rds-stress -r 1.1.1.14 -s 1.1.1.16 -D 1M -T 30
The following will occur.
"
Starting up....
tsks tx/s rx/s tx+rx K/s mbi K/s mbo K/s tx us/c rtt us cpu
%
1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
"
>From vmcore, we can find that clean_list is NULL.
>From the source code, rds_mr_flushd calls rds_ib_mr_pool_flush_worker.
Then rds_ib_mr_pool_flush_worker calls
"
rds_ib_flush_mr_pool(pool, 0, NULL);
"
Then in function
"
int rds_ib_flush_mr_pool(struct rds_ib_mr_pool *pool,
int free_all, struct rds_ib_mr **ibmr_ret)
"
ibmr_ret is NULL.
In the source code,
"
...
list_to_llist_nodes(pool, &unmap_list, &clean_nodes, &clean_tail);
if (ibmr_ret)
*ibmr_ret = llist_entry(clean_nodes, struct rds_ib_mr, llnode);
/* more than one entry in llist nodes */
if (clean_nodes->next)
llist_add_batch(clean_nodes->next, clean_tail, &pool->clean_list);
...
"
When ibmr_ret is NULL, llist_entry is not executed. clean_nodes->next
instead of clean_nodes is added in clean_list.
So clean_nodes is discarded. It can not be used again.
The workqueue is executed periodically. So more and more clean_nodes are
discarded. Finally the clean_list is NULL.
Then this problem will occur.
Fixes: 1bc144b62524 ("net, rds, Replace xlist in net/rds/xlist.h with llist")
Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rds/ib_rdma.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -428,12 +428,14 @@ int rds_ib_flush_mr_pool(struct rds_ib_m
wait_clean_list_grace();
list_to_llist_nodes(pool, &unmap_list, &clean_nodes, &clean_tail);
- if (ibmr_ret)
+ if (ibmr_ret) {
*ibmr_ret = llist_entry(clean_nodes, struct rds_ib_mr, llnode);
-
+ clean_nodes = clean_nodes->next;
+ }
/* more than one entry in llist nodes */
- if (clean_nodes->next)
- llist_add_batch(clean_nodes->next, clean_tail, &pool->clean_list);
+ if (clean_nodes)
+ llist_add_batch(clean_nodes, clean_tail,
+ &pool->clean_list);
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 08/70] net: sfp: read eeprom in maximum 16 byte increments
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 07/70] net: rds: fix memory leak in rds_ib_flush_mr_pool Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 09/70] packet: unconditionally free po->rollover Greg Kroah-Hartman
` (66 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Russell King, Andrew Lunn, David S. Miller
From: Russell King <rmk+kernel@armlinux.org.uk>
[ Upstream commit 28e74a7cfd6403f0d1c0f8b10b45d6fae37b227e ]
Some SFP modules do not like reads longer than 16 bytes, so read the
EEPROM in chunks of 16 bytes at a time. This behaviour is not specified
in the SFP MSAs, which specifies:
"The serial interface uses the 2-wire serial CMOS E2PROM protocol
defined for the ATMEL AT24C01A/02/04 family of components."
and
"As long as the SFP+ receives an acknowledge, it shall serially clock
out sequential data words. The sequence is terminated when the host
responds with a NACK and a STOP instead of an acknowledge."
We must avoid breaking a read across a 16-bit quantity in the diagnostic
page, thankfully all 16-bit quantities in that page are naturally
aligned.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/phy/sfp.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -281,6 +281,7 @@ static int sfp_i2c_read(struct sfp *sfp,
{
struct i2c_msg msgs[2];
u8 bus_addr = a2 ? 0x51 : 0x50;
+ size_t this_len;
int ret;
msgs[0].addr = bus_addr;
@@ -292,11 +293,26 @@ static int sfp_i2c_read(struct sfp *sfp,
msgs[1].len = len;
msgs[1].buf = buf;
- ret = i2c_transfer(sfp->i2c, msgs, ARRAY_SIZE(msgs));
- if (ret < 0)
- return ret;
+ while (len) {
+ this_len = len;
+ if (this_len > 16)
+ this_len = 16;
- return ret == ARRAY_SIZE(msgs) ? len : 0;
+ msgs[1].len = this_len;
+
+ ret = i2c_transfer(sfp->i2c, msgs, ARRAY_SIZE(msgs));
+ if (ret < 0)
+ return ret;
+
+ if (ret != ARRAY_SIZE(msgs))
+ break;
+
+ msgs[1].buf += this_len;
+ dev_addr += this_len;
+ len -= this_len;
+ }
+
+ return msgs[1].buf - (u8 *)buf;
}
static int sfp_i2c_write(struct sfp *sfp, bool a2, u8 dev_addr, void *buf,
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 09/70] packet: unconditionally free po->rollover
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 08/70] net: sfp: read eeprom in maximum 16 byte increments Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 10/70] pktgen: do not sleep with the thread lock held Greg Kroah-Hartman
` (65 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot, Willem de Bruijn,
David S. Miller, Dmitry Vyukov
From: Willem de Bruijn <willemb@google.com>
[ Upstream commit afa0925c6fcc6a8f610e996ca09bc3215048033c ]
Rollover used to use a complex RCU mechanism for assignment, which had
a race condition. The below patch fixed the bug and greatly simplified
the logic.
The feature depends on fanout, but the state is private to the socket.
Fanout_release returns f only when the last member leaves and the
fanout struct is to be freed.
Destroy rollover unconditionally, regardless of fanout state.
Fixes: 57f015f5eccf2 ("packet: fix crash in fanout_demux_rollover()")
Reported-by: syzbot <syzkaller@googlegroups.com>
Diagnosed-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/packet/af_packet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -3016,8 +3016,8 @@ static int packet_release(struct socket
synchronize_net();
+ kfree(po->rollover);
if (f) {
- kfree(po->rollover);
fanout_release_data(f);
kfree(f);
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 10/70] pktgen: do not sleep with the thread lock held.
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 09/70] packet: unconditionally free po->rollover Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 11/70] Revert "fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied" Greg Kroah-Hartman
` (64 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paolo Abeni, David S. Miller, Matteo Croce
From: Paolo Abeni <pabeni@redhat.com>
[ Upstream commit 720f1de4021f09898b8c8443f3b3e995991b6e3a ]
Currently, the process issuing a "start" command on the pktgen procfs
interface, acquires the pktgen thread lock and never release it, until
all pktgen threads are completed. The above can blocks indefinitely any
other pktgen command and any (even unrelated) netdevice removal - as
the pktgen netdev notifier acquires the same lock.
The issue is demonstrated by the following script, reported by Matteo:
ip -b - <<'EOF'
link add type dummy
link add type veth
link set dummy0 up
EOF
modprobe pktgen
echo reset >/proc/net/pktgen/pgctrl
{
echo rem_device_all
echo add_device dummy0
} >/proc/net/pktgen/kpktgend_0
echo count 0 >/proc/net/pktgen/dummy0
echo start >/proc/net/pktgen/pgctrl &
sleep 1
rmmod veth
Fix the above releasing the thread lock around the sleep call.
Additionally we must prevent racing with forcefull rmmod - as the
thread lock no more protects from them. Instead, acquire a self-reference
before waiting for any thread. As a side effect, running
rmmod pktgen
while some thread is running now fails with "module in use" error,
before this patch such command hanged indefinitely.
Note: the issue predates the commit reported in the fixes tag, but
this fix can't be applied before the mentioned commit.
v1 -> v2:
- no need to check for thread existence after flipping the lock,
pktgen threads are freed only at net exit time
-
Fixes: 6146e6a43b35 ("[PKTGEN]: Removes thread_{un,}lock() macros.")
Reported-and-tested-by: Matteo Croce <mcroce@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/pktgen.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3066,7 +3066,13 @@ static int pktgen_wait_thread_run(struct
{
while (thread_is_running(t)) {
+ /* note: 't' will still be around even after the unlock/lock
+ * cycle because pktgen_thread threads are only cleared at
+ * net exit
+ */
+ mutex_unlock(&pktgen_thread_lock);
msleep_interruptible(100);
+ mutex_lock(&pktgen_thread_lock);
if (signal_pending(current))
goto signal;
@@ -3081,6 +3087,10 @@ static int pktgen_wait_all_threads_run(s
struct pktgen_thread *t;
int sig = 1;
+ /* prevent from racing with rmmod */
+ if (!try_module_get(THIS_MODULE))
+ return sig;
+
mutex_lock(&pktgen_thread_lock);
list_for_each_entry(t, &pn->pktgen_threads, th_list) {
@@ -3094,6 +3104,7 @@ static int pktgen_wait_all_threads_run(s
t->control |= (T_STOP);
mutex_unlock(&pktgen_thread_lock);
+ module_put(THIS_MODULE);
return sig;
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 11/70] Revert "fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied"
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 10/70] pktgen: do not sleep with the thread lock held Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 12/70] udp: only choose unbound UDP socket for multicast when not in a VRF Greg Kroah-Hartman
` (63 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nathan Chancellor, Yaro Slav,
Maciej Żenczykowski, Hangbin Liu, David S. Miller
From: Hangbin Liu <liuhangbin@gmail.com>
[ Upstream commit 4970b42d5c362bf873982db7d93245c5281e58f4 ]
This reverts commit e9919a24d3022f72bcadc407e73a6ef17093a849.
Nathan reported the new behaviour breaks Android, as Android just add
new rules and delete old ones.
If we return 0 without adding dup rules, Android will remove the new
added rules and causing system to soft-reboot.
Fixes: e9919a24d302 ("fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied")
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Reported-by: Yaro Slav <yaro330@gmail.com>
Reported-by: Maciej Żenczykowski <zenczykowski@gmail.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/fib_rules.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -756,9 +756,9 @@ int fib_nl_newrule(struct sk_buff *skb,
if (err)
goto errout;
- if (rule_exists(ops, frh, tb, rule)) {
- if (nlh->nlmsg_flags & NLM_F_EXCL)
- err = -EEXIST;
+ if ((nlh->nlmsg_flags & NLM_F_EXCL) &&
+ rule_exists(ops, frh, tb, rule)) {
+ err = -EEXIST;
goto errout_free;
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 12/70] udp: only choose unbound UDP socket for multicast when not in a VRF
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 11/70] Revert "fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied" Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 13/70] ipv6: use READ_ONCE() for inet->hdrincl as in ipv4 Greg Kroah-Hartman
` (62 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tim Beale, David Ahern, David S. Miller
From: Tim Beale <timbeale@catalyst.net.nz>
[ Upstream commit 82ba25c6de200d7a9e9c970c998cdd6dfa8637ae ]
By default, packets received in another VRF should not be passed to an
unbound socket in the default VRF. This patch updates the IPv4 UDP
multicast logic to match the unicast VRF logic (in compute_score()),
as well as the IPv6 mcast logic (in __udp_v6_is_mcast_sock()).
The particular case I noticed was DHCP discover packets going
to the 255.255.255.255 address, which are handled by
__udp4_lib_mcast_deliver(). The previous code meant that running
multiple different DHCP server or relay agent instances across VRFs
did not work correctly - any server/relay agent in the default VRF
received DHCP discover packets for all other VRFs.
Fixes: 6da5b0f027a8 ("net: ensure unbound datagram socket to be chosen when not in a VRF")
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/udp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -538,8 +538,7 @@ static inline bool __udp_is_mcast_sock(s
(inet->inet_dport != rmt_port && inet->inet_dport) ||
(inet->inet_rcv_saddr && inet->inet_rcv_saddr != loc_addr) ||
ipv6_only_sock(sk) ||
- (sk->sk_bound_dev_if && sk->sk_bound_dev_if != dif &&
- sk->sk_bound_dev_if != sdif))
+ !udp_sk_bound_dev_eq(net, sk->sk_bound_dev_if, dif, sdif))
return false;
if (!ip_mc_sf_allow(sk, loc_addr, rmt_addr, dif, sdif))
return false;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 13/70] ipv6: use READ_ONCE() for inet->hdrincl as in ipv4
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 12/70] udp: only choose unbound UDP socket for multicast when not in a VRF Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 14/70] ipv6: fix EFAULT on sendto with icmpv6 and hdrincl Greg Kroah-Hartman
` (61 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Olivier Matz, David S. Miller
From: Olivier Matz <olivier.matz@6wind.com>
[ Upstream commit 59e3e4b52663a9d97efbce7307f62e4bc5c9ce91 ]
As it was done in commit 8f659a03a0ba ("net: ipv4: fix for a race
condition in raw_sendmsg") and commit 20b50d79974e ("net: ipv4: emulate
READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()") for ipv4, copy the
value of inet->hdrincl in a local variable, to avoid introducing a race
condition in the next commit.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/raw.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -783,6 +783,7 @@ static int rawv6_sendmsg(struct sock *sk
struct flowi6 fl6;
struct ipcm6_cookie ipc6;
int addr_len = msg->msg_namelen;
+ int hdrincl;
u16 proto;
int err;
@@ -796,6 +797,13 @@ static int rawv6_sendmsg(struct sock *sk
if (msg->msg_flags & MSG_OOB)
return -EOPNOTSUPP;
+ /* hdrincl should be READ_ONCE(inet->hdrincl)
+ * but READ_ONCE() doesn't work with bit fields.
+ * Doing this indirectly yields the same result.
+ */
+ hdrincl = inet->hdrincl;
+ hdrincl = READ_ONCE(hdrincl);
+
/*
* Get and verify the address.
*/
@@ -908,7 +916,7 @@ static int rawv6_sendmsg(struct sock *sk
fl6.flowi6_oif = np->ucast_oif;
security_sk_classify_flow(sk, flowi6_to_flowi(&fl6));
- if (inet->hdrincl)
+ if (hdrincl)
fl6.flowi6_flags |= FLOWI_FLAG_KNOWN_NH;
if (ipc6.tclass < 0)
@@ -931,7 +939,7 @@ static int rawv6_sendmsg(struct sock *sk
goto do_confirm;
back_from_confirm:
- if (inet->hdrincl)
+ if (hdrincl)
err = rawv6_send_hdrinc(sk, msg, len, &fl6, &dst,
msg->msg_flags, &ipc6.sockc);
else {
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 14/70] ipv6: fix EFAULT on sendto with icmpv6 and hdrincl
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 13/70] ipv6: use READ_ONCE() for inet->hdrincl as in ipv4 Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 15/70] net: aquantia: fix wol configuration not applied sometimes Greg Kroah-Hartman
` (60 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Olivier Matz, Nicolas Dichtel,
David S. Miller
From: Olivier Matz <olivier.matz@6wind.com>
[ Upstream commit b9aa52c4cb457e7416cc0c95f475e72ef4a61336 ]
The following code returns EFAULT (Bad address):
s = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
setsockopt(s, SOL_IPV6, IPV6_HDRINCL, 1);
sendto(ipv6_icmp6_packet, addr); /* returns -1, errno = EFAULT */
The IPv4 equivalent code works. A workaround is to use IPPROTO_RAW
instead of IPPROTO_ICMPV6.
The failure happens because 2 bytes are eaten from the msghdr by
rawv6_probe_proto_opt() starting from commit 19e3c66b52ca ("ipv6
equivalent of "ipv4: Avoid reading user iov twice after
raw_probe_proto_opt""), but at that time it was not a problem because
IPV6_HDRINCL was not yet introduced.
Only eat these 2 bytes if hdrincl == 0.
Fixes: 715f504b1189 ("ipv6: add IPV6_HDRINCL option for raw sockets")
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-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/ipv6/raw.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -895,11 +895,14 @@ static int rawv6_sendmsg(struct sock *sk
opt = ipv6_fixup_options(&opt_space, opt);
fl6.flowi6_proto = proto;
- rfv.msg = msg;
- rfv.hlen = 0;
- err = rawv6_probe_proto_opt(&rfv, &fl6);
- if (err)
- goto out;
+
+ if (!hdrincl) {
+ rfv.msg = msg;
+ rfv.hlen = 0;
+ err = rawv6_probe_proto_opt(&rfv, &fl6);
+ if (err)
+ goto out;
+ }
if (!ipv6_addr_any(daddr))
fl6.daddr = *daddr;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 15/70] net: aquantia: fix wol configuration not applied sometimes
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 14/70] ipv6: fix EFAULT on sendto with icmpv6 and hdrincl Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 16/70] neighbor: Reset gc_entries counter if new entry is released before insert Greg Kroah-Hartman
` (59 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nikita Danilov, Igor Russkikh,
David S. Miller
From: Nikita Danilov <nikita.danilov@aquantia.com>
[ Upstream commit 930b9a0543385d4eb8ef887e88cf84d95a844577 ]
WoL magic packet configuration sometimes does not work due to
couple of leakages found.
Mainly there was a regression introduced during readx_poll refactoring.
Next, fw request waiting time was too small. Sometimes that
caused sleep proxy config function to return with an error
and to skip WoL configuration.
At last, WoL data were passed to FW from not clean buffer.
That could cause FW to accept garbage as a random configuration data.
Fixes: 6a7f2277313b ("net: aquantia: replace AQ_HW_WAIT_FOR with readx_poll_timeout_atomic")
Signed-off-by: Nikita Danilov <nikita.danilov@aquantia.com>
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c | 14 +++++-----
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c | 4 ++
2 files changed, 10 insertions(+), 8 deletions(-)
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
@@ -335,13 +335,13 @@ static int hw_atl_utils_fw_upload_dwords
{
u32 val;
int err = 0;
- bool is_locked;
- is_locked = hw_atl_sem_ram_get(self);
- if (!is_locked) {
- err = -ETIME;
+ err = readx_poll_timeout_atomic(hw_atl_sem_ram_get, self,
+ val, val == 1U,
+ 10U, 100000U);
+ if (err < 0)
goto err_exit;
- }
+
if (IS_CHIP_FEATURE(REVISION_B1)) {
u32 offset = 0;
@@ -353,8 +353,8 @@ static int hw_atl_utils_fw_upload_dwords
/* 1000 times by 10us = 10ms */
err = readx_poll_timeout_atomic(hw_atl_scrpad12_get,
self, val,
- (val & 0xF0000000) ==
- 0x80000000,
+ (val & 0xF0000000) !=
+ 0x80000000,
10U, 10000U);
}
} else {
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
@@ -349,7 +349,7 @@ static int aq_fw2x_set_sleep_proxy(struc
err = readx_poll_timeout_atomic(aq_fw2x_state2_get,
self, val,
val & HW_ATL_FW2X_CTRL_SLEEP_PROXY,
- 1U, 10000U);
+ 1U, 100000U);
err_exit:
return err;
@@ -369,6 +369,8 @@ static int aq_fw2x_set_wol_params(struct
msg = (struct fw2x_msg_wol *)rpc;
+ memset(msg, 0, sizeof(*msg));
+
msg->msg_id = HAL_ATLANTIC_UTILS_FW2X_MSG_WOL;
msg->magic_packet_enabled = true;
memcpy(msg->hw_addr, mac, ETH_ALEN);
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 16/70] neighbor: Reset gc_entries counter if new entry is released before insert
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 15/70] net: aquantia: fix wol configuration not applied sometimes Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 17/70] neighbor: Call __ipv4_neigh_lookup_noref in neigh_xmit Greg Kroah-Hartman
` (58 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ian Kumlien, Alan Maguire,
David Ahern, David S. Miller
From: David Ahern <dsahern@gmail.com>
[ Upstream commit 64c6f4bbca748c3b2101469a76d88b7cd1c00476 ]
Ian and Alan both reported seeing overflows after upgrades to 5.x kernels:
neighbour: arp_cache: neighbor table overflow!
Alan's mpls script helped get to the bottom of this bug. When a new entry
is created the gc_entries counter is bumped in neigh_alloc to check if a
new one is allowed to be created. ___neigh_create then searches for an
existing entry before inserting the just allocated one. If an entry
already exists, the new one is dropped in favor of the existing one. In
this case the cleanup path needs to drop the gc_entries counter. There
is no memory leak, only a counter leak.
Fixes: 58956317c8d ("neighbor: Improve garbage collection")
Reported-by: Ian Kumlien <ian.kumlien@gmail.com>
Reported-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
Tested-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/neighbour.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -663,6 +663,8 @@ out:
out_tbl_unlock:
write_unlock_bh(&tbl->lock);
out_neigh_release:
+ if (!exempt_from_gc)
+ atomic_dec(&tbl->gc_entries);
neigh_release(n);
goto out;
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 17/70] neighbor: Call __ipv4_neigh_lookup_noref in neigh_xmit
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 16/70] neighbor: Reset gc_entries counter if new entry is released before insert Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 18/70] cls_matchall: avoid panic when receiving a packet before filter set Greg Kroah-Hartman
` (57 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alan Maguire, David Ahern, David S. Miller
From: David Ahern <dsahern@gmail.com>
[ Upstream commit 4b2a2bfeb3f056461a90bd621e8bd7d03fa47f60 ]
Commit cd9ff4de0107 changed the key for IFF_POINTOPOINT devices to
INADDR_ANY but neigh_xmit which is used for MPLS encapsulations was not
updated to use the altered key. The result is that every packet Tx does
a lookup on the gateway address which does not find an entry, a new one
is created only to find the existing one in the table right before the
insert since arp_constructor was updated to reset the primary key. This
is seen in the allocs and destroys counters:
ip -s -4 ntable show | head -10 | grep alloc
which increase for each packet showing the unnecessary overhread.
Fix by having neigh_xmit use __ipv4_neigh_lookup_noref for NEIGH_ARP_TABLE.
Fixes: cd9ff4de0107 ("ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY")
Reported-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
Tested-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/neighbour.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -31,6 +31,7 @@
#include <linux/times.h>
#include <net/net_namespace.h>
#include <net/neighbour.h>
+#include <net/arp.h>
#include <net/dst.h>
#include <net/sock.h>
#include <net/netevent.h>
@@ -2984,7 +2985,13 @@ int neigh_xmit(int index, struct net_dev
if (!tbl)
goto out;
rcu_read_lock_bh();
- neigh = __neigh_lookup_noref(tbl, addr, dev);
+ if (index == NEIGH_ARP_TABLE) {
+ u32 key = *((u32 *)addr);
+
+ neigh = __ipv4_neigh_lookup_noref(dev, key);
+ } else {
+ neigh = __neigh_lookup_noref(tbl, addr, dev);
+ }
if (!neigh)
neigh = __neigh_create(tbl, addr, dev, false);
err = PTR_ERR(neigh);
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 18/70] cls_matchall: avoid panic when receiving a packet before filter set
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 17/70] neighbor: Call __ipv4_neigh_lookup_noref in neigh_xmit Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 19/70] ipmr_base: Do not reset index in mr_table_dump Greg Kroah-Hartman
` (56 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matteo Croce, Cong Wang, David S. Miller
From: Matteo Croce <mcroce@redhat.com>
[ Upstream commit 25426043ec9e22b90c789407c28e40f32a9d1985 ]
When a matchall classifier is added, there is a small time interval in
which tp->root is NULL. If we receive a packet in this small time slice
a NULL pointer dereference will happen, leading to a kernel panic:
# tc qdisc replace dev eth0 ingress
# tc filter add dev eth0 parent ffff: matchall action gact drop
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000034
Mem abort info:
ESR = 0x96000005
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000005
CM = 0, WnR = 0
user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000a623d530
[0000000000000034] pgd=0000000000000000, pud=0000000000000000
Internal error: Oops: 96000005 [#1] SMP
Modules linked in: cls_matchall sch_ingress nls_iso8859_1 nls_cp437 vfat fat m25p80 spi_nor mtd xhci_plat_hcd xhci_hcd phy_generic sfp mdio_i2c usbcore i2c_mv64xxx marvell10g mvpp2 usb_common spi_orion mvmdio i2c_core sbsa_gwdt phylink ip_tables x_tables autofs4
Process ksoftirqd/0 (pid: 9, stack limit = 0x0000000009de7d62)
CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.1.0-rc6 #21
Hardware name: Marvell 8040 MACCHIATOBin Double-shot (DT)
pstate: 40000005 (nZcv daif -PAN -UAO)
pc : mall_classify+0x28/0x78 [cls_matchall]
lr : tcf_classify+0x78/0x138
sp : ffffff80109db9d0
x29: ffffff80109db9d0 x28: ffffffc426058800
x27: 0000000000000000 x26: ffffffc425b0dd00
x25: 0000000020000000 x24: 0000000000000000
x23: ffffff80109dbac0 x22: 0000000000000001
x21: ffffffc428ab5100 x20: ffffffc425b0dd00
x19: ffffff80109dbac0 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: 0000000000000000
x13: ffffffbf108ad288 x12: dead000000000200
x11: 00000000f0000000 x10: 0000000000000001
x9 : ffffffbf1089a220 x8 : 0000000000000001
x7 : ffffffbebffaa950 x6 : 0000000000000000
x5 : 000000442d6ba000 x4 : 0000000000000000
x3 : ffffff8008735ad8 x2 : ffffff80109dbac0
x1 : ffffffc425b0dd00 x0 : ffffff8010592078
Call trace:
mall_classify+0x28/0x78 [cls_matchall]
tcf_classify+0x78/0x138
__netif_receive_skb_core+0x29c/0xa20
__netif_receive_skb_one_core+0x34/0x60
__netif_receive_skb+0x28/0x78
netif_receive_skb_internal+0x2c/0xc0
napi_gro_receive+0x1a0/0x1d8
mvpp2_poll+0x928/0xb18 [mvpp2]
net_rx_action+0x108/0x378
__do_softirq+0x128/0x320
run_ksoftirqd+0x44/0x60
smpboot_thread_fn+0x168/0x1b0
kthread+0x12c/0x130
ret_from_fork+0x10/0x1c
Code: aa0203f3 aa1e03e0 d503201f f9400684 (b9403480)
---[ end trace fc71e2ef7b8ab5a5 ]---
Kernel panic - not syncing: Fatal exception in interrupt
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x002,00002000
Memory Limit: none
Rebooting in 1 seconds..
Fix this by adding a NULL check in mall_classify().
Fixes: ed76f5edccc9 ("net: sched: protect filter_chain list with filter_chain_lock mutex")
Signed-off-by: Matteo Croce <mcroce@redhat.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sched/cls_matchall.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@ -32,6 +32,9 @@ static int mall_classify(struct sk_buff
{
struct cls_mall_head *head = rcu_dereference_bh(tp->root);
+ if (unlikely(!head))
+ return -1;
+
if (tc_skip_sw(head->flags))
return -1;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 19/70] ipmr_base: Do not reset index in mr_table_dump
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 18/70] cls_matchall: avoid panic when receiving a packet before filter set Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 20/70] net/mlx4_en: ethtool, Remove unsupported SFP EEPROM high pages query Greg Kroah-Hartman
` (55 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, David Ahern, David S. Miller
From: David Ahern <dsahern@gmail.com>
[ Upstream commit 7fcd1e033dacedd520abebc943c960dcf5add3ae ]
e is the counter used to save the location of a dump when an
skb is filled. Once the walk of the table is complete, mr_table_dump
needs to return without resetting that index to 0. Dump of a specific
table is looping because of the reset because there is no way to
indicate the walk of the table is done.
Move the reset to the caller so the dump of each table starts at 0,
but the loop counter is maintained if a dump fills an skb.
Fixes: e1cedae1ba6b0 ("ipmr: Refactor mr_rtm_dumproute")
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/ipmr_base.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/net/ipv4/ipmr_base.c
+++ b/net/ipv4/ipmr_base.c
@@ -335,8 +335,6 @@ next_entry2:
}
spin_unlock_bh(lock);
err = 0;
- e = 0;
-
out:
cb->args[1] = e;
return err;
@@ -374,6 +372,7 @@ int mr_rtm_dumproute(struct sk_buff *skb
err = mr_table_dump(mrt, skb, cb, fill, lock, filter);
if (err < 0)
break;
+ cb->args[1] = 0;
next_table:
t++;
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 20/70] net/mlx4_en: ethtool, Remove unsupported SFP EEPROM high pages query
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 19/70] ipmr_base: Do not reset index in mr_table_dump Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 21/70] net/tls: replace the sleeping lock around RX resync with a bit lock Greg Kroah-Hartman
` (54 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Erez Alfasi, Tariq Toukan, David S. Miller
From: Erez Alfasi <ereza@mellanox.com>
[ Upstream commit 135dd9594f127c8a82d141c3c8430e9e2143216a ]
Querying EEPROM high pages data for SFP module is currently
not supported by our driver but is still tried, resulting in
invalid FW queries.
Set the EEPROM ethtool data length to 256 for SFP module to
limit the reading for page 0 only and prevent invalid FW queries.
Fixes: 7202da8b7f71 ("ethtool, net/mlx4_en: Cable info, get_module_info/eeprom ethtool support")
Signed-off-by: Erez Alfasi <ereza@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 4 +++-
drivers/net/ethernet/mellanox/mlx4/port.c | 5 -----
2 files changed, 3 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -2010,6 +2010,8 @@ static int mlx4_en_set_tunable(struct ne
return ret;
}
+#define MLX4_EEPROM_PAGE_LEN 256
+
static int mlx4_en_get_module_info(struct net_device *dev,
struct ethtool_modinfo *modinfo)
{
@@ -2044,7 +2046,7 @@ static int mlx4_en_get_module_info(struc
break;
case MLX4_MODULE_ID_SFP:
modinfo->type = ETH_MODULE_SFF_8472;
- modinfo->eeprom_len = ETH_MODULE_SFF_8472_LEN;
+ modinfo->eeprom_len = MLX4_EEPROM_PAGE_LEN;
break;
default:
return -EINVAL;
--- a/drivers/net/ethernet/mellanox/mlx4/port.c
+++ b/drivers/net/ethernet/mellanox/mlx4/port.c
@@ -2077,11 +2077,6 @@ int mlx4_get_module_info(struct mlx4_dev
size -= offset + size - I2C_PAGE_SIZE;
i2c_addr = I2C_ADDR_LOW;
- if (offset >= I2C_PAGE_SIZE) {
- /* Reset offset to high page */
- i2c_addr = I2C_ADDR_HIGH;
- offset -= I2C_PAGE_SIZE;
- }
cable_info = (struct mlx4_cable_info *)inmad->data;
cable_info->dev_mem_address = cpu_to_be16(offset);
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 21/70] net/tls: replace the sleeping lock around RX resync with a bit lock
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 20/70] net/mlx4_en: ethtool, Remove unsupported SFP EEPROM high pages query Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 22/70] rcu: locking and unlocking need to always be at least barriers Greg Kroah-Hartman
` (53 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jakub Kicinski, David S. Miller
From: Jakub Kicinski <jakub.kicinski@netronome.com>
[ Upstream commit e52972c11d6b1262964db96d65934196db621685 ]
Commit 38030d7cb779 ("net/tls: avoid NULL-deref on resync during device removal")
tried to fix a potential NULL-dereference by taking the
context rwsem. Unfortunately the RX resync may get called
from soft IRQ, so we can't use the rwsem to protect from
the device disappearing. Because we are guaranteed there
can be only one resync at a time (it's called from strparser)
use a bit to indicate resync is busy and make device
removal wait for the bit to get cleared.
Note that there is a leftover "flags" field in struct
tls_context already.
Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/tls.h | 4 ++++
net/tls/tls_device.c | 27 +++++++++++++++++++++------
2 files changed, 25 insertions(+), 6 deletions(-)
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -199,6 +199,10 @@ struct tls_offload_context_tx {
(ALIGN(sizeof(struct tls_offload_context_tx), sizeof(void *)) + \
TLS_DRIVER_STATE_SIZE)
+enum tls_context_flags {
+ TLS_RX_SYNC_RUNNING = 0,
+};
+
struct cipher_context {
char *iv;
char *rec_seq;
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -570,10 +570,22 @@ void tls_device_write_space(struct sock
}
}
+static void tls_device_resync_rx(struct tls_context *tls_ctx,
+ struct sock *sk, u32 seq, u64 rcd_sn)
+{
+ struct net_device *netdev;
+
+ if (WARN_ON(test_and_set_bit(TLS_RX_SYNC_RUNNING, &tls_ctx->flags)))
+ return;
+ netdev = READ_ONCE(tls_ctx->netdev);
+ if (netdev)
+ netdev->tlsdev_ops->tls_dev_resync_rx(netdev, sk, seq, rcd_sn);
+ clear_bit_unlock(TLS_RX_SYNC_RUNNING, &tls_ctx->flags);
+}
+
void handle_device_resync(struct sock *sk, u32 seq, u64 rcd_sn)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
- struct net_device *netdev = tls_ctx->netdev;
struct tls_offload_context_rx *rx_ctx;
u32 is_req_pending;
s64 resync_req;
@@ -588,10 +600,10 @@ void handle_device_resync(struct sock *s
is_req_pending = resync_req;
if (unlikely(is_req_pending) && req_seq == seq &&
- atomic64_try_cmpxchg(&rx_ctx->resync_req, &resync_req, 0))
- netdev->tlsdev_ops->tls_dev_resync_rx(netdev, sk,
- seq + TLS_HEADER_SIZE - 1,
- rcd_sn);
+ atomic64_try_cmpxchg(&rx_ctx->resync_req, &resync_req, 0)) {
+ seq += TLS_HEADER_SIZE - 1;
+ tls_device_resync_rx(tls_ctx, sk, seq, rcd_sn);
+ }
}
static int tls_device_reencrypt(struct sock *sk, struct sk_buff *skb)
@@ -981,7 +993,10 @@ static int tls_device_down(struct net_de
if (ctx->rx_conf == TLS_HW)
netdev->tlsdev_ops->tls_dev_del(netdev, ctx,
TLS_OFFLOAD_CTX_DIR_RX);
- ctx->netdev = NULL;
+ WRITE_ONCE(ctx->netdev, NULL);
+ smp_mb__before_atomic(); /* pairs with test_and_set_bit() */
+ while (test_bit(TLS_RX_SYNC_RUNNING, &ctx->flags))
+ usleep_range(10, 200);
dev_put(netdev);
list_del_init(&ctx->list);
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 22/70] rcu: locking and unlocking need to always be at least barriers
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 21/70] net/tls: replace the sleeping lock around RX resync with a bit lock Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 23/70] habanalabs: fix debugfs code Greg Kroah-Hartman
` (52 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Herbert Xu, stable, Boqun Feng,
Paul E. McKenney, Linus Torvalds
From: Linus Torvalds <torvalds@linux-foundation.org>
commit 66be4e66a7f422128748e3c3ef6ee72b20a6197b upstream.
Herbert Xu pointed out that commit bb73c52bad36 ("rcu: Don't disable
preemption for Tiny and Tree RCU readers") was incorrect in making the
preempt_disable/enable() be conditional on CONFIG_PREEMPT_COUNT.
If CONFIG_PREEMPT_COUNT isn't enabled, the preemption enable/disable is
a no-op, but still is a compiler barrier.
And RCU locking still _needs_ that compiler barrier.
It is simply fundamentally not true that RCU locking would be a complete
no-op: we still need to guarantee (for example) that things that can
trap and cause preemption cannot migrate into the RCU locked region.
The way we do that is by making it a barrier.
See for example commit 386afc91144b ("spinlocks and preemption points
need to be at least compiler barriers") from back in 2013 that had
similar issues with spinlocks that become no-ops on UP: they must still
constrain the compiler from moving other operations into the critical
region.
Now, it is true that a lot of RCU operations already use READ_ONCE() and
WRITE_ONCE() (which in practice likely would never be re-ordered wrt
anything remotely interesting), but it is also true that that is not
globally the case, and that it's not even necessarily always possible
(ie bitfields etc).
Reported-by: Herbert Xu <herbert@gondor.apana.org.au>
Fixes: bb73c52bad36 ("rcu: Don't disable preemption for Tiny and Tree RCU readers")
Cc: stable@kernel.org
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/rcupdate.h | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -56,14 +56,12 @@ void __rcu_read_unlock(void);
static inline void __rcu_read_lock(void)
{
- if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
- preempt_disable();
+ preempt_disable();
}
static inline void __rcu_read_unlock(void)
{
- if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
- preempt_enable();
+ preempt_enable();
}
static inline int rcu_preempt_depth(void)
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 23/70] habanalabs: fix debugfs code
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 22/70] rcu: locking and unlocking need to always be at least barriers Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 24/70] ARC: mm: SIGSEGV userspace trying to access kernel virtual memory Greg Kroah-Hartman
` (51 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jann Horn, Oded Gabbay
From: Jann Horn <jannh@google.com>
commit 8438846cce61e284a22316c13aa4b63772963070 upstream.
This fixes multiple things in the habanalabs debugfs code, in particular:
- mmu_write() was unnecessarily verbose, copying around between multiple
buffers
- mmu_write() could write a user-specified, unbounded amount of userspace
memory into a kernel buffer (out-of-bounds write)
- multiple debugfs read handlers ignored the user-supplied count,
potentially corrupting out-of-bounds userspace data
- hl_device_read() was unnecessarily verbose
- hl_device_write() could read uninitialized stack memory
- multiple debugfs read handlers copied terminating null characters to
userspace
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/habanalabs/debugfs.c | 60 +++++++++++---------------------------
1 file changed, 18 insertions(+), 42 deletions(-)
--- a/drivers/misc/habanalabs/debugfs.c
+++ b/drivers/misc/habanalabs/debugfs.c
@@ -459,41 +459,31 @@ static ssize_t mmu_write(struct file *fi
struct hl_debugfs_entry *entry = s->private;
struct hl_dbg_device_entry *dev_entry = entry->dev_entry;
struct hl_device *hdev = dev_entry->hdev;
- char kbuf[MMU_KBUF_SIZE], asid_kbuf[MMU_ASID_BUF_SIZE],
- addr_kbuf[MMU_ADDR_BUF_SIZE];
+ char kbuf[MMU_KBUF_SIZE];
char *c;
ssize_t rc;
if (!hdev->mmu_enable)
return count;
- memset(kbuf, 0, sizeof(kbuf));
- memset(asid_kbuf, 0, sizeof(asid_kbuf));
- memset(addr_kbuf, 0, sizeof(addr_kbuf));
-
+ if (count > sizeof(kbuf) - 1)
+ goto err;
if (copy_from_user(kbuf, buf, count))
goto err;
-
- kbuf[MMU_KBUF_SIZE - 1] = 0;
+ kbuf[count] = 0;
c = strchr(kbuf, ' ');
if (!c)
goto err;
+ *c = '\0';
- memcpy(asid_kbuf, kbuf, c - kbuf);
-
- rc = kstrtouint(asid_kbuf, 10, &dev_entry->mmu_asid);
+ rc = kstrtouint(kbuf, 10, &dev_entry->mmu_asid);
if (rc)
goto err;
- c = strstr(kbuf, " 0x");
- if (!c)
+ if (strncmp(c+1, "0x", 2))
goto err;
-
- c += 3;
- memcpy(addr_kbuf, c, (kbuf + count) - c);
-
- rc = kstrtoull(addr_kbuf, 16, &dev_entry->mmu_addr);
+ rc = kstrtoull(c+3, 16, &dev_entry->mmu_addr);
if (rc)
goto err;
@@ -525,10 +515,8 @@ static ssize_t hl_data_read32(struct fil
}
sprintf(tmp_buf, "0x%08x\n", val);
- rc = simple_read_from_buffer(buf, strlen(tmp_buf) + 1, ppos, tmp_buf,
- strlen(tmp_buf) + 1);
-
- return rc;
+ return simple_read_from_buffer(buf, count, ppos, tmp_buf,
+ strlen(tmp_buf));
}
static ssize_t hl_data_write32(struct file *f, const char __user *buf,
@@ -559,7 +547,6 @@ static ssize_t hl_get_power_state(struct
struct hl_dbg_device_entry *entry = file_inode(f)->i_private;
struct hl_device *hdev = entry->hdev;
char tmp_buf[200];
- ssize_t rc;
int i;
if (*ppos)
@@ -574,10 +561,8 @@ static ssize_t hl_get_power_state(struct
sprintf(tmp_buf,
"current power state: %d\n1 - D0\n2 - D3hot\n3 - Unknown\n", i);
- rc = simple_read_from_buffer(buf, strlen(tmp_buf) + 1, ppos, tmp_buf,
- strlen(tmp_buf) + 1);
-
- return rc;
+ return simple_read_from_buffer(buf, count, ppos, tmp_buf,
+ strlen(tmp_buf));
}
static ssize_t hl_set_power_state(struct file *f, const char __user *buf,
@@ -630,8 +615,8 @@ static ssize_t hl_i2c_data_read(struct f
}
sprintf(tmp_buf, "0x%02x\n", val);
- rc = simple_read_from_buffer(buf, strlen(tmp_buf) + 1, ppos, tmp_buf,
- strlen(tmp_buf) + 1);
+ rc = simple_read_from_buffer(buf, count, ppos, tmp_buf,
+ strlen(tmp_buf));
return rc;
}
@@ -720,18 +705,9 @@ static ssize_t hl_led2_write(struct file
static ssize_t hl_device_read(struct file *f, char __user *buf,
size_t count, loff_t *ppos)
{
- char tmp_buf[200];
- ssize_t rc;
-
- if (*ppos)
- return 0;
-
- sprintf(tmp_buf,
- "Valid values: disable, enable, suspend, resume, cpu_timeout\n");
- rc = simple_read_from_buffer(buf, strlen(tmp_buf) + 1, ppos, tmp_buf,
- strlen(tmp_buf) + 1);
-
- return rc;
+ static const char *help =
+ "Valid values: disable, enable, suspend, resume, cpu_timeout\n";
+ return simple_read_from_buffer(buf, count, ppos, help, strlen(help));
}
static ssize_t hl_device_write(struct file *f, const char __user *buf,
@@ -739,7 +715,7 @@ static ssize_t hl_device_write(struct fi
{
struct hl_dbg_device_entry *entry = file_inode(f)->i_private;
struct hl_device *hdev = entry->hdev;
- char data[30];
+ char data[30] = {0};
/* don't allow partial writes */
if (*ppos != 0)
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 24/70] ARC: mm: SIGSEGV userspace trying to access kernel virtual memory
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 23/70] habanalabs: fix debugfs code Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 25/70] parisc: Use implicit space register selection for loading the coherence index of I/O pdirs Greg Kroah-Hartman
` (50 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Eugeniy Paltsev, Vineet Gupta
From: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
commit a8c715b4dd73c26a81a9cc8dc792aa715d8b4bb2 upstream.
As of today if userspace process tries to access a kernel virtual addres
(0x7000_0000 to 0x7ffff_ffff) such that a legit kernel mapping already
exists, that process hangs instead of being killed with SIGSEGV
Fix that by ensuring that do_page_fault() handles kenrel vaddr only if
in kernel mode.
And given this, we can also simplify the code a bit. Now a vmalloc fault
implies kernel mode so its failure (for some reason) can reuse the
@no_context label and we can remove @bad_area_nosemaphore.
Reproduce user test for original problem:
------------------------>8-----------------
#include <stdlib.h>
#include <stdint.h>
int main(int argc, char *argv[])
{
volatile uint32_t temp;
temp = *(uint32_t *)(0x70000000);
}
------------------------>8-----------------
Cc: <stable@vger.kernel.org>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arc/mm/fault.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
@@ -66,7 +66,7 @@ void do_page_fault(unsigned long address
struct vm_area_struct *vma = NULL;
struct task_struct *tsk = current;
struct mm_struct *mm = tsk->mm;
- int si_code = 0;
+ int si_code = SEGV_MAPERR;
int ret;
vm_fault_t fault;
int write = regs->ecr_cause & ECR_C_PROTV_STORE; /* ST/EX */
@@ -81,16 +81,14 @@ void do_page_fault(unsigned long address
* only copy the information from the master page table,
* nothing more.
*/
- if (address >= VMALLOC_START) {
+ if (address >= VMALLOC_START && !user_mode(regs)) {
ret = handle_kernel_vaddr_fault(address);
if (unlikely(ret))
- goto bad_area_nosemaphore;
+ goto no_context;
else
return;
}
- si_code = SEGV_MAPERR;
-
/*
* If we're in an interrupt or have no user
* context, we must not take the fault..
@@ -198,7 +196,6 @@ good_area:
bad_area:
up_read(&mm->mmap_sem);
-bad_area_nosemaphore:
/* User mode accesses just cause a SIGSEGV */
if (user_mode(regs)) {
tsk->thread.fault_address = address;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 25/70] parisc: Use implicit space register selection for loading the coherence index of I/O pdirs
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 24/70] ARC: mm: SIGSEGV userspace trying to access kernel virtual memory Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 26/70] parisc: Fix crash due alternative coding for NP iopdir_fdc bit Greg Kroah-Hartman
` (49 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, John David Anglin, Helge Deller
From: John David Anglin <dave.anglin@bell.net>
commit 63923d2c3800919774f5c651d503d1dd2adaddd5 upstream.
We only support I/O to kernel space. Using %sr1 to load the coherence
index may be racy unless interrupts are disabled. This patch changes the
code used to load the coherence index to use implicit space register
selection. This saves one instruction and eliminates the race.
Tested on rp3440, c8000 and c3750.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/parisc/ccio-dma.c | 4 +---
drivers/parisc/sba_iommu.c | 3 +--
2 files changed, 2 insertions(+), 5 deletions(-)
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -565,8 +565,6 @@ ccio_io_pdir_entry(u64 *pdir_ptr, space_
/* We currently only support kernel addresses */
BUG_ON(sid != KERNEL_SPACE);
- mtsp(sid,1);
-
/*
** WORD 1 - low order word
** "hints" parm includes the VALID bit!
@@ -597,7 +595,7 @@ ccio_io_pdir_entry(u64 *pdir_ptr, space_
** Grab virtual index [0:11]
** Deposit virt_idx bits into I/O PDIR word
*/
- asm volatile ("lci %%r0(%%sr1, %1), %0" : "=r" (ci) : "r" (vba));
+ asm volatile ("lci %%r0(%1), %0" : "=r" (ci) : "r" (vba));
asm volatile ("extru %1,19,12,%0" : "+r" (ci) : "r" (ci));
asm volatile ("depw %1,15,12,%0" : "+r" (pa) : "r" (ci));
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -575,8 +575,7 @@ sba_io_pdir_entry(u64 *pdir_ptr, space_t
pa = virt_to_phys(vba);
pa &= IOVP_MASK;
- mtsp(sid,1);
- asm("lci 0(%%sr1, %1), %0" : "=r" (ci) : "r" (vba));
+ asm("lci 0(%1), %0" : "=r" (ci) : "r" (vba));
pa |= (ci >> PAGE_SHIFT) & 0xff; /* move CI (8 bits) into lowest byte */
pa |= SBA_PDIR_VALID_BIT; /* set "valid" bit */
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 26/70] parisc: Fix crash due alternative coding for NP iopdir_fdc bit
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 25/70] parisc: Use implicit space register selection for loading the coherence index of I/O pdirs Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 27/70] SUNRPC fix regression in umount of a secure mount Greg Kroah-Hartman
` (48 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sven Schnelle, Carlo Pisani, Helge Deller
From: Helge Deller <deller@gmx.de>
commit 527a1d1ede98479bf90c31a64822107ac7e6d276 upstream.
According to the found documentation, data cache flushes and sync
instructions are needed on the PCX-U+ (PA8200, e.g. C200/C240)
platforms, while PCX-W (PA8500, e.g. C360) platforms aparently don't
need those flushes when changing the IO PDIR data structures.
We have no documentation for PCX-W+ (PA8600) and PCX-W2 (PA8700) CPUs,
but Carlo Pisani reported that his C3600 machine (PA8600, PCX-W+) fails
when the fdc instructions were removed. His firmware didn't set the NIOP
bit, so one may assume it's a firmware bug since other C3750 machines
had the bit set.
Even if documentation (as mentioned above) states that PCX-W (PA8500,
e.g. J5000) does not need fdc flushes, Sven could show that an Adaptec
29320A PCI-X SCSI controller reliably failed on a dd command during the
first five minutes in his J5000 when fdc flushes were missing.
Going forward, we will now NOT replace the fdc and sync assembler
instructions by NOPS if:
a) the NP iopdir_fdc bit was set by firmware, or
b) we find a CPU up to and including a PCX-W+ (PA8600).
This fixes the HPMC crashes on a C240 and C36XX machines. For other
machines we rely on the firmware to set the bit when needed.
In case one finds HPMC issues, people could try to boot their machines
with the "no-alternatives" kernel option to turn off any alternative
patching.
Reported-by: Sven Schnelle <svens@stackframe.org>
Reported-by: Carlo Pisani <carlojpisani@gmail.com>
Tested-by: Sven Schnelle <svens@stackframe.org>
Fixes: 3847dab77421 ("parisc: Add alternative coding infrastructure")
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 5.0+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/kernel/alternative.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/parisc/kernel/alternative.c
+++ b/arch/parisc/kernel/alternative.c
@@ -56,7 +56,8 @@ void __init_or_module apply_alternatives
* time IO-PDIR is changed in Ike/Astro.
*/
if ((cond & ALT_COND_NO_IOC_FDC) &&
- (boot_cpu_data.pdc.capabilities & PDC_MODEL_IOPDIR_FDC))
+ ((boot_cpu_data.cpu_type <= pcxw_) ||
+ (boot_cpu_data.pdc.capabilities & PDC_MODEL_IOPDIR_FDC)))
continue;
/* Want to replace pdtlb by a pdtlb,l instruction? */
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 27/70] SUNRPC fix regression in umount of a secure mount
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 26/70] parisc: Fix crash due alternative coding for NP iopdir_fdc bit Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 28/70] SUNRPC: Fix a use after free when a server rejects the RPCSEC_GSS credential Greg Kroah-Hartman
` (47 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Olga Kornievskaia, Anna Schumaker
From: Olga Kornievskaia <kolga@netapp.com>
commit ec6017d9035986a36de064f48a63245930bfad6f upstream.
If call_status returns ENOTCONN, we need to re-establish the connection
state after. Otherwise the client goes into an infinite loop of call_encode,
call_transmit, call_status (ENOTCONN), call_encode.
Fixes: c8485e4d63 ("SUNRPC: Handle ECONNREFUSED correctly in xprt_transmit()")
Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Cc: stable@vger.kernel.org # v2.6.29+
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sunrpc/clnt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -2260,13 +2260,13 @@ call_status(struct rpc_task *task)
case -ECONNREFUSED:
case -ECONNRESET:
case -ECONNABORTED:
+ case -ENOTCONN:
rpc_force_rebind(clnt);
/* fall through */
case -EADDRINUSE:
rpc_delay(task, 3*HZ);
/* fall through */
case -EPIPE:
- case -ENOTCONN:
case -EAGAIN:
break;
case -EIO:
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 28/70] SUNRPC: Fix a use after free when a server rejects the RPCSEC_GSS credential
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 27/70] SUNRPC fix regression in umount of a secure mount Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 29/70] NFSv4.1: Again fix a race where CB_NOTIFY_LOCK fails to wake a waiter Greg Kroah-Hartman
` (46 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Olga Kornievskaia, Nick Bowler,
Trond Myklebust, Anna Schumaker
From: Trond Myklebust <trond.myklebust@hammerspace.com>
commit 7987b694ade8cc465ce10fb3dceaa614f13ceaf3 upstream.
The addition of rpc_check_timeout() to call_decode causes an Oops
when the RPCSEC_GSS credential is rejected.
The reason is that rpc_decode_header() will call xprt_release() in
order to free task->tk_rqstp, which is needed by rpc_check_timeout()
to check whether or not we should exit due to a soft timeout.
The fix is to move the call to xprt_release() into call_decode() so
we can perform it after rpc_check_timeout().
Reported-by: Olga Kornievskaia <olga.kornievskaia@gmail.com>
Reported-by: Nick Bowler <nbowler@draconx.ca>
Fixes: cea57789e408 ("SUNRPC: Clean up")
Cc: stable@vger.kernel.org # v5.1+
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sunrpc/clnt.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -2387,17 +2387,21 @@ call_decode(struct rpc_task *task)
return;
case -EAGAIN:
task->tk_status = 0;
- /* Note: rpc_decode_header() may have freed the RPC slot */
- if (task->tk_rqstp == req) {
- xdr_free_bvec(&req->rq_rcv_buf);
- req->rq_reply_bytes_recvd = 0;
- req->rq_rcv_buf.len = 0;
- if (task->tk_client->cl_discrtry)
- xprt_conditional_disconnect(req->rq_xprt,
- req->rq_connect_cookie);
- }
+ xdr_free_bvec(&req->rq_rcv_buf);
+ req->rq_reply_bytes_recvd = 0;
+ req->rq_rcv_buf.len = 0;
+ if (task->tk_client->cl_discrtry)
+ xprt_conditional_disconnect(req->rq_xprt,
+ req->rq_connect_cookie);
task->tk_action = call_encode;
rpc_check_timeout(task);
+ break;
+ case -EKEYREJECTED:
+ task->tk_action = call_reserve;
+ rpc_check_timeout(task);
+ rpcauth_invalcred(task);
+ /* Ensure we obtain a new XID if we retry! */
+ xprt_release(task);
}
}
@@ -2533,11 +2537,7 @@ out_msg_denied:
break;
task->tk_cred_retry--;
trace_rpc__stale_creds(task);
- rpcauth_invalcred(task);
- /* Ensure we obtain a new XID! */
- xprt_release(task);
- task->tk_action = call_reserve;
- return -EAGAIN;
+ return -EKEYREJECTED;
case rpc_autherr_badcred:
case rpc_autherr_badverf:
/* possibly garbled cred/verf? */
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 29/70] NFSv4.1: Again fix a race where CB_NOTIFY_LOCK fails to wake a waiter
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 28/70] SUNRPC: Fix a use after free when a server rejects the RPCSEC_GSS credential Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 30/70] NFSv4.1: Fix bug only first CB_NOTIFY_LOCK is handled Greg Kroah-Hartman
` (45 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yihao Wu, Jeff Layton, Anna Schumaker
From: Yihao Wu <wuyihao@linux.alibaba.com>
commit 52b042ab9948cc367b61f9ca9c18603aa7813c3a upstream.
Commit b7dbcc0e433f "NFSv4.1: Fix a race where CB_NOTIFY_LOCK fails to wake a waiter"
found this bug. However it didn't fix it.
This commit replaces schedule_timeout() with wait_woken() and
default_wake_function() with woken_wake_function() in function
nfs4_retry_setlk() and nfs4_wake_lock_waiter(). wait_woken() uses
memory barriers in its implementation to avoid potential race condition
when putting a process into sleeping state and then waking it up.
Fixes: a1d617d8f134 ("nfs: allow blocking locks to be awoken by lock callbacks")
Cc: stable@vger.kernel.org #4.9+
Signed-off-by: Yihao Wu <wuyihao@linux.alibaba.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfs/nfs4proc.c | 24 +++++++-----------------
1 file changed, 7 insertions(+), 17 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -6867,7 +6867,6 @@ struct nfs4_lock_waiter {
struct task_struct *task;
struct inode *inode;
struct nfs_lowner *owner;
- bool notified;
};
static int
@@ -6889,13 +6888,13 @@ nfs4_wake_lock_waiter(wait_queue_entry_t
/* Make sure it's for the right inode */
if (nfs_compare_fh(NFS_FH(waiter->inode), &cbnl->cbnl_fh))
return 0;
-
- waiter->notified = true;
}
/* override "private" so we can use default_wake_function */
wait->private = waiter->task;
- ret = autoremove_wake_function(wait, mode, flags, key);
+ ret = woken_wake_function(wait, mode, flags, key);
+ if (ret)
+ list_del_init(&wait->entry);
wait->private = waiter;
return ret;
}
@@ -6904,7 +6903,6 @@ static int
nfs4_retry_setlk(struct nfs4_state *state, int cmd, struct file_lock *request)
{
int status = -ERESTARTSYS;
- unsigned long flags;
struct nfs4_lock_state *lsp = request->fl_u.nfs4_fl.owner;
struct nfs_server *server = NFS_SERVER(state->inode);
struct nfs_client *clp = server->nfs_client;
@@ -6914,8 +6912,7 @@ nfs4_retry_setlk(struct nfs4_state *stat
.s_dev = server->s_dev };
struct nfs4_lock_waiter waiter = { .task = current,
.inode = state->inode,
- .owner = &owner,
- .notified = false };
+ .owner = &owner};
wait_queue_entry_t wait;
/* Don't bother with waitqueue if we don't expect a callback */
@@ -6928,21 +6925,14 @@ nfs4_retry_setlk(struct nfs4_state *stat
add_wait_queue(q, &wait);
while(!signalled()) {
- waiter.notified = false;
status = nfs4_proc_setlk(state, cmd, request);
if ((status != -EAGAIN) || IS_SETLK(cmd))
break;
status = -ERESTARTSYS;
- spin_lock_irqsave(&q->lock, flags);
- if (waiter.notified) {
- spin_unlock_irqrestore(&q->lock, flags);
- continue;
- }
- set_current_state(TASK_INTERRUPTIBLE);
- spin_unlock_irqrestore(&q->lock, flags);
-
- freezable_schedule_timeout(NFS4_LOCK_MAXTIMEOUT);
+ freezer_do_not_count();
+ wait_woken(&wait, TASK_INTERRUPTIBLE, NFS4_LOCK_MAXTIMEOUT);
+ freezer_count();
}
finish_wait(q, &wait);
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 30/70] NFSv4.1: Fix bug only first CB_NOTIFY_LOCK is handled
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 29/70] NFSv4.1: Again fix a race where CB_NOTIFY_LOCK fails to wake a waiter Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 31/70] fuse: fallocate: fix return with locked inode Greg Kroah-Hartman
` (44 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yihao Wu, Jeff Layton, Anna Schumaker
From: Yihao Wu <wuyihao@linux.alibaba.com>
commit ba851a39c9703f09684a541885ed176f8fb7c868 upstream.
When a waiter is waked by CB_NOTIFY_LOCK, it will retry
nfs4_proc_setlk(). The waiter may fail to nfs4_proc_setlk() and sleep
again. However, the waiter is already removed from clp->cl_lock_waitq
when handling CB_NOTIFY_LOCK in nfs4_wake_lock_waiter(). So any
subsequent CB_NOTIFY_LOCK won't wake this waiter anymore. We should
put the waiter back to clp->cl_lock_waitq before retrying.
Cc: stable@vger.kernel.org #4.9+
Signed-off-by: Yihao Wu <wuyihao@linux.alibaba.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfs/nfs4proc.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -6922,20 +6922,22 @@ nfs4_retry_setlk(struct nfs4_state *stat
init_wait(&wait);
wait.private = &waiter;
wait.func = nfs4_wake_lock_waiter;
- add_wait_queue(q, &wait);
while(!signalled()) {
+ add_wait_queue(q, &wait);
status = nfs4_proc_setlk(state, cmd, request);
- if ((status != -EAGAIN) || IS_SETLK(cmd))
+ if ((status != -EAGAIN) || IS_SETLK(cmd)) {
+ finish_wait(q, &wait);
break;
+ }
status = -ERESTARTSYS;
freezer_do_not_count();
wait_woken(&wait, TASK_INTERRUPTIBLE, NFS4_LOCK_MAXTIMEOUT);
freezer_count();
+ finish_wait(q, &wait);
}
- finish_wait(q, &wait);
return status;
}
#else /* !CONFIG_NFS_V4_1 */
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 31/70] fuse: fallocate: fix return with locked inode
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 30/70] NFSv4.1: Fix bug only first CB_NOTIFY_LOCK is handled Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 32/70] fuse: fix copy_file_range() in the writeback case Greg Kroah-Hartman
` (43 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, kbuild test robot, Dan Carpenter,
Liu Bo, Miklos Szeredi
From: Miklos Szeredi <mszeredi@redhat.com>
commit 35d6fcbb7c3e296a52136347346a698a35af3fda upstream.
Do the proper cleanup in case the size check fails.
Tested with xfstests:generic/228
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 0cbade024ba5 ("fuse: honor RLIMIT_FSIZE in fuse_file_fallocate")
Cc: Liu Bo <bo.liu@linux.alibaba.com>
Cc: <stable@vger.kernel.org> # v3.5
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/fuse/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -3050,7 +3050,7 @@ static long fuse_file_fallocate(struct f
offset + length > i_size_read(inode)) {
err = inode_newsize_ok(inode, offset + length);
if (err)
- return err;
+ goto out;
}
if (!(mode & FALLOC_FL_KEEP_SIZE))
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 32/70] fuse: fix copy_file_range() in the writeback case
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 31/70] fuse: fallocate: fix return with locked inode Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 33/70] pstore: Set tfm to NULL on free_buf_for_compression Greg Kroah-Hartman
` (42 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Miklos Szeredi
From: Miklos Szeredi <mszeredi@redhat.com>
commit a2bc92362941006830afa3dfad6caec1f99acbf5 upstream.
Prior to sending COPY_FILE_RANGE to userspace filesystem, we must flush all
dirty pages in both the source and destination files.
This patch adds the missing flush of the source file.
Tested on libfuse-3.5.0 with:
libfuse/example/passthrough_ll /mnt/fuse/ -o writeback
libfuse/test/test_syscalls /mnt/fuse/tmp/test
Fixes: 88bc7d5097a1 ("fuse: add support for copy_file_range()")
Cc: <stable@vger.kernel.org> # v4.20
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/fuse/file.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -3098,6 +3098,7 @@ static ssize_t fuse_copy_file_range(stru
{
struct fuse_file *ff_in = file_in->private_data;
struct fuse_file *ff_out = file_out->private_data;
+ struct inode *inode_in = file_inode(file_in);
struct inode *inode_out = file_inode(file_out);
struct fuse_inode *fi_out = get_fuse_inode(inode_out);
struct fuse_conn *fc = ff_in->fc;
@@ -3121,6 +3122,17 @@ static ssize_t fuse_copy_file_range(stru
if (fc->no_copy_file_range)
return -EOPNOTSUPP;
+ if (fc->writeback_cache) {
+ inode_lock(inode_in);
+ err = filemap_write_and_wait_range(inode_in->i_mapping,
+ pos_in, pos_in + len);
+ if (!err)
+ fuse_sync_writes(inode_in);
+ inode_unlock(inode_in);
+ if (err)
+ return err;
+ }
+
inode_lock(inode_out);
if (fc->writeback_cache) {
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 33/70] pstore: Set tfm to NULL on free_buf_for_compression
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 32/70] fuse: fix copy_file_range() in the writeback case Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 34/70] pstore/ram: Run without kernel crash dump region Greg Kroah-Hartman
` (41 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pi-Hsun Shih, Kees Cook
From: Pi-Hsun Shih <pihsun@chromium.org>
commit a9fb94a99bb515d8720ba8440ce3aba84aec80f8 upstream.
Set tfm to NULL on free_buf_for_compression() after crypto_free_comp().
This avoid a use-after-free when allocate_buf_for_compression()
and free_buf_for_compression() are called twice. Although
free_buf_for_compression() freed the tfm, allocate_buf_for_compression()
won't reinitialize the tfm since the tfm pointer is not NULL.
Fixes: 95047b0519c1 ("pstore: Refactor compression initialization")
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/pstore/platform.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -347,8 +347,10 @@ static void allocate_buf_for_compression
static void free_buf_for_compression(void)
{
- if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && tfm)
+ if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && tfm) {
crypto_free_comp(tfm);
+ tfm = NULL;
+ }
kfree(big_oops_buf);
big_oops_buf = NULL;
big_oops_buf_sz = 0;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 34/70] pstore/ram: Run without kernel crash dump region
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 33/70] pstore: Set tfm to NULL on free_buf_for_compression Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 35/70] kbuild: use more portable command -v for cc-cross-prefix Greg Kroah-Hartman
` (40 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kees Cook, Yaro Slav
From: Kees Cook <keescook@chromium.org>
commit 8880fa32c557600f5f624084152668ed3c2ea51e upstream.
The ram pstore backend has always had the crash dumper frontend enabled
unconditionally. However, it was possible to effectively disable it
by setting a record_size=0. All the machinery would run (storing dumps
to the temporary crash buffer), but 0 bytes would ultimately get stored
due to there being no przs allocated for dumps. Commit 89d328f637b9
("pstore/ram: Correctly calculate usable PRZ bytes"), however, assumed
that there would always be at least one allocated dprz for calculating
the size of the temporary crash buffer. This was, of course, not the
case when record_size=0, and would lead to a NULL deref trying to find
the dprz buffer size:
BUG: unable to handle kernel NULL pointer dereference at (null)
...
IP: ramoops_probe+0x285/0x37e (fs/pstore/ram.c:808)
cxt->pstore.bufsize = cxt->dprzs[0]->buffer_size;
Instead, we need to only enable the frontends based on the success of the
prz initialization and only take the needed actions when those zones are
available. (This also fixes a possible error in detecting if the ftrace
frontend should be enabled.)
Reported-and-tested-by: Yaro Slav <yaro330@gmail.com>
Fixes: 89d328f637b9 ("pstore/ram: Correctly calculate usable PRZ bytes")
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/pstore/platform.c | 3 ++-
fs/pstore/ram.c | 36 +++++++++++++++++++++++-------------
2 files changed, 25 insertions(+), 14 deletions(-)
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -608,7 +608,8 @@ int pstore_register(struct pstore_info *
return -EINVAL;
}
- allocate_buf_for_compression();
+ if (psi->flags & PSTORE_FLAGS_DMESG)
+ allocate_buf_for_compression();
if (pstore_is_mounted())
pstore_get_records(0);
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -800,26 +800,36 @@ static int ramoops_probe(struct platform
cxt->pstore.data = cxt;
/*
- * Since bufsize is only used for dmesg crash dumps, it
- * must match the size of the dprz record (after PRZ header
- * and ECC bytes have been accounted for).
+ * Prepare frontend flags based on which areas are initialized.
+ * For ramoops_init_przs() cases, the "max count" variable tells
+ * if there are regions present. For ramoops_init_prz() cases,
+ * the single region size is how to check.
*/
- cxt->pstore.bufsize = cxt->dprzs[0]->buffer_size;
- cxt->pstore.buf = kzalloc(cxt->pstore.bufsize, GFP_KERNEL);
- if (!cxt->pstore.buf) {
- pr_err("cannot allocate pstore crash dump buffer\n");
- err = -ENOMEM;
- goto fail_clear;
- }
-
- cxt->pstore.flags = PSTORE_FLAGS_DMESG;
+ cxt->pstore.flags = 0;
+ if (cxt->max_dump_cnt)
+ cxt->pstore.flags |= PSTORE_FLAGS_DMESG;
if (cxt->console_size)
cxt->pstore.flags |= PSTORE_FLAGS_CONSOLE;
- if (cxt->ftrace_size)
+ if (cxt->max_ftrace_cnt)
cxt->pstore.flags |= PSTORE_FLAGS_FTRACE;
if (cxt->pmsg_size)
cxt->pstore.flags |= PSTORE_FLAGS_PMSG;
+ /*
+ * Since bufsize is only used for dmesg crash dumps, it
+ * must match the size of the dprz record (after PRZ header
+ * and ECC bytes have been accounted for).
+ */
+ if (cxt->pstore.flags & PSTORE_FLAGS_DMESG) {
+ cxt->pstore.bufsize = cxt->dprzs[0]->buffer_size;
+ cxt->pstore.buf = kzalloc(cxt->pstore.bufsize, GFP_KERNEL);
+ if (!cxt->pstore.buf) {
+ pr_err("cannot allocate pstore crash dump buffer\n");
+ err = -ENOMEM;
+ goto fail_clear;
+ }
+ }
+
err = pstore_register(&cxt->pstore);
if (err) {
pr_err("registering with pstore failed\n");
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 35/70] kbuild: use more portable command -v for cc-cross-prefix
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 34/70] pstore/ram: Run without kernel crash dump region Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 36/70] memstick: mspro_block: Fix an error code in mspro_block_issue_req() Greg Kroah-Hartman
` (39 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alexey Brodkin, Masahiro Yamada
From: Masahiro Yamada <yamada.masahiro@socionext.com>
commit 913ab9780fc021298949cc5514d6255a008e69f9 upstream.
To print the pathname that will be used by shell in the current
environment, 'command -v' is a standardized way. [1]
'which' is also often used in scripts, but it is less portable.
When I worked on commit bd55f96fa9fc ("kbuild: refactor cc-cross-prefix
implementation"), I was eager to use 'command -v' but it did not work.
(The reason is explained below.)
I kept 'which' as before but got rid of '> /dev/null 2>&1' as I
thought it was no longer needed. Sorry, I was wrong.
It works well on my Ubuntu machine, but Alexey Brodkin reports noisy
warnings on CentOS7 when 'which' fails to find the given command in
the PATH environment.
$ which foo
which: no foo in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
Given that behavior of 'which' depends on system (and it may not be
installed by default), I want to try 'command -v' once again.
The specification [1] clearly describes the behavior of 'command -v'
when the given command is not found:
Otherwise, no output shall be written and the exit status shall reflect
that the name was not found.
However, we need a little magic to use 'command -v' from Make.
$(shell ...) passes the argument to a subshell for execution, and
returns the standard output of the command.
Here is a trick. GNU Make may optimize this by executing the command
directly instead of forking a subshell, if no shell special characters
are found in the command and omitting the subshell will not change the
behavior.
In this case, no shell special character is used. So, Make will try
to run it directly. However, 'command' is a shell-builtin command,
then Make would fail to find it in the PATH environment:
$ make ARCH=m68k defconfig
make: command: Command not found
make: command: Command not found
make: command: Command not found
In fact, Make has a table of shell-builtin commands because it must
ask the shell to execute them.
Until recently, 'command' was missing in the table.
This issue was fixed by the following commit:
| commit 1af314465e5dfe3e8baa839a32a72e83c04f26ef
| Author: Paul Smith <psmith@gnu.org>
| Date: Sun Nov 12 18:10:28 2017 -0500
|
| * job.c: Add "command" as a known shell built-in.
|
| This is not a POSIX shell built-in but it's common in UNIX shells.
| Reported by Nick Bowler <nbowler@draconx.ca>.
Because the latest release is GNU Make 4.2.1 in 2016, this commit is
not included in any released versions. (But some distributions may
have back-ported it.)
We need to trick Make to spawn a subshell. There are various ways to
do so:
1) Use a shell special character '~' as dummy
$(shell : ~; command -v $(c)gcc)
2) Use a variable reference that always expands to the empty string
(suggested by David Laight)
$(shell command$${x:+} -v $(c)gcc)
3) Use redirect
$(shell command -v $(c)gcc 2>/dev/null)
I chose 3) to not confuse people. The stderr would not be polluted
anyway, but it will provide extra safety, and is easy to understand.
Tested on Make 3.81, 3.82, 4.0, 4.1, 4.2, 4.2.1
[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html
Fixes: bd55f96fa9fc ("kbuild: refactor cc-cross-prefix implementation")
Cc: linux-stable <stable@vger.kernel.org> # 5.1
Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
scripts/Kbuild.include | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -73,8 +73,13 @@ endef
# Usage: CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu- m68k-linux-)
# Return first <prefix> where a <prefix>gcc is found in PATH.
# If no gcc found in PATH with listed prefixes return nothing
+#
+# Note: '2>/dev/null' is here to force Make to invoke a shell. Otherwise, it
+# would try to directly execute the shell builtin 'command'. This workaround
+# should be kept for a long time since this issue was fixed only after the
+# GNU Make 4.2.1 release.
cc-cross-prefix = $(firstword $(foreach c, $(filter-out -%, $(1)), \
- $(if $(shell which $(c)gcc), $(c))))
+ $(if $(shell command -v $(c)gcc 2>/dev/null), $(c))))
# output directory for tests below
TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/)
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 36/70] memstick: mspro_block: Fix an error code in mspro_block_issue_req()
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 35/70] kbuild: use more portable command -v for cc-cross-prefix Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 37/70] mmc: tmio: fix SCC error handling to avoid false positive CRC error Greg Kroah-Hartman
` (38 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Ulf Hansson
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 61009f82a93f7c0b33cd9b3b263a6ab48f8b49d4 upstream.
We accidentally changed the error code from -EAGAIN to 1 when we did the
blk-mq conversion.
Maybe a contributing factor to this mistake is that it wasn't obvious
that the "while (chunk) {" condition is always true. I have cleaned
that up as well.
Fixes: d0be12274dad ("mspro_block: convert to blk-mq")
Cc: stable@vger.kernel.org
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/memstick/core/mspro_block.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- a/drivers/memstick/core/mspro_block.c
+++ b/drivers/memstick/core/mspro_block.c
@@ -694,13 +694,13 @@ static void h_mspro_block_setup_cmd(stru
/*** Data transfer ***/
-static int mspro_block_issue_req(struct memstick_dev *card, bool chunk)
+static int mspro_block_issue_req(struct memstick_dev *card)
{
struct mspro_block_data *msb = memstick_get_drvdata(card);
u64 t_off;
unsigned int count;
- while (chunk) {
+ while (true) {
msb->current_page = 0;
msb->current_seg = 0;
msb->seg_count = blk_rq_map_sg(msb->block_req->q,
@@ -709,6 +709,7 @@ static int mspro_block_issue_req(struct
if (!msb->seg_count) {
unsigned int bytes = blk_rq_cur_bytes(msb->block_req);
+ bool chunk;
chunk = blk_update_request(msb->block_req,
BLK_STS_RESOURCE,
@@ -718,7 +719,7 @@ static int mspro_block_issue_req(struct
__blk_mq_end_request(msb->block_req,
BLK_STS_RESOURCE);
msb->block_req = NULL;
- break;
+ return -EAGAIN;
}
t_off = blk_rq_pos(msb->block_req);
@@ -735,8 +736,6 @@ static int mspro_block_issue_req(struct
memstick_new_req(card->host);
return 0;
}
-
- return 1;
}
static int mspro_block_complete_req(struct memstick_dev *card, int error)
@@ -779,7 +778,7 @@ static int mspro_block_complete_req(stru
chunk = blk_update_request(msb->block_req,
errno_to_blk_status(error), t_len);
if (chunk) {
- error = mspro_block_issue_req(card, chunk);
+ error = mspro_block_issue_req(card);
if (!error)
goto out;
} else {
@@ -849,7 +848,7 @@ static blk_status_t mspro_queue_rq(struc
msb->block_req = bd->rq;
blk_mq_start_request(bd->rq);
- if (mspro_block_issue_req(card, true))
+ if (mspro_block_issue_req(card))
msb->block_req = NULL;
spin_unlock_irq(&msb->q_lock);
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 37/70] mmc: tmio: fix SCC error handling to avoid false positive CRC error
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 36/70] memstick: mspro_block: Fix an error code in mspro_block_issue_req() Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 38/70] mmc: sdhci_am654: Fix SLOTTYPE write Greg Kroah-Hartman
` (37 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Takeshi Saito, Wolfram Sang,
Simon Horman, Yoshihiro Shimoda, Ulf Hansson
From: Takeshi Saito <takeshi.saito.xv@renesas.com>
commit 51b72656bb39fdcb8f3174f4007bcc83ad1d275f upstream.
If an SCC error occurs during a read/write command execution, a false
positive CRC error message is output.
mmcblk0: response CRC error sending r/w cmd command, card status 0x900
check_scc_error() checks SCC_RVSREQ.RVSERR bit. RVSERR detects a
correction error in the next (up or down) delay tap position. However,
since the command is successful, only retuning needs to be executed.
This has been confirmed by HW engineers.
Thus, on SCC error, set retuning flag instead of setting an error code.
Fixes: b85fb0a1c8ae ("mmc: tmio: Fix SCC error detection")
Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com>
[wsa: updated comment and commit message, removed some braces]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/tmio_mmc_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -842,8 +842,9 @@ static void tmio_mmc_finish_request(stru
if (mrq->cmd->error || (mrq->data && mrq->data->error))
tmio_mmc_abort_dma(host);
+ /* SCC error means retune, but executed command was still successful */
if (host->check_scc_error && host->check_scc_error(host))
- mrq->cmd->error = -EILSEQ;
+ mmc_retune_needed(host->mmc);
/* If SET_BLOCK_COUNT, continue with main command */
if (host->mrq && !mrq->cmd->error) {
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 38/70] mmc: sdhci_am654: Fix SLOTTYPE write
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 37/70] mmc: tmio: fix SCC error handling to avoid false positive CRC error Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 39/70] x86/power: Fix nosmt vs hibernation triple fault during resume Greg Kroah-Hartman
` (36 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Faiz Abbas, Ulf Hansson
From: Faiz Abbas <faiz_abbas@ti.com>
commit 7397993145872c74871ab2aa7fa26a427144088a upstream.
In the call to regmap_update_bits() for SLOTTYPE, the mask and value
fields are exchanged. Fix this.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Fixes: 41fd4caeb00b ("mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci_am654.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mmc/host/sdhci_am654.c
+++ b/drivers/mmc/host/sdhci_am654.c
@@ -209,7 +209,7 @@ static int sdhci_am654_init(struct sdhci
ctl_cfg_2 = SLOTTYPE_EMBEDDED;
regmap_update_bits(sdhci_am654->base, CTL_CFG_2,
- ctl_cfg_2, SLOTTYPE_MASK);
+ SLOTTYPE_MASK, ctl_cfg_2);
return sdhci_add_host(host);
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 39/70] x86/power: Fix nosmt vs hibernation triple fault during resume
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 38/70] mmc: sdhci_am654: Fix SLOTTYPE write Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 40/70] x86/insn-eval: Fix use-after-free access to LDT entry Greg Kroah-Hartman
` (35 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiri Kosina, Pavel Machek,
Thomas Gleixner, Josh Poimboeuf, Rafael J. Wysocki
From: Jiri Kosina <jkosina@suse.cz>
commit ec527c318036a65a083ef68d8ba95789d2212246 upstream.
As explained in
0cc3cd21657b ("cpu/hotplug: Boot HT siblings at least once")
we always, no matter what, have to bring up x86 HT siblings during boot at
least once in order to avoid first MCE bringing the system to its knees.
That means that whenever 'nosmt' is supplied on the kernel command-line,
all the HT siblings are as a result sitting in mwait or cpudile after
going through the online-offline cycle at least once.
This causes a serious issue though when a kernel, which saw 'nosmt' on its
commandline, is going to perform resume from hibernation: if the resume
from the hibernated image is successful, cr3 is flipped in order to point
to the address space of the kernel that is being resumed, which in turn
means that all the HT siblings are all of a sudden mwaiting on address
which is no longer valid.
That results in triple fault shortly after cr3 is switched, and machine
reboots.
Fix this by always waking up all the SMT siblings before initiating the
'restore from hibernation' process; this guarantees that all the HT
siblings will be properly carried over to the resumed kernel waiting in
resume_play_dead(), and acted upon accordingly afterwards, based on the
target kernel configuration.
Symmetricaly, the resumed kernel has to push the SMT siblings to mwait
again in case it has SMT disabled; this means it has to online all
the siblings when resuming (so that they come out of hlt) and offline
them again to let them reach mwait.
Cc: 4.19+ <stable@vger.kernel.org> # v4.19+
Debugged-by: Thomas Gleixner <tglx@linutronix.de>
Fixes: 0cc3cd21657b ("cpu/hotplug: Boot HT siblings at least once")
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/power/cpu.c | 10 ++++++++++
arch/x86/power/hibernate.c | 33 +++++++++++++++++++++++++++++++++
include/linux/cpu.h | 4 ++++
kernel/cpu.c | 4 ++--
kernel/power/hibernate.c | 9 +++++++++
5 files changed, 58 insertions(+), 2 deletions(-)
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -299,7 +299,17 @@ int hibernate_resume_nonboot_cpu_disable
* address in its instruction pointer may not be possible to resolve
* any more at that point (the page tables used by it previously may
* have been overwritten by hibernate image data).
+ *
+ * First, make sure that we wake up all the potentially disabled SMT
+ * threads which have been initially brought up and then put into
+ * mwait/cpuidle sleep.
+ * Those will be put to proper (not interfering with hibernation
+ * resume) sleep afterwards, and the resumed kernel will decide itself
+ * what to do with them.
*/
+ ret = cpuhp_smt_enable();
+ if (ret)
+ return ret;
smp_ops.play_dead = resume_play_dead;
ret = disable_nonboot_cpus();
smp_ops.play_dead = play_dead;
--- a/arch/x86/power/hibernate.c
+++ b/arch/x86/power/hibernate.c
@@ -11,6 +11,7 @@
#include <linux/suspend.h>
#include <linux/scatterlist.h>
#include <linux/kdebug.h>
+#include <linux/cpu.h>
#include <crypto/hash.h>
@@ -246,3 +247,35 @@ out:
__flush_tlb_all();
return 0;
}
+
+int arch_resume_nosmt(void)
+{
+ int ret = 0;
+ /*
+ * We reached this while coming out of hibernation. This means
+ * that SMT siblings are sleeping in hlt, as mwait is not safe
+ * against control transition during resume (see comment in
+ * hibernate_resume_nonboot_cpu_disable()).
+ *
+ * If the resumed kernel has SMT disabled, we have to take all the
+ * SMT siblings out of hlt, and offline them again so that they
+ * end up in mwait proper.
+ *
+ * Called with hotplug disabled.
+ */
+ cpu_hotplug_enable();
+ if (cpu_smt_control == CPU_SMT_DISABLED ||
+ cpu_smt_control == CPU_SMT_FORCE_DISABLED) {
+ enum cpuhp_smt_control old = cpu_smt_control;
+
+ ret = cpuhp_smt_enable();
+ if (ret)
+ goto out;
+ ret = cpuhp_smt_disable(old);
+ if (ret)
+ goto out;
+ }
+out:
+ cpu_hotplug_disable();
+ return ret;
+}
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -183,10 +183,14 @@ enum cpuhp_smt_control {
extern enum cpuhp_smt_control cpu_smt_control;
extern void cpu_smt_disable(bool force);
extern void cpu_smt_check_topology(void);
+extern int cpuhp_smt_enable(void);
+extern int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval);
#else
# define cpu_smt_control (CPU_SMT_ENABLED)
static inline void cpu_smt_disable(bool force) { }
static inline void cpu_smt_check_topology(void) { }
+static inline int cpuhp_smt_enable(void) { return 0; }
+static inline int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval) { return 0; }
#endif
/*
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2064,7 +2064,7 @@ static void cpuhp_online_cpu_device(unsi
kobject_uevent(&dev->kobj, KOBJ_ONLINE);
}
-static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
+int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
{
int cpu, ret = 0;
@@ -2096,7 +2096,7 @@ static int cpuhp_smt_disable(enum cpuhp_
return ret;
}
-static int cpuhp_smt_enable(void)
+int cpuhp_smt_enable(void)
{
int cpu, ret = 0;
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -258,6 +258,11 @@ void swsusp_show_speed(ktime_t start, kt
(kps % 1000) / 10);
}
+__weak int arch_resume_nosmt(void)
+{
+ return 0;
+}
+
/**
* create_image - Create a hibernation image.
* @platform_mode: Whether or not to use the platform driver.
@@ -325,6 +330,10 @@ static int create_image(int platform_mod
Enable_cpus:
enable_nonboot_cpus();
+ /* Allow architectures to do nosmt-specific post-resume dances */
+ if (!in_suspend)
+ error = arch_resume_nosmt();
+
Platform_finish:
platform_finish(platform_mode);
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 40/70] x86/insn-eval: Fix use-after-free access to LDT entry
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 39/70] x86/power: Fix nosmt vs hibernation triple fault during resume Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 41/70] i2c: xiic: Add max_read_len quirk Greg Kroah-Hartman
` (34 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jann Horn, Linus Torvalds
From: Jann Horn <jannh@google.com>
commit de9f869616dd95e95c00bdd6b0fcd3421e8a4323 upstream.
get_desc() computes a pointer into the LDT while holding a lock that
protects the LDT from being freed, but then drops the lock and returns the
(now potentially dangling) pointer to its caller.
Fix it by giving the caller a copy of the LDT entry instead.
Fixes: 670f928ba09b ("x86/insn-eval: Add utility function to get segment descriptor")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/lib/insn-eval.c | 47 ++++++++++++++++++++++++-----------------------
1 file changed, 24 insertions(+), 23 deletions(-)
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
@@ -557,7 +557,8 @@ static int get_reg_offset_16(struct insn
}
/**
- * get_desc() - Obtain pointer to a segment descriptor
+ * get_desc() - Obtain contents of a segment descriptor
+ * @out: Segment descriptor contents on success
* @sel: Segment selector
*
* Given a segment selector, obtain a pointer to the segment descriptor.
@@ -565,18 +566,18 @@ static int get_reg_offset_16(struct insn
*
* Returns:
*
- * Pointer to segment descriptor on success.
+ * True on success, false on failure.
*
* NULL on error.
*/
-static struct desc_struct *get_desc(unsigned short sel)
+static bool get_desc(struct desc_struct *out, unsigned short sel)
{
struct desc_ptr gdt_desc = {0, 0};
unsigned long desc_base;
#ifdef CONFIG_MODIFY_LDT_SYSCALL
if ((sel & SEGMENT_TI_MASK) == SEGMENT_LDT) {
- struct desc_struct *desc = NULL;
+ bool success = false;
struct ldt_struct *ldt;
/* Bits [15:3] contain the index of the desired entry. */
@@ -584,12 +585,14 @@ static struct desc_struct *get_desc(unsi
mutex_lock(¤t->active_mm->context.lock);
ldt = current->active_mm->context.ldt;
- if (ldt && sel < ldt->nr_entries)
- desc = &ldt->entries[sel];
+ if (ldt && sel < ldt->nr_entries) {
+ *out = ldt->entries[sel];
+ success = true;
+ }
mutex_unlock(¤t->active_mm->context.lock);
- return desc;
+ return success;
}
#endif
native_store_gdt(&gdt_desc);
@@ -604,9 +607,10 @@ static struct desc_struct *get_desc(unsi
desc_base = sel & ~(SEGMENT_RPL_MASK | SEGMENT_TI_MASK);
if (desc_base > gdt_desc.size)
- return NULL;
+ return false;
- return (struct desc_struct *)(gdt_desc.address + desc_base);
+ *out = *(struct desc_struct *)(gdt_desc.address + desc_base);
+ return true;
}
/**
@@ -628,7 +632,7 @@ static struct desc_struct *get_desc(unsi
*/
unsigned long insn_get_seg_base(struct pt_regs *regs, int seg_reg_idx)
{
- struct desc_struct *desc;
+ struct desc_struct desc;
short sel;
sel = get_segment_selector(regs, seg_reg_idx);
@@ -666,11 +670,10 @@ unsigned long insn_get_seg_base(struct p
if (!sel)
return -1L;
- desc = get_desc(sel);
- if (!desc)
+ if (!get_desc(&desc, sel))
return -1L;
- return get_desc_base(desc);
+ return get_desc_base(&desc);
}
/**
@@ -692,7 +695,7 @@ unsigned long insn_get_seg_base(struct p
*/
static unsigned long get_seg_limit(struct pt_regs *regs, int seg_reg_idx)
{
- struct desc_struct *desc;
+ struct desc_struct desc;
unsigned long limit;
short sel;
@@ -706,8 +709,7 @@ static unsigned long get_seg_limit(struc
if (!sel)
return 0;
- desc = get_desc(sel);
- if (!desc)
+ if (!get_desc(&desc, sel))
return 0;
/*
@@ -716,8 +718,8 @@ static unsigned long get_seg_limit(struc
* not tested when checking the segment limits. In practice,
* this means that the segment ends in (limit << 12) + 0xfff.
*/
- limit = get_desc_limit(desc);
- if (desc->g)
+ limit = get_desc_limit(&desc);
+ if (desc.g)
limit = (limit << 12) + 0xfff;
return limit;
@@ -741,7 +743,7 @@ static unsigned long get_seg_limit(struc
*/
int insn_get_code_seg_params(struct pt_regs *regs)
{
- struct desc_struct *desc;
+ struct desc_struct desc;
short sel;
if (v8086_mode(regs))
@@ -752,8 +754,7 @@ int insn_get_code_seg_params(struct pt_r
if (sel < 0)
return sel;
- desc = get_desc(sel);
- if (!desc)
+ if (!get_desc(&desc, sel))
return -EINVAL;
/*
@@ -761,10 +762,10 @@ int insn_get_code_seg_params(struct pt_r
* determines whether a segment contains data or code. If this is a data
* segment, return error.
*/
- if (!(desc->type & BIT(3)))
+ if (!(desc.type & BIT(3)))
return -EINVAL;
- switch ((desc->l << 1) | desc->d) {
+ switch ((desc.l << 1) | desc.d) {
case 0: /*
* Legacy mode. CS.L=0, CS.D=0. Address and operand size are
* both 16-bit.
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 41/70] i2c: xiic: Add max_read_len quirk
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 40/70] x86/insn-eval: Fix use-after-free access to LDT entry Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 42/70] s390/mm: fix address space detection in exception handling Greg Kroah-Hartman
` (33 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Robert Hancock, Michal Simek,
Wolfram Sang, stable
From: Robert Hancock <hancock@sedsystems.ca>
commit 49b809586730a77b57ce620b2f9689de765d790b upstream.
This driver does not support reading more than 255 bytes at once because
the register for storing the number of bytes to read is only 8 bits. Add
a max_read_len quirk to enforce this.
This was found when using this driver with the SFP driver, which was
previously reading all 256 bytes in the SFP EEPROM in one transaction.
This caused a bunch of hard-to-debug errors in the xiic driver since the
driver/logic was treating the number of bytes to read as zero.
Rejecting transactions that aren't supported at least allows the problem
to be diagnosed more easily.
Signed-off-by: Robert Hancock <hancock@sedsystems.ca>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/busses/i2c-xiic.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -718,11 +718,16 @@ static const struct i2c_algorithm xiic_a
.functionality = xiic_func,
};
+static const struct i2c_adapter_quirks xiic_quirks = {
+ .max_read_len = 255,
+};
+
static const struct i2c_adapter xiic_adapter = {
.owner = THIS_MODULE,
.name = DRIVER_NAME,
.class = I2C_CLASS_DEPRECATED,
.algo = &xiic_algorithm,
+ .quirks = &xiic_quirks,
};
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 42/70] s390/mm: fix address space detection in exception handling
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 41/70] i2c: xiic: Add max_read_len quirk Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 43/70] nvme-rdma: fix queue mapping when queue count is limited Greg Kroah-Hartman
` (32 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Janosch Frank, Heiko Carstens,
Gerald Schaefer
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
commit 962f0af83c239c0aef05639631e871c874b00f99 upstream.
Commit 0aaba41b58bc ("s390: remove all code using the access register
mode") removed access register mode from the kernel, and also from the
address space detection logic. However, user space could still switch
to access register mode (trans_exc_code == 1), and exceptions in that
mode would not be correctly assigned.
Fix this by adding a check for trans_exc_code == 1 to get_fault_type(),
and remove the wrong comment line before that function.
Fixes: 0aaba41b58bc ("s390: remove all code using the access register mode")
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: <stable@vger.kernel.org> # v4.15+
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/mm/fault.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -83,7 +83,6 @@ static inline int notify_page_fault(stru
/*
* Find out which address space caused the exception.
- * Access register mode is impossible, ignore space == 3.
*/
static inline enum fault_type get_fault_type(struct pt_regs *regs)
{
@@ -108,6 +107,10 @@ static inline enum fault_type get_fault_
}
return VDSO_FAULT;
}
+ if (trans_exc_code == 1) {
+ /* access register mode, not used in the kernel */
+ return USER_FAULT;
+ }
/* home space exception -> access via kernel ASCE */
return KERNEL_FAULT;
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 43/70] nvme-rdma: fix queue mapping when queue count is limited
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 42/70] s390/mm: fix address space detection in exception handling Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 44/70] xen-blkfront: switch kcalloc to kvcalloc for large array allocation Greg Kroah-Hartman
` (31 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Harris, James R, Max Gurtovoy, Sagi Grimberg
From: Sagi Grimberg <sagi@grimberg.me>
commit 5651cd3c43368873d0787b52acb2e0e08f3c5da4 upstream.
When the controller supports less queues than requested, we
should make sure that queue mapping does the right thing and
not assume that all queues are available. This fixes a crash
when the controller supports less queues than requested.
The rules are:
1. if no write/poll queues are requested, we assign the available queues
to the default queue map. The default and read queue maps share the
existing queues.
2. if write queues are requested:
- first make sure that read queue map gets the requested
nr_io_queues count
- then grant the default queue map the minimum between the requested
nr_write_queues and the remaining queues. If there are no available
queues to dedicate to the default queue map, fallback to (1) and
share all the queues in the existing queue map.
3. if poll queues are requested:
- map the remaining queues to the poll queue map.
Also, provide a log indication on how we constructed the different
queue maps.
Reported-by: Harris, James R <james.r.harris@intel.com>
Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
Tested-by: Jim Harris <james.r.harris@intel.com>
Cc: <stable@vger.kernel.org> # v5.0+
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvme/host/rdma.c | 99 ++++++++++++++++++++++++++++-------------------
1 file changed, 61 insertions(+), 38 deletions(-)
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -641,34 +641,16 @@ static int nvme_rdma_alloc_io_queues(str
{
struct nvmf_ctrl_options *opts = ctrl->ctrl.opts;
struct ib_device *ibdev = ctrl->device->dev;
- unsigned int nr_io_queues;
+ unsigned int nr_io_queues, nr_default_queues;
+ unsigned int nr_read_queues, nr_poll_queues;
int i, ret;
- nr_io_queues = min(opts->nr_io_queues, num_online_cpus());
-
- /*
- * we map queues according to the device irq vectors for
- * optimal locality so we don't need more queues than
- * completion vectors.
- */
- nr_io_queues = min_t(unsigned int, nr_io_queues,
- ibdev->num_comp_vectors);
-
- if (opts->nr_write_queues) {
- ctrl->io_queues[HCTX_TYPE_DEFAULT] =
- min(opts->nr_write_queues, nr_io_queues);
- nr_io_queues += ctrl->io_queues[HCTX_TYPE_DEFAULT];
- } else {
- ctrl->io_queues[HCTX_TYPE_DEFAULT] = nr_io_queues;
- }
-
- ctrl->io_queues[HCTX_TYPE_READ] = nr_io_queues;
-
- if (opts->nr_poll_queues) {
- ctrl->io_queues[HCTX_TYPE_POLL] =
- min(opts->nr_poll_queues, num_online_cpus());
- nr_io_queues += ctrl->io_queues[HCTX_TYPE_POLL];
- }
+ nr_read_queues = min_t(unsigned int, ibdev->num_comp_vectors,
+ min(opts->nr_io_queues, num_online_cpus()));
+ nr_default_queues = min_t(unsigned int, ibdev->num_comp_vectors,
+ min(opts->nr_write_queues, num_online_cpus()));
+ nr_poll_queues = min(opts->nr_poll_queues, num_online_cpus());
+ nr_io_queues = nr_read_queues + nr_default_queues + nr_poll_queues;
ret = nvme_set_queue_count(&ctrl->ctrl, &nr_io_queues);
if (ret)
@@ -681,6 +663,34 @@ static int nvme_rdma_alloc_io_queues(str
dev_info(ctrl->ctrl.device,
"creating %d I/O queues.\n", nr_io_queues);
+ if (opts->nr_write_queues && nr_read_queues < nr_io_queues) {
+ /*
+ * separate read/write queues
+ * hand out dedicated default queues only after we have
+ * sufficient read queues.
+ */
+ ctrl->io_queues[HCTX_TYPE_READ] = nr_read_queues;
+ nr_io_queues -= ctrl->io_queues[HCTX_TYPE_READ];
+ ctrl->io_queues[HCTX_TYPE_DEFAULT] =
+ min(nr_default_queues, nr_io_queues);
+ nr_io_queues -= ctrl->io_queues[HCTX_TYPE_DEFAULT];
+ } else {
+ /*
+ * shared read/write queues
+ * either no write queues were requested, or we don't have
+ * sufficient queue count to have dedicated default queues.
+ */
+ ctrl->io_queues[HCTX_TYPE_DEFAULT] =
+ min(nr_read_queues, nr_io_queues);
+ nr_io_queues -= ctrl->io_queues[HCTX_TYPE_DEFAULT];
+ }
+
+ if (opts->nr_poll_queues && nr_io_queues) {
+ /* map dedicated poll queues only if we have queues left */
+ ctrl->io_queues[HCTX_TYPE_POLL] =
+ min(nr_poll_queues, nr_io_queues);
+ }
+
for (i = 1; i < ctrl->ctrl.queue_count; i++) {
ret = nvme_rdma_alloc_queue(ctrl, i,
ctrl->ctrl.sqsize + 1);
@@ -1787,17 +1797,24 @@ static void nvme_rdma_complete_rq(struct
static int nvme_rdma_map_queues(struct blk_mq_tag_set *set)
{
struct nvme_rdma_ctrl *ctrl = set->driver_data;
+ struct nvmf_ctrl_options *opts = ctrl->ctrl.opts;
- set->map[HCTX_TYPE_DEFAULT].queue_offset = 0;
- set->map[HCTX_TYPE_DEFAULT].nr_queues =
- ctrl->io_queues[HCTX_TYPE_DEFAULT];
- set->map[HCTX_TYPE_READ].nr_queues = ctrl->io_queues[HCTX_TYPE_READ];
- if (ctrl->ctrl.opts->nr_write_queues) {
+ if (opts->nr_write_queues && ctrl->io_queues[HCTX_TYPE_READ]) {
/* separate read/write queues */
+ set->map[HCTX_TYPE_DEFAULT].nr_queues =
+ ctrl->io_queues[HCTX_TYPE_DEFAULT];
+ set->map[HCTX_TYPE_DEFAULT].queue_offset = 0;
+ set->map[HCTX_TYPE_READ].nr_queues =
+ ctrl->io_queues[HCTX_TYPE_READ];
set->map[HCTX_TYPE_READ].queue_offset =
- ctrl->io_queues[HCTX_TYPE_DEFAULT];
+ ctrl->io_queues[HCTX_TYPE_DEFAULT];
} else {
- /* mixed read/write queues */
+ /* shared read/write queues */
+ set->map[HCTX_TYPE_DEFAULT].nr_queues =
+ ctrl->io_queues[HCTX_TYPE_DEFAULT];
+ set->map[HCTX_TYPE_DEFAULT].queue_offset = 0;
+ set->map[HCTX_TYPE_READ].nr_queues =
+ ctrl->io_queues[HCTX_TYPE_DEFAULT];
set->map[HCTX_TYPE_READ].queue_offset = 0;
}
blk_mq_rdma_map_queues(&set->map[HCTX_TYPE_DEFAULT],
@@ -1805,16 +1822,22 @@ static int nvme_rdma_map_queues(struct b
blk_mq_rdma_map_queues(&set->map[HCTX_TYPE_READ],
ctrl->device->dev, 0);
- if (ctrl->ctrl.opts->nr_poll_queues) {
+ if (opts->nr_poll_queues && ctrl->io_queues[HCTX_TYPE_POLL]) {
+ /* map dedicated poll queues only if we have queues left */
set->map[HCTX_TYPE_POLL].nr_queues =
ctrl->io_queues[HCTX_TYPE_POLL];
set->map[HCTX_TYPE_POLL].queue_offset =
- ctrl->io_queues[HCTX_TYPE_DEFAULT];
- if (ctrl->ctrl.opts->nr_write_queues)
- set->map[HCTX_TYPE_POLL].queue_offset +=
- ctrl->io_queues[HCTX_TYPE_READ];
+ ctrl->io_queues[HCTX_TYPE_DEFAULT] +
+ ctrl->io_queues[HCTX_TYPE_READ];
blk_mq_map_queues(&set->map[HCTX_TYPE_POLL]);
}
+
+ dev_info(ctrl->ctrl.device,
+ "mapped %d/%d/%d default/read/poll queues.\n",
+ ctrl->io_queues[HCTX_TYPE_DEFAULT],
+ ctrl->io_queues[HCTX_TYPE_READ],
+ ctrl->io_queues[HCTX_TYPE_POLL]);
+
return 0;
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 44/70] xen-blkfront: switch kcalloc to kvcalloc for large array allocation
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 43/70] nvme-rdma: fix queue mapping when queue count is limited Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 45/70] MIPS: Bounds check virt_addr_valid Greg Kroah-Hartman
` (30 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ian Jackson, Roger Pau Monné,
Juergen Gross, Konrad Rzeszutek Wilk, Boris Ostrovsky
From: Roger Pau Monne <roger.pau@citrix.com>
commit 1d5c76e66433382a1e170d1d5845bb0fed7467aa upstream.
There's no reason to request physically contiguous memory for those
allocations.
[boris: added CC to stable]
Cc: stable@vger.kernel.org
Reported-by: Ian Jackson <ian.jackson@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/block/xen-blkfront.c | 38 +++++++++++++++++++-------------------
1 file changed, 19 insertions(+), 19 deletions(-)
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1310,11 +1310,11 @@ static void blkif_free_ring(struct blkfr
}
free_shadow:
- kfree(rinfo->shadow[i].grants_used);
+ kvfree(rinfo->shadow[i].grants_used);
rinfo->shadow[i].grants_used = NULL;
- kfree(rinfo->shadow[i].indirect_grants);
+ kvfree(rinfo->shadow[i].indirect_grants);
rinfo->shadow[i].indirect_grants = NULL;
- kfree(rinfo->shadow[i].sg);
+ kvfree(rinfo->shadow[i].sg);
rinfo->shadow[i].sg = NULL;
}
@@ -1353,7 +1353,7 @@ static void blkif_free(struct blkfront_i
for (i = 0; i < info->nr_rings; i++)
blkif_free_ring(&info->rinfo[i]);
- kfree(info->rinfo);
+ kvfree(info->rinfo);
info->rinfo = NULL;
info->nr_rings = 0;
}
@@ -1914,9 +1914,9 @@ static int negotiate_mq(struct blkfront_
if (!info->nr_rings)
info->nr_rings = 1;
- info->rinfo = kcalloc(info->nr_rings,
- sizeof(struct blkfront_ring_info),
- GFP_KERNEL);
+ info->rinfo = kvcalloc(info->nr_rings,
+ sizeof(struct blkfront_ring_info),
+ GFP_KERNEL);
if (!info->rinfo) {
xenbus_dev_fatal(info->xbdev, -ENOMEM, "allocating ring_info structure");
info->nr_rings = 0;
@@ -2232,17 +2232,17 @@ static int blkfront_setup_indirect(struc
for (i = 0; i < BLK_RING_SIZE(info); i++) {
rinfo->shadow[i].grants_used =
- kcalloc(grants,
- sizeof(rinfo->shadow[i].grants_used[0]),
- GFP_NOIO);
- rinfo->shadow[i].sg = kcalloc(psegs,
- sizeof(rinfo->shadow[i].sg[0]),
- GFP_NOIO);
+ kvcalloc(grants,
+ sizeof(rinfo->shadow[i].grants_used[0]),
+ GFP_NOIO);
+ rinfo->shadow[i].sg = kvcalloc(psegs,
+ sizeof(rinfo->shadow[i].sg[0]),
+ GFP_NOIO);
if (info->max_indirect_segments)
rinfo->shadow[i].indirect_grants =
- kcalloc(INDIRECT_GREFS(grants),
- sizeof(rinfo->shadow[i].indirect_grants[0]),
- GFP_NOIO);
+ kvcalloc(INDIRECT_GREFS(grants),
+ sizeof(rinfo->shadow[i].indirect_grants[0]),
+ GFP_NOIO);
if ((rinfo->shadow[i].grants_used == NULL) ||
(rinfo->shadow[i].sg == NULL) ||
(info->max_indirect_segments &&
@@ -2256,11 +2256,11 @@ static int blkfront_setup_indirect(struc
out_of_memory:
for (i = 0; i < BLK_RING_SIZE(info); i++) {
- kfree(rinfo->shadow[i].grants_used);
+ kvfree(rinfo->shadow[i].grants_used);
rinfo->shadow[i].grants_used = NULL;
- kfree(rinfo->shadow[i].sg);
+ kvfree(rinfo->shadow[i].sg);
rinfo->shadow[i].sg = NULL;
- kfree(rinfo->shadow[i].indirect_grants);
+ kvfree(rinfo->shadow[i].indirect_grants);
rinfo->shadow[i].indirect_grants = NULL;
}
if (!list_empty(&rinfo->indirect_pages)) {
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 45/70] MIPS: Bounds check virt_addr_valid
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (43 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 44/70] xen-blkfront: switch kcalloc to kvcalloc for large array allocation Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 46/70] MIPS: pistachio: Build uImage.gz by default Greg Kroah-Hartman
` (29 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul Burton, Julien Cristau,
Philippe Mathieu-Daudé,
YunQiang Su, linux-mips
From: Paul Burton <paul.burton@mips.com>
commit 074a1e1167afd82c26f6d03a9a8b997d564bb241 upstream.
The virt_addr_valid() function is meant to return true iff
virt_to_page() will return a valid struct page reference. This is true
iff the address provided is found within the unmapped address range
between PAGE_OFFSET & MAP_BASE, but we don't currently check for that
condition. Instead we simply mask the address to obtain what will be a
physical address if the virtual address is indeed in the desired range,
shift it to form a PFN & then call pfn_valid(). This can incorrectly
return true if called with a virtual address which, after masking,
happens to form a physical address corresponding to a valid PFN.
For example we may vmalloc an address in the kernel mapped region
starting a MAP_BASE & obtain the virtual address:
addr = 0xc000000000002000
When masked by virt_to_phys(), which uses __pa() & in turn CPHYSADDR(),
we obtain the following (bogus) physical address:
addr = 0x2000
In a common system with PHYS_OFFSET=0 this will correspond to a valid
struct page which should really be accessed by virtual address
PAGE_OFFSET+0x2000, causing virt_addr_valid() to incorrectly return 1
indicating that the original address corresponds to a struct page.
This is equivalent to the ARM64 change made in commit ca219452c6b8
("arm64: Correctly bounds check virt_addr_valid").
This fixes fallout when hardened usercopy is enabled caused by the
related commit 517e1fbeb65f ("mm/usercopy: Drop extra
is_vmalloc_or_module() check") which removed a check for the vmalloc
range that was present from the introduction of the hardened usercopy
feature.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Reported-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: YunQiang Su <ysu@wavecomp.com>
URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929366
Cc: stable@vger.kernel.org # v4.12+
Cc: linux-mips@vger.kernel.org
Cc: Yunqiang Su <ysu@wavecomp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/mm/mmap.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -203,6 +203,11 @@ unsigned long arch_randomize_brk(struct
int __virt_addr_valid(const volatile void *kaddr)
{
+ unsigned long vaddr = (unsigned long)vaddr;
+
+ if ((vaddr < PAGE_OFFSET) || (vaddr >= MAP_BASE))
+ return 0;
+
return pfn_valid(PFN_DOWN(virt_to_phys(kaddr)));
}
EXPORT_SYMBOL_GPL(__virt_addr_valid);
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 46/70] MIPS: pistachio: Build uImage.gz by default
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 45/70] MIPS: Bounds check virt_addr_valid Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 47/70] genwqe: Prevent an integer overflow in the ioctl Greg Kroah-Hartman
` (28 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul Burton,
Philippe Mathieu-Daudé,
Kevin Hilman, linux-mips
From: Paul Burton <paul.burton@mips.com>
commit e4f2d1af7163becb181419af9dece9206001e0a6 upstream.
The pistachio platform uses the U-Boot bootloader & generally boots a
kernel in the uImage format. As such it's useful to build one when
building the kernel, but to do so currently requires the user to
manually specify a uImage target on the make command line.
Make uImage.gz the pistachio platform's default build target, so that
the default is to build a kernel image that we can actually boot on a
board such as the MIPS Creator Ci40.
Marked for stable backport as far as v4.1 where pistachio support was
introduced. This is primarily useful for CI systems such as kernelci.org
which will benefit from us building a suitable image which can then be
booted as part of automated testing, extending our test coverage to the
affected stable branches.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
URL: https://groups.io/g/kernelci/message/388
Cc: stable@vger.kernel.org # v4.1+
Cc: linux-mips@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/pistachio/Platform | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/pistachio/Platform
+++ b/arch/mips/pistachio/Platform
@@ -6,3 +6,4 @@ cflags-$(CONFIG_MACH_PISTACHIO) += \
-I$(srctree)/arch/mips/include/asm/mach-pistachio
load-$(CONFIG_MACH_PISTACHIO) += 0xffffffff80400000
zload-$(CONFIG_MACH_PISTACHIO) += 0xffffffff81000000
+all-$(CONFIG_MACH_PISTACHIO) := uImage.gz
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 47/70] genwqe: Prevent an integer overflow in the ioctl
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 46/70] MIPS: pistachio: Build uImage.gz by default Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:41 ` [PATCH 5.1 48/70] test_firmware: Use correct snprintf() limit Greg Kroah-Hartman
` (27 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dan Carpenter
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 110080cea0d0e4dfdb0b536e7f8a5633ead6a781 upstream.
There are a couple potential integer overflows here.
round_up(m->size + (m->addr & ~PAGE_MASK), PAGE_SIZE);
The first thing is that the "m->size + (...)" addition could overflow,
and the second is that round_up() overflows to zero if the result is
within PAGE_SIZE of the type max.
In this code, the "m->size" variable is an u64 but we're saving the
result in "map_size" which is an unsigned long and genwqe_user_vmap()
takes an unsigned long as well. So I have used ULONG_MAX as the upper
bound. From a practical perspective unsigned long is fine/better than
trying to change all the types to u64.
Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/genwqe/card_dev.c | 2 ++
drivers/misc/genwqe/card_utils.c | 4 ++++
2 files changed, 6 insertions(+)
--- a/drivers/misc/genwqe/card_dev.c
+++ b/drivers/misc/genwqe/card_dev.c
@@ -780,6 +780,8 @@ static int genwqe_pin_mem(struct genwqe_
if ((m->addr == 0x0) || (m->size == 0))
return -EINVAL;
+ if (m->size > ULONG_MAX - PAGE_SIZE - (m->addr & ~PAGE_MASK))
+ return -EINVAL;
map_addr = (m->addr & PAGE_MASK);
map_size = round_up(m->size + (m->addr & ~PAGE_MASK), PAGE_SIZE);
--- a/drivers/misc/genwqe/card_utils.c
+++ b/drivers/misc/genwqe/card_utils.c
@@ -586,6 +586,10 @@ int genwqe_user_vmap(struct genwqe_dev *
/* determine space needed for page_list. */
data = (unsigned long)uaddr;
offs = offset_in_page(data);
+ if (size > ULONG_MAX - PAGE_SIZE - offs) {
+ m->size = 0; /* mark unused and not added */
+ return -EINVAL;
+ }
m->nr_pages = DIV_ROUND_UP(offs + size, PAGE_SIZE);
m->page_list = kcalloc(m->nr_pages,
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 48/70] test_firmware: Use correct snprintf() limit
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 47/70] genwqe: Prevent an integer overflow in the ioctl Greg Kroah-Hartman
@ 2019-06-09 16:41 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 49/70] drm/rockchip: fix fb references in async update Greg Kroah-Hartman
` (26 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dan Carpenter
From: Dan Carpenter <dan.carpenter@oracle.com>
commit bd17cc5a20ae9aaa3ed775f360b75ff93cd66a1d upstream.
The limit here is supposed to be how much of the page is left, but it's
just using PAGE_SIZE as the limit.
The other thing to remember is that snprintf() returns the number of
bytes which would have been copied if we had had enough room. So that
means that if we run out of space then this code would end up passing a
negative value as the limit and the kernel would print an error message.
I have change the code to use scnprintf() which returns the number of
bytes that were successfully printed (not counting the NUL terminator).
Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
lib/test_firmware.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/lib/test_firmware.c
+++ b/lib/test_firmware.c
@@ -223,30 +223,30 @@ static ssize_t config_show(struct device
mutex_lock(&test_fw_mutex);
- len += snprintf(buf, PAGE_SIZE,
+ len += scnprintf(buf, PAGE_SIZE - len,
"Custom trigger configuration for: %s\n",
dev_name(dev));
if (test_fw_config->name)
- len += snprintf(buf+len, PAGE_SIZE,
+ len += scnprintf(buf+len, PAGE_SIZE - len,
"name:\t%s\n",
test_fw_config->name);
else
- len += snprintf(buf+len, PAGE_SIZE,
+ len += scnprintf(buf+len, PAGE_SIZE - len,
"name:\tEMTPY\n");
- len += snprintf(buf+len, PAGE_SIZE,
+ len += scnprintf(buf+len, PAGE_SIZE - len,
"num_requests:\t%u\n", test_fw_config->num_requests);
- len += snprintf(buf+len, PAGE_SIZE,
+ len += scnprintf(buf+len, PAGE_SIZE - len,
"send_uevent:\t\t%s\n",
test_fw_config->send_uevent ?
"FW_ACTION_HOTPLUG" :
"FW_ACTION_NOHOTPLUG");
- len += snprintf(buf+len, PAGE_SIZE,
+ len += scnprintf(buf+len, PAGE_SIZE - len,
"sync_direct:\t\t%s\n",
test_fw_config->sync_direct ? "true" : "false");
- len += snprintf(buf+len, PAGE_SIZE,
+ len += scnprintf(buf+len, PAGE_SIZE - len,
"read_fw_idx:\t%u\n", test_fw_config->read_fw_idx);
mutex_unlock(&test_fw_mutex);
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 49/70] drm/rockchip: fix fb references in async update
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2019-06-09 16:41 ` [PATCH 5.1 48/70] test_firmware: Use correct snprintf() limit Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 50/70] drm/vc4: " Greg Kroah-Hartman
` (25 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Helen Koike, Boris Brezillon
From: Helen Koike <helen.koike@collabora.com>
commit d985a3533274ef7dd1ccb25cb05a72259b25268f upstream.
In the case of async update, modifications are done in place, i.e. in the
current plane state, so the new_state is prepared and the new_state is
cleaned up (instead of the old_state, unlike what happens in a
normal sync update).
To cleanup the old_fb properly, it needs to be placed in the new_state
in the end of async_update, so cleanup call will unreference the old_fb
correctly.
Also, the previous code had a:
plane_state = plane->funcs->atomic_duplicate_state(plane);
...
swap(plane_state, plane->state);
if (plane->state->fb && plane->state->fb != new_state->fb) {
...
}
Which was wrong, as the fb were just assigned to be equal, so this if
statement nevers evaluates to true.
Another details is that the function drm_crtc_vblank_get() can only be
called when vop->is_enabled is true, otherwise it has no effect and
trows a WARN_ON().
Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
fb and pus the old fb) is not required, as it is taken care by
drm_mode_cursor_universal() when calling
drm_atomic_helper_update_plane().
Fixes: 15609559a834 ("drm/rockchip: update cursors asynchronously through atomic.")
Cc: <stable@vger.kernel.org> # v4.20+
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-2-helen.koike@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 49 ++++++++++++++--------------
1 file changed, 25 insertions(+), 24 deletions(-)
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -924,29 +924,17 @@ static void vop_plane_atomic_async_updat
struct drm_plane_state *new_state)
{
struct vop *vop = to_vop(plane->state->crtc);
- struct drm_plane_state *plane_state;
+ struct drm_framebuffer *old_fb = plane->state->fb;
- plane_state = plane->funcs->atomic_duplicate_state(plane);
- plane_state->crtc_x = new_state->crtc_x;
- plane_state->crtc_y = new_state->crtc_y;
- plane_state->crtc_h = new_state->crtc_h;
- plane_state->crtc_w = new_state->crtc_w;
- plane_state->src_x = new_state->src_x;
- plane_state->src_y = new_state->src_y;
- plane_state->src_h = new_state->src_h;
- plane_state->src_w = new_state->src_w;
-
- if (plane_state->fb != new_state->fb)
- drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
-
- swap(plane_state, plane->state);
-
- if (plane->state->fb && plane->state->fb != new_state->fb) {
- drm_framebuffer_get(plane->state->fb);
- WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
- drm_flip_work_queue(&vop->fb_unref_work, plane->state->fb);
- set_bit(VOP_PENDING_FB_UNREF, &vop->pending);
- }
+ plane->state->crtc_x = new_state->crtc_x;
+ plane->state->crtc_y = new_state->crtc_y;
+ plane->state->crtc_h = new_state->crtc_h;
+ plane->state->crtc_w = new_state->crtc_w;
+ plane->state->src_x = new_state->src_x;
+ plane->state->src_y = new_state->src_y;
+ plane->state->src_h = new_state->src_h;
+ plane->state->src_w = new_state->src_w;
+ swap(plane->state->fb, new_state->fb);
if (vop->is_enabled) {
rockchip_drm_psr_inhibit_get_state(new_state->state);
@@ -955,9 +943,22 @@ static void vop_plane_atomic_async_updat
vop_cfg_done(vop);
spin_unlock(&vop->reg_lock);
rockchip_drm_psr_inhibit_put_state(new_state->state);
- }
- plane->funcs->atomic_destroy_state(plane, plane_state);
+ /*
+ * A scanout can still be occurring, so we can't drop the
+ * reference to the old framebuffer. To solve this we get a
+ * reference to old_fb and set a worker to release it later.
+ * FIXME: if we perform 500 async_update calls before the
+ * vblank, then we can have 500 different framebuffers waiting
+ * to be released.
+ */
+ if (old_fb && plane->state->fb != old_fb) {
+ drm_framebuffer_get(old_fb);
+ WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
+ drm_flip_work_queue(&vop->fb_unref_work, old_fb);
+ set_bit(VOP_PENDING_FB_UNREF, &vop->pending);
+ }
+ }
}
static const struct drm_plane_helper_funcs plane_helper_funcs = {
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 50/70] drm/vc4: fix fb references in async update
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (48 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 49/70] drm/rockchip: fix fb references in async update Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 51/70] drm/gma500/cdv: Check vbt config bits when detecting lvds panels Greg Kroah-Hartman
` (24 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Boris Brezillon, Helen Koike
From: Helen Koike <helen.koike@collabora.com>
commit c16b85559dcfb5a348cc085a7b4c75ed49b05e2c upstream.
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().
Cc: <stable@vger.kernel.org> # v4.19+
Fixes: 539c320bfa97 ("drm/vc4: update cursors asynchronously through atomic")
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-5-helen.koike@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -968,7 +968,7 @@ static void vc4_plane_atomic_async_updat
{
struct vc4_plane_state *vc4_state, *new_vc4_state;
- drm_atomic_set_fb_for_plane(plane->state, state->fb);
+ swap(plane->state->fb, state->fb);
plane->state->crtc_x = state->crtc_x;
plane->state->crtc_y = state->crtc_y;
plane->state->crtc_w = state->crtc_w;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 51/70] drm/gma500/cdv: Check vbt config bits when detecting lvds panels
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (49 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 50/70] drm/vc4: " Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 52/70] drm/msm: fix fb references in async update Greg Kroah-Hartman
` (23 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans de Goede, Patrik Jakobsson
From: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
commit 7c420636860a719049fae9403e2c87804f53bdde upstream.
Some machines have an lvds child device in vbt even though a panel is
not attached. To make detection more reliable we now also check the lvds
config bits available in the vbt.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Cc: stable@vger.kernel.org
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416114607.1072-1-patrik.r.jakobsson@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +++
drivers/gpu/drm/gma500/intel_bios.c | 3 +++
drivers/gpu/drm/gma500/psb_drv.h | 1 +
3 files changed, 7 insertions(+)
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -594,6 +594,9 @@ void cdv_intel_lvds_init(struct drm_devi
int pipe;
u8 pin;
+ if (!dev_priv->lvds_enabled_in_vbt)
+ return;
+
pin = GMBUS_PORT_PANEL;
if (!lvds_is_present_in_vbt(dev, &pin)) {
DRM_DEBUG_KMS("LVDS is not present in VBT\n");
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -436,6 +436,9 @@ parse_driver_features(struct drm_psb_pri
if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
dev_priv->edp.support = 1;
+ dev_priv->lvds_enabled_in_vbt = driver->lvds_config != 0;
+ DRM_DEBUG_KMS("LVDS VBT config bits: 0x%x\n", driver->lvds_config);
+
/* This bit means to use 96Mhz for DPLL_A or not */
if (driver->primary_lfp_id)
dev_priv->dplla_96mhz = true;
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -537,6 +537,7 @@ struct drm_psb_private {
int lvds_ssc_freq;
bool is_lvds_on;
bool is_mipi_on;
+ bool lvds_enabled_in_vbt;
u32 mipi_ctrl_display;
unsigned int core_freq;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 52/70] drm/msm: fix fb references in async update
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (50 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 51/70] drm/gma500/cdv: Check vbt config bits when detecting lvds panels Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 53/70] drm: add non-desktop quirk for Valve HMDs Greg Kroah-Hartman
` (22 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Boris Brezillon, Helen Koike, Rob Clark
From: Helen Koike <helen.koike@collabora.com>
commit 474d952b4870cfbdc55d3498f4d498775fe77e81 upstream.
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Cc: <stable@vger.kernel.org> # v4.14+
Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through atomic")
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-4-helen.koike@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -502,6 +502,8 @@ static int mdp5_plane_atomic_async_check
static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
struct drm_plane_state *new_state)
{
+ struct drm_framebuffer *old_fb = plane->state->fb;
+
plane->state->src_x = new_state->src_x;
plane->state->src_y = new_state->src_y;
plane->state->crtc_x = new_state->crtc_x;
@@ -524,6 +526,8 @@ static void mdp5_plane_atomic_async_upda
*to_mdp5_plane_state(plane->state) =
*to_mdp5_plane_state(new_state);
+
+ new_state->fb = old_fb;
}
static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 53/70] drm: add non-desktop quirk for Valve HMDs
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (51 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 52/70] drm/msm: fix fb references in async update Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 54/70] drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3) Greg Kroah-Hartman
` (21 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andres Rodriguez, Dave Airlie
From: Andres Rodriguez <andresx7@gmail.com>
commit 30d62d4453e49f85dd17b2ba60bbb68b6593dba0 upstream.
Add vendor/product pairs for the Valve Index HMDs.
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: <stable@vger.kernel.org> # v4.15
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190502193157.15692-1-andresx7@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -172,6 +172,25 @@ static const struct edid_quirk {
/* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
{ "ETR", 13896, EDID_QUIRK_FORCE_8BPC },
+ /* Valve Index Headset */
+ { "VLV", 0x91a8, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b0, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b1, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b2, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b3, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b4, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b5, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b6, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b7, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b8, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b9, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91ba, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91bb, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91bc, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91bd, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91be, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91bf, EDID_QUIRK_NON_DESKTOP },
+
/* HTC Vive and Vive Pro VR Headsets */
{ "HVR", 0xaa01, EDID_QUIRK_NON_DESKTOP },
{ "HVR", 0xaa02, EDID_QUIRK_NON_DESKTOP },
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 54/70] drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (52 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 53/70] drm: add non-desktop quirk for Valve HMDs Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 55/70] drm: add non-desktop quirks to Sensics and OSVR headsets Greg Kroah-Hartman
` (20 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Daniel Vetter, Dave Airlie
From: Dave Airlie <airlied@redhat.com>
commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream.
There was a nouveau DDX that relied on legacy context ioctls to work,
but we fixed it years ago, give distros that have a modern DDX the
option to break the uAPI and close the mess of holes that legacy
context support is.
Full context of the story:
commit 0e975980d435d58df2d430d688b8c18778b42218
Author: Peter Antoine <peter.antoine@intel.com>
Date: Tue Jun 23 08:18:49 2015 +0100
drm: Turn off Legacy Context Functions
The context functions are not used by the i915 driver and should not
be used by modeset drivers. These driver functions contain several bugs
and security holes. This change makes these functions optional can be
turned on by a setting, they are turned off by default for modeset
driver with the exception of the nouvea driver that may require them with
an old version of libdrm.
The previous attempt was
commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Aug 8 15:41:21 2013 +0200
drm: mark context support as a legacy subsystem
but this had to be reverted
commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Sep 20 08:32:59 2013 +1000
Revert "drm: mark context support as a legacy subsystem"
v2: remove returns from void function, and formatting (Daniel Vetter)
v3:
- s/Nova/nouveau/ in the commit message, and add references to the
previous attempts
- drop the part touching the drm hw lock, that should be a separate
patch.
Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2)
Cc: Peter Antoine <peter.antoine@intel.com> (v2)
Reviewed-by: Peter Antoine <peter.antoine@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: move DRM_VM dependency into legacy config.
v3: fix missing dep (kbuild robot)
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/Kconfig | 13 ++++++++++++-
drivers/gpu/drm/nouveau/nouveau_drm.c | 7 +++++--
2 files changed, 17 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -17,10 +17,21 @@ config DRM_NOUVEAU
select INPUT if ACPI && X86
select THERMAL if ACPI && X86
select ACPI_VIDEO if ACPI && X86
- select DRM_VM
help
Choose this option for open-source NVIDIA support.
+config NOUVEAU_LEGACY_CTX_SUPPORT
+ bool "Nouveau legacy context support"
+ depends on DRM_NOUVEAU
+ select DRM_VM
+ default y
+ help
+ There was a version of the nouveau DDX that relied on legacy
+ ctx ioctls not erroring out. But that was back in time a long
+ ways, so offer a way to disable it now. For uapi compat with
+ old nouveau ddx this should be on by default, but modern distros
+ should consider turning it off.
+
config NOUVEAU_PLATFORM_DRIVER
bool "Nouveau (NVIDIA) SoC GPUs"
depends on DRM_NOUVEAU && ARCH_TEGRA
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1094,8 +1094,11 @@ nouveau_driver_fops = {
static struct drm_driver
driver_stub = {
.driver_features =
- DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER |
- DRIVER_KMS_LEGACY_CONTEXT,
+ DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER
+#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT)
+ | DRIVER_KMS_LEGACY_CONTEXT
+#endif
+ ,
.open = nouveau_drm_open,
.postclose = nouveau_drm_postclose,
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 55/70] drm: add non-desktop quirks to Sensics and OSVR headsets.
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (53 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 54/70] drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3) Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 56/70] drm: Fix timestamp docs for variable refresh properties Greg Kroah-Hartman
` (19 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ryan Pavlik, Daniel Stone, Philipp Zabel
From: Ryan Pavlik <ryan.pavlik@collabora.com>
commit 29054230f3e11ea818eccfa7bb4e4b3e89544164 upstream.
Add two EDID vendor/product pairs used across a variety of
Sensics products, as well as the OSVR HDK and HDK 2.
Signed-off-by: Ryan Pavlik <ryan.pavlik@collabora.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203164644.13974-1-ryan.pavlik@collabora.com
Cc: <stable@vger.kernel.org> # v4.15+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -212,6 +212,12 @@ static const struct edid_quirk {
/* Sony PlayStation VR Headset */
{ "SNY", 0x0704, EDID_QUIRK_NON_DESKTOP },
+
+ /* Sensics VR Headsets */
+ { "SEN", 0x1019, EDID_QUIRK_NON_DESKTOP },
+
+ /* OSVR HDK and HDK2 VR Headsets */
+ { "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
};
/*
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 56/70] drm: Fix timestamp docs for variable refresh properties.
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (54 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 55/70] drm: add non-desktop quirks to Sensics and OSVR headsets Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 57/70] drm/amdgpu/psp: move psp version specific function pointers to early_init Greg Kroah-Hartman
` (18 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Vetter, Nicholas Kazlauskas,
Mario Kleiner, Alex Deucher
From: Mario Kleiner <mario.kleiner.de@gmail.com>
commit 0cbd0adc4429930567083d18cc8c0fbc5f635d96 upstream.
As discussed with Nicholas and Daniel Vetter (patchwork
link to discussion below), the VRR timestamping behaviour
produced utterly useless and bogus vblank/pageflip
timestamps. We have found a way to fix this and provide
sane behaviour.
As of Linux 5.2, the amdgpu driver will be able to
provide exactly the same vblank / pageflip timestamp
semantic in variable refresh rate mode as in standard
fixed refresh rate mode. This is achieved by deferring
core vblank handling (drm_crtc_handle_vblank()) until
the end of front porch, and also defer the sending of
pageflip completion events until end of front porch,
when we can safely compute correct pageflip/vblank
timestamps.
The same approach will be possible for other VRR
capable kms drivers, so we can actually have sane
and useful timestamps in VRR mode.
This patch removes the section of the docs that
describes the broken timestamp behaviour present
in Linux 5.0/5.1.
Fixes: ab7a664f7a2d ("drm: Document variable refresh properties")
Link: https://patchwork.freedesktop.org/patch/285333/
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190418060157.18968-1-mario.kleiner.de@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_connector.c | 6 ------
1 file changed, 6 deletions(-)
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1385,12 +1385,6 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mo
*
* The driver may place further restrictions within these minimum
* and maximum bounds.
- *
- * The semantics for the vertical blank timestamp differ when
- * variable refresh rate is active. The vertical blank timestamp
- * is defined to be an estimate using the current mode's fixed
- * refresh rate timings. The semantics for the page-flip event
- * timestamp remain the same.
*/
/**
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 57/70] drm/amdgpu/psp: move psp version specific function pointers to early_init
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (55 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 56/70] drm: Fix timestamp docs for variable refresh properties Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 58/70] drm/radeon: prefer lower reference dividers Greg Kroah-Hartman
` (17 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christian König, Alex Deucher
From: Alex Deucher <alexander.deucher@amd.com>
commit 9d6fea5744d6798353f37ac42a8a653a2607ca69 upstream.
In case we need to use them for GPU reset prior initializing the
asic. Fixes a crash if the driver attempts to reset the GPU at driver
load time.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -38,18 +38,10 @@ static void psp_set_funcs(struct amdgpu_
static int psp_early_init(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+ struct psp_context *psp = &adev->psp;
psp_set_funcs(adev);
- return 0;
-}
-
-static int psp_sw_init(void *handle)
-{
- struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- struct psp_context *psp = &adev->psp;
- int ret;
-
switch (adev->asic_type) {
case CHIP_VEGA10:
case CHIP_VEGA12:
@@ -67,6 +59,15 @@ static int psp_sw_init(void *handle)
psp->adev = adev;
+ return 0;
+}
+
+static int psp_sw_init(void *handle)
+{
+ struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+ struct psp_context *psp = &adev->psp;
+ int ret;
+
ret = psp_init_microcode(psp);
if (ret) {
DRM_ERROR("Failed to load psp firmware!\n");
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 58/70] drm/radeon: prefer lower reference dividers
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (56 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 57/70] drm/amdgpu/psp: move psp version specific function pointers to early_init Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 59/70] drm/amdgpu: remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check when hotplug-in Greg Kroah-Hartman
` (16 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul Dufresne, Christian König,
Alex Deucher
From: Christian König <christian.koenig@amd.com>
commit 2e26ccb119bde03584be53406bbd22e711b0d6e6 upstream.
Instead of the closest reference divider prefer the lowest,
this fixes flickering issues on HP Compaq nx9420.
Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=108514
Suggested-by: Paul Dufresne <dufresnep@gmail.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -922,12 +922,12 @@ static void avivo_get_fb_ref_div(unsigne
ref_div_max = max(min(100 / post_div, ref_div_max), 1u);
/* get matching reference and feedback divider */
- *ref_div = min(max(DIV_ROUND_CLOSEST(den, post_div), 1u), ref_div_max);
+ *ref_div = min(max(den/post_div, 1u), ref_div_max);
*fb_div = DIV_ROUND_CLOSEST(nom * *ref_div * post_div, den);
/* limit fb divider to its maximum */
if (*fb_div > fb_div_max) {
- *ref_div = DIV_ROUND_CLOSEST(*ref_div * fb_div_max, *fb_div);
+ *ref_div = (*ref_div * fb_div_max)/(*fb_div);
*fb_div = fb_div_max;
}
}
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 59/70] drm/amdgpu: remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check when hotplug-in
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (57 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 58/70] drm/radeon: prefer lower reference dividers Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 60/70] drm/i915: Fix I915_EXEC_RING_MASK Greg Kroah-Hartman
` (15 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Aaron Liu, Alex Deucher
From: Aaron Liu <aaron.liu@amd.com>
commit bdb1ccb080dafc1b4224873a5b759ff85a7d1c10 upstream.
In amdgpu_atif_handler, when hotplug event received, remove
ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check. This bit's check will cause missing
system resume.
Signed-off-by: Aaron Liu <aaron.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -464,8 +464,7 @@ static int amdgpu_atif_handler(struct am
}
}
if (req.pending & ATIF_DGPU_DISPLAY_EVENT) {
- if ((adev->flags & AMD_IS_PX) &&
- amdgpu_atpx_dgpu_req_power_for_displays()) {
+ if (adev->flags & AMD_IS_PX) {
pm_runtime_get_sync(adev->ddev->dev);
/* Just fire off a uevent and let userspace tell us what to do */
drm_helper_hpd_irq_event(adev->ddev);
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 60/70] drm/i915: Fix I915_EXEC_RING_MASK
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (58 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 59/70] drm/amdgpu: remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check when hotplug-in Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 61/70] drm/amdgpu/soc15: skip reset on init Greg Kroah-Hartman
` (14 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Chris Wilson, Tvrtko Ursulin
From: Chris Wilson <chris@chris-wilson.co.uk>
commit d90c06d57027203f73021bb7ddb30b800d65c636 upstream.
This was supposed to be a mask of all known rings, but it is being used
by execbuffer to filter out invalid rings, and so is instead mapping high
unused values onto valid rings. Instead of a mask of all known rings,
we need it to be the mask of all possible rings.
Fixes: 549f7365820a ("drm/i915: Enable SandyBridge blitter ring")
Fixes: de1add360522 ("drm/i915: Decouple execbuf uAPI from internal implementation")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org> # v4.6+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190301140404.26690-21-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/uapi/drm/i915_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -972,7 +972,7 @@ struct drm_i915_gem_execbuffer2 {
* struct drm_i915_gem_exec_fence *fences.
*/
__u64 cliprects_ptr;
-#define I915_EXEC_RING_MASK (7<<0)
+#define I915_EXEC_RING_MASK (0x3f)
#define I915_EXEC_DEFAULT (0<<0)
#define I915_EXEC_RENDER (1<<0)
#define I915_EXEC_BSD (2<<0)
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 61/70] drm/amdgpu/soc15: skip reset on init
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (59 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 60/70] drm/i915: Fix I915_EXEC_RING_MASK Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 62/70] drm/amd/display: Add ASICREV_IS_PICASSO Greg Kroah-Hartman
` (13 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Amber Lin, Alex Deucher
From: Alex Deucher <alexander.deucher@amd.com>
commit 5887a59961e2295c5b02f39dbc0ecf9212709b7b upstream.
Not necessary on soc15 and breaks driver reload on server cards.
Acked-by: Amber Lin <Amber.Lin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -713,6 +713,11 @@ static bool soc15_need_reset_on_init(str
{
u32 sol_reg;
+ /* Just return false for soc15 GPUs. Reset does not seem to
+ * be necessary.
+ */
+ return false;
+
if (adev->flags & AMD_IS_APU)
return false;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 62/70] drm/amd/display: Add ASICREV_IS_PICASSO
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (60 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 61/70] drm/amdgpu/soc15: skip reset on init Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 63/70] drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2) Greg Kroah-Hartman
` (12 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Harry Wentland, Nicholas Kazlauskas,
Alex Deucher
From: Harry Wentland <harry.wentland@amd.com>
commit ada637e70f96862ff5ba20a169506b58cf567db9 upstream.
[WHY]
We only want to load DMCU FW on Picasso and Raven 2, not on Raven 1.
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/display/include/dal_asic_id.h | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/amd/display/include/dal_asic_id.h
+++ b/drivers/gpu/drm/amd/display/include/dal_asic_id.h
@@ -138,13 +138,14 @@
#endif
#define RAVEN_UNKNOWN 0xFF
-#if defined(CONFIG_DRM_AMD_DC_DCN1_01)
-#define ASICREV_IS_RAVEN2(eChipRev) ((eChipRev >= RAVEN2_A0) && (eChipRev < 0xF0))
-#endif /* DCN1_01 */
#define ASIC_REV_IS_RAVEN(eChipRev) ((eChipRev >= RAVEN_A0) && eChipRev < RAVEN_UNKNOWN)
#define RAVEN1_F0 0xF0
#define ASICREV_IS_RV1_F0(eChipRev) ((eChipRev >= RAVEN1_F0) && (eChipRev < RAVEN_UNKNOWN))
+#if defined(CONFIG_DRM_AMD_DC_DCN1_01)
+#define ASICREV_IS_PICASSO(eChipRev) ((eChipRev >= PICASSO_A0) && (eChipRev < RAVEN2_A0))
+#define ASICREV_IS_RAVEN2(eChipRev) ((eChipRev >= RAVEN2_A0) && (eChipRev < 0xF0))
+#endif /* DCN1_01 */
#define FAMILY_RV 142 /* DCN 1*/
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 63/70] drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (61 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 62/70] drm/amd/display: Add ASICREV_IS_PICASSO Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 64/70] drm/i915/fbc: disable framebuffer compression on GeminiLake Greg Kroah-Hartman
` (11 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Louis Li, Christian König, Alex Deucher
From: Louis Li <Ching-shih.Li@amd.com>
commit ce0e22f5d886d1b56c7ab4347c45b9ac5fcc058d upstream.
[What]
vce ring test fails consistently during resume in s3 cycle, due to
mismatch read & write pointers.
On debug/analysis its found that rptr to be compared is not being
correctly updated/read, which leads to this failure.
Below is the failure signature:
[drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed
[drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block <vce_v3_0> failed -110
[drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110).
[How]
fetch rptr appropriately, meaning move its read location further down
in the code flow.
With this patch applied the s3 failure is no more seen for >5k s3 cycles,
which otherwise is pretty consistent.
V2: remove reduntant fetch of rptr
Signed-off-by: Louis Li <Ching-shih.Li@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -1072,7 +1072,7 @@ void amdgpu_vce_ring_emit_fence(struct a
int amdgpu_vce_ring_test_ring(struct amdgpu_ring *ring)
{
struct amdgpu_device *adev = ring->adev;
- uint32_t rptr = amdgpu_ring_get_rptr(ring);
+ uint32_t rptr;
unsigned i;
int r, timeout = adev->usec_timeout;
@@ -1084,6 +1084,8 @@ int amdgpu_vce_ring_test_ring(struct amd
if (r)
return r;
+ rptr = amdgpu_ring_get_rptr(ring);
+
amdgpu_ring_write(ring, VCE_CMD_END);
amdgpu_ring_commit(ring);
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 64/70] drm/i915/fbc: disable framebuffer compression on GeminiLake
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (62 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 63/70] drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2) Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 65/70] drm/i915/gvt: emit init breadcrumb for gvt request Greg Kroah-Hartman
` (10 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paulo Zanoni, Daniel Vetter,
Jani Nikula, Daniel Drake, Jian-Hong Pan, Jani Nikula,
Joonas Lahtinen
From: Daniel Drake <drake@endlessm.com>
commit 396dd8143bdd94bd1c358a228a631c8c895a1126 upstream.
On many (all?) the Gemini Lake systems we work with, there is frequent
momentary graphical corruption at the top of the screen, and it seems
that disabling framebuffer compression can avoid this.
The ticket was reported 6 months ago and has already affected a
multitude of users, without any real progress being made. So, lets
disable framebuffer compression on GeminiLake until a solution is found.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108085
Fixes: fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.11+
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190423092810.28359-1-jian-hong@endlessm.com
(cherry picked from commit 1d25724b41fad7eeb2c3058a5c8190d6ece73e08)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_fbc.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1278,6 +1278,10 @@ static int intel_sanitize_fbc_option(str
if (!HAS_FBC(dev_priv))
return 0;
+ /* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */
+ if (IS_GEMINILAKE(dev_priv))
+ return 0;
+
if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9)
return 1;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 65/70] drm/i915/gvt: emit init breadcrumb for gvt request
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (63 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 64/70] drm/i915/fbc: disable framebuffer compression on GeminiLake Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 66/70] drm/i915: Maintain consistent documentation subsection ordering Greg Kroah-Hartman
` (9 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Zhenyu Wang, Weinan
From: Weinan <weinan.z.li@intel.com>
commit a8c2d5ab9e71be3f9431c47bd45329a36e1fc650 upstream.
"To track whether a request has started on HW, we can emit a breadcrumb at
the beginning of the request and check its timeline's HWSP to see if the
breadcrumb has advanced past the start of this request." It means all the
request which timeline's has_init_breadcrumb is true, then the
emit_init_breadcrumb process must have before emitting the real commands,
otherwise, the scheduler might get a wrong state of this request during
reset. If the request is exactly the guilty one, the scheduler won't
terminate it with the wrong state. To avoid this, do emit_init_breadcrumb
for all the requests from gvt.
v2: cc to stable kernel
Fixes: 8547444137ec ("drm/i915: Identify active requests")
Cc: stable@vger.kernel.org
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Weinan <weinan.z.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/gvt/scheduler.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -298,12 +298,31 @@ static int copy_workload_to_ring_buffer(
struct i915_request *req = workload->req;
void *shadow_ring_buffer_va;
u32 *cs;
+ int err;
if ((IS_KABYLAKE(req->i915) || IS_BROXTON(req->i915)
|| IS_COFFEELAKE(req->i915))
&& is_inhibit_context(req->hw_context))
intel_vgpu_restore_inhibit_context(vgpu, req);
+ /*
+ * To track whether a request has started on HW, we can emit a
+ * breadcrumb at the beginning of the request and check its
+ * timeline's HWSP to see if the breadcrumb has advanced past the
+ * start of this request. Actually, the request must have the
+ * init_breadcrumb if its timeline set has_init_bread_crumb, or the
+ * scheduler might get a wrong state of it during reset. Since the
+ * requests from gvt always set the has_init_breadcrumb flag, here
+ * need to do the emit_init_breadcrumb for all the requests.
+ */
+ if (req->engine->emit_init_breadcrumb) {
+ err = req->engine->emit_init_breadcrumb(req);
+ if (err) {
+ gvt_vgpu_err("fail to emit init breadcrumb\n");
+ return err;
+ }
+ }
+
/* allocate shadow ring buffer */
cs = intel_ring_begin(workload->req, workload->rb_len / sizeof(u32));
if (IS_ERR(cs)) {
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 66/70] drm/i915: Maintain consistent documentation subsection ordering
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (64 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 65/70] drm/i915/gvt: emit init breadcrumb for gvt request Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 67/70] drm: dont block fb changes for async plane updates Greg Kroah-Hartman
` (8 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jani Nikula, Jonathan Corbet
From: Jonathan Corbet <corbet@lwn.net>
commit 551bd3368a7b3cfef01edaade8970948d178d40a upstream.
With Sphinx 2.0 (or prior versions with the deprecation warnings fixed) the
docs build fails with:
Documentation/gpu/i915.rst:403: WARNING: Title level inconsistent:
Global GTT Fence Handling
~~~~~~~~~~~~~~~~~~~~~~~~~
reST markup error:
Documentation/gpu/i915.rst:403: (SEVERE/4) Title level inconsistent:
I "fixed" it by changing the subsections in i915.rst, but that didn't seem
like the correct change. It turns out that a couple of i915 files create
their own subsections in kerneldoc comments using apostrophes as the
heading marker:
Layout
''''''
That breaks the normal subsection marker ordering, and newer Sphinx is
rather more strict about enforcing that ordering. So fix the offending
comments to make Sphinx happy.
(This is unfortunate, in that kerneldoc comments shouldn't need to be aware
of where they might be included in the heading hierarchy, but I don't see
a better way around it).
Cc: stable@vger.kernel.org # v4.14+
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_reg.h | 6 +++---
drivers/gpu/drm/i915/intel_workarounds.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -32,7 +32,7 @@
* macros. Do **not** mass change existing definitions just to update the style.
*
* Layout
- * ''''''
+ * ~~~~~~
*
* Keep helper macros near the top. For example, _PIPE() and friends.
*
@@ -78,7 +78,7 @@
* style. Use lower case in hexadecimal values.
*
* Naming
- * ''''''
+ * ~~~~~~
*
* Try to name registers according to the specs. If the register name changes in
* the specs from platform to another, stick to the original name.
@@ -96,7 +96,7 @@
* suffix to the name. For example, ``_SKL`` or ``_GEN8``.
*
* Examples
- * ''''''''
+ * ~~~~~~~~
*
* (Note that the values in the example are indented using spaces instead of
* TABs to avoid misalignment in generated documentation. Use TABs in the
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -37,7 +37,7 @@
* costly and simplifies things. We can revisit this in the future.
*
* Layout
- * ''''''
+ * ~~~~~~
*
* Keep things in this file ordered by WA type, as per the above (context, GT,
* display, register whitelist, batchbuffer). Then, inside each type, keep the
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 67/70] drm: dont block fb changes for async plane updates
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (65 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 66/70] drm/i915: Maintain consistent documentation subsection ordering Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 68/70] drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack Greg Kroah-Hartman
` (7 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Boris Brezillon, Helen Koike,
Nicholas Kazlauskas
From: Helen Koike <helen.koike@collabora.com>
commit 89a4aac0ab0e6f5eea10d7bf4869dd15c3de2cd4 upstream.
In the case of a normal sync update, the preparation of framebuffers (be
it calling drm_atomic_helper_prepare_planes() or doing setups with
drm_framebuffer_get()) are performed in the new_state and the respective
cleanups are performed in the old_state.
In the case of async updates, the preparation is also done in the
new_state but the cleanups are done in the new_state (because updates
are performed in place, i.e. in the current state).
The current code blocks async udpates when the fb is changed, turning
async updates into sync updates, slowing down cursor updates and
introducing regressions in igt tests with errors of type:
"CRITICAL: completed 97 cursor updated in a period of 30 flips, we
expect to complete approximately 15360 updates, with the threshold set
at 7680"
Fb changes in async updates were prevented to avoid the following scenario:
- Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong)
Where we have a single call to prepare fb2 but double cleanup call to fb2.
To solve the above problems, instead of blocking async fb changes, we
place the old framebuffer in the new_state object, so when the code
performs cleanups in the new_state it will cleanup the old_fb and we
will have the following scenario instead:
- Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
Where calls to prepare/cleanup are balanced.
Cc: <stable@vger.kernel.org> # v4.14+
Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-6-helen.koike@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_atomic_helper.c | 22 ++++++++++++----------
include/drm/drm_modeset_helper_vtables.h | 8 ++++++++
2 files changed, 20 insertions(+), 10 deletions(-)
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1607,15 +1607,6 @@ int drm_atomic_helper_async_check(struct
old_plane_state->crtc != new_plane_state->crtc)
return -EINVAL;
- /*
- * FIXME: Since prepare_fb and cleanup_fb are always called on
- * the new_plane_state for async updates we need to block framebuffer
- * changes. This prevents use of a fb that's been cleaned up and
- * double cleanups from occuring.
- */
- if (old_plane_state->fb != new_plane_state->fb)
- return -EINVAL;
-
funcs = plane->helper_private;
if (!funcs->atomic_async_update)
return -EINVAL;
@@ -1646,6 +1637,8 @@ EXPORT_SYMBOL(drm_atomic_helper_async_ch
* drm_atomic_async_check() succeeds. Async commits are not supposed to swap
* the states like normal sync commits, but just do in-place changes on the
* current state.
+ *
+ * TODO: Implement full swap instead of doing in-place changes.
*/
void drm_atomic_helper_async_commit(struct drm_device *dev,
struct drm_atomic_state *state)
@@ -1656,6 +1649,9 @@ void drm_atomic_helper_async_commit(stru
int i;
for_each_new_plane_in_state(state, plane, plane_state, i) {
+ struct drm_framebuffer *new_fb = plane_state->fb;
+ struct drm_framebuffer *old_fb = plane->state->fb;
+
funcs = plane->helper_private;
funcs->atomic_async_update(plane, plane_state);
@@ -1664,11 +1660,17 @@ void drm_atomic_helper_async_commit(stru
* plane->state in-place, make sure at least common
* properties have been properly updated.
*/
- WARN_ON_ONCE(plane->state->fb != plane_state->fb);
+ WARN_ON_ONCE(plane->state->fb != new_fb);
WARN_ON_ONCE(plane->state->crtc_x != plane_state->crtc_x);
WARN_ON_ONCE(plane->state->crtc_y != plane_state->crtc_y);
WARN_ON_ONCE(plane->state->src_x != plane_state->src_x);
WARN_ON_ONCE(plane->state->src_y != plane_state->src_y);
+
+ /*
+ * Make sure the FBs have been swapped so that cleanups in the
+ * new_state performs a cleanup in the old FB.
+ */
+ WARN_ON_ONCE(plane_state->fb != old_fb);
}
}
EXPORT_SYMBOL(drm_atomic_helper_async_commit);
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -1178,6 +1178,14 @@ struct drm_plane_helper_funcs {
* current one with the new plane configurations in the new
* plane_state.
*
+ * Drivers should also swap the framebuffers between current plane
+ * state (&drm_plane.state) and new_state.
+ * This is required since cleanup for async commits is performed on
+ * the new state, rather than old state like for traditional commits.
+ * Since we want to give up the reference on the current (old) fb
+ * instead of our brand new one, swap them in the driver during the
+ * async commit.
+ *
* FIXME:
* - It only works for single plane updates
* - Async Pageflips are not supported yet
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 68/70] drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (66 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 67/70] drm: dont block fb changes for async plane updates Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 69/70] drm/amd: fix fb references in async update Greg Kroah-Hartman
` (6 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Zhenyu Wang, Tina Zhang
From: Tina Zhang <tina.zhang@intel.com>
commit 387a4c2b55291b37e245c840813bd8a8bd06ed49 upstream.
Stack struct intel_gvt_gtt_entry value needs to be initialized before
being used, as the fields may contain garbage values.
W/o this patch, set_ggtt_entry prints:
-------------------------------------
274.046840: set_ggtt_entry: vgpu1:set ggtt entry 0x9bed8000ffffe900
274.046846: set_ggtt_entry: vgpu1:set ggtt entry 0xe55df001
274.046852: set_ggtt_entry: vgpu1:set ggtt entry 0x9bed8000ffffe900
0x9bed8000 is the stack grabage.
W/ this patch, set_ggtt_entry prints:
------------------------------------
274.046840: set_ggtt_entry: vgpu1:set ggtt entry 0xffffe900
274.046846: set_ggtt_entry: vgpu1:set ggtt entry 0xe55df001
274.046852: set_ggtt_entry: vgpu1:set ggtt entry 0xffffe900
v2:
- Initialize during declaration. (Zhenyu)
Fixes: 7598e8700e9a ("drm/i915/gvt: Missed to cancel dma map for ggtt entries")
Cc: stable@vger.kernel.org # v4.20+
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/gvt/gtt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -2178,7 +2178,8 @@ static int emulate_ggtt_mmio_write(struc
struct intel_gvt_gtt_pte_ops *ops = gvt->gtt.pte_ops;
unsigned long g_gtt_index = off >> info->gtt_entry_size_shift;
unsigned long gma, gfn;
- struct intel_gvt_gtt_entry e, m;
+ struct intel_gvt_gtt_entry e = {.val64 = 0, .type = GTT_TYPE_GGTT_PTE};
+ struct intel_gvt_gtt_entry m = {.val64 = 0, .type = GTT_TYPE_GGTT_PTE};
dma_addr_t dma_addr;
int ret;
struct intel_gvt_partial_pte *partial_pte, *pos, *n;
@@ -2245,7 +2246,8 @@ static int emulate_ggtt_mmio_write(struc
if (!partial_update && (ops->test_present(&e))) {
gfn = ops->get_pfn(&e);
- m = e;
+ m.val64 = e.val64;
+ m.type = e.type;
/* one PTE update may be issued in multiple writes and the
* first write may not construct a valid gfn
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 69/70] drm/amd: fix fb references in async update
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (67 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 68/70] drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 16:42 ` [PATCH 5.1 70/70] TTY: serial_core, add ->install Greg Kroah-Hartman
` (5 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Boris Brezillon, Helen Koike,
Nicholas Kazlauskas
From: Helen Koike <helen.koike@collabora.com>
commit 332af874db929f92931727bfe191b2c666438c81 upstream.
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().
Cc: <stable@vger.kernel.org> # v4.20+
Fixes: 674e78acae0d ("drm/amd/display: Add fast path for cursor plane updates")
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-3-helen.koike@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3789,8 +3789,7 @@ static void dm_plane_atomic_async_update
struct drm_plane_state *old_state =
drm_atomic_get_old_plane_state(new_state->state, plane);
- if (plane->state->fb != new_state->fb)
- drm_atomic_set_fb_for_plane(plane->state, new_state->fb);
+ swap(plane->state->fb, new_state->fb);
plane->state->src_x = new_state->src_x;
plane->state->src_y = new_state->src_y;
^ permalink raw reply [flat|nested] 81+ messages in thread* [PATCH 5.1 70/70] TTY: serial_core, add ->install
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (68 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 69/70] drm/amd: fix fb references in async update Greg Kroah-Hartman
@ 2019-06-09 16:42 ` Greg Kroah-Hartman
2019-06-09 22:37 ` [PATCH 5.1 00/70] 5.1.9-stable review Jiunn Chang
` (4 subsequent siblings)
74 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-09 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiri Slaby, Li RongQing, Wang Li, Zhang Yu
From: Jiri Slaby <jslaby@suse.cz>
commit 4cdd17ba1dff20ffc99fdbd2e6f0201fc7fe67df upstream.
We need to compute the uart state only on the first open. This is
usually what is done in the ->install hook. serial_core used to do this
in ->open on every open. So move it to ->install.
As a side effect, it ensures the state is set properly in the window
after tty_init_dev is called, but before uart_open. This fixes a bunch
of races between tty_open and flush_to_ldisc we were dealing with
recently.
One of such bugs was attempted to fix in commit fedb5760648a (serial:
fix race between flush_to_ldisc and tty_open), but it only took care of
a couple of functions (uart_start and uart_unthrottle). I was able to
reproduce the crash on a SLE system, but in uart_write_room which is
also called from flush_to_ldisc via process_echoes. I was *unable* to
reproduce the bug locally. It is due to having this patch in my queue
since 2012!
general protection fault: 0000 [#1] SMP KASAN PTI
CPU: 1 PID: 5 Comm: kworker/u4:0 Tainted: G L 4.12.14-396-default #1 SLE15-SP1 (unreleased)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c89-prebuilt.qemu.org 04/01/2014
Workqueue: events_unbound flush_to_ldisc
task: ffff8800427d8040 task.stack: ffff8800427f0000
RIP: 0010:uart_write_room+0xc4/0x590
RSP: 0018:ffff8800427f7088 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 000000000000002f RSI: 00000000000000ee RDI: ffff88003888bd90
RBP: ffffffffb9545850 R08: 0000000000000001 R09: 0000000000000400
R10: ffff8800427d825c R11: 000000000000006e R12: 1ffff100084fee12
R13: ffffc900004c5000 R14: ffff88003888bb28 R15: 0000000000000178
FS: 0000000000000000(0000) GS:ffff880043300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000561da0794148 CR3: 000000000ebf4000 CR4: 00000000000006e0
Call Trace:
tty_write_room+0x6d/0xc0
__process_echoes+0x55/0x870
n_tty_receive_buf_common+0x105e/0x26d0
tty_ldisc_receive_buf+0xb7/0x1c0
tty_port_default_receive_buf+0x107/0x180
flush_to_ldisc+0x35d/0x5c0
...
0 in rbx means tty->driver_data is NULL in uart_write_room. 0x178 is
tried to be dereferenced (0x178 >> 3 is 0x2f in rdx) at
uart_write_room+0xc4. 0x178 is exactly (struct uart_state *)NULL->refcount
used in uart_port_lock from uart_write_room.
So revert the upstream commit here as my local patch should fix the
whole family.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Li RongQing <lirongqing@baidu.com>
Cc: Wang Li <wangli39@baidu.com>
Cc: Zhang Yu <zhangyu31@baidu.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/serial_core.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -130,9 +130,6 @@ static void uart_start(struct tty_struct
struct uart_port *port;
unsigned long flags;
- if (!state)
- return;
-
port = uart_port_lock(state, flags);
__uart_start(tty);
uart_port_unlock(port, flags);
@@ -730,9 +727,6 @@ static void uart_unthrottle(struct tty_s
upstat_t mask = UPSTAT_SYNC_FIFO;
struct uart_port *port;
- if (!state)
- return;
-
port = uart_port_ref(state);
if (!port)
return;
@@ -1747,6 +1741,16 @@ static void uart_dtr_rts(struct tty_port
uart_port_deref(uport);
}
+static int uart_install(struct tty_driver *driver, struct tty_struct *tty)
+{
+ struct uart_driver *drv = driver->driver_state;
+ struct uart_state *state = drv->state + tty->index;
+
+ tty->driver_data = state;
+
+ return tty_standard_install(driver, tty);
+}
+
/*
* Calls to uart_open are serialised by the tty_lock in
* drivers/tty/tty_io.c:tty_open()
@@ -1759,11 +1763,8 @@ static void uart_dtr_rts(struct tty_port
*/
static int uart_open(struct tty_struct *tty, struct file *filp)
{
- struct uart_driver *drv = tty->driver->driver_state;
- int retval, line = tty->index;
- struct uart_state *state = drv->state + line;
-
- tty->driver_data = state;
+ struct uart_state *state = tty->driver_data;
+ int retval;
retval = tty_port_open(&state->port, tty, filp);
if (retval > 0)
@@ -2448,6 +2449,7 @@ static void uart_poll_put_char(struct tt
#endif
static const struct tty_operations uart_ops = {
+ .install = uart_install,
.open = uart_open,
.close = uart_close,
.write = uart_write,
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 5.1 00/70] 5.1.9-stable review
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (69 preceding siblings ...)
2019-06-09 16:42 ` [PATCH 5.1 70/70] TTY: serial_core, add ->install Greg Kroah-Hartman
@ 2019-06-09 22:37 ` Jiunn Chang
2019-06-10 5:57 ` Greg Kroah-Hartman
2019-06-10 6:03 ` Naresh Kamboju
` (3 subsequent siblings)
74 siblings, 1 reply; 81+ messages in thread
From: Jiunn Chang @ 2019-06-09 22:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable
On Sun, Jun 09, 2019 at 06:41:11PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.9 release.
> There are 70 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 Tue 11 Jun 2019 04:40:04 PM UTC.
> 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/v5.x/stable-review/patch-5.1.9-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-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
Compiled and booted. No regressions on x86_64.
THX
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 5.1 00/70] 5.1.9-stable review
2019-06-09 22:37 ` [PATCH 5.1 00/70] 5.1.9-stable review Jiunn Chang
@ 2019-06-10 5:57 ` Greg Kroah-Hartman
0 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-10 5:57 UTC (permalink / raw)
To: Jiunn Chang
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable
On Sun, Jun 09, 2019 at 05:37:37PM -0500, Jiunn Chang wrote:
> On Sun, Jun 09, 2019 at 06:41:11PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.9 release.
> > There are 70 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 Tue 11 Jun 2019 04:40:04 PM UTC.
> > 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/v5.x/stable-review/patch-5.1.9-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-5.1.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> > -------------
>
> Compiled and booted. No regressions on x86_64.
Thanks for testing and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH 5.1 00/70] 5.1.9-stable review
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (70 preceding siblings ...)
2019-06-09 22:37 ` [PATCH 5.1 00/70] 5.1.9-stable review Jiunn Chang
@ 2019-06-10 6:03 ` Naresh Kamboju
2019-06-10 14:26 ` Greg Kroah-Hartman
2019-06-10 8:52 ` Jon Hunter
` (2 subsequent siblings)
74 siblings, 1 reply; 81+ messages in thread
From: Naresh Kamboju @ 2019-06-10 6:03 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Sun, 9 Jun 2019 at 22:15, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.1.9 release.
> There are 70 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 Tue 11 Jun 2019 04:40:04 PM UTC.
> 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/v5.x/stable-review/patch-5.1.9-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-5.1.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: 5.1.9-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.1.y
git commit: 5b3d375b3838a28e769a56fdcb67d5422579d53b
git describe: v5.1.7-157-g5b3d375b3838
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.1-oe/build/v5.1.7-157-g5b3d375b3838
No regressions (compared to build v5.1.7)
No fixes (compared to build v5.1.7)
Ran 24361 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* network-basic-tests
* ltp-fs-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 5.1 00/70] 5.1.9-stable review
2019-06-10 6:03 ` Naresh Kamboju
@ 2019-06-10 14:26 ` Greg Kroah-Hartman
0 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-10 14:26 UTC (permalink / raw)
To: Naresh Kamboju
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Mon, Jun 10, 2019 at 11:33:43AM +0530, Naresh Kamboju wrote:
> On Sun, 9 Jun 2019 at 22:15, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 5.1.9 release.
> > There are 70 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 Tue 11 Jun 2019 04:40:04 PM UTC.
> > 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/v5.x/stable-review/patch-5.1.9-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-5.1.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.
Thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH 5.1 00/70] 5.1.9-stable review
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (71 preceding siblings ...)
2019-06-10 6:03 ` Naresh Kamboju
@ 2019-06-10 8:52 ` Jon Hunter
2019-06-10 14:25 ` Greg Kroah-Hartman
2019-06-10 14:45 ` Guenter Roeck
2019-06-10 22:01 ` shuah
74 siblings, 1 reply; 81+ messages in thread
From: Jon Hunter @ 2019-06-10 8:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings,
lkft-triage, stable, linux-tegra
On 09/06/2019 17:41, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.9 release.
> There are 70 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 Tue 11 Jun 2019 04:40:04 PM UTC.
> 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/v5.x/stable-review/patch-5.1.9-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-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.1:
12 builds: 12 pass, 0 fail
22 boots: 22 pass, 0 fail
32 tests: 32 pass, 0 fail
Linux version: 5.1.9-rc1-g5b3d375b3838
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 5.1 00/70] 5.1.9-stable review
2019-06-10 8:52 ` Jon Hunter
@ 2019-06-10 14:25 ` Greg Kroah-Hartman
0 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-10 14:25 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable, linux-tegra
On Mon, Jun 10, 2019 at 09:52:18AM +0100, Jon Hunter wrote:
>
> On 09/06/2019 17:41, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.9 release.
> > There are 70 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 Tue 11 Jun 2019 04:40:04 PM UTC.
> > 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/v5.x/stable-review/patch-5.1.9-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-5.1.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> All tests are passing for Tegra ...
>
> Test results for stable-v5.1:
> 12 builds: 12 pass, 0 fail
> 22 boots: 22 pass, 0 fail
> 32 tests: 32 pass, 0 fail
>
> Linux version: 5.1.9-rc1-g5b3d375b3838
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra30-cardhu-a04
Thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH 5.1 00/70] 5.1.9-stable review
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (72 preceding siblings ...)
2019-06-10 8:52 ` Jon Hunter
@ 2019-06-10 14:45 ` Guenter Roeck
2019-06-10 14:51 ` Greg Kroah-Hartman
2019-06-10 22:01 ` shuah
74 siblings, 1 reply; 81+ messages in thread
From: Guenter Roeck @ 2019-06-10 14:45 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
On Sun, Jun 09, 2019 at 06:41:11PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.9 release.
> There are 70 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 Tue 11 Jun 2019 04:40:04 PM UTC.
> Anything received after that time might be too late.
>
Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 351 pass: 351 fail: 0
Guenter
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 5.1 00/70] 5.1.9-stable review
2019-06-10 14:45 ` Guenter Roeck
@ 2019-06-10 14:51 ` Greg Kroah-Hartman
0 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-10 14:51 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
On Mon, Jun 10, 2019 at 07:45:03AM -0700, Guenter Roeck wrote:
> On Sun, Jun 09, 2019 at 06:41:11PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.9 release.
> > There are 70 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 Tue 11 Jun 2019 04:40:04 PM UTC.
> > Anything received after that time might be too late.
> >
> Build results:
> total: 159 pass: 159 fail: 0
> Qemu test results:
> total: 351 pass: 351 fail: 0
Thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH 5.1 00/70] 5.1.9-stable review
2019-06-09 16:41 [PATCH 5.1 00/70] 5.1.9-stable review Greg Kroah-Hartman
` (73 preceding siblings ...)
2019-06-10 14:45 ` Guenter Roeck
@ 2019-06-10 22:01 ` shuah
2019-06-11 7:21 ` Greg Kroah-Hartman
74 siblings, 1 reply; 81+ messages in thread
From: shuah @ 2019-06-10 22:01 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, shuah
On 6/9/19 10:41 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.9 release.
> There are 70 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 Tue 11 Jun 2019 04:40:04 PM UTC.
> 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/v5.x/stable-review/patch-5.1.9-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-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 5.1 00/70] 5.1.9-stable review
2019-06-10 22:01 ` shuah
@ 2019-06-11 7:21 ` Greg Kroah-Hartman
0 siblings, 0 replies; 81+ messages in thread
From: Greg Kroah-Hartman @ 2019-06-11 7:21 UTC (permalink / raw)
To: shuah
Cc: linux-kernel, torvalds, akpm, linux, patches, ben.hutchings,
lkft-triage, stable
On Mon, Jun 10, 2019 at 04:01:41PM -0600, shuah wrote:
> On 6/9/19 10:41 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.9 release.
> > There are 70 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 Tue 11 Jun 2019 04:40:04 PM UTC.
> > 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/v5.x/stable-review/patch-5.1.9-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-5.1.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 81+ messages in thread