This is the start of the stable review cycle for the 5.2.4 release.
There are 66 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun 28 Jul 2019 03:21:13 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.2.4-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.2.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.2.4-rc1
Damien Le Moal <[email protected]>
block: Limit zone array allocation size
Damien Le Moal <[email protected]>
sd_zbc: Fix report zones buffer allocation
Paolo Bonzini <[email protected]>
Revert "kvm: x86: Use task structs fpu field for user"
Jan Kiszka <[email protected]>
KVM: nVMX: Clear pending KVM_REQ_GET_VMCS12_PAGES when leaving nested
Paolo Bonzini <[email protected]>
KVM: nVMX: do not use dangling shadow VMCS after guest reset
Theodore Ts'o <[email protected]>
ext4: allow directory holes
Ross Zwisler <[email protected]>
ext4: use jbd2_inode dirty range scoping
Ross Zwisler <[email protected]>
jbd2: introduce jbd2_inode dirty range scoping
Ross Zwisler <[email protected]>
mm: add filemap_fdatawait_range_keep_errors()
Theodore Ts'o <[email protected]>
ext4: enforce the immutable flag on open files
Darrick J. Wong <[email protected]>
ext4: don't allow any modifications to an immutable file
Peter Zijlstra <[email protected]>
perf/core: Fix race between close() and fork()
Alexander Shishkin <[email protected]>
perf/core: Fix exclusive events' grouping
Song Liu <[email protected]>
perf script: Assume native_arch for pipe mode
Paul Cercueil <[email protected]>
MIPS: lb60: Fix pin mappings
Keerthy <[email protected]>
gpio: davinci: silence error prints in case of EPROBE_DEFER
Nishka Dasgupta <[email protected]>
gpiolib: of: fix a memory leak in of_gpio_flags_quirks()
Linus Walleij <[email protected]>
Revert "gpio/spi: Fix spi-gpio regression on active high CS"
Chris Wilson <[email protected]>
dma-buf: Discard old fence_excl on retrying get_fences_rcu for realloc
Jérôme Glisse <[email protected]>
dma-buf: balance refcount inbalance
Ido Schimmel <[email protected]>
mlxsw: spectrum: Do not process learned records with a dummy FID
Maor Gottlieb <[email protected]>
net/mlx5: E-Switch, Fix default encap mode
Petr Machata <[email protected]>
mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed
Michael Chan <[email protected]>
bnxt_en: Fix VNIC accounting when enabling aRFS on 57500 chips.
Aya Levin <[email protected]>
net/mlx5e: Fix error flow in tx reporter diagnose
Aya Levin <[email protected]>
net/mlx5e: Fix return value from timeout recover function
Saeed Mahameed <[email protected]>
net/mlx5e: Rx, Fix checksum calculation for new hardware
Eli Britstein <[email protected]>
net/mlx5e: Fix port tunnel GRE entropy control
Jakub Kicinski <[email protected]>
net/tls: reject offload of TLS 1.3
Jakub Kicinski <[email protected]>
net/tls: fix poll ignoring partially copied records
Frank de Brabander <[email protected]>
selftests: txring_overwrite: fix incorrect test of mmap() return value
Cong Wang <[email protected]>
netrom: hold sock when setting skb->destructor
Cong Wang <[email protected]>
netrom: fix a memory leak in nr_rx_frame()
Andreas Steinmetz <[email protected]>
macsec: fix checksumming after decryption
Andreas Steinmetz <[email protected]>
macsec: fix use-after-free of skb during RX
Nikolay Aleksandrov <[email protected]>
net: bridge: stp: don't cache eth dest pointer before skb pull
Nikolay Aleksandrov <[email protected]>
net: bridge: don't cache ether dest pointer on input
Nikolay Aleksandrov <[email protected]>
net: bridge: mcast: fix stale ipv6 hdr pointer when handling v6 query
Nikolay Aleksandrov <[email protected]>
net: bridge: mcast: fix stale nsrcs pointer in igmp3/mld2 report handling
Aya Levin <[email protected]>
net/mlx5e: IPoIB, Add error path in mlx5_rdma_setup_rn
Peter Kosyh <[email protected]>
vrf: make sure skb->data contains ip header to make routing
Christoph Paasch <[email protected]>
tcp: Reset bytes_acked and bytes_received when disconnecting
Eric Dumazet <[email protected]>
tcp: fix tcp_set_congestion_control() use from bpf hook
Eric Dumazet <[email protected]>
tcp: be more careful in tcp_fragment()
Takashi Iwai <[email protected]>
sky2: Disable MSI on ASUS P6T
Xin Long <[email protected]>
sctp: not bind the socket in sctp_connect
Marcelo Ricardo Leitner <[email protected]>
sctp: fix error handling on stream scheduler initialization
David Howells <[email protected]>
rxrpc: Fix send on a connected, but unbound socket
Heiner Kallweit <[email protected]>
r8169: fix issue with confused RX unit after PHY power-down on RTL8411b
Yang Wei <[email protected]>
nfc: fix potential illegal memory access
Jakub Kicinski <[email protected]>
net/tls: make sure offload also gets the keys wiped
Jose Abreu <[email protected]>
net: stmmac: Re-work the queue selection for TSO packets
Cong Wang <[email protected]>
net_sched: unset TCQ_F_CAN_BYPASS when adding filters
Andrew Lunn <[email protected]>
net: phy: sfp: hwmon: Fix scaling of RX power
John Hurley <[email protected]>
net: openvswitch: fix csum updates for MPLS actions
Lorenzo Bianconi <[email protected]>
net: neigh: fix multiple neigh timer scheduling
Florian Westphal <[email protected]>
net: make skb_dst_force return true when dst is refcounted
Baruch Siach <[email protected]>
net: dsa: mv88e6xxx: wait after reset deactivation
Justin Chen <[email protected]>
net: bcmgenet: use promisc for unsupported filters
Ido Schimmel <[email protected]>
ipv6: Unlink sibling route in case of failure
David Ahern <[email protected]>
ipv6: rt6_check should return NULL if 'from' is NULL
Matteo Croce <[email protected]>
ipv4: don't set IPv6 only flags to IPv4 addresses
Eric Dumazet <[email protected]>
igmp: fix memory leak in igmpv3_del_delrec()
Haiyang Zhang <[email protected]>
hv_netvsc: Fix extra rcu_read_unlock in netvsc_recv_callback()
Taehee Yoo <[email protected]>
caif-hsi: fix possible deadlock in cfhsi_exit_module()
Brian King <[email protected]>
bnx2x: Prevent load reordering in tx completion processing
-------------
Diffstat:
Makefile | 4 +-
arch/mips/jz4740/board-qi_lb60.c | 16 +--
arch/x86/include/asm/kvm_host.h | 7 +-
arch/x86/kvm/vmx/nested.c | 10 +-
arch/x86/kvm/x86.c | 4 +-
block/blk-zoned.c | 46 ++++---
drivers/dma-buf/dma-buf.c | 1 +
drivers/dma-buf/reservation.c | 4 +
drivers/gpio/gpio-davinci.c | 5 +-
drivers/gpio/gpiolib-of.c | 10 +-
drivers/net/caif/caif_hsi.c | 2 +-
drivers/net/dsa/mv88e6xxx/chip.c | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 3 +
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 7 +-
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 57 ++++-----
drivers/net/ethernet/marvell/sky2.c | 7 ++
drivers/net/ethernet/mellanox/mlx5/core/en.h | 1 +
.../ethernet/mellanox/mlx5/core/en/reporter_tx.c | 10 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 3 +
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 7 +-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 5 -
.../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 7 ++
.../net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 9 +-
.../net/ethernet/mellanox/mlx5/core/lib/port_tun.c | 23 +---
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 +
drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c | 16 +--
drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c | 10 ++
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 6 +
drivers/net/ethernet/realtek/r8169.c | 137 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 28 +++--
drivers/net/hyperv/netvsc_drv.c | 1 -
drivers/net/macsec.c | 6 +-
drivers/net/phy/sfp.c | 2 +-
drivers/net/vrf.c | 58 +++++----
drivers/scsi/sd_zbc.c | 104 +++++++++++-----
fs/ext4/dir.c | 19 ++-
fs/ext4/ext4_jbd2.h | 12 +-
fs/ext4/file.c | 4 +
fs/ext4/inode.c | 24 +++-
fs/ext4/ioctl.c | 46 ++++++-
fs/ext4/move_extent.c | 3 +-
fs/ext4/namei.c | 45 +++++--
fs/jbd2/commit.c | 23 +++-
fs/jbd2/journal.c | 4 +
fs/jbd2/transaction.c | 49 ++++----
include/linux/blkdev.h | 5 +
include/linux/fs.h | 2 +
include/linux/jbd2.h | 22 ++++
include/linux/mlx5/mlx5_ifc.h | 3 +-
include/linux/perf_event.h | 5 +
include/net/dst.h | 5 +-
include/net/tcp.h | 8 +-
include/net/tls.h | 1 +
kernel/events/core.c | 83 ++++++++++---
mm/filemap.c | 22 ++++
net/bridge/br_input.c | 8 +-
net/bridge/br_multicast.c | 23 ++--
net/bridge/br_stp_bpdu.c | 3 +-
net/core/filter.c | 2 +-
net/core/neighbour.c | 2 +
net/ipv4/devinet.c | 8 ++
net/ipv4/igmp.c | 8 +-
net/ipv4/tcp.c | 6 +-
net/ipv4/tcp_cong.c | 6 +-
net/ipv4/tcp_output.c | 13 +-
net/ipv6/ip6_fib.c | 18 ++-
net/ipv6/route.c | 2 +-
net/netfilter/nf_queue.c | 6 +-
net/netrom/af_netrom.c | 4 +-
net/nfc/nci/data.c | 2 +-
net/openvswitch/actions.c | 6 +-
net/rxrpc/af_rxrpc.c | 4 +-
net/sched/cls_api.c | 1 +
net/sched/sch_fq_codel.c | 2 -
net/sched/sch_sfq.c | 2 -
net/sctp/socket.c | 24 +---
net/sctp/stream.c | 9 +-
net/tls/tls_device.c | 10 +-
net/tls/tls_main.c | 4 +-
net/tls/tls_sw.c | 3 +-
tools/perf/builtin-script.c | 3 +-
tools/testing/selftests/net/txring_overwrite.c | 2 +-
82 files changed, 850 insertions(+), 335 deletions(-)
From: Jose Abreu <[email protected]>
[ Upstream commit 4993e5b37e8bcb55ac90f76eb6d2432647273747 ]
Ben Hutchings says:
"This is the wrong place to change the queue mapping.
stmmac_xmit() is called with a specific TX queue locked,
and accessing a different TX queue results in a data race
for all of that queue's state.
I think this commit should be reverted upstream and in all
stable branches. Instead, the driver should implement the
ndo_select_queue operation and override the queue mapping there."
Fixes: c5acdbee22a1 ("net: stmmac: Send TSO packets always from Queue 0")
Suggested-by: Ben Hutchings <[email protected]>
Signed-off-by: Jose Abreu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 28 ++++++++++++++--------
1 file changed, 18 insertions(+), 10 deletions(-)
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3048,17 +3048,8 @@ static netdev_tx_t stmmac_xmit(struct sk
/* Manage oversized TCP frames for GMAC4 device */
if (skb_is_gso(skb) && priv->tso) {
- if (skb_shinfo(skb)->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)) {
- /*
- * There is no way to determine the number of TSO
- * capable Queues. Let's use always the Queue 0
- * because if TSO is supported then at least this
- * one will be capable.
- */
- skb_set_queue_mapping(skb, 0);
-
+ if (skb_shinfo(skb)->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))
return stmmac_tso_xmit(skb, dev);
- }
}
if (unlikely(stmmac_tx_avail(priv, queue) < nfrags + 1)) {
@@ -3875,6 +3866,22 @@ static int stmmac_setup_tc(struct net_de
}
}
+static u16 stmmac_select_queue(struct net_device *dev, struct sk_buff *skb,
+ struct net_device *sb_dev)
+{
+ if (skb_shinfo(skb)->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)) {
+ /*
+ * There is no way to determine the number of TSO
+ * capable Queues. Let's use always the Queue 0
+ * because if TSO is supported then at least this
+ * one will be capable.
+ */
+ return 0;
+ }
+
+ return netdev_pick_tx(dev, skb, NULL) % dev->real_num_tx_queues;
+}
+
static int stmmac_set_mac_address(struct net_device *ndev, void *addr)
{
struct stmmac_priv *priv = netdev_priv(ndev);
@@ -4091,6 +4098,7 @@ static const struct net_device_ops stmma
.ndo_tx_timeout = stmmac_tx_timeout,
.ndo_do_ioctl = stmmac_ioctl,
.ndo_setup_tc = stmmac_setup_tc,
+ .ndo_select_queue = stmmac_select_queue,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = stmmac_poll_controller,
#endif
From: Jan Kiszka <[email protected]>
commit cf64527bb33f6cec2ed50f89182fc4688d0056b6 upstream.
Letting this pend may cause nested_get_vmcs12_pages to run against an
invalid state, corrupting the effective vmcs of L1.
This was triggerable in QEMU after a guest corruption in L2, followed by
a L1 reset.
Signed-off-by: Jan Kiszka <[email protected]>
Reviewed-by: Liran Alon <[email protected]>
Cc: [email protected]
Fixes: 7f7f1ba33cf2 ("KVM: x86: do not load vmcs12 pages while still in SMM")
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kvm/vmx/nested.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -210,6 +210,8 @@ static void free_nested(struct kvm_vcpu
if (!vmx->nested.vmxon && !vmx->nested.smm.vmxon)
return;
+ kvm_clear_request(KVM_REQ_GET_VMCS12_PAGES, vcpu);
+
vmx->nested.vmxon = false;
vmx->nested.smm.vmxon = false;
free_vpid(vmx->nested.vpid02);
From: Peter Kosyh <[email protected]>
[ Upstream commit 107e47cc80ec37cb332bd41b22b1c7779e22e018 ]
vrf_process_v4_outbound() and vrf_process_v6_outbound() do routing
using ip/ipv6 addresses, but don't make sure the header is available
in skb->data[] (skb_headlen() is less then header size).
Case:
1) igb driver from intel.
2) Packet size is greater then 255.
3) MPLS forwards to VRF device.
So, patch adds pskb_may_pull() calls in vrf_process_v4/v6_outbound()
functions.
Signed-off-by: Peter Kosyh <[email protected]>
Reviewed-by: David Ahern <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/vrf.c | 58 ++++++++++++++++++++++++++++++++----------------------
1 file changed, 35 insertions(+), 23 deletions(-)
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -165,23 +165,29 @@ static int vrf_ip6_local_out(struct net
static netdev_tx_t vrf_process_v6_outbound(struct sk_buff *skb,
struct net_device *dev)
{
- const struct ipv6hdr *iph = ipv6_hdr(skb);
+ const struct ipv6hdr *iph;
struct net *net = dev_net(skb->dev);
- struct flowi6 fl6 = {
- /* needed to match OIF rule */
- .flowi6_oif = dev->ifindex,
- .flowi6_iif = LOOPBACK_IFINDEX,
- .daddr = iph->daddr,
- .saddr = iph->saddr,
- .flowlabel = ip6_flowinfo(iph),
- .flowi6_mark = skb->mark,
- .flowi6_proto = iph->nexthdr,
- .flowi6_flags = FLOWI_FLAG_SKIP_NH_OIF,
- };
+ struct flowi6 fl6;
int ret = NET_XMIT_DROP;
struct dst_entry *dst;
struct dst_entry *dst_null = &net->ipv6.ip6_null_entry->dst;
+ if (!pskb_may_pull(skb, ETH_HLEN + sizeof(struct ipv6hdr)))
+ goto err;
+
+ iph = ipv6_hdr(skb);
+
+ memset(&fl6, 0, sizeof(fl6));
+ /* needed to match OIF rule */
+ fl6.flowi6_oif = dev->ifindex;
+ fl6.flowi6_iif = LOOPBACK_IFINDEX;
+ fl6.daddr = iph->daddr;
+ fl6.saddr = iph->saddr;
+ fl6.flowlabel = ip6_flowinfo(iph);
+ fl6.flowi6_mark = skb->mark;
+ fl6.flowi6_proto = iph->nexthdr;
+ fl6.flowi6_flags = FLOWI_FLAG_SKIP_NH_OIF;
+
dst = ip6_route_output(net, NULL, &fl6);
if (dst == dst_null)
goto err;
@@ -237,21 +243,27 @@ static int vrf_ip_local_out(struct net *
static netdev_tx_t vrf_process_v4_outbound(struct sk_buff *skb,
struct net_device *vrf_dev)
{
- struct iphdr *ip4h = ip_hdr(skb);
+ struct iphdr *ip4h;
int ret = NET_XMIT_DROP;
- struct flowi4 fl4 = {
- /* needed to match OIF rule */
- .flowi4_oif = vrf_dev->ifindex,
- .flowi4_iif = LOOPBACK_IFINDEX,
- .flowi4_tos = RT_TOS(ip4h->tos),
- .flowi4_flags = FLOWI_FLAG_ANYSRC | FLOWI_FLAG_SKIP_NH_OIF,
- .flowi4_proto = ip4h->protocol,
- .daddr = ip4h->daddr,
- .saddr = ip4h->saddr,
- };
+ struct flowi4 fl4;
struct net *net = dev_net(vrf_dev);
struct rtable *rt;
+ if (!pskb_may_pull(skb, ETH_HLEN + sizeof(struct iphdr)))
+ goto err;
+
+ ip4h = ip_hdr(skb);
+
+ memset(&fl4, 0, sizeof(fl4));
+ /* needed to match OIF rule */
+ fl4.flowi4_oif = vrf_dev->ifindex;
+ fl4.flowi4_iif = LOOPBACK_IFINDEX;
+ fl4.flowi4_tos = RT_TOS(ip4h->tos);
+ fl4.flowi4_flags = FLOWI_FLAG_ANYSRC | FLOWI_FLAG_SKIP_NH_OIF;
+ fl4.flowi4_proto = ip4h->protocol;
+ fl4.daddr = ip4h->daddr;
+ fl4.saddr = ip4h->saddr;
+
rt = ip_route_output_flow(net, &fl4, NULL);
if (IS_ERR(rt))
goto err;
From: Nikolay Aleksandrov <[email protected]>
[ Upstream commit e57f61858b7cf478ed6fa23ed4b3876b1c9625c4 ]
We take a pointer to grec prior to calling pskb_may_pull and use it
afterwards to get nsrcs so record nsrcs before the pull when handling
igmp3 and we get a pointer to nsrcs and call pskb_may_pull when handling
mld2 which again could lead to reading 2 bytes out-of-bounds.
==================================================================
BUG: KASAN: use-after-free in br_multicast_rcv+0x480c/0x4ad0 [bridge]
Read of size 2 at addr ffff8880421302b4 by task ksoftirqd/1/16
CPU: 1 PID: 16 Comm: ksoftirqd/1 Tainted: G OE 5.2.0-rc6+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Call Trace:
dump_stack+0x71/0xab
print_address_description+0x6a/0x280
? br_multicast_rcv+0x480c/0x4ad0 [bridge]
__kasan_report+0x152/0x1aa
? br_multicast_rcv+0x480c/0x4ad0 [bridge]
? br_multicast_rcv+0x480c/0x4ad0 [bridge]
kasan_report+0xe/0x20
br_multicast_rcv+0x480c/0x4ad0 [bridge]
? br_multicast_disable_port+0x150/0x150 [bridge]
? ktime_get_with_offset+0xb4/0x150
? __kasan_kmalloc.constprop.6+0xa6/0xf0
? __netif_receive_skb+0x1b0/0x1b0
? br_fdb_update+0x10e/0x6e0 [bridge]
? br_handle_frame_finish+0x3c6/0x11d0 [bridge]
br_handle_frame_finish+0x3c6/0x11d0 [bridge]
? br_pass_frame_up+0x3a0/0x3a0 [bridge]
? virtnet_probe+0x1c80/0x1c80 [virtio_net]
br_handle_frame+0x731/0xd90 [bridge]
? select_idle_sibling+0x25/0x7d0
? br_handle_frame_finish+0x11d0/0x11d0 [bridge]
__netif_receive_skb_core+0xced/0x2d70
? virtqueue_get_buf_ctx+0x230/0x1130 [virtio_ring]
? do_xdp_generic+0x20/0x20
? virtqueue_napi_complete+0x39/0x70 [virtio_net]
? virtnet_poll+0x94d/0xc78 [virtio_net]
? receive_buf+0x5120/0x5120 [virtio_net]
? __netif_receive_skb_one_core+0x97/0x1d0
__netif_receive_skb_one_core+0x97/0x1d0
? __netif_receive_skb_core+0x2d70/0x2d70
? _raw_write_trylock+0x100/0x100
? __queue_work+0x41e/0xbe0
process_backlog+0x19c/0x650
? _raw_read_lock_irq+0x40/0x40
net_rx_action+0x71e/0xbc0
? __switch_to_asm+0x40/0x70
? napi_complete_done+0x360/0x360
? __switch_to_asm+0x34/0x70
? __switch_to_asm+0x40/0x70
? __schedule+0x85e/0x14d0
__do_softirq+0x1db/0x5f9
? takeover_tasklets+0x5f0/0x5f0
run_ksoftirqd+0x26/0x40
smpboot_thread_fn+0x443/0x680
? sort_range+0x20/0x20
? schedule+0x94/0x210
? __kthread_parkme+0x78/0xf0
? sort_range+0x20/0x20
kthread+0x2ae/0x3a0
? kthread_create_worker_on_cpu+0xc0/0xc0
ret_from_fork+0x35/0x40
The buggy address belongs to the page:
page:ffffea0001084c00 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0
flags: 0xffffc000000000()
raw: 00ffffc000000000 ffffea0000cfca08 ffffea0001098608 0000000000000000
raw: 0000000000000000 0000000000000003 00000000ffffff7f 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888042130180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888042130200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff888042130280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff888042130300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888042130380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
Disabling lock debugging due to kernel taint
Fixes: bc8c20acaea1 ("bridge: multicast: treat igmpv3 report with INCLUDE and no sources as a leave")
Reported-by: Martin Weinelt <[email protected]>
Signed-off-by: Nikolay Aleksandrov <[email protected]>
Tested-by: Martin Weinelt <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/bridge/br_multicast.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -911,6 +911,7 @@ static int br_ip4_multicast_igmp3_report
int type;
int err = 0;
__be32 group;
+ u16 nsrcs;
ih = igmpv3_report_hdr(skb);
num = ntohs(ih->ngrec);
@@ -924,8 +925,9 @@ static int br_ip4_multicast_igmp3_report
grec = (void *)(skb->data + len - sizeof(*grec));
group = grec->grec_mca;
type = grec->grec_type;
+ nsrcs = ntohs(grec->grec_nsrcs);
- len += ntohs(grec->grec_nsrcs) * 4;
+ len += nsrcs * 4;
if (!ip_mc_may_pull(skb, len))
return -EINVAL;
@@ -946,7 +948,7 @@ static int br_ip4_multicast_igmp3_report
src = eth_hdr(skb)->h_source;
if ((type == IGMPV3_CHANGE_TO_INCLUDE ||
type == IGMPV3_MODE_IS_INCLUDE) &&
- ntohs(grec->grec_nsrcs) == 0) {
+ nsrcs == 0) {
br_ip4_multicast_leave_group(br, port, group, vid, src);
} else {
err = br_ip4_multicast_add_group(br, port, group, vid,
@@ -983,7 +985,8 @@ static int br_ip6_multicast_mld2_report(
len = skb_transport_offset(skb) + sizeof(*icmp6h);
for (i = 0; i < num; i++) {
- __be16 *nsrcs, _nsrcs;
+ __be16 *_nsrcs, __nsrcs;
+ u16 nsrcs;
nsrcs_offset = len + offsetof(struct mld2_grec, grec_nsrcs);
@@ -991,12 +994,13 @@ static int br_ip6_multicast_mld2_report(
nsrcs_offset + sizeof(_nsrcs))
return -EINVAL;
- nsrcs = skb_header_pointer(skb, nsrcs_offset,
- sizeof(_nsrcs), &_nsrcs);
- if (!nsrcs)
+ _nsrcs = skb_header_pointer(skb, nsrcs_offset,
+ sizeof(__nsrcs), &__nsrcs);
+ if (!_nsrcs)
return -EINVAL;
- grec_len = struct_size(grec, grec_src, ntohs(*nsrcs));
+ nsrcs = ntohs(*_nsrcs);
+ grec_len = struct_size(grec, grec_src, nsrcs);
if (!ipv6_mc_may_pull(skb, len + grec_len))
return -EINVAL;
@@ -1021,7 +1025,7 @@ static int br_ip6_multicast_mld2_report(
src = eth_hdr(skb)->h_source;
if ((grec->grec_type == MLD2_CHANGE_TO_INCLUDE ||
grec->grec_type == MLD2_MODE_IS_INCLUDE) &&
- ntohs(*nsrcs) == 0) {
+ nsrcs == 0) {
br_ip6_multicast_leave_group(br, port, &grec->grec_mca,
vid, src);
} else {
From: Alexander Shishkin <[email protected]>
commit 8a58ddae23796c733c5dfbd717538d89d036c5bd upstream.
So far, we tried to disallow grouping exclusive events for the fear of
complications they would cause with moving between contexts. Specifically,
moving a software group to a hardware context would violate the exclusivity
rules if both groups contain matching exclusive events.
This attempt was, however, unsuccessful: the check that we have in the
perf_event_open() syscall is both wrong (looks at wrong PMU) and
insufficient (group leader may still be exclusive), as can be illustrated
by running:
$ perf record -e '{intel_pt//,cycles}' uname
$ perf record -e '{cycles,intel_pt//}' uname
ultimately successfully.
Furthermore, we are completely free to trigger the exclusivity violation
by:
perf -e '{cycles,intel_pt//}' -e '{intel_pt//,instructions}'
even though the helpful perf record will not allow that, the ABI will.
The warning later in the perf_event_open() path will also not trigger, because
it's also wrong.
Fix all this by validating the original group before moving, getting rid
of broken safeguards and placing a useful one to perf_install_in_context().
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Cc: [email protected]
Cc: [email protected]
Fixes: bed5b25ad9c8a ("perf: Add a pmu capability for "exclusive" events")
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/perf_event.h | 5 +++++
kernel/events/core.c | 34 ++++++++++++++++++++++------------
2 files changed, 27 insertions(+), 12 deletions(-)
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1049,6 +1049,11 @@ static inline int in_software_context(st
return event->ctx->pmu->task_ctx_nr == perf_sw_context;
}
+static inline int is_exclusive_pmu(struct pmu *pmu)
+{
+ return pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE;
+}
+
extern struct static_key perf_swevent_enabled[PERF_COUNT_SW_MAX];
extern void ___perf_sw_event(u32, u64, struct pt_regs *, u64);
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2553,6 +2553,9 @@ unlock:
return ret;
}
+static bool exclusive_event_installable(struct perf_event *event,
+ struct perf_event_context *ctx);
+
/*
* Attach a performance event to a context.
*
@@ -2567,6 +2570,8 @@ perf_install_in_context(struct perf_even
lockdep_assert_held(&ctx->mutex);
+ WARN_ON_ONCE(!exclusive_event_installable(event, ctx));
+
if (event->cpu != -1)
event->cpu = cpu;
@@ -4358,7 +4363,7 @@ static int exclusive_event_init(struct p
{
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ if (!is_exclusive_pmu(pmu))
return 0;
/*
@@ -4389,7 +4394,7 @@ static void exclusive_event_destroy(stru
{
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ if (!is_exclusive_pmu(pmu))
return;
/* see comment in exclusive_event_init() */
@@ -4409,14 +4414,15 @@ static bool exclusive_event_match(struct
return false;
}
-/* Called under the same ctx::mutex as perf_install_in_context() */
static bool exclusive_event_installable(struct perf_event *event,
struct perf_event_context *ctx)
{
struct perf_event *iter_event;
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ lockdep_assert_held(&ctx->mutex);
+
+ if (!is_exclusive_pmu(pmu))
return true;
list_for_each_entry(iter_event, &ctx->event_list, event_entry) {
@@ -10922,11 +10928,6 @@ SYSCALL_DEFINE5(perf_event_open,
goto err_alloc;
}
- if ((pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE) && group_leader) {
- err = -EBUSY;
- goto err_context;
- }
-
/*
* Look up the group leader (we will attach this event to it):
*/
@@ -11014,6 +11015,18 @@ SYSCALL_DEFINE5(perf_event_open,
move_group = 0;
}
}
+
+ /*
+ * Failure to create exclusive events returns -EBUSY.
+ */
+ err = -EBUSY;
+ if (!exclusive_event_installable(group_leader, ctx))
+ goto err_locked;
+
+ for_each_sibling_event(sibling, group_leader) {
+ if (!exclusive_event_installable(sibling, ctx))
+ goto err_locked;
+ }
} else {
mutex_lock(&ctx->mutex);
}
@@ -11050,9 +11063,6 @@ SYSCALL_DEFINE5(perf_event_open,
* because we need to serialize with concurrent event creation.
*/
if (!exclusive_event_installable(event, ctx)) {
- /* exclusive and group stuff are assumed mutually exclusive */
- WARN_ON_ONCE(move_group);
-
err = -EBUSY;
goto err_locked;
}
From: Paul Cercueil <[email protected]>
commit 1323c3b72a987de57141cabc44bf9cd83656bc70 upstream.
The pin mappings introduced in commit 636f8ba67fb6
("MIPS: JZ4740: Qi LB60: Add pinctrl configuration for several drivers")
are completely wrong. The pinctrl driver name is incorrect, and the
function and group fields are swapped.
Fixes: 636f8ba67fb6 ("MIPS: JZ4740: Qi LB60: Add pinctrl configuration for several drivers")
Cc: <[email protected]>
Signed-off-by: Paul Cercueil <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Paul Burton <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: James Hogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/jz4740/board-qi_lb60.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/arch/mips/jz4740/board-qi_lb60.c
+++ b/arch/mips/jz4740/board-qi_lb60.c
@@ -466,27 +466,27 @@ static unsigned long pin_cfg_bias_disabl
static struct pinctrl_map pin_map[] __initdata = {
/* NAND pin configuration */
PIN_MAP_MUX_GROUP_DEFAULT("jz4740-nand",
- "10010000.jz4740-pinctrl", "nand", "nand-cs1"),
+ "10010000.pin-controller", "nand-cs1", "nand"),
/* fbdev pin configuration */
PIN_MAP_MUX_GROUP("jz4740-fb", PINCTRL_STATE_DEFAULT,
- "10010000.jz4740-pinctrl", "lcd", "lcd-8bit"),
+ "10010000.pin-controller", "lcd-8bit", "lcd"),
PIN_MAP_MUX_GROUP("jz4740-fb", PINCTRL_STATE_SLEEP,
- "10010000.jz4740-pinctrl", "lcd", "lcd-no-pins"),
+ "10010000.pin-controller", "lcd-no-pins", "lcd"),
/* MMC pin configuration */
PIN_MAP_MUX_GROUP_DEFAULT("jz4740-mmc.0",
- "10010000.jz4740-pinctrl", "mmc", "mmc-1bit"),
+ "10010000.pin-controller", "mmc-1bit", "mmc"),
PIN_MAP_MUX_GROUP_DEFAULT("jz4740-mmc.0",
- "10010000.jz4740-pinctrl", "mmc", "mmc-4bit"),
+ "10010000.pin-controller", "mmc-4bit", "mmc"),
PIN_MAP_CONFIGS_PIN_DEFAULT("jz4740-mmc.0",
- "10010000.jz4740-pinctrl", "PD0", pin_cfg_bias_disable),
+ "10010000.pin-controller", "PD0", pin_cfg_bias_disable),
PIN_MAP_CONFIGS_PIN_DEFAULT("jz4740-mmc.0",
- "10010000.jz4740-pinctrl", "PD2", pin_cfg_bias_disable),
+ "10010000.pin-controller", "PD2", pin_cfg_bias_disable),
/* PWM pin configuration */
PIN_MAP_MUX_GROUP_DEFAULT("jz4740-pwm",
- "10010000.jz4740-pinctrl", "pwm4", "pwm4"),
+ "10010000.pin-controller", "pwm4", "pwm4"),
};
stable-rc/linux-5.2.y boot: 129 boots: 1 failed, 83 passed with 45 offline (v5.2.3-67-gd61e440a1852)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.2.y/kernel/v5.2.3-67-gd61e440a1852/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.2.y/kernel/v5.2.3-67-gd61e440a1852/
Tree: stable-rc
Branch: linux-5.2.y
Git Describe: v5.2.3-67-gd61e440a1852
Git Commit: d61e440a1852a64d8a2d0d358b9582b19157e039
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 76 unique boards, 28 SoC families, 17 builds out of 209
Boot Failure Detected:
arm:
omap2plus_defconfig:
gcc-8:
omap4-panda: 1 failed lab
Offline Platforms:
riscv:
defconfig:
gcc-8
sifive_fu540: 1 offline lab
arm64:
defconfig:
gcc-8
meson-axg-s400: 1 offline lab
meson-g12a-u200: 1 offline lab
meson-g12a-x96-max: 1 offline lab
meson-gxbb-odroidc2: 1 offline lab
meson-gxl-s905d-p230: 1 offline lab
meson-gxl-s905x-libretech-cc: 1 offline lab
meson-gxl-s905x-nexbox-a95x: 1 offline lab
meson-gxl-s905x-p212: 1 offline lab
meson-gxm-nexbox-a1: 1 offline lab
rk3399-firefly: 1 offline lab
sun50i-a64-pine64-plus: 1 offline lab
mips:
pistachio_defconfig:
gcc-8
pistachio_marduk: 1 offline lab
arm:
exynos_defconfig:
gcc-8
exynos5250-arndale: 1 offline lab
exynos5420-arndale-octa: 1 offline lab
exynos5800-peach-pi: 1 offline lab
multi_v7_defconfig:
gcc-8
bcm72521-bcm97252sffe: 1 offline lab
bcm7445-bcm97445c: 1 offline lab
exynos5250-arndale: 1 offline lab
exynos5420-arndale-octa: 1 offline lab
exynos5800-peach-pi: 1 offline lab
imx6dl-wandboard_dual: 1 offline lab
imx6dl-wandboard_solo: 1 offline lab
imx6q-wandboard: 1 offline lab
imx7s-warp: 1 offline lab
meson8b-odroidc1: 1 offline lab
omap3-beagle: 1 offline lab
omap4-panda: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab
stih410-b2120: 1 offline lab
sun4i-a10-cubieboard: 1 offline lab
sun7i-a20-bananapi: 1 offline lab
vf610-colibri-eval-v3: 1 offline lab
omap2plus_defconfig:
gcc-8
omap3-beagle: 1 offline lab
omap4-panda: 1 offline lab
qcom_defconfig:
gcc-8
qcom-apq8064-ifc6410: 1 offline lab
davinci_all_defconfig:
gcc-8
da850-evm: 1 offline lab
dm365evm,legacy: 1 offline lab
imx_v6_v7_defconfig:
gcc-8
imx6dl-wandboard_dual: 1 offline lab
imx6dl-wandboard_solo: 1 offline lab
imx6q-wandboard: 1 offline lab
imx7s-warp: 1 offline lab
vf610-colibri-eval-v3: 1 offline lab
sunxi_defconfig:
gcc-8
sun4i-a10-cubieboard: 1 offline lab
sun7i-a20-bananapi: 1 offline lab
---
For more info write to <[email protected]>
On 7/26/19 9:23 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.4 release.
> There are 66 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun 28 Jul 2019 03:21:13 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.2.4-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.2.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions,
thanks,
-- Shuah
On Fri, 26 Jul 2019 at 20:55, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.2.4 release.
> There are 66 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun 28 Jul 2019 03:21:13 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.2.4-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.2.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.2.4-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.2.y
git commit: d61e440a1852a64d8a2d0d358b9582b19157e039
git describe: v5.2.3-67-gd61e440a1852
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.2-oe/build/v5.2.3-67-gd61e440a1852
No regressions (compared to build v5.2.3)
No fixes (compared to build v5.2.3)
Ran 22512 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
* network-basic-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-fs-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* kvm-unit-tests
--
Linaro LKFT
https://lkft.linaro.org
On Sat, Jul 27, 2019 at 11:05:04AM +0530, Naresh Kamboju wrote:
> On Fri, 26 Jul 2019 at 20:55, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.2.4 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun 28 Jul 2019 03:21:13 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.2.4-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.2.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
On Fri, Jul 26, 2019 at 08:33:27PM -0600, shuah wrote:
> On 7/26/19 9:23 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.2.4 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun 28 Jul 2019 03:21:13 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.2.4-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.2.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
On 7/26/19 8:23 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.4 release.
> There are 66 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun 28 Jul 2019 03:21:13 PM UTC.
> Anything received after that time might be too late.
>
Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 364 pass: 364 fail: 0
Guenter
On Sat, Jul 27, 2019 at 09:07:49AM -0700, Guenter Roeck wrote:
> On 7/26/19 8:23 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.2.4 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun 28 Jul 2019 03:21:13 PM UTC.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 159 pass: 159 fail: 0
> Qemu test results:
> total: 364 pass: 364 fail: 0
Thanks for testing all of these and letting me know.
greg k-h
On 26/07/2019 16:23, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.4 release.
> There are 66 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun 28 Jul 2019 03:21:13 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.2.4-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.2.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.2:
12 builds: 12 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 38 pass, 0 fail
Linux version: 5.2.4-gfc89179bfa10
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
On Mon, Jul 29, 2019 at 10:03:10AM +0100, Jon Hunter wrote:
>
> On 26/07/2019 16:23, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.2.4 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun 28 Jul 2019 03:21:13 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.2.4-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.2.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> All tests are passing for Tegra ...
>
> Test results for stable-v5.2:
> 12 builds: 12 pass, 0 fail
> 22 boots: 22 pass, 0 fail
> 38 tests: 38 pass, 0 fail
>
> Linux version: 5.2.4-gfc89179bfa10
> 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